Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote: > "It is RECOMMENDED that implementations warn operators (or treat as an > error) if they attempt to add an NTA for a domain that has a > configured positive trust anchor." You still need to say what happens if the implementation decides to warn instead of treat it as an error. Actually, weirdly enough, after I implemented NTA's in BIND, one of the very first applications somebody came up with for them was to temporarily disable DNSSEC validation by setting an NTA for ".". This was seen as better than "rndc validation off" because he didn't have to send "rndc validation on" afterward; it would just quiety switch itself back on after a minute. It's... actually a pretty clever hack, and I don't really want to disable it. May I suggest: "An NTA placed at a node where there is a configured positive trust anchor takes precendence over that trust anchor, effectively disabling it. Implementations MAY issue a warning when this occurs." -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
On 5/9/15, 18:27, "John Levine" wrote: >>Besides Paul's valid "what if it's 100,000?", how does an engineer >>distinguish between 100x people and 100x organized bots? > >I dunno. How do we know that the traffic for .corp and .home is from >people rather than botnets? Through forensic analysis. E.g., finding that Cert Auth's issued certificates with ".corp" names. And that some) CPE's defaulted to ".home". Not saying that in a confrontational way. Just that this makes it pretty certain that the high query counts for those two were from non-bots. (Citing a report by Interisle: https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf) >If that wasn't clear, of course I agree with you. But we are writing >policy, not software. We're looking for evidence of substantial >private use, which is something we decide by making human decisions, >not by some mechanical packet counting formula. > >Having said all that, I'm certainly not opposed to collecting more >data. It's just not a substitute for making decisions. And just not more, but the right data. Keep in mind that there are two cases. Names that are already "polluted" and names that someone wants to innovate with. In the former case, a definition of "polluted" needs to be made being careful not to fall victim to gaming. For the latter case, the criteria would need to be different. Assuming both cases are accommodated. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
>Besides Paul's valid "what if it's 100,000?", how does an engineer >distinguish between 100x people and 100x organized bots? I dunno. How do we know that the traffic for .corp and .home is from people rather than botnets? >If there is a group of people using an identifier as you describe, then >I'd suspect there would be other evidence than just the log of leaked >queries. (What if they don't leak?) Criteria based on the other evidence >would likely be stronger than just counts of leaked queries. If that wasn't clear, of course I agree with you. But we are writing policy, not software. We're looking for evidence of substantial private use, which is something we decide by making human decisions, not by some mechanical packet counting formula. Having said all that, I'm certainly not opposed to collecting more data. It's just not a substitute for making decisions. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
On May 8, 2015, at 7:10 PM, Suzanne Woolf wrote: > > I share David’s reservations about this— how do we objectively and > reproducibly distinguish “people are using these in private networks” from > “people are generating arbitrary traffic to the roots for these”? I think doing so would be a fool's errand. It probably could be done, but you asked some good questions which I think show that it's pointless to try. > Is there any concern for the IETF in a policy that says “If you start using > an arbitrary name that isn’t currently in the root zone, you can just get the > IETF to protect it for you”? I think clearly we should not have such a policy. The point of special use names is to serve some purpose, not to put a bandaid on misuses. I think there is some value in things like .corp, .home and .lan, which can be justified without resorting to data collection, and that is how we should approach it. > Furthermore, given that ICANN has already said they won’t delegate these > names in particular, how is it helpful for the IETF to also add them to the > Special Use Names registry? As you clearly intended to imply with your rhetorical question, there is no point in the IETF doing any such thing, to which I will add one slight caveat: unless there is some reason why writing up how these names are used would actually be useful and beneficial. If it would be useful and beneficial, and someone wants to do it, then I think that should be allowed, and if consensus can be achieved, then we can add such names as are described in this document to the special names registry. But absent such a document, we should not. I hasten to add that "consensus" ought not to mean "nobody is offended," but rather "there is a clear protocol-related use case for doing it, and nobody can raise a clear technical reason _not_ to do it." ___ 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
On May 9, 2015, at 6:08 AM, Warren Kumari wrote: >> Two more related points: >> >> 1. In my very original comment on this matter: >> www.ietf.org/mail-archive/web/dnsop/current/msg12614.html >> I noted one other corner case, which we might also want to clarify: >> On a related note, there are some corner cases which may also be >> worth noting: queries for DS or DLV (or anything similar to that). >> So, for example, zone1.example.com/DS should still be validated even >> if there's an NTA for zone1.example.com. Again, this might sound >> obvious, but I think it's worthwhile. > > > I have spent some time trying to figure out some text that explains > this without becoming really complex and wordy. If anyone has some > text that they would be willing to send I'd appreciate it... I'm with Warren on this: I can't think of a way to describe this without going into the whole "actually owned by the parent" dance that keeps being hard to describe for everyone. --Paul Hoffman ___ 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
On May 9, 2015, at 6:07 AM, Warren Kumari wrote: >> 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. > > > DONE? > "It is important to confirm that the comains is still under the > ownership / control of the legitimate owner of the domain - this is to > ensure that disabling validation for a specific domain does not direct > users to an address under an attackers control. Contacting the domain > owner allows the resolver operator to determine if the issue is a > DNSSEC misconfiguration or an attack." > > I'm not really sure if this addresses your concerns? If not, do you > happen to have any suggested text? Using your, expanding just a bit: "It is important for the resolver operator to confirm that the domain is still under the ownership / control of the legitimate owner of the domain in order to ensure that disabling validation for a specific domain does not direct users to an address under an attacker's control. Contacting the domain owner and telling them the DNSSEC records that the resolver operator is seeing allows the resolver operator to determine if the issue is a DNSSEC misconfiguration or an attack." > > >> >> 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. > > DONE. > I added: "An example of a list of "top N" websites is the target="Alexa">"Alexa Top 500 Sites on the Web" " > > Is this OK? That's OK, but I would prefer to add in what Scott Rose suggested: ", or a list of the of the most-accessed names in the resolver's cache". --Paul Hoffman ___ 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
On Wed, May 6, 2015 at 6:51 PM, 神明達哉 wrote: > At Tue, 5 May 2015 17:06:04 -0400, > Warren Kumari wrote: > >> ... and now I'm replying to the rest of the comments. > > Thanks, I've confirmed that my major and minor points are addressed in > the 05 version. So I'm now basically fine with shipping it. Excellent, thank you... > > Some non-blocking comments follow... > >> 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... > > The added text looks good enough to me. If you don't like it > yourself, I might suggest something else, but I'm not sure if it's > obviously better than the current one. In any case, I think Section 2 > is probably a better place to clarify this, partly because that > section has example cases. But it's not a strong opinion. Fair -- I also have put text at the bottom of section 2 explaining this. > > Two more related points: > > 1. In my very original comment on this matter: >www.ietf.org/mail-archive/web/dnsop/current/msg12614.html >I noted one other corner case, which we might also want to clarify: > On a related note, there are some corner cases which may also be > worth noting: queries for DS or DLV (or anything similar to that). > So, for example, zone1.example.com/DS should still be validated even > if there's an NTA for zone1.example.com. Again, this might sound > obvious, but I think it's worthwhile. I have spent some time trying to figure out some text that explains this without becoming really complex and wordy. If anyone has some text that they would be willing to send I'd appreciate it... > > 2. What if both positive and negative trust anchors are specified for >the same name at the same time? Maybe it's just implementation >dependent, and it may or may not be something that is worth >discussing in this document. DONE. Oooh. Good point. I believe that this is (probably) something that implementations should warn about, or refuse. I'll add some text to say this. How is: "It is RECOMMENDED that implementations warn operators (or treat as an error) if they attempt to add an NTA for a domain that has a configured positive trust anchor." > > And, here are some other editorial points I happened to notice in this > round of read: > > - (this is technical rather than editorial in some sense) Section 4: > >When removing the NTA, the implementation SHOULD remove all cached >entries below the NTA node. > > Probably s/below/at and below/ DONE. Good catch. Thank you! > > - Appendix B: s/do this/to do this/ ? >There are several tools do this, an incomplete list includes: DONE. Nice. Thanks. > > - Appendix B: It's better if we can use a different level of bullets >for these: >o DS pointing to a non existent key in the child zone. Questions... >o DS pointing to an existent key, but no signatures are made with... >o Data in DS or DNSKEY doesn't match the other. This is more common... > > since they are sub-bullets of this one: > >o DNSKEYs in child zone don't match the DS record in the parent > zone. [...] Common Variations of > this can be: > > (I don't know if I-D xml allows nested listing though). DONE. Whooo! It does! Fixed... > > -- > JINMEI, Tatuya -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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
On Wed, May 6, 2015 at 5:08 PM, Dan York wrote: > Warren and Tim, > > I support the publishing of this document subject to incorporating the > various comments I’ve seen here on that list. I had a couple of specific > points but they seem to have been covered by others, so… > > On May 6, 2015, at 9:46 AM, Warren Kumari wrote: > > I really appreciate all feedback, and will integrate comments in the next > couple of days (I like to rev the doc even during WGLC, so that everyone can > see the most recent state, and not comment on older comments, etc > > > … I’ll wait for your next version before making any specific comments on the > text. With all the comments coming in I’ve lost track of all the suggested > changes. Yah, fair enough. This is why I like to integrate comments and post new versions, even during WGLC -- but, I got somewhat behind New version posted, with (I *think*) all comments integrated / resolved. W > > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > y...@isoc.org +1-802-735-1624 > Jabber: y...@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/ > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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
On Wed, May 6, 2015 at 3:33 PM, Rose, Scott W. wrote: > I think the draft is just about ready for publication as well. > > On May 5, 2015, at 5:53 PM, Paul Hoffman wrote: > >> 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. >> > I would recommend local query logs, naturally. Oooh! Added. Thanks. > > >> >> 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 a security consideration there, reading between the lines - in that > this is broadcasting a spoofable name to the world. However, a "Altering > User's" section would be a good addition to include text about apps that may > break if it is known they demand to see the AD bit set in responses. Good point. I'm assuming^W hoping that applications that assume a domain is signed, and expect the AD bit *should* actually be doing their own validation. But I added this to the security section (it felt securityish). "One side effect of implementing an NTA is that it may break client applications that assume that a domain is signed and expect an AD bit in the response. It is expected that many application that require DNSSEC for a domain will perform their own validation, and so this should not be a major issue." Is this clear / helpful? > > Scott > > > > === > Scott Rose > NIST > scott.r...@nist.gov > +1 301-975-8439 > Google Voice: +1 571-249-3671 > http://www.dnsops.gov/ > https://www.had-pilot.com/ > === > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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 ] Integrating these -- 'parently I'm processing emails out of order... Thank you for your comments, I've integrated them and will post a new version soon (planning on incorporating some of Jinmei's comments before posting). On Tue, May 5, 2015 at 5:53 PM, Paul Hoffman wrote: > 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. > Thanks. > 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. DONE? "It is important to confirm that the comains is still under the ownership / control of the legitimate owner of the domain - this is to ensure that disabling validation for a specific domain does not direct users to an address under an attackers control. Contacting the domain owner allows the resolver operator to determine if the issue is a DNSSEC misconfiguration or an attack." I'm not really sure if this addresses your concerns? If not, do you happen to have any suggested text? > > 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. DONE. I added: "An example of a list of "top N" websites is the "Alexa Top 500 Sites on the Web" " Is this OK? > > 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". > DONE. I was going to add some hand-wavy bit about the fact that DNSSEC is an "added feature" and that the behavior differs based upon if you have turned validation on or not, but this didn't feel helpful, so I just used your text. Thanks. > 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." DONE. Thank you. > > 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". DONE. I'm fairly jetlagged, and it took me a silly amount of time to parse the suggested name :-) Yay autocorrect. > > 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. DONE. It had felt more "Appendixy" to me, but I don't know why. Moved it into the body of the doc. > > References to other documents are done inconsistently. For example, there is > both "from RFC4033 [RFC4033]" and "in [RFC5914]". DONE. Thank you, and apologies for the delay. W > > --Paul Hoffman > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-07.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-07.txt Pages : 17 Date: 2015-05-09 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-negative-trust-anchors-07 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] Interim DNSOP WG meeting on Special Use Names: some reading material
On 5/7/15, 11:41, "John Levine" wrote: >ICANN has a whole bunch of rules that mandate that once you've paid >the $185,000, you have to deploy a DNSSEC signed zone on multiple >servers, implement elaborate reservation and trademark claiming rules, >takedown processes, WHOIS servers, and so forth. In the recent TLD >application round there was one applicant that only wanted to reserve >the domain (they were apparently concerned that someone else would >squat ... My thought (as I wasn't in ICANN when the 2012 new TLD program was established, etc.) is that the process in place was built to allow the establishment of operating TLDs with all of "those" concerns. As opposed to being a process by which to reserve "strings" (labels) that would not "be in" (delegated/have whois servers/registration interfaces/etc) the root zone, i.e., for the purpose of squatting to prevent collisions. The problem (the topic of discussion here) I see is that there are class of strings that are intended to not be active in the DNS and further more, the DNS isn't even meant to be consulted. The closest process in place today to achieving this is the Special Use Names registry - and I emphasize "closest" recognizing that if it was "perfect" we wouldn't be having an interim meeting in a few days time. I may be wrong...but this is how I see view the topic. (I.e., not a statement on behalf of ICANN.) smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
Playing "devil's advocate" (http://en.wikipedia.org/wiki/Devil%27s_advocate): On 5/9/15, 3:54, "John R Levine" wrote: >Let's say we found that there's some online thing we never heard of >before, but it turns out that 100,000,000 people in India and China use >it, it uses private names in .SECRET, and people looking at DNS logs >confirm that they're seeing leakage of .SECRET names. Beyond rolling our >eyes and saying we wish they hadn't done that, what else should we do? >Why shouldn't we reserve it? The number of possible TLDs is effectively >unlimited, striking one more off the list that might be sold in the >future >doesn't matter. This is engineering, not ideally what we might have done >with a blank slate, but the best we can do under the circumstances. Besides Paul's valid "what if it's 100,000?", how does an engineer distinguish between 100x people and 100x organized bots? My question adds to what David is saying - we need solid criteria. (Just to be clear, he is my boss but this does not represent any opinion on behalf of our employer.) The criteria of just seeing queries is, I'll say, naive, because it's so obviously vulnerable to gaming. (Not saying the data to date has evidence of being gamed, but it wouldn't be hard to pull this off.) (And why data collections efforts are not publicly announced, so as to limit anyone from prepping to game.) If there is a group of people using an identifier as you describe, then I'd suspect there would be other evidence than just the log of leaked queries. (What if they don't leak?) Criteria based on the other evidence would likely be stronger than just counts of leaked queries. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
On 5/9/15, 1:10, "Suzanne Woolf" wrote: >I share David’s reservations about this— how do we objectively and >reproducibly distinguish “people are using these in private networks” >from “people are generating arbitrary traffic to the roots for these”? One good characterization of the technical problem, although I'd modify the former to "people...networks and leaking the queries to the root". A recipient of a DNS query cannot know why it was asked (no context). So whether this is a leak or a gaming cannot be determined in-band. >Is there any concern for the IETF in a policy that says “If you start >using an arbitrary name that isn’t currently in the root zone, you can >just get the IETF to protect it for you”? I find this above statement a little unclear. Whose policy (as in ICANN policy/IETF policy/someone else's policy)? >Furthermore, given that ICANN has already said they won’t delegate these >names in particular, how is it helpful for the IETF to also add them to >the Special Use Names registry? I'll throw out what is in my personal mental model on this topic (as opposed to something explicitly documented elsewhere): For the non-DNS software using identifiers. If a layer in the software stack sees an identifier matching an entry in the Special Use Names registry, it should avoid trying to resolve the name using DNS. This issue is about more than the DNS. As far as the DNS, I believe it's really only about how it can be kept from harming other identifier systems[0] and not meant to be a way to "shape/prune" the DNS name space tree. [0] As in "name.onion." isn't a domain name, it's a string that happens to have dots in it. And at the end of it and otherwise appears to conform with the "BNF" in RFC 103-something - but that's just coincidental. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-05.txt
On Fri, May 8, 2015 at 2:41 AM, Warren Kumari wrote: > [ Top post ] > > Thanks for all the comments. I've integrated most of them (need > additional text for one), and am posting a new version with the > changes. > > Comments inline. > > On Wed, May 6, 2015 at 8:37 AM, Tony Finch wrote: >> I have read through the draft. Looks good. >> >> Some wording suggestions: >> >> Section 1.1: >> >>By way >>of analogy, negative trust anchors stop validation of the >>authentication chain. Instead, the resolver sends the response as if >>the zone is unsigned and does not set the AD bit. >> >> I suggest: >> >>Instead, the validator treats any upstream responses as if >>the zone is unsigned and does not set the AD bit in responses it sends >>to clients. > > DONE. > Thanks. > >> >> >> Section 1.2: >> >>As domains transition to DNSSEC, the most >>likely reason for a validation failure will be misconfiguration. >> >> I suggest: >> >>As domains transition to DNSSEC, the most >>common reason for a validation failure has been misconfiguration. >> > > DONE. > Thanks. > >> I am also worried about DNSSEC failures resulting from botched changes of >> domain hosting or ownership. Not sure what to say about that. >> > > Me neither -- but that's a type of misconfiguration? :-) If anyone has > suggested test I'm happy to consider it. > > >> Section 2: >> >> The requirement MUST NOT affect parental domains is fine, but why only >> SHOULD NOT for other branches of the tree? I would expect that to be MUST >> NOT as well. Is this to allow for someone putting an NTA on a DLV domain >> perhaps? > > I seem to remember it being something subtle to do with delegations, > but will check with co-authors / go back through earlier mail. > Example.com uses ns1.example.net. example.net borks their keyroll, and > we "rescue" them by putting in an NTA. This has affected something in > another branch of the tree. > > >> >> I don't understand the diagram :-( > > Fair enough - it *is* confusing. I'll ask one of the other authors to > fix it (you *so* don't want me to fix it :-)) So, I've chatted with some of the other authors (Paul and Jason) and we agree that: A: the diagram is confusing and B: it doesn't actually *add* anything to the document. So, we are proposing simply removing it. If anyone screams we'll put it back... Seem good? W > >> >> Section 3: >> >>Most current implementations of DNS validating resolvers currently >>follow [RFC4033] on defining the implementation of Trust Anchor as >>either using Delegation Signer (DS), Key Signing Key (KSK), or Zone >>Signing Key (ZSK). >> >> I suggest: >> >>Most current implementations of DNS validating resolvers currently >>follow [RFC4033] on configuring a Trust Anchor using either a public >>key as in a DNSKEY RR or a hash of a public key as in a DS RR. >> >> ... because this is closer to what RFC 4033 says, and from the point of >> view of the validator there's no difference between a KSK and ZSK, and >> usual practice says you should only use SEP keys (i.e. KSKs) for trust >> anchors so mentioning ZSKs here is very unwise. > > DONE. > Fair 'nuff. > >> >> This sentence is unclear: >> >>A Negative Trust Anchor should use domain name >>formatting that signifies where in a delegation a validation process >>should be stopped. > > Yes, that is unclear > >> >> Does it mean: >> >>A Negative Trust Anchor should be configured using a >>fully-qualified domain name in RFC 1035 master file syntax, to >>indicate that validation should not occur at or below that domain name. > > DONE. > Nope. I don't think that we need to define the format here -- it is > (IMO) an implementation detail. > I don't really know what the point of the sentence is, but it does't > (AFAICT) add anything, and so I'm removing it... > Thanks! > > >> >> And for: >> >>Different DNS recursive resolvers may have different configuration >>names for a Negative Trust Anchor. For example, Unbound calls their >>configuration "domain-insecure."[Unbound-Configuration] >> >> I suggest: >> >>Different DNS validators may have different configuration >>names for a Negative Trust Anchor. For examples see Appendix A. > > DONE. > Thanks, much better. That was left over from earlier versions... > >> >> Section A.1: >> >> Worth mentioning unbound-control insecure_add and insecure_remove? > > NOT DONE. > Yes, yes it is. I believe one of the Unbound developers was going to > contribute text, I'll follow up with them. > > > > Thanks again, > W > >> >> >> Tony. >> -- >> f.anthony.n.finchhttp://dotat.at/ >> Hebrides, Bailey: Northerly backing northwesterly 6 to gale 8, increasing >> severe gale 9 at times, decreasing 5 later in west Bailey. Rough or very >> rough, occasionally high in Hebrides. Occasional rain. Good, occasionally >> poor. >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> ht
