Re: [DNSOP] terminology: glue
On May 5, 2015, at 7:45 AM, Tony Finch d...@dotat.at wrote: Casey Deccio ca...@deccio.net wrote: Glue records -- [Records] which are not part of the authoritative data [for a zone], and are address resource records for the servers [in a subzone]. These RRs are only necessary if the name server's name is 'below' the cut, and are only used as part of a referral response. Without glue we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. (Definition from RFC 1034, section 4.2.1) A later definition is that glue includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, , etc), and any other stray data that might appear ([RFC2181], section 5.4.1). Although glue is sometimes used today with this wider definition in mind, the context surrounding the RFC 2181 definition suggests it is intended to apply to the use of glue within document itself and not necessarily beyond. I like this wording. Seems OK to me, and I like the fact that it keeps puts the quotations in context. Are there any objections? Re other stray data, can we conclude if it includes or excludes occluded records (as in RFC 6672 section 5.2 and RFC 2136 paragraph 7.18)? I propose that we don't try to over-analyze RFC 2181 here, given that we are using the RFC 1034 definition as the more important one. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] terminology: glue
On Mon, May 4, 2015 at 10:32 AM, Casey Deccio ca...@deccio.net wrote: within document itself and not necessarily beyond. typo: there should be a the after within. Casey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] terminology: glue
Casey Deccio ca...@deccio.net wrote: Glue records -- [Records] which are not part of the authoritative data [for a zone], and are address resource records for the servers [in a subzone]. These RRs are only necessary if the name server's name is 'below' the cut, and are only used as part of a referral response. Without glue we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. (Definition from RFC 1034, section 4.2.1) A later definition is that glue includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, , etc), and any other stray data that might appear ([RFC2181], section 5.4.1). Although glue is sometimes used today with this wider definition in mind, the context surrounding the RFC 2181 definition suggests it is intended to apply to the use of glue within document itself and not necessarily beyond. I like this wording. Re other stray data, can we conclude if it includes or excludes occluded records (as in RFC 6672 section 5.2 and RFC 2136 paragraph 7.18)? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle: Easterly 4 or 5 becoming cyclonic 6 to gale 8, occasionally severe gale 9 later in west. Moderate becoming rough or very rough, then high later in far west. Rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
[ Top post] Only replying to the biggest issue here, will reply to the rest later today. On Mon, May 4, 2015 at 2:25 PM, 神明達哉 jin...@wide.ad.jp wrote: At Mon, 27 Apr 2015 18:58:10 -0400, Tim Wicinski tjw.i...@gmail.com wrote: This starts a Working Group Last Call for Adoption for draft-ietf-dnsop-negative-trust-anchors (I guess this is for Publication, not for Adoption). Also, have we decided to publish it as an Informational document? I'm not opposed to it, but this document contains some normative text and affects inseparability in some sense, so a standard truck seems to be a more appropriate choice for me. Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04 Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons I do not think it's ready for publication yet. I'd like to see a discussion on whether it really makes sense that an NTA for a domain name even disables a positive trust anchor below the name. I made more specific comment on this in a separate message: http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html (with some other comments on the 04 version of the draft). So, I got a little confused by this comment (because that isn't what I'd meant to say), and so went back to Jinmei's comments on -04... and realized that I'd misunderstood one of them (I'd missed the positive in the question). The way that our resolver works is that the closest TA would win, and so a positive TA under a negative trust anchor *would* be used. To me this seems to be the obviously right thing to do, and so, unless anyone objects, I'll add text to the document stating that. So, in summary, a configured *positive* trust anchor for good.subdomain.example would override a negative trust anchor for .example. This seems to very much be in keeping with the principle of least surprise... W I also think Appendix B needs more editorial cleanups. Those editorial matters may not be a showstopper by themselves, but I guess it's better to fix them before sending it to the IESG. A couple of other comments on version 4: - Section 4: It is therefore recommended that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the I guess this 'recommended' may be better RFC2119 capitalized, i.e., RECOMMENDED. Not a strong opinion, but it seems to me to be more aligned with general tone and other usage of RFC2119 keywords of this section. - Section 4: likewise, maybe s/should/SHOULD/ When removing the NTA, the implementation should remove all cached entries below the NTA node. Editorial and minor comments: - Section 3: there's an awkward blank line (and spaces) before the reference: names for a Negative Trust Anchor. For example, Unbound calls their configuration domain-insecure. [Unbound-Configuration] - Section 7.1: s/has have/has/ Thus, there may be a gap between when a domain has have been re- - Appendix B: s/servers/server's/ (?) domain is consistency and history. It therefore is good if you have the ability to look at the servers DNS traffic over a long period of - Appendix B: s/them install/install them/ most of these tools are open source so you can them install locally if you want. - Appendix B: this sentence doesn't parse well to me... Using the tools over the Internet has the advantage though that as these are not located in the same part of the network you already will have more than local view by using different tools. - Appendix B: s/server.s/servers./ consistently around the world and from all authoritative server.s Use - Appendix B: s/an guarantee/a guarantee/ attack, although that is not an guarantee. Also if the output from - Appendix B: it's now a dnsop wg document EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to the domain. - Appendix B: this sentence doesn't parse well to me... Again if the data is the same this is an indication that the error is operator caused not an guarantee. - Appendix B: s/parents/parent's/ (or parent zone's ?) o DNSKEYs in child zone don't match parents zone DS record. There - Appendix B: these two sentences seem too informal grammatically, if not broken: Has the existed before and was used? Was there a change in the DNSKEY RRSet recently (indicating a key rollover) and of course has the actual data in the zone changes. - Appendix B: o Data in DS or DNSKEY doesn't match the other. This is more common in initial setup when there was a copy and paste error. Again checking history on data is the best you can do there. It's not possible to
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
On Tue, May 05, 2015 at 12:24:13PM -0400, Warren Kumari wrote: The way that our resolver works is that the closest TA would win, and so a positive TA under a negative trust anchor *would* be used. To me this seems to be the obviously right thing to do, and so, unless anyone objects, I'll add text to the document stating that. This matches the BIND implementation. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-livingood-dnsop-negative-trust-anch...@tools.ietf.org
On Fri, May 1, 2015 at 2:25 PM, 神明達哉 jin...@wide.ad.jp wrote: At Fri, 24 Apr 2015 23:59:22 -0400, Warren Kumari war...@kumari.net wrote: So, I have gone back through previous mail and it seems that this was the only email that got missed. Anyway, it seems that other folk also made similar comments, and so, by -03, we had addressed almost all of them. Apologies again for not seeing and responding to your mail. No worries, and thanks for addressing these so quickly. I agree with the sense of the statement, but specifically how can the operator confirm that it's misconfiguration? [...] My last update (a few days ago) included inserting an Appendix that covers some of this. It is somewhat rough,and more conversational in tone than if it were in the main part of the draft, but I think strikes a nice balance. Do you mean Appendix B? It certainly looks good enough to me to address this point. Yup. Excellent! - Also on that sense and this one in Section 8: Use of a Negative Trust Anchor MUST NOT be automatic. Again, I agree with the sense, but I wonder whether players like big ISPs or public DNS services are really willing to follow the suggestion of human intervention and/or ban of automation. [...] For these recommendations to be really effective rather than just ignored, I think we need to provide some more information, e.g., statistics on how often these events are happening in actual providers that use NTAs, show example of operational practices (which I guess would include some level of automation). We don't really have anything published, but I spoke with the person who deals with these and it is around once per quarter (it has slowed down). This year we have only done it once - for the .KE keyroll event ( thread here: https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/013060.html ) Okay, then I'd suggest adding some brief note on this point. One possibility would be to add something like this to the end of the first paragraph of Section 2: [... prior to implementing the Negative Trust Anchor.] Involving trained technical personnel is costly, but operations experiences so far suggest that this is a very rare event such as around once per quarter or even less. Will do. (and if we can include a concrete reference, do that) - Also on Section 8: Finally, a Negative Trust Anchor SHOULD be used only in a specific domain or sub-domain and MUST NOT affect validation of other names up the authentication chain. I think it would also help clarify that the deepest anchor should be used, whether positive or negative. [...] Actually, an NTA stops validation at that point, which includes things under that. Here is text (which probably changed after your comment: This Negative Trust Anchor can potentially be implemented at any level within the chain of trust and would stop validation from that point in the chain down. This gave us the needed behavior when .ke broke... Yes, turning off validation for an entire ccTLD is a big hammer -- but, it is better than turning off validation for *everyone*, or just leaving an entire country unresolvable for many hours Hmm...first, if this is really the intent, I'd suggest revising Section 8, too, to state it more explicitly (also possibly with an example). Secondly, does it make most sense? If we have a manually configured positive trust anchor for good.example.ke, isn't it better to still use it for anything on or below that, but skip DNSSEC validation for everything else on or under .ke? At least this shouldn't mean turning off validation for *everyone* or just leaving an entire country unresolvable for many hours, so such arguments don't seem to be a reason for not doing this. Ah! I've just realized that I'd misunderstood your question -- I'd somehow completely skipped over the whether **positive** or negative (emphasis added). This isn't a very common case for us, and so I'm not sure that the authors have discussed it. The way that our resolver works is the most specific (deepest) TA would win, so, assuming that we had a positive TA for good.example.ke it *would* override the NTA for .ke. I personally (and I think you as well) believe that this makes the most sense, but let me double check with co-authors. Whatever the case, we don't actually address this in the document, and it should be - Section 10 validates can have security considerations. It is therefore recommended that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the I wonder whether this 'should' may better be SHOULD. Not a strong opinion, but it seems to be similar to other recommendations using the capitalized keyword in Section 8. So, I went to go make that change, and discovered it is already a SHOULD. Sometime between
Re: [DNSOP] TLD, ccTLD and gTLD, agreement with the consensus (Was: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt
On Mon, May 04, 2015 at 03:54:26PM +, Dan York y...@isoc.org wrote a message of 107 lines which said: Would you support Ed Lewis’ modification of that text into this? Yes TLDs are often divided into ccTLDs, gTLDs and other categories; the division is a matter of policy in the root zone, and beyond the scope of this document.” ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
... and now I'm replying to the rest of the comments. I've integrated them and posted a new version with the clarifications on a *positive* **trust anchor** under an NTA. I'm not very happy with the text I added, if others have better text happy to consider it... Huge thanks to Jinmei for the careful review, catching this corner case, and providing helpful text... More comments inline. On Mon, May 4, 2015 at 2:25 PM, 神明達哉 jin...@wide.ad.jp wrote: At Mon, 27 Apr 2015 18:58:10 -0400, Tim Wicinski tjw.i...@gmail.com wrote: This starts a Working Group Last Call for Adoption for draft-ietf-dnsop-negative-trust-anchors (I guess this is for Publication, not for Adoption). Also, have we decided to publish it as an Informational document? I'm not opposed to it, but this document contains some normative text and affects inseparability in some sense, so a standard truck seems to be a more appropriate choice for me. I personally don't have a strong opinion here. I think that the authors figured that it felt more informational, and mainly (in our view) provided advice to operators -- but, we are perfectly happy to change it to Std if that's what the chairs would like... Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04 Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons I do not think it's ready for publication yet. I'd like to see a discussion on whether it really makes sense that an NTA for a domain name even disables a positive trust anchor below the name. I made more specific comment on this in a separate message: http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html (with some other comments on the 04 version of the draft). So, I've heard back from some of the other authors (and Evan, one of the implementors), and what we'd all assumed / understood was what you also believe is the right thing. Since the root is signed we haven't really been seeing many manually configured trust anchors, and so we hadn't really discussed it much. If there is a *positive* *trust anchor* for foo.bar.baz.example, it takes precedence over a negative trust anchor at baz.example. The mental model I've been using is just pretend that there is no DS in the parent when you see an NTA. So, now all I need to do is try craft some text (and probably an example to illustrate). There are number of places where I'll have to make some changes to clarify this. I've just posted a new version that somewhat clarifies this, but more text gratefully accepted... I also think Appendix B needs more editorial cleanups. Those editorial matters may not be a showstopper by themselves, but I guess it's better to fix them before sending it to the IESG. Fair. I'll do those. I may post a new version with the larger changes first, as they may need more discussion. A couple of other comments on version 4: - Section 4: It is therefore recommended that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the I guess this 'recommended' may be better RFC2119 capitalized, i.e., RECOMMENDED. Not a strong opinion, but it seems to me to be more aligned with general tone and other usage of RFC2119 keywords of this section. DONE. I now have It is therefore RECOMMENDED that NTA implementors SHOULD periodically attempt to validate the domain in question... Is that what folk would like? - Section 4: likewise, maybe s/should/SHOULD/ When removing the NTA, the implementation should remove all cached entries below the NTA node. DONE. Looks good. Editorial and minor comments: - Section 3: there's an awkward blank line (and spaces) before the reference: names for a Negative Trust Anchor. For example, Unbound calls their configuration domain-insecure. [Unbound-Configuration] DONE. Weird... - Section 7.1: s/has have/has/ DONE. Good catch. Thus, there may be a gap between when a domain has have been re- - Appendix B: s/servers/server's/ (?) domain is consistency and history. It therefore is good if you have the ability to look at the servers DNS traffic over a long period of DONE. - Appendix B: s/them install/install them/ most of these tools are open source so you can them install locally if you want. DONE. - Appendix B: this sentence doesn't parse well to me... Using the tools over the Internet has the advantage though that as these are not located in the same part of the network you already will have more than local view by using different tools. DONE. - Appendix B: s/server.s/servers./ consistently around the world and from all authoritative server.s Use DONE. - Appendix B: s/an guarantee/a
[DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Definition and Use of DNSSEC Negative Trust Anchors Authors : Paul Ebersman Chris Griffiths Warren Kumari Jason Livingood Ralf Weber Filename: draft-ietf-dnsop-negative-trust-anchors-05.txt Pages : 16 Date: 2015-05-05 Abstract: DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. Negative Trust Anchors (described in this document) can be used to mitigate DNSSEC validation failures. [RFC Editor: Please remove this before publication. This document is being stored in github at https://github.com/wkumari/draft-livingood- dnsop-negative-trust-anchors . Authors accept pull requests, and keep the latest (edit buffer) versions there, so commenters can follow along at home.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-negative-trust-anchors-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
This document has progressed very well and is nearly ready for publication. Related to an earlier thread about intended status: Informational is most appropriate here because the document is all about proposed operations but no best current practice. There is no problem with WGs producing Informational RFCs, and Informational RFCs can have RFC 2119 language. In Section 2, there should be a new paragraph after the first paragraph that describes why the reasonable attempt in the first paragraph is needed to determine whether the attacker has partial control of the zone, or is just mounting an on-path attack between all the nameservers and the recursive. In Section 2, it talks about a popular domain name but don't say how to determine that. Giving examples of sources of that data would be valuable. Section 5 is one paragraph too short. It says what other misconfigurations should not be fixed by recursive resolver operators, but it does not say why likely DNSSEC validation errors should be. The (missing) second paragraph should say something to the effect of with DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been. In Section 6, add a second sentence to the second paragraph: Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC. In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly called Altering Users of NTA Use. There is no stated reason for Appendix B to be an appendix. It is just as important as other sections in the main body of the text, and should be moved there. References to other documents are done inconsistently. For example, there is both from RFC4033 [RFC4033] and in [RFC5914]. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
