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

[Pieter Lexis <[e-mail]>]

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