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

[Mark Andrews <[e-mail]>]

> On 6 Aug 2020, at 04:51, 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.

-Infinity. Definitely not. 

>> (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.

> 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
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]