Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni <[e-mail]>]

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.