Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Dave Lawrence wrote: > > Could you please clarify explicitly what should happen in the case of > encountering CNAMEs? Or DNAMEs? I guess when I originally sketched a qname minimization algorithm https://mailarchive.ietf.org/arch/msg/dns-privacy/gAgGx9Zz6W0OfyRdJ0Rx7xxmHDg/ I intended that it would slot into the RFC 1034 resolver algorithm https://tools.ietf.org/html/rfc1034#section-4.3.2 which treats QNAME as a variable name rather than a protocol field, so the QNAME changes when the resolver chases a CNAME. That was probably a bad idea: on balance I think it's better to make a clear distinction between protocol fields and variables in algorithms. Elsewhere RFC 1034 uses SNAME for the variable containing the name we are searching for https://tools.ietf.org/html/rfc1034#section-5.3.3 which would be better if it hadn't used QNAME for the same thing elsewhere :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Easterly 6 to gale 8, becoming cyclonic 5 to 7. Rough or very rough, becoming moderate or rough later. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use
Paul Wouters wrote: > > The IETF / DNSOP should not recommend setting up private space TLDs by > instructing people how to do this. +1 Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher: West or northwest 4 to 6, becoming variable 2 to 4 later. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> On 4 Nov 2020, at 15:31, fujiw...@jprs.co.jp wrote: > > I submitted draft-fujiwara-dnsop-delegation-information-signer-00. > > Name: draft-fujiwara-dnsop-delegation-information-signer > Revision: 00 > Title:Delegation Information (Referrals) Signer for DNSSEC > Document date:2020-11-03 > Group:Individual Submission > Pages:6 > URL: > https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt > > DNSSEC does not have a function to validate delegation information. > I think it is a large missing peace of DNSSEC. > > I have a question why we did not include signature validation function > to delegation information ? Delegating NS records because the zone would become big and people didn’t want to have TLD zones have signatures for each delegation. We could sign delegating NS records as you can determine delegating vs top of zone by looking at the signer field of the NS RRset. You would then have to deal with the case where you have signed parent and unsigned child and a referral to the grand child. You would have to stop following the referral, verify the child is unsigned, then restart following the referral. This is a lot of work for very little benefit. Glue records would need a different signature type and would need to compute the signature differently to prevent it being used in a replay attack when the RRset differ. I suppose you could use the same algorithm as it would encourage people to keep data coherent. You would still have the parent, child, grandchild issues from above. If one wants to stop spoofed referrals being accepted do something like well known TSIG which will stop off path spoofed traffic dead. It will also stop off path reassembly attacks dead as the spoofed reassembled packet will be rejected. On path attackers can just race the server without DNSSEC. Chairs, can you issue a call for WG adoption of my well known TSIG draft please. > Probably, because it is non-authoritative information. > Or, because it was difficult to define the necessary and sufficient > delegation information. > > It is now widely agreed (although not explicitly documented) that the > delegation information is the information used for name resolution and > does not result in name resolution. > > We have a word "in-domain" glue which is the necessary and sufficient glue. > > And the idea may offer the signature for root priming data. It can’t. There is no requirement for addresses records for nameservers for a zone to exist in the zone, as glue or not, even if the nameservers are below top of zone. Glue is only required for delegations. > If someone interested the document, I would like time slot at dnsop WG > meeting. > > Regards, > > -- > Kazunori Fujiwara, JPRS > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
DNS is loosely coherent. DiS does not work when the sources of data are not coherent. -- Mark Andrews > On 5 Nov 2020, at 19:26, fujiw...@jprs.co.jp wrote: > > >> >> From: Mark Andrews One problem with DiS is that assumes that address records in the additional section *always* come from the delegating zone (see how the hash is created). This is not how DNS works. Address records can, correctly, come from other sources, even when the name is *below* the zone cut. Take a server that serves example.net and sub.child.example.net. That A record comes from sub.child.example.net not example.net when the name of the server is a.sub.example.net. child.example.net NS a.sub.example.net a.sub.example.net A 1.2.3.4 >> I ment >>child.example.net NS a.sub.child.example.net >>a.sub.child.example.net A 1.2.3.4 >> >> (which should have been obvious from the paragraph above) > > Do you mean these 2 lines in example.net zone ? >>child.example.net NS a.sub.child.example.net >>a.sub.child.example.net A 1.2.3.4 > > Then, we can generate DiS RR. > hash ( child.example.net NS | a.sub.child.example.net A). > > DNSSEC validators can get both "child.example.net NS a.sub.child.example.net" > and glue "a.sub.child.example.net A 1.2.3.4", > and validate child.example.net DiS RR. > > -- > Kazunori Fujiwara, JPRS > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
All, I have a few comments, focusing on the algorithm in section 3. > 3. Algorithm to Perform QNAME Minimisation > > This algorithm performs name resolution with QNAME minimisation in > the presence of zone cuts that are not yet known. > > Although a validating resolver already has the logic to find the > zone cuts, implementers of resolvers may want to use this algorithm > to locate the zone cuts. > > (0) If the query can be answered from the cache, do so; otherwise, > iterate as follows: > > (1) Get the closest delegation point that can be used for the > original QNAME/QTYPE combination from the cache. Shouldn't that be just "original QNAME" since the QTYPE should be irrelevant in locating zone cuts and delegation points? > > (1a) For queries with QTYPE=DS this is the NS RRset with the >owner matching the most labels with the QNAME stripped by >one label. The QNAME will be a subdomain of (but not equal >to) this NS RRset. Call this ANCESTOR. How confident are we that DS will remain the only RR with parent-side authoritative data? There was recently a proposal (draft-peetterr-dnsop-parent-side-auth-types) to reserve a range for types with this property, but I guess it was pretty quickly shot down. If a new authoritative-in-parent RR type is defined in the future, then would it need to update this specification? > > (1b) For queries with other original QTYPEs this is the NS RRset >with the owner matching the most labels with the QNAME. The >QNAME will be equal to or a subdomain of this NS RRset. >Call this ANCESTOR. > > (2) Initialise CHILD to the same as ANCESTOR. > > (3) If CHILD is the same as the QNAME, or if the CHILD is one label > shorter than the QNAME and the original QTYPE is DS, resolve the > original query using ANCESTOR's name servers, and finish. Throughout this section (and maybe elsewhere) the document should be consistent with "the CHILD" and "the QNAME" or just "CHILD" and "QNAME". My suggestion is to drop "the". > > (4) Otherwise, add a label from the QNAME to the start of CHILD. I'd like to see a lot more specificity here. e.g., not just "a label" but the next relevant label. Also Section 2.3 talks about appending more than one label per iteration in some cases, which isn't mentioned here. > > (5) Look for a cache entry for the RRset at CHILD with the original > QTYPE. If this entry is for an NXDOMAIN and the resolver has > support for [RFC8020], the NXDOMAIN can be used in response to > the original query, and stop. If the entry is for a NOERROR > answer (either positive or negative), go back to step 3. If the > entry is for an NXDOMAIN answer and the resolver does not support > RFC 8020, go back to step 3. I find this step somewhat confusing as written. My interpretation of it goes something like this: if A and B then X; if C then Y; if A and not B then Y; I would like to see it (if not the whole algorithm!) as a flow chart, or maybe pseudo-code? Wording like "an NXDOMAIN" and "the NXDOMAIN" is imprecise. It really means a cached response whose RCODE is NXDOMAIN. This talks about RCODES NXDOMAIN and NOERROR. What about others, SERVFAIL, REFUSED? Assumes they are never cached? Since NXDOMAIN means there are no RRsets of any type for the name, I would expect the (original) QTYPE to be irrelevant when looking for a cached NXDOMAIN response, especially in the RFC 8020 case. Instead of "If the entry is for a NOERROR answer (either positive or negative).." consider "If the cached response code is NOERROR (including NODATA)..." > > (6) Query for CHILD with the selected QTYPE using ANCESTOR's > name servers. The response can be: Using one of ANCESTOR's name servers? > > (6a) A referral. Cache the NS RRset from the authority section, >and go back to step 1. > > (6b) A NOERROR answer (either positive or negative). Cache this >answer, and go back to step 3. again consider "(including NODATA)" instead of "(either positive or negative)". > > (6c) If the resolver is doing RFC 8020 with strict NXDOMAIN, an >NXDOMAIN answer. Return an NXDOMAIN answer in response to >the original query, and stop. If the resolver does not >support RFC 8020, go back to step 3. This would be better as: (6c) An NXDOMAIN response. If the resolver supports RFC8020, return an NXDOMAIN response to the original query and stop. If the resolver does not support RFC8020, go to step 3. > > (6d) An answer with another RCODE, or no answer. Try another >name server at the same delegation point. Stop if none of >them are able to return a valid answer. This seems to be specifying (requiring?) some retry behavior. I don't know if or where resolver retry
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7816bis
I support publication of this document. I do have some "last call" feedback to share: Section 2, paragraph 4 states that "A resolver that implements QNAME minimisation changes the QNAME and QTYPE in queries directed to an authoritative nameserver that is not known to be responsible for the original QNAME". This is true, except when the QNAME and/or QTYPE are already in the preferred form. For instance, if the resolver prefers to send QTYPE=A, and the client has requested QTYPE=A, then no change is needed. For similar reasons, the change does not necessarily "hide" the QTYPE, but rather prevents an observer from distinguishing queries of one type from another. Suggested changes: "changes the QNAME and QTYPE" -> "obscures the QNAME and QTYPE" "to hide the original QTYPE" -> "to obscure the original QTYPE" Section 2.3, last paragraph: I believe the intent of this paragraph is to show how many labels to add during each iteration, but it would benefit from further precision. These questions stand out: "The number of QNAME minimization iterations is the difference between this closest nameserver and the incoming QNAME". This should read "… the delegation point for this closest nameserver", correct? But this isn’t the number of iterations in any case, it’s the number of labels that are still not exposed. It’s only the number of iterations if it's less than or equal to MAX_MINIMIZE_COUNT. "The number of labels that are not exposed yet now need to be divided over the iterations that are left (MAX_MINIMISE_COUNT – MINIMISE_ONE_LAB). The remainder of the division should be added to the last iteration". True, but this overlooks all the iterations in between. Based on the example, I’m assuming the idea is to allocate the labels that are left proportionally to the remaining iterations, rounding down. The text should also state whether the algorithm is mandatory or optional. 2119 key words would be helpful. Minor edits: Section 1.1, paragraph 1: "publicaiton" -> "publication" Section 2.3, last paragraph: "handles" -> "handled" Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews >>> One problem with DiS is that assumes that address records in the additional >>> section *always* come from the delegating zone (see how the hash is >>> created). >>> This is not how DNS works. Address records can, correctly, come from other >>> sources, even when the name is *below* the zone cut. >>> >>> Take a server that serves example.net and sub.child.example.net. That A >>> record >>> comes from sub.child.example.net not example.net when the name of the >>> server is >>> a.sub.example.net. >>> >>> child.example.net NS a.sub.example.net >>> a.sub.example.net A 1.2.3.4 > I ment > child.example.net NS a.sub.child.example.net > a.sub.child.example.net A 1.2.3.4 > > (which should have been obvious from the paragraph above) Do you mean these 2 lines in example.net zone ? > child.example.net NS a.sub.child.example.net > a.sub.child.example.net A 1.2.3.4 Then, we can generate DiS RR. hash ( child.example.net NS | a.sub.child.example.net A). DNSSEC validators can get both "child.example.net NS a.sub.child.example.net" and glue "a.sub.child.example.net A 1.2.3.4", and validate child.example.net DiS RR. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
