Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
Warren Kumari wrote: > > > > > Wildcards > > > > Should the box in section 7 say "positive responses" instead of "negative > > responses"? > > > > If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4 > > and RFC 5155 section 8.8 which both discuss validating positive wildcard > > responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide > > text if you want. > > NOT DONE. > Yes please. That would be awesome! Thinking about wildcards makes me wonder if we need to approach this whole idea from two directions - firstly, how the validator proves to itself that it can synthesize a negative response or a wildcard response; and secondly, how it can prove that it did the right thing to a downstream validator. At the moment the draft talks about the first aspect, but not very much the second. Specifically, Should we treat synthesis as if the cache is pretending to be an authoritative server? e.g. for wildcards and NSEC3, something like, When synthesizing a wildcard response from its cache, the validating resolver MUST include all the records specified in RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6 (for positive responses). That is, it MUST generate a response that matches what an authoritative server would send. If the required records are not present in the cache, the resolver SHALL query upstream instead of synthesizing the response. If this makes sense then the other cases should be adjusted to describe things in a similar way, e.g. referring to section 7 of RFC 5155 instead of (or as well as?) section 8, and section 3.1 instead of / as well as section 5 of RFC 4035. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05
Unfortunately we are no longer in the early days of the Internet AND the IETF has no business in enforcing compliance with our protocol standards. That's for the zone operators to do. We are not the dns police. Even Paul mocapetris has called for more innovation in the dns space. We must not presume there is just one way to do things. On Sunday, 9 October 2016, Mark Andrews wrote: > > In message < > caaiteh9rbw4u3gv9gulq-8wdophf3sxqmtry+ctfugrnqsg...@mail.gmail.com > >, Matthew Pounsett writes: > > > > My first impression of this document is that it is still in need of some > > extreme editing – mostly for grammar and syntax, but also for clarity and > > readability. I've included many of the early problems I found in a list > > of nits at the end of this email, but at two and three errors per > paragraph > > (and occasionally per sentence) it's just too much to cover this way, so > I > > stopped noting nits after the first couple of sections. I suggest such > > sweeping changes to later sections that any nits I noted there may end up > > being rewritten anyway. > > > > The draft still suffers from inconsistent approaches to the content. In > > any given section it might shift from a problem description, to > > admonishment, to advice for workarounds, and back again without a clear > or > > consistent structure. This makes it difficult to figure out what the > > intended takeaway is in places. I've tried to point out specifics below, > > and suggest better approaches where I can. > > > > Don't let my criticism of the document give you the wrong impression. I > > think this is useful work, and I'm very appreciative of the work that has > > gone into it so far. I just happen to think that there is still work > left > > to be done. > > > > > > As for the meat of the matter... > > > > > > In the Introduction, in the paragraph which begins "Unless a nameserver > is > > under attack" would it make sense to replace "broken delegations" with > > "lame delegations"? We have a term for delegating to a name server > which > > is not authoritative for the delegation... we should probably use it. > > > > > Section 2, "Consequences," seems out of place to me. It makes a number > of > > assertions that seem to follow no particular flow, or pattern. The line > > of > > reasoning or evidence that lead to these assertions has not appeared yet > > in > > the document, and so they seem unsupported. If I'm interpreting the > > author's intent correctly, perhaps this section should be split up and > > interspersed into the current section 3 as the direct or indirect > > consequences of each type of dropped response. > > > > > > The way section 3 is titled and introduced I expect to just see a survey > > of > > commonly dropped queries, but the content seems to be inconsistent as to > > whether it's just a survey, or a survey and advice to client authors > about > > working around problems, or just advice without a clear description of > the > > problem behaviour. It seems to me that if the section is intended to be > > advice to authors, then it should be introduced that way. Also, > > clarification for server authors on how they should respond–instead of > > dropping queries–should probably come before any advice on how to work > > around dropped queries. > > > > If the goal here is to help implementors fix what's broken, then I would > > suggest each subsection start with a clear description of an observed > > broken behaviour, followed up with a description of how that behaviour > > should change (possibly only as a short summary with external references, > > as we don't want to reproduce whole RFCs here) and then follow that with > > advice for client authors for working around existing brokenness. > > Sticking > > to a pattern–either the one I've suggested or some other–for every query > > type would make the entire section easier to read. It will also make it > > easier for the working group to go through the section item by item and > > discuss whether we agree on the problem descriptions and proposed > > remediation. > > > > RFC 2119 language is conspicuously absent from this section and SHOULD be > > added. > > > > > > Section 4, "Remediating", is very problematic. I think the biggest > issues > > stem from two false assertions: > > 1) "TLD operators are being asked to do this as they...have access to a > > large numbers of nameserver names as well as contact details for the > > registrants of those nameservers." > > > > This is incorrect. Or, at least, frequently incorrect. TLD registries > > fall into one of two categories: thick or thin. Thick registries do > have > > this information, but a significant number of thin registries exist, > which > > delegate the responsibility for maintaining registrant contact > information > > to the registrar. All thin registries know is that a delegation should > > exist, which name servers are currently supposed to be authoritative for > > the subzone,
[DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt
Dear colleagues, this is just a refresh to keep the draft going as we are still waiting for irtf-cfrg-eddsa, but that looks like it's in IESG Review, so it might be a good time to have a final look and send the comments to /me or Robert or curdle WG mailing list. 1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/ Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Forwarded Message - From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: cur...@ietf.org Sent: Monday, 10 October, 2016 15:46:46 Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : EdDSA for DNSSEC Authors : Ondrej Sury Robert Edmonds Filename: draft-ietf-curdle-dnskey-eddsa-01.txt Pages : 8 Date: 2016-10-10 Abstract: This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-01 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/ ___ Curdle mailing list cur...@ietf.org https://www.ietf.org/mailman/listinfo/curdle ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-alt-tld-05
On Sun, Oct 09, 2016 at 05:36:34PM -, John Levine wrote a message of 47 lines which said: > I hate to bring this up, but we might want to reconsider whether .alt > is still the best name for this hack. May be the author of the I-D should change every occurrence of .alt by TODO-NAME-TO-BE-DISCUSSED-LATER so we can focus on the idea and avoid discussions about the name? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-alt-tld-05
I hate to bring this up, but we might want to reconsider whether .alt is still the best name for this hack. May be the author of the I-D should change every occurrence of .alt by TODO-NAME-TO-BE-DISCUSSED-LATER so we can focus on the idea and avoid discussions about the name? I'd think we could just note that the name is TBD in discussions about whether anyone would actually use a generic not-DNS TLD. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05
In message , william manning writes: > > Unfortunately we are no longer in the early days of the Internet AND the > IETF has no business in enforcing compliance with our protocol standards. > That's for the zone operators to do. We are not the dns police. Even Paul > mocapetris has called for more innovation in the dns space. We must not > presume there is just one way to do things. If the IETF was setting servers that went and checked DNS servers and informed the operators then the IETF would be in the business of enforcing protocols. At this stage I don't see the IETF doing that nor is this document asking the IETF to do that. The is a difference between innovation and not exercising care / lazyness. Returing FORMERR because you see a EDNS flag you don't understand is not innovation. Returing FORMERR because you see a EDNS option you don't understand is not innovation. Returing FORMERR because you see a EDNS version you don't understand is not innovation. If there was anything innovative in what I'm seeing I'd be all for it but there isn't. Mark -- 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] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski wrote: > > Just a reminder that the WGLC for draft-ietf-dnsop-nsec-aggressiveuse > will end later today (barring any stuck issues). The authors appear to > have addressed all open issues (except JINMEI's last comments). Please > read the current version here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ > > and speak up with any final questions, concerns, etc. > > (Reading the version at https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse in case it is different) Section "3. Problem Statement" The example domain includes a wildcard, but the text reads as though the answer to "cat.example.com" would be that is does not exist. Should the wildcard be removed for this example? -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
UI On Monday, October 10, 2016, Bob Harold wrote: > > On Thu, Oct 6, 2016 at 2:53 AM, Tim Wicinski > wrote: > >> >> Just a reminder that the WGLC for draft-ietf-dnsop-nsec-aggressiveuse >> will end later today (barring any stuck issues). The authors appear to >> have addressed all open issues (except JINMEI's last comments). Please >> read the current version here: >> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ >> >> and speak up with any final questions, concerns, etc. >> >> (Reading the version at https://github.com/wkumari/draft-ietf-dnsop-nsec- > aggressiveuse in case it is different) > > Section "3. Problem Statement" > The example domain includes a wildcard, but the text reads as though the > answer to "cat.example.com" would be that is does not exist. Should the > wildcard be removed for this example? > Doh! Yes, yes it should. I was trying to avoid having two separate example zones, but, well, premature optimization and all that.. The way it is now is, um, just wrong. W > > -- > Bob Harold > > -- 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] review of draft-ietf-dnsop-no-response-issue-05
On Tue, Oct 11, 2016 at 01:56:42AM +1100, Mark Andrews wrote: > If the IETF was setting servers that went and checked DNS servers > and informed the operators then the IETF would be in the business > of enforcing protocols. At this stage I don't see the IETF doing > that nor is this document asking the IETF to do that. > > The is a difference between innovation and not exercising care / > lazyness. > > Returing FORMERR because you see a EDNS flag you don't understand > is not innovation. > > Returing FORMERR because you see a EDNS option you don't understand > is not innovation. > > Returing FORMERR because you see a EDNS version you don't understand > is not innovation. > > If there was anything innovative in what I'm seeing I'd be all for > it but there isn't. Amen. This draft documents widely problematic behaviour that is seen much too often. It is good to have it all written down in one place. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
>Should we treat synthesis as if the cache is pretending to be an >authoritative server? > >e.g. for wildcards and NSEC3, something like, > > When synthesizing a wildcard response from its cache, the > validating resolver MUST include all the records specified in > RFC 5155 section 7.2.5 (for negative responses) or section 7.2.6 > (for positive responses). That is, it MUST generate a response > that matches what an authoritative server would send. If the > required records are not present in the cache, the resolver SHALL > query upstream instead of synthesizing the response. Yes, although it's kind of subtle. For example, I query for a.h.g.iana.fail: ;; QUESTION SECTION: ;a.h.g.iana.fail. IN A ;; ANSWER SECTION: a.h.g.iana.fail.3510IN A 2.2.2.2 a.h.g.iana.fail.3510IN RRSIG A 8 4 3600 2016121100 20161010180056 31806 iana.fail. fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk= ;; AUTHORITY SECTION: *.h.g.iana.fail.7110IN NSECb.h.g.iana.fail. A RRSIG NSEC *.h.g.iana.fail.7110IN RRSIG NSEC 8 4 7200 2016121100 20161010180056 31806 iana.fail. iQF8nmONvtzkvDy+8QRjlRRI12+XyJ0XZG8jig/o7EJ21P/VShfE3I9W 3E+JVnkKuYg3Wg3R4tSUSLVZKxVaL/yGSTDvI0+S4RfjNaTWoeuqb+qo vAw78j2TMjevWJPA+NhYjHqc6daB3b38kn5cN3vCYmAO1OR5pn+whdqN d94= iana.fail. 3510IN NS sdn.iecc.com. iana.fail. 3510IN NS osdn.iecc.com. iana.fail. 3510IN NS light.lightlink.com. iana.fail. 3510IN RRSIG NS 8 2 3600 2016121100 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0= You can see that the wildcard is *.h.g.iana.fail. But query for e.h.g.iana.fail: ;; QUESTION SECTION: ;e.h.g.iana.fail. IN A ;; ANSWER SECTION: e.h.g.iana.fail.3600IN A 2.2.2.2 e.h.g.iana.fail.3600IN RRSIG A 8 4 3600 2016121100 20161010180056 31806 iana.fail. fe7QsinhJnyAk6Zz52OO676KXryp3GDMdez38CwyiwNeEiaEzzu83h6c XHum/xbt7uYA7B5EmI/W0x6LMkpe9oAZgzj/LcbXv/BLqvUY4+iCcoW6 6UAoyPeWmSRaheRuBG5jvr/kIFqN+VGBo5Kt6pzGt+NIuIemjRcfPkz4 rIk= ;; AUTHORITY SECTION: b.h.g.iana.fail.7061IN NSECmx.iana.fail. A RRSIG NSEC b.h.g.iana.fail.7061IN RRSIG NSEC 8 5 7200 2016121100 20161010180056 31806 iana.fail. hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8= iana.fail. 3403IN NS sdn.iecc.com. iana.fail. 3403IN NS osdn.iecc.com. iana.fail. 3403IN NS light.lightlink.com. iana.fail. 3403IN RRSIG NS 8 2 3600 2016121100 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0= You can see that it's synthesized from a wildcard, but you can't tell whether the wildcard was *.iana.fail or *.g.iana.fail or *.h.g.iana.fail. And if I query for i.g.iana.fail: ;i.g.iana.fail. IN A ;; ANSWER SECTION: i.g.iana.fail. 3600IN A 1.1.1.1 i.g.iana.fail. 3600IN RRSIG A 8 3 3600 2016121100 20161010180056 31806 iana.fail. u3icLxUEeJ2RMuhUufrhvze8hUAEkNCKPAfVHXYlQq7D1don0l4opjI2 Sd6fxEPKcF8ah1vtCvIewFctbXQ/HH6gviKslrJekzJcX6PQccsMtygG SzAr3HyWf2HfcMfDJqW2PjP5v9teB/uR7KCWGbxYogFt+sEXu77xHhqi Kug= ;; AUTHORITY SECTION: b.h.g.iana.fail.6796IN NSECmx.iana.fail. A RRSIG NSEC b.h.g.iana.fail.6796IN RRSIG NSEC 8 5 7200 2016121100 20161010180056 31806 iana.fail. hjxpHIt1tzpXePloM08h1wwzY48kBSSH+okPmkglDod2QG2oqtZaEHlt 7rNhjrdwCKcnfoj7QawpneApAciM6jpLevjg8VqCpvHHRNBwgMKPwYq1 ABiFdoMpEdc2D2+7SZ1RMCeIN+NFZtuBMBuYVWMDqvIwxAEapP9PPVXS vC8= iana.fail. 3138IN NS sdn.iecc.com. iana.fail. 3138IN NS osdn.iecc.com. iana.fail. 3138IN NS light.lightlink.com. iana.fail. 3138IN RRSIG NS 8 2 3600 2016121100 20161010180056 31806 iana.fail. I2mKwv75mSfgKf6MBkVWaXg4By9Bs8reUmnTHiBrHcY6O1hMA9XBE8Nq puyXgNured/cHlD8TcApu9FXKWw/L6gjE72eEvZ0WF5ciMGSHrPkW7va XPEXKgD0n9kVHITdFcXGSm5DfQ7j1bYb/j76GSzlxiX1cTss+V2uAXU+ wl0= I get a different synthesized answer because in this case, there's one wildcard for *.g.iana.fail and another one for *.b.g.iana.fail. That's OK, and I believe it is
Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
John Levine wrote: > >Should we treat synthesis as if the cache is pretending to be an > >authoritative server? > > > Yes, although it's kind of subtle. Yep, that's kind of why I am suggesting a more detailed spec but also trying to leave as much as possible to the existing intricate documentation. > For example, I query for > a.h.g.iana.fail: [snip] > You can see that the wildcard is *.h.g.iana.fail. > > But query for e.h.g.iana.fail: > > ;; ANSWER SECTION: > e.h.g.iana.fail.3600IN A 2.2.2.2 > e.h.g.iana.fail.3600IN RRSIG A 8 4 3600 > 2016121100 > 20161010180056 31806 iana.fail. > > You can see that it's synthesized from a wildcard, but you can't tell > whether the wildcard was > *.iana.fail or *.g.iana.fail or *.h.g.iana.fail. Ah, but that is what the label count (4) is for in the RRSIG A. The QNAME has 5 labels so you know the RRSIG belongs to *.h.g.iana.fail, and you have to work this out in order to validate it. > That's OK, and I believe it is straightforward for a cache to tell > what names it can synthesize and what names it can't, but it means > it'd probably be a good idea to make it clear that if there are other > names in the wildcard's range, the cache often can't synthesize > results. And the rules for authoritative servers say which records you have to put in the answer, so I think it is enough for the cache to check that it already has the right ones. In your examples, the first NSEC covered *.h.g to b.h.g proving that a.h.g did not exist and could be the result of wildcard expansion. In the second query, e.h.g is outside that NSEC's range, so although the cache knows it e.h.g is a candidate for wildcard synthesis, it doesn't have the nonexistence proof, so it has to query upstream. And it knows what nonexistence proof it needs from the rules for authoritative answers. I think something that might need saying (it probably isn't in the existing specs) is that the validator should cache the wildcard record that it retconned from the answer (*.h.g in this example). Or maybe it is obvious from the fact that it is being used for synthesis :-) Tony (sorry this is a bit vague and off the cuff). -- f.anthony.n.finchhttp://dotat.at/ - I xn-- zr8h punycode ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse
Having read the draft… How does one distinguish a Empty Non-Terminal NODATA response from an NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. There is an attack vector where an RCODE0 can be replaced by RCODE3 while keeping the rest of the response completely intact, causing an aggressive use enabled cache to deny existing records. These kind of subtleties aren’t described in the draft, as far as I can tell. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse
In message , Roy Arends writes: > Having read the draft > > How does one distinguish a Empty Non-Terminal NODATA response from an > NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. NSEC: Find the NSEC record that proves that there are no records at the given name (note all of the owner, the next domain name and the bit map need to be examined to do this). It either the owner name or the next domain name of that record are a subdomain of the given name then it is a ENT otherwise it is a NXDOMAIN. > There is an attack vector where an RCODE0 can be replaced by RCODE3 while > keeping the rest of the response completely intact, causing an aggressive > use enabled cache to deny existing records. > > These kind of subtleties arent described in the draft, as far as I can > tell. > > Roy > ___ > 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] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse
On 10 Oct 2016, at 21:39, Mark Andrews wrote: > > > In message , Roy Arends writes: >> Having read the draft >> >> How does one distinguish a Empty Non-Terminal NODATA response from an >> NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. > > NSEC: Find the NSEC record that proves that there are no records > at the given name (note all of the owner, the next domain name and > the bit map need to be examined to do this). It either the owner > name or the next domain name of that record are a subdomain of the > given name then it is a ENT otherwise it is a NXDOMAIN. Thanks Mark. There should be some guidance to this in the draft. To be complete, for NSEC3: each empty non-terminal has an NSEC3 record associated with it, so there is always a matching NSEC3 record. The issue remains with NSEC. It is possible to determine the difference. It is important to determine the difference. This method is not specified in the draft that encourages this local optimisation. Warmly Roy > >> There is an attack vector where an RCODE0 can be replaced by RCODE3 while >> keeping the rest of the response completely intact, causing an aggressive >> use enabled cache to deny existing records. >> >> These kind of subtleties arent described in the draft, as far as I can >> tell. >> >> Roy >> ___ >> 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] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse
In message <0be787cd-3877-48c0-8bf9-3e15f605d...@dnss.ec>, Roy Arends writes: > On 10 Oct 2016, at 21:39, Mark Andrews wrote: > >=20 > >=20 > > In message , Roy Arends = > writes: > >> Having read the draft > >>=20 > >> How does one distinguish a Empty Non-Terminal NODATA response from an > >> NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. > >=20 > > NSEC: Find the NSEC record that proves that there are no records > > at the given name (note all of the owner, the next domain name and > > the bit map need to be examined to do this). It either the owner > > name or the next domain name of that record are a subdomain of the > > given name then it is a ENT otherwise it is a NXDOMAIN. > > Thanks Mark. > > There should be some guidance to this in the draft. > > To be complete, for NSEC3: each empty non-terminal has an NSEC3 record = > associated with it, so there is always a matching NSEC3 record. > > The issue remains with NSEC. It is possible to determine the difference. = > It is important to determine the difference. This method is not = > specified in the draft that encourages this local optimisation. > > Warmly > > Roy If the NSEC record has not been verified as secure discard it. If the given name sorts before or matches the NSEC owner name discard it as it does not prove the NXDOMAIN or ENT. If the given name is a subdomain of the NSEC owner name and the NS bit is present and the SOA bit is absent then discard the NSEC as it is from a parent zone. If the next domain name sorts after the NSEC owner name and the given name sorts after or matches next domain name then discard the NSEC record as it does not prove the NXDOMAIN or ENT. If the next domain name sorts before or matches the NSEC owner name and the given name is not a subdomain of the next domain name then discard the NSEC as it does not prove the NXDOMAIN or ENT. You now have a NSEC record that proves the NXDOMAIN or ENT. If the next domain name is a subdomain of the given name you have a ENT otherwise you have a NXDOMAIN. > >=20 > >> There is an attack vector where an RCODE0 can be replaced by RCODE3 = > while > >> keeping the rest of the response completely intact, causing an = > aggressive > >> use enabled cache to deny existing records. > >>=20 > >> These kind of subtleties arent described in the draft, as far as I = > can > >> tell. > >>=20 > >> Roy > >> ___ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > >=20 > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- 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] Special Use Names Summary
On 10/7/16 1:56 PM, Tim Wicinski wrote: > > Special Use Names Summary > > > First, thanks to all for a pretty useful discussion. There were a few > things uncovered which are not in either draft. It does appear that the > draft-tldr-sutld-ps is the very rough consensus choice as a starting > point. Both drafts say useful things, and the chairs would very much > like to see people keep working to get all relevant points into one. The > scoping question of choosing between “What do we think of RFC 6761” and > “What underlying problem do we actually have” came up quite clearly, and > seemed like a key factor to us. Thank you for doing this, sieving the discussion on the adoption was no small effort. > The chairs felt that a limited scope draft was possible, and what we > were looking for. Even with a limited scope draft, we've found we can't > ignore questions about the underlying assumptions behind 6761, both > because they're not fully articulated and because they may not include > several cases we care about. For example: > - what problem do we have because we value uniqueness in domain > names as an architectural principle, regardless of specific strings chosen? > - what problem exists for the IETF even if we say we don’t care what > other groups (ICANN, the Tor Project, open source creators) do? > - what happens if we abandon this work, or deprecate RFC 6761? > > There are also several items which need clarifying, which the WG > discussion may also include and the chairs will work on with the IESG > and the IAB as appropriate. > > - Describing, as much as possible, how this work interlocks with > ICANN’s policy authority over the DNS root zone > - Providing guidelines for IETF WGs > - Providing guidelines for domain name use outside of the IETF > disposing of some distractions that keep coming up > - Clarifying, to the degree possible, who has process authority over > what (IESG, IAB, this WG, other IETF WGS) We have previously sent liason statements to ICANN to make them aware of this work. Personally I would expect that a future liaison statement on outcomes would need to be supported by an ietf consensus call so I look to us being able to offer guidance for such a statement. > Thanks > > Tim/Suzanne > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop