On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote:
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> > won't be legitimate A/AAAA owner names (and shouldn't exist), and if a
> > client did that it would be harmful (to the client), at least a little
> > bit harmful (trying something that won't work.)
>
> (FWIW, I had trouble parsing this last bit.)
>
> Can the AliasMode record reference a name that includes attrleaf
> labels, such that this could be as non-functional as using the
> attrleaf-laden original $QNAME?
It can, but that would be a bad idea in general, unless one was
absolutely sure that there's a ServiceMode record at the target,
and that's all that the AliasMode record is for. And if A/AAAA
records for the qname fail to be discovered should a fallback
be attempted, all's well, since none were expected.
This touches on the RFC1123 question, which I think the WG did not want
to tackle (as too late for a substantive change) at this time.
But in any case, wheh there were no AliasMode records, and we're
using SVCB attrleaf prefixes for the original $QNAME, there really
was no intention to try that $QNAME as a fallback, as confirmed by
Ben (IIRC upthread at some point).
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
