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

[Ben Schwartz <[e-mail]>]

Thanks for that warning, Tony.  It sounds like we should stick to the
Additional section, and not alter the Answer contents.

I've tried to incorporate the feedback from this discussion into a proposed
change that avoids imposing new requirements, but enables the CNAME chain
optimizations identified by Brian Dickson and specifies SOA behavior as
proposed by Pieter Lexis:
https://github.com/MikeBishop/dns-alt-svc/pull/238/files?short_path=d44bc72#diff-d44bc722e745a4e66186057a4127f461

This change would replace Section 4.1 with the following text:

When replying to a SVCB query, authoritative DNS servers SHOULD return
any useful in-bailiwick records in the Additional section.  Authoritative
servers MAY implement this Additional section processing by applying the
following procedure to each returned SVCB record:

1. If TargetName is not in-bailiwick and is not ".", terminate the
procedure.
2. If SvcPriority is 0:
    * If TargetName is ".", terminate the procedure.
    * Otherwise, perform a SVCB "follow-up" query for TargetName and add all
      returned records, including any records added by this procedure.
      If any SVCB records were added, terminate.
3. Perform A and AAAA follow-up queries for TargetName (or for the owner
name if
   TargetName is "."), and add all returned records.

All follow-up queries MUST retain the original query's "DNSSEC OK" setting.

If the server does not complete this procedure (e.g. due to response size
limits), it MUST remove any SOA records from the Additional section.
Recursive resolvers MAY use the presence of an SOA record in the Additional
section to enable negative caching of the follow-up queries, as in
{{?RFC2308}}.

On Mon, Aug 10, 2020 at 6:17 PM Tony Finch <[e-mail]> wrote:

> Brian Dickson <[e-mail]> wrote:
> >
> > 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)
>
> I've only skimmed this thread, so I might be repeating something that's
> already agreed... but I want to emphasize that a new RR type specification
> will have impossible interop problems if it tries to put records in the
> ANSWER section that aren't expected by existing DNS software.
>
> "Unexpected" means anything that isn't part of a CNAME or DNAME chain on
> the way from the original query name to an RRset of the query type.
>
> If a resolver queries for the owner of SVCB record (or a CNAME pointing at
> one) then anything related to the RDATA of the SVCB record(s) has to go in
> the ADDITIONAL section, or there will be sadness.
>
> It was a very long time before DNAME was usable and even within the last
> 10 years there was software that would choke on DNAME records in the
> ANSWER section that it didn't expect.
>
> Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Shannon, Rockall: Variable 2 to 4. Moderate, occasionally slight. Drizzle.
> Moderate or poor.
>