Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

[Ben Schwartz <[e-mail]>]

Thanks for the review!  I'd appreciate it if other authoritative server
implementors could comment on this proposal.  If they agree then I'm happy
to make this change.

On Wed, Aug 5, 2020 at 2:51 PM Pieter Lexis <[e-mail]>
wrote:

> On 8/5/20 8:03 PM, Brian Dickson wrote:
> >
> >
> > On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz
> > <bemasc=[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis
> >     <[e-mail] <mailto:[e-mail]>>
> wrote:
> >     ...
> >
> >     Conceptually, AliasMode is not a CNAME: it only affects SVCB queries
> >     (not other RR types), and can safely be implemented entirely as an
> >     RFC 3597 Unknown RR Type.  That suggests that it is at least safe,
> >     and perhaps least-surprising, for the authoritative server to put
> >     all responses for other owner names in the Additional section, as
> >     the current text seems to indicate fairly clearly.
> >
> >
> > I beg to differ, in that I would view AliasMode as a constrained CNAME.
>
> I agree with Brian here. Compliant DNS servers (be it auth or recursor)
>  MUST treat an Alias-mode SVCB (or derived) record as a CNAME for the
> purposes of processing that SVCB or derived record.
>
> i.e. foo.example.com SVCB 0 srv1.example.net == (logically)
> foo.example.com CNAME srv1.example.com when QType = SVCB, but not for
> any other QType.
>
> > What I would suggest is the following, paraphrased (i.e. please clean it
> > up before using in the I-D, if you agree it's the right semantics):
> >
> >   * In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and
> >     for CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be
> >     iteratively processed for inclusion)
> >   * CNAME and SVCB records MUST be placed in the Answer section (because
> >     of existing CNAME rules and because of RRTYPE match to the query)
> >   * A and AAAA records MUST be placed in the Additional section (since
> >     those would not match the query RRTYPE of SVCB)
>
> +1 to this summary. It reflects how I see the semantics of alias mode as
> well.
>
> > (I am not sure of the question/issue of including the SOA, or where that
> > would go, but I'll defer to anyone who knows or has an opinion. My gut
> > says, do whatever gets done for CNAME.)
>
> The SOA MUST go in the packet. As a compliant resolver talking to an
> auth that does not implement SVCB will follow the chain and the auth
> will respond with NODATA (and thus the SOA).
>
> After reading section 4.2, I also think that a resolver that implements
> this MUST include the SOA as well if the final target has no SVCB
> record, to indicate that the answer to the actual question
> (example.com|SVCB) yielded NODATA after alias chaining. A compliant
> client can ignore the fact that the DNS says NODATA and use the A/AAAA
> records from the ADDITIONAL section (or send a query for them based on
> the final target).
>
> > All the in-bailiwick stuff is essentially an optimization. Authority
> > servers may not implement that, and would still be compliant if they did
> > not.
> > Resolvers MUST be prepared to handle the non-inclusion of in-bailiwick
> > stuff from authority servers, as this would not be an error or violation
> > of the (eventual) RFC.
>
> Yes.
>
> >     P..S. The text on this point has recently
> >     changed:
> https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971.
> >     One of the questions there is what should happen for
> >     AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft
> >     says "Clients and recursive resolvers MUST follow CNAMEs as
> >     normal.", but it no longer says anything about authoritatives.
> >
> >
> > IMHO, I think this is correct, or at least consistent with what I wrote
> > above. (If there are any inconsistencies, could you highlight what those
> > would be, please?)
>
> I believe you are correct.
>
>
> Cheers,
>
> Pieter
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
>