On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews <[email protected]> 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. 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, - followed optionally by an SVCB record set of only ServiceForm records. 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. 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. Clients should not be talking directly to Authoritative servers, 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. 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. 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. Each of those is going to be an atomic result with a single RCODE. 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). 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
