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

[Brian Dickson <[e-mail]>]

On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman <[e-mail]> wrote:

> On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni <[e-mail]>
> wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the authority
> > endpoint's port number, and no SvcParams.  (This endpoint will be
> > attempted before falling back to non-SVCB connection modes.  This
> ensures that
> > SVCB-optional clients will make use of an AliasMode record whose
> TargetName has
> > A and/or AAAA records but no SVCB records.)
>
> What happens under the current wording, before the addition above? That
> is, if no AliasMode record was processed, is the addition along the lines
> of "you can only add this if you have it, and if no AliasMode record was
> processed, you don't have it"? Or does the addition solve the problem "if
> no AliasMode record was processed, the thing you append will be harmful"?
>

Yes.

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.)

If instead of the initial $QNAME, the origin name (and port) are added to
the end of the list, that is literally the exact same thing as non-SVCB
connection mode, so adding that to the list would be moot.

Brian