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

[Mark Andrews <[e-mail]>]

> On 7 Aug 2020, at 11:54, Brian Dickson <[e-mail]> wrote:
> 
> 
> 
> On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews <[e-mail]> wrote:
> 
> 
> 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.
> 
> I don't think this actually changes the spec, only clarifies it or fixes errors. It doesn't change wire format or presentation format, nor does it change the logical resolution tree. It only proposes a change to where the authoritative server should place RRs when QTYPE is found. It does so to maintain consistency with the general processing rules from 1034. That it happens to very closely align with parts of the CNAME rules, is a happy coincidence.

No, it doesn’t maintain consistency with RFC 1034.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

If you want to treat SVBC and HTTPS as CNAMES then lets do that.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a SINGLE SVCB in AliasForm,
	    and QTYPE doesn’t match SVBC, copy the SVCB RR into the
	    answer section of the response, change QNAME to the target
	    name in the SVCB RR, and go back to step 1.

	    If the data at the node is SVBC and the 

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

> But, this is the correct time to fix lingering issues that require clarification or correction. The latest rev, which includes substantial changes, is only a few weeks old (early June to early August).
> 
> Here's a run-down of how I see the more explicit summary of what an authoritative server should do:
> 
> An authority server should (in response to an SVCB query) return, at most
> 	• a single sequence of zero or more CNAMEs (with a 1:1 linkage from RDATA to owner once the chain is normalized), which must be in the Answer section
> 	• followed optionally by an SVCB record set of only AliasForm records, 

Sorry you just broke DNSSEC if there are more than one AliasForm records.  More than one is permitted with the same name.

> 	• followed optionally by an SVCB record set of only ServiceForm records.

Well this at the minimum would be a RRset and possibly multiple RRsets.

> These would all necessarily be in the Answer section, as they all are (a) in-bailiwick, and (b) match the QTYPE (or are CNAMEs and as per RFC 1034 required to be in the Answer section). 
> The above statement is ONLY in reference to recursive-to-authority query/response packets.
> 
> Note: section 2.4.1 talks about AliasMode, but does not refer to Answer vs Additional sections at all.

When there was already clear instructions to add records to the Additional section why would it?

> It only specifies the logical relationship between owner names and TargetNames and SVCB types.
> Note: Section 4.1 (Authoritative Servers) is only one paragraph long. IMHO, this is the part that is way under-specified. It also appears to be conflating the Additional section placement with what the Client expects.

The clients will expect what we tell them to expect.

> Clients should not be talking directly to Authoritative servers,

Garbage.

> so it might be a legitimate error that needs to be fixed. The overall placement of what should be an Answer, in the Additional section (i.e. when QTYPE == SVCB and RRTYPE returned == SVCB) is at odds with RFC 1034, IMNSHO.

The DNS says if there are records of the given type at this name return them (this applies to CNAMES as well).
If you happen to encounter a CNAME (and you are not asking for a CNAME) restart the query with the CNAME target.

> NB: If (and only if) there are in-bailiwick A/AAAA records which are also resolved from the AliasForm records, those would need to be in the Additional section; this is not something I dispute in any way.
> Also NB: If TargetName names can be CNAME owner names (see below), it's not entirely clear whether those should go in the Answer section or Additional section. My initial opinion on this is, it's really Additional section processing, as there was no rewriting of the QNAME itself involved, so put it in the Additional section.
> Also NB: If an authority server happened to be authoritative for multiple zones, any SVCB records of either form from the non-in-bailiwick zone(s), if included at all, ,should be in the Additional section. (The spec doesn't mention authoritative servers that are authoritative for multiple zones, so my assumption would be that adding these should be explicitly excluded by the spec (but is not), or their treatment should be explicitly outlined by the spec as belonging in the Additional section.)
> 
> So, to address your other questions:
> How a recursive responds to a client is something else entirely; whether and where SVCB records get returned might be an implicit signal for understanding SVCB as something other than "unknown" record types. Putting everything into the Additional section would be okay, but really only if the recursive knew the client was an actual end system, and not another resolver in "forwarder" mode. A more conservative approach would be to put all the received Answer sections in the Answer section, and all the Additional sections in the additional section.

Really the question is are you answering authoritatively or recursively.  See RD and RA. That is actually different to are you authoritative for the QNAME or not.

> I don't think the graph process depends on where the authoritative puts the answers to a single query... you have to deal with the results either way.

But if does when the result will be different rcodes.

> Each of those is going to be an atomic result with a single RCODE.

Nope.  Can’t be.

> This actually provides stronger support for AliasMode treatment being the same as CNAME treatment.
> If an authoritative server is adding in-bailiwick data, and gets to a TargetName which is (a) in-bailiwick, but (b) a non-existent name, this should get the RCODE=3 treatment (same as if a CNAME canonical name was in-bailiwick but was a non-existent name).

And how do you do that with a graph?  This is the multiple QNAME problem.

> An authoritative server providing an answer would, by definition, not SERVFAIL, so the question there is moot.
> How you handle references between zones is orthogonal. You have either walked the graph to a successful answer, or you have not.
> If you have, do whatever the rest of the DNS protocol specs say to do. I think that ends up being: return the appropriate data in the appropriate section(s) if you get an answer. Otherwise, return the appropriate stuff (either NOERROR, NODATA, or the last non SERVFAIL answer, or SERVFAIL, I think.)
>  
> 
> 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.
> 
> The key word there is "supposed to believe". It may not be the case that all the errors have already been caught.
> That's why the WG is supposed to review the draft, and provide feedback, including on any semantic, structural, logic, or language errors or nits.
> This is better categorized as "how the nameserver does what it does" changes, rather than "what the nameserver does”.
>  
> 
> 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.
> 
> I'm not comparing to QTYPE == CNAME. I'm comparing it to QTYPE != CNAME, with the constraint here that the processing treat AliasForm SVCB analogously to the AliasForm SVCB actually being a CNAME record. I.e. acting as an "apex CNAME" which is not something that the DNS RFCs support. So, this constrained "CNAME-like" behavior is being proposed SPECIFICALLY because it isn't something that could ever have been done with an actual CNAME.
> The fact that the original DNS RFCs make it impossible, does not rule out re-using the same semantic rules for this use case. I would argue, the exact opposite is the case -- the absence of any way of accomplishing this aliasing at an apex, is EXACTLY why treating SVCB AliasForm at the apex "as if" it were a CNAME is the correct approach to use.
> 
> Clearly, it has no bearing on the behavior of any other QTYPEs.
>  
> 
> 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.
> 
> Then the current draft needs work, because it has inconsistencies (or errors, depending on how you look at them), that currently differ from what you like.
> 
> So, specifically:
> 2.4.1, paragraph 2, sentence 2: 
> In AliasMode, TargetName MUST be
> the name of a domain that has SVCB, AAAA, or A records 
> However, same section, a few paragraphs later, we get the following sentence:
> Note that the SVCB record's owner name MAY be the canonical name of a 
> CNAME record, and the TargetName MAY be the owner of a CNAME record. 
> 
> I'm good with either of these, but obviously it has to be one or the other -- possibly a CNAME, or never a CNAME.
> 
> Brian

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