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

[Mark Andrews <[e-mail]>]

> On 7 Aug 2020, at 04:03, Brian Dickson <[e-mail]> wrote:
> 
> 
> 
> On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews <[e-mail]> wrote:
> 
> 
> I really don’t know how this thread got started with clear and unambiguous instructions to add all the records to the additional section.
> 
> The possibility of changing what is specified in the draft, was what started this thread.
> Your responses all suppose that it is not possible to change what is specified in the draft.
> It would be helpful (IMHO) to the conversation to give consideration to the contents of the thread, from the perspective that the specs in the draft are not absolutely set in stone and immutable.
> 
> Here's the quote from Ben:
> I think Section 4.1 is pretty clear that everything goes in the Additional section.  (But this can be changed!) 
>  
> 
> "Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records) and return them in the Additional Section of the response. Clients either use responses included in the additional section returned by the recursive resolver or perform necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional Section to responses for a SVCB query."
> 
> Yes this means you need may need to change additional section process to chase other records.  Named was already doing this for one type and with HTTPS and SVCB needing we made the processing general.  Yes, it also means that one has to add CNAMEs to the additional section when processing HTTPS or SVBC.
> 
> 
> We can all read, and we understand what the current draft says.
> That's NOT what is being discussed (how to interpret those words).
> What IS being discussed in this thread is whether it may be more sensible to align the process of handling the "alias" form in a manner more consistent with how CNAME processing happens.
> It is a proposal to change the spec itself, rather than an alternate interpretation of what the current draft of the spec says.
> 
> This is why I suggested that, while it is not CNAME per se, treating it as "constrained alias applicable only to SVCB queries" isn't a huge leap, and would simplify the code for handling alias form, on both the server and client side of a lookup.
> 
> If the standard says they belong in the Answer section (as I am suggesting), I think the expected BIND client-side handling of SVCB records (alias and non-alias, if in-bailiwick) and CNAME records if they are both placed in the answer section by the server should be okay, in both situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB handling logic is added.
> 
> Brian

What benefit is there in changing this now?  Moving the SVBC chain (graph actually) to the answer section.  I know I can follow a graph much easier in the additional section than I can in the answer section with simple depth limited recursion.  In the answer section I have to initiate multiple parallel recursions to complete the graph hitting different zones. What happens when one of those recursions fail? Do I return a partial answer? Do I SERVFAIL the entire query?  What if one returns NXDOMAN? With everything in the addition section those questions go away.  I return what I have.  I can initiate speculative queries for missing RRsets where I don’t have NODATA/NXDOMAIN cached so when the client comes back I have the response in cache.

The code point has been allocated.  Implementations have been written to the existing spec.  That’s what happens when you ask for a code point. You are saying:
* This is its wire form.
* This is its presentation form. 
* This is what the nameserver does. 
Now we can go play with the rest of the specification and tidy that up with nameservers that know about the code point. Working group chairs are supposed to believe the specification is in this state of readiness before asking for a early code point.

If you want to compare to CNAME and query for CNAME you get back exactly 1 CNAME record even if there is a chain of CNAME records.  The target is not followed.  This is RFC 1034 behaviour.

What I would like is for SVCB alias form to ONLY require looking for SVCB records and SVCB service mode to only require looking up address records.  At the moment there is a scatter gun approach though I may have missed something.  CNAME/DNAME records are found as a side effect of looking for other types.

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