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

[Pieter Lexis <[e-mail]>]

On 8/5/20 11:13 PM, Mark Andrews wrote:
>> On 6 Aug 2020, at 04:51, Pieter Lexis <[e-mail]> wrote:
>> On 8/5/20 8:03 PM, Brian Dickson wrote:
>>> (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).
>
> You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
> if it exists at the QNAME or you will get NODATA if neither exists.
If you
> find a CNAME you repeat at the target of the CNAME.
>
> If the server is SVCB aware it will then process the SVCB RRset and
add those
> records to the additional section, if any of those trigger additional
section
> processing those records too get added to the additional section.  This is
> consistent with STD 13 that says words to the effect of “add anything
useful” (I’m
> not going to look up the exact words).  The additional section rules
for SVCB say
> to add CNAME, SVCB, A and AAAA to the additional section.

The semantic rules for the Alias form lead me to believe that an SVCB at
the targetname *is* an answer to the question (no other SVCB at that
ownername, at the very least no Service mode SVCB at that name).

The end-clients (browsers, other programs actually querying for
SVCB/HTTPS)

Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
recursor might accept the data in the answer section:

  […]
  + Data from the answer section of a non-authoritative answer, and
    non-authoritative data from the answer section of authoritative
    answers,
  + Additional information from an authoritative answer,
    Data from the authority section of a non-authoritative answer,
    Additional information from non-authoritative answers.

On the other hand, a non-SVCB-aware resolver might even choose to drop
both the data in the ANSWER and ADDITIONAL section that do not match the
original QNAME. Thus only serving its client the SVCB alias record in
the ANSWER section, leading to the end-client re-querying for the
targetname SVCB record.

It would be good to know what most implementations do when they
encounter in-bailiwick data with a different owner name in both the
ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
method:

 * Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
 * Backwards compatible (All related data in ADDITIONAL)

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com