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

[Brian Dickson <[e-mail]>]

On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz <[e-mail]> wrote:

> Brian,
>
> I think arguing about the strength of the analogies to CNAME (Answer) vs
> SRV (Additional) is going to be a slow path to consensus.  Apart from that
> analogy, I'm not sure I understand your motivating use case.  Could you
> write a small example zone where you think the "chain in Answer" behavior
> has a clear advantage over "chain in Additional"?
>

Sure. Here are two very similar examples, where the first one I think is
required to put the entire chain in the Answer for ${reasons}. (Take as
ready any underscore prefixing needed to make this make sense...)

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-common-thing.example.com.
my-common-thing.example.com. CNAME my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

The motivation here is that the optimization of adding in-bailiwick records
should, to maximize the benefit to the resolver and to the authority
server, process the second CNAME of the first example.

However, if the placement of the in-bailiwick TargetName's records is in
the Additional section, this is somewhat more complex. Either the CNAME
processing has to happen before the TargetName and CNAME canonical name
records are collectively placed in the Additional section, or the
Additional section must now also process the CNAME. Not doing either of
those would leave a "dangling CNAME" in the Additional section, which would
then necessitate an additional query round-trip from the recursive to
authoritative.

Putting them all in the Answer section, means normal Answer section
handling would basically handle the second CNAME "for free".

This is all opportunistic behavior. It doesn't matter whether the extra
records are added or not, so their absence from either section does not
imply their non-existence, nor does it imply the authoritative server is
aware or unaware of SVCB.

I'm not sure I understand why having them be in the Answer section is any
different from having them be in the Additional section, when it comes to
their handling upon receipt by a recursive resolver.

If the rules were "Put any SVCB records into the Answer section along with
CNAME records found while obtaining them", then the only records that
should be in the Additional section would be A/AAAA records and related
DNSSEC records (and possibly CNAMEs found when obtaining the A/AAAA
records?).
I think this actually simplifies the processing:
The ServiceForm SVCB record(s) might not be present (based on whether the
authoritative is SVCB-aware and whether it is doing the addition of those
records), but IF they are present, they are in the Answer section.
This ALSO means that the only reason for anything being in the Additional
section is if there are A or AAAA records returned, which (hopefully)
implies the presence of a ServiceForm SVCB record.
The only other reason A/AAAA records should be in the Additional section,
is if there is a delegation, in which case there should be stuff in the
Authority section too.

So basically, it becomes:
AliasForm only in Answer -> not in-bailiwick, or not SVCB-aware. Either
way, another query is needed.
AliasForm plus Service Form in Answer -> Check Additional for A/AAAA
records, or query for them if not found
(Both of the above possibly also include CNAMEs in the chain)
CNAME chain only in the Answer -> not in bailiwick, need another query.
No Data in the Answer, Authority has a delegation -> follow the delegation,
possibly use Additional section for glue.

I think this is pretty simple logic, and I don't see the problem... could
you point out the problem if there is one?

Brian

>