Re: [DNSOP] DNS updates and classless in-addr.arpa delegation/CNAMEs
On 3.6.2015 10:44, Mark Andrews wrote: > In message <556ea478.80...@redhat.com>, Petr Spacek writes: >> I would like early feedback about following idea about interaction between DN >> S >> updates (RFC 2136) and classless IN-ADDR.ARPA delegation (RFC 2317). >> >> In short, the RFC 2317 tells me to fill reverse zone with CNAMEs pointing to >> (potentially) some other zone. >> >> At the same time, an attempt to add a PTR record to a node already containing >> CNAME will fail, possibly without reporting an error to the requester. AFAIK >> BIND 9.9 just prints an error to log but returns NOERROR to the client. >> >> As a result, RFC 2317 breaks dynamic updates for classless reverse zones. > > No, it doesn't. Add a appropriate prerequisite and you will a > error. > > nxrrset owner cname > add owner ptr hostname > > A naive client won't work but RFC 2317 has been around for decades > now so cnames should be handled. I wish it was true. I did some experiments and even latest versions of Windows clients (8 + latest 10 beta) fail to take RFC 2317 into account and fail miserably when attempting to update PTR records. This confirms rumors from support people in the field. nsupdate from BIND 9.9 is basically a low-level tool so it cannot be blamed that it 'just fails' if the CNAME is present, but it also means that 'nsupdate' user has to implement own logic on top of it to handle RFC 2317. I seriously doubt that anybody did that. I feel that this effectively means that significant portion of PTR-updating DNS clients does not work when RFC 2317 is used and this in my eyes justifies a clarification. >> I'm going to sketch -00 draft which will attempt to address this by >> client-side canonization: >> >> The client should attempt to resolve whole chain of CNAME/DNAMEs from >> 1.2.0.192.in-addr.arpa down to terminal node and update the terminal node >> instead of the original name. > > You will get that as a side effect of working out where the zone > cut points are. > > will get back the cname chain (if any) > and the appropriate zone soa if rfc2308 is supported either in the > answer section or in the authority section. I agree with this, but it is not enough, only a first step. Requestor also has to replace original names with the canonicalized versions in prerequisite and update sections of the Update Message otherwise the update will fail with 'out-of-zone' errors. >> Most interesting part of the text will be 'Security Considerations' >> (considering signed updates). >> >> I would welcome early feedback about the idea even before the -00 is publishe >> d. > > This shouldn't require a RFC as is it just apply exisiting RFC but > if it was to recommend that all nodes attempt to add PTR records > for themselves and described handling RFC 2317 as a senario it would > be more useful. Similarly handling DNAME. Here is the first sketch. It does not propose any protocol changes, it is just guidance for DNS UPDATE requestors. This is my very first draft and I struggle with terminology, especially with definition of canonicalization. Any feedback is more than welcome! Petr Spacek @ Red Hat Forwarded Message Subject: New Version Notification for draft-spacek-dnsop-update-clarif-00.txt Date: Mon, 29 Jun 2015 05:04:14 -0700 From: internet-dra...@ietf.org To: Petr Spacek , Petr Spacek A new version of I-D, draft-spacek-dnsop-update-clarif-00.txt has been successfully submitted by Petr Spacek and posted to the IETF repository. Name: draft-spacek-dnsop-update-clarif Revision: 00 Title: Clarifications to the Dynamic Updates in the Domain Name System (DNS UPDATE) specification Document date: 2015-06-29 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-00.txt Status: https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/ Htmlized: https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-00 Abstract: This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some distinctions and a request
Hi Ed, On Thu, Jun 25, 2015 at 12:51:46PM +, Edward Lewis wrote: > >It seems to me that, for any domain name, there are three things that > >are relevant: > > > >1. The namespace. > >2. The registry for that name (in the old-fashioned, not ICANN, sense) > >3. The zone at that name. > > I have to admit that this list isn't clear enough for me. When you same > "name space" are you referring to a domain name space or a more general > name space. I ask because the last entry "the zone" is specific to domain > names. In my view, the namespace is the logical space of all possible domain names. So, it includes any name that has at least one label. Any label may be no more than 63 octets long. The whole thing can only be 255 octets long. In presentation format, each label is separated by a dot. Frequently, the last dot (and the final, null label) is implicit. In this namespace, I claim, there are several registries. One such registry is a special-names registry. This registry has a bunch of rules for ho things get into it. The things that get in are domain names, but they are not necessarily DNS names. In my view, local. and the proposed onion. are both non-DNS domain names. Indeed, their very function is to act as a switch to a resolver, to tell it, "The name anchored here is not in the DNS, but is resolved in some other way." The rest of the registries in the domain name space -- the ones that cover all the parts of the namespace not excluded by the special-names registry -- are DNS domain name registries. One of these is the root registry. In those registries are two kinds of registrations: ones that are there to enable further delegation (a "positive registration", to give this a name), and ones that are there to _prevent_ further delegation (a "negative registration"). For instance, com. is registered in the root zone, as a delegation point. Conversely, IETF is on the reserved strings list in the Applicant Guidebook (section 2.2.1.2.1) and is therefore, I claim, in the registry to prevent further delegation. Similarly, the rule about all 2-letter strings that are not in the ISO 3166 short codes list is such a preventative registration. Finally, there is the zone file, which contains the positive registrations in the DNS. (Naturally, by way of implementation, one could turn all negative registrations into entries in a zone file, by registering TXT records that said, "This name is not registered for resolution on the Internet," or something like that. Let's stipulate that this is a special case, but I don't think it obscures the point I'm trying to make.) > > With "onion" as the root of a namespace for Tor (sorry, maybe the term is > off), it has names in it that are in the "Tor name space". Yes, but as I understand it the rule is that such names are also part of the domain name space. (There could be a future time where some names beneath onion. are actually longer than the DNS would permit, and I don't know whether to call such things "domain names" or not; but it's fortunately not a problem for us today so I'm going to ignore it.) > There's no "zone" in the DNS sense related to this, because this is > not DNS. Yes. > However, there is talk that the TLD "onion." ought to remain, forever, a > non-existant name (as defined in RFC 4592 [The wildcard one]) and that > then means there should be no zone for "onion." I claim that, because of the function of onion., a registration of it in the special names registry effectively takes it out of the DNS name space (while maintaining it in the domain name space). For that reason, onion. MUST NOT be registered in the DNS root; but that's because its name is excluded from the DNS namespace and not because of something special it does with respect to DNS. This is different from (say) ietf., which _is_ in the DNS name space (it's registered there, though negatively). Does this make the distinction I'm trying for any clearer? > These are two very different things. The first is that the name's look > implies how it is resolved (mapped to an address, say). The latter is how > the DNS is impacted by a domain name that looks similar to the name in > question is treated. No, I don't think I was saying that. The first is a case where, if you match that label, you get a signal that you are walking out of the DNS name space and into some other protocol. For instance, if you encounter a domain name with the top-most label "local.", you immediately know that you shouldn't look that up in DNS, but instead in mDNS. The second case is where a name _is_ part of the DNS, but is not registered in some special way. "Example.com" is an example of this: it shouldn't normally give back results in the DNS, because of its special function. > I don't know if this comment is related, and I think I've said this before > (so guilty of repeating myself perhaps), the special-use domain-name > registry isn't very useful unless it indicates what someone
[DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Hi all, So, there is a project underway to roll the DNSSEC root key. There has been much written about this, including SAC063 (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a DNSSEC Root KSK Rollover Plan Design Team, various consultations with the community, many presentations at DNS-OARCs, etc. One of the biggest impediments to actually performing the rollover is that some set of folk will not have performed RFC5011 style rollover, whether because their software doesn't support 5011, because they have statically configured a TA, because the bigger response makes them sad, whatever. The fact that we cannot tell who has only has the old key, and who has both makes the keyroll very scary - we cannot predict who, and how wide scale the outage will be when the old key is removed. I've written a draft that proposes a different way of performing root key rollover that exposes who all has which key - this allows one to know that 99.8% of resolvers have the new key, who has the old one, and who will break. It does this by encoding the current set of TAs that the resolver has into a query, and using that to fetch the new keys. By watching queries at the root one can see the population of people with each TA, and watch that change over time. This was written for root key roll, but is applicable to any TA in the tree. I'd appreciate any feedback, the draft announcment is here: Name: draft-wkumari-dnsop-trust-management Revision: 00 Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors Document date: 2015-06-29 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt Status: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ Htmlized: https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 Abstract: This document describes a simple means for automated updating of DNSSEC trust anchors. This mechanism allows the trust anchor maintainer to monitor the progress of the migration to the new trust anchor, and so predict the effect before decommissioning the existing trust anchor. It is primarily aimed at the root DNSSEC trust anchor, but should be applicable to trust anchors elsewhere in the DNS as well. [ Ed note - informal summary: One of the big issues with rolling the root key is that it is unclear who all is using RFC5011, who all has successfully fetched and installed the new key, and, most importantly, who all will die when the old key is revoked. A secondary problem is that the response sizes suddenly increase, potentially blowing the MTU limit. This document describes a method that is basically CDS, but for the root key (or any other trust anchor). Unlike the CDS record though, this record lives at a special name - by querying for this name, the recursive exposes its list of TAs to the auth server (signalling upstream) . This allows the TA maintainer to predict how many, and who all will break. It also allows the pre-publication of a key before using it, and so avoids the need to double response sizes...] [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.] [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ] W [0]: Full disclosure: Author. -- 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] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Moin! On 29 Jun 2015, at 22:48, Warren Kumari wrote: I've written a draft that proposes a different way of performing root key rollover that exposes who all has which key - this allows one to know that 99.8% of resolvers have the new key, who has the old one, and who will break. It does this by encoding the current set of TAs that the resolver has into a query, and using that to fetch the new keys. By watching queries at the root one can see the population of people with each TA, and watch that change over time. This was written for root key roll, but is applicable to any TA in the tree. So while this might work with future root key rollovers, I think it's to late for this one, as it requires all software (root servers and validating resolvers) to be updated, and one concern that we have with the root key rollover is old software. On another note, how does that interact with the root loopback draft, where the resolver doesn't ask the root at all, but the local copy of the root zone? So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
This looks very much like the draft that Olaf, Johan, and I wrote at the same time MSJ was proposing what we have now. You might want to talk to either Olaf or Johan for more details. And yes, this will fail if any of the loopback drafts are deployed. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 29June2015Monday, at 14:59, Ralf Weber wrote: > Moin! > > On 29 Jun 2015, at 22:48, Warren Kumari wrote: >> I've written a draft that proposes a different way of performing root >> key rollover that exposes who all has which key - this allows one to >> know that 99.8% of resolvers have the new key, who has the old one, >> and who will break. >> It does this by encoding the current set of TAs that the resolver has >> into a query, and using that to fetch the new keys. By watching >> queries at the root one can see the population of people with each TA, >> and watch that change over time. This was written for root key roll, >> but is applicable to any TA in the tree. > So while this might work with future root key rollovers, I think it's to late > for this one, as it requires all software (root servers and validating > resolvers) to be updated, and one concern that we have with the root key > rollover is old software. > > On another note, how does that interact with the root loopback draft, where > the resolver doesn't ask the root at all, but the local copy of the root zone? > > So long > -Ralf > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
There is much simpler way. Just add record to the rootzone that is only signed by the new key. If resolver returns AD bit it has the new key. All that is needed is to sign a Rrset for a long time and add it at to the rootzone and make sure no ZSK signs it. Olafur On Jun 29, 2015 4:49 PM, "Warren Kumari" wrote: > Hi all, > > So, there is a project underway to roll the DNSSEC root key. There has > been much written about this, including SAC063 > (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a > DNSSEC Root KSK Rollover Plan Design Team, various consultations with > the community, many presentations at DNS-OARCs, etc. > > One of the biggest impediments to actually performing the rollover is > that some set of folk will not have performed RFC5011 style rollover, > whether because their software doesn't support 5011, because they have > statically configured a TA, because the bigger response makes them > sad, whatever. The fact that we cannot tell who has only has the old > key, and who has both makes the keyroll very scary - we cannot predict > who, and how wide scale the outage will be when the old key is > removed. > > I've written a draft that proposes a different way of performing root > key rollover that exposes who all has which key - this allows one to > know that 99.8% of resolvers have the new key, who has the old one, > and who will break. > It does this by encoding the current set of TAs that the resolver has > into a query, and using that to fetch the new keys. By watching > queries at the root one can see the population of people with each TA, > and watch that change over time. This was written for root key roll, > but is applicable to any TA in the tree. > > > I'd appreciate any feedback, the draft announcment is here: > Name: draft-wkumari-dnsop-trust-management > Revision: 00 > Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors > Document date: 2015-06-29 > Group: Individual Submission > Pages: 8 > URL: > > https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ > Htmlized: > https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 > > > Abstract: >This document describes a simple means for automated updating of >DNSSEC trust anchors. This mechanism allows the trust anchor >maintainer to monitor the progress of the migration to the new trust >anchor, and so predict the effect before decommissioning the existing >trust anchor. > >It is primarily aimed at the root DNSSEC trust anchor, but should be >applicable to trust anchors elsewhere in the DNS as well. > >[ Ed note - informal summary: One of the big issues with rolling the >root key is that it is unclear who all is using RFC5011, who all has >successfully fetched and installed the new key, and, most >importantly, who all will die when the old key is revoked. A >secondary problem is that the response sizes suddenly increase, >potentially blowing the MTU limit. This document describes a method >that is basically CDS, but for the root key (or any other trust >anchor). Unlike the CDS record though, this record lives at a >special name - by querying for this name, the recursive exposes its >list of TAs to the auth server (signalling upstream) . This allows >the TA maintainer to predict how many, and who all will break. It >also allows the pre-publication of a key before using it, and so >avoids the need to double response sizes...] > >[ Ed note: Text inside square brackets ([]) is additional background >information, answers to frequently asked questions, general musings, >etc. They will be removed before publication.] > >[ This document is being collaborated on in Github at: >https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The >most recent version of the document, open issues, etc should all be >available here. The authors (gratefully) accept pull requests ] > > > > W > [0]: Full disclosure: Author. > > -- > 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Bill, > This looks very much like the draft that Olaf, Johan, and I wrote at the same > time MSJ was proposing what we have now. > You might want to talk to either Olaf or Johan for more details. Don't suppose anyone has a copy of that draft? > And yes, this will fail if any of the loopback drafts are deployed. Sorry, I must be missing something obvious. Why? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
On Mon, Jun 29, 2015 at 5:59 PM, Ralf Weber wrote: > Moin! > > On 29 Jun 2015, at 22:48, Warren Kumari wrote: >> >> I've written a draft that proposes a different way of performing root >> key rollover that exposes who all has which key - this allows one to >> know that 99.8% of resolvers have the new key, who has the old one, >> and who will break. >> It does this by encoding the current set of TAs that the resolver has >> into a query, and using that to fetch the new keys. By watching >> queries at the root one can see the population of people with each TA, >> and watch that change over time. This was written for root key roll, >> but is applicable to any TA in the tree. > > So while this might work with future root key rollovers, I think it's to > late for this one, as it requires all software (root servers and validating > resolvers) to be updated, and one concern that we have with the root key > rollover is old software. Well, yes and no. I'd also through that there was no point in trying to get this done soon -- but then, after chatting with some folk, I have reconsidered that position... *When* exactly the root key will actually roll is still unclear -- I've heard estimates from "the middle of next year" to "sometime in 2018 or 2019". I'm starting an informal poll - my choice is July 2017. If folk send me their guesses I'll collect them and we'll figure out some sort of prize for whoever gets closest. Anyway, let's say it *is* mid-2017, just for arguments sake. Let's also say that ISC and Unbound decide to implement this (much of the logic is already in there), and have it done by mid 2016 (that's ~1year). There is a *really* long tail of people who don't upgrade their name-servers, but there are also a whole bunch who do, especially if there is a security announcement / issue that gets patched. Let's say 10% of people upgrade (note that these are not the ones that are likely to have a key-roll issue, kinda by definition). Whatever the case, at least there will be *some* visibility at the root of the people who are not likely to go "Boom". IANA can publish the _tag record for the new key, or they can just rely on RFC 5011 (note that this doesn't preclude using RFC5011) - whatever the case, there will be a signal. If they choose to publish the _tag record, it will save those people who are A: upgraded and B: unable to get large responses... > > On another note, how does that interact with the root loopback draft, where > the resolver doesn't ask the root at all, but the local copy of the root > zone? I think it is OK -- the draft-ietf-dnsop-root-loopback draft says that resolvers download the root zone and serve it on their loopbacks. Compliant resolvers will then query themselves and this will Just Work. You do lose most of the purpose of this, which is to get visibility -- but, those name-servers are not *really* querying the root, and so... well... draft-ietf-dnsop-root-loopback is also really designed for niche cases W [0]: This contest void where prohibited, not open to ICANN / IANA employees and their immediate families, bribery not allowed, unless I get a cut too... > > So long > -Ralf -- 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] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson wrote: > There is much simpler way. > Just add record to the rootzone that is only signed by the new key. > If resolver returns AD bit it has the new key. > > All that is needed is to sign a Rrset for a long time and add it at to the > rootzone and make sure no ZSK signs it. ... and know where the nameservers are, and be able to query the nameservers to see if they are returning the AD bit. This requires that they are open recursive, that IANA (or someone) is able to query them, or something similar... Unless I've completely misunderstood? W > > Olafur > > On Jun 29, 2015 4:49 PM, "Warren Kumari" wrote: >> >> Hi all, >> >> So, there is a project underway to roll the DNSSEC root key. There has >> been much written about this, including SAC063 >> (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a >> DNSSEC Root KSK Rollover Plan Design Team, various consultations with >> the community, many presentations at DNS-OARCs, etc. >> >> One of the biggest impediments to actually performing the rollover is >> that some set of folk will not have performed RFC5011 style rollover, >> whether because their software doesn't support 5011, because they have >> statically configured a TA, because the bigger response makes them >> sad, whatever. The fact that we cannot tell who has only has the old >> key, and who has both makes the keyroll very scary - we cannot predict >> who, and how wide scale the outage will be when the old key is >> removed. >> >> I've written a draft that proposes a different way of performing root >> key rollover that exposes who all has which key - this allows one to >> know that 99.8% of resolvers have the new key, who has the old one, >> and who will break. >> It does this by encoding the current set of TAs that the resolver has >> into a query, and using that to fetch the new keys. By watching >> queries at the root one can see the population of people with each TA, >> and watch that change over time. This was written for root key roll, >> but is applicable to any TA in the tree. >> >> >> I'd appreciate any feedback, the draft announcment is here: >> Name: draft-wkumari-dnsop-trust-management >> Revision: 00 >> Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors >> Document date: 2015-06-29 >> Group: Individual Submission >> Pages: 8 >> URL: >> >> https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ >> Htmlized: >> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 >> >> >> Abstract: >>This document describes a simple means for automated updating of >>DNSSEC trust anchors. This mechanism allows the trust anchor >>maintainer to monitor the progress of the migration to the new trust >>anchor, and so predict the effect before decommissioning the existing >>trust anchor. >> >>It is primarily aimed at the root DNSSEC trust anchor, but should be >>applicable to trust anchors elsewhere in the DNS as well. >> >>[ Ed note - informal summary: One of the big issues with rolling the >>root key is that it is unclear who all is using RFC5011, who all has >>successfully fetched and installed the new key, and, most >>importantly, who all will die when the old key is revoked. A >>secondary problem is that the response sizes suddenly increase, >>potentially blowing the MTU limit. This document describes a method >>that is basically CDS, but for the root key (or any other trust >>anchor). Unlike the CDS record though, this record lives at a >>special name - by querying for this name, the recursive exposes its >>list of TAs to the auth server (signalling upstream) . This allows >>the TA maintainer to predict how many, and who all will break. It >>also allows the pre-publication of a key before using it, and so >>avoids the need to double response sizes...] >> >>[ Ed note: Text inside square brackets ([]) is additional background >>information, answers to frequently asked questions, general musings, >>etc. They will be removed before publication.] >> >>[ This document is being collaborated on in Github at: >>https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The >>most recent version of the document, open issues, etc should all be >>available here. The authors (gratefully) accept pull requests ] >> >> >> >> W >> [0]: Full disclosure: Author. >> >> -- >> 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/
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Olafur Gudmundsson wrote: > > There is much simpler way. > Just add record to the rootzone that is only signed by the new key. > If resolver returns AD bit it has the new key. > > All that is needed is to sign a Rrset for a long time and add it at to > the rootzone and make sure no ZSK signs it. > this. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Atlas probes can help us we can even measure this from webpages, cellphones, OS updates can add a test etc. Olafur On Jun 29, 2015 7:33 PM, "Warren Kumari" wrote: > On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson > wrote: > > There is much simpler way. > > Just add record to the rootzone that is only signed by the new key. > > If resolver returns AD bit it has the new key. > > > > All that is needed is to sign a Rrset for a long time and add it at to > the > > rootzone and make sure no ZSK signs it. > > ... and know where the nameservers are, and be able to query the > nameservers to see if they are returning the AD bit. This requires > that they are open recursive, that IANA (or someone) is able to query > them, or something similar... > > > Unless I've completely misunderstood? > > W > > > > > > Olafur > > > > On Jun 29, 2015 4:49 PM, "Warren Kumari" wrote: > >> > >> Hi all, > >> > >> So, there is a project underway to roll the DNSSEC root key. There has > >> been much written about this, including SAC063 > >> (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a > >> DNSSEC Root KSK Rollover Plan Design Team, various consultations with > >> the community, many presentations at DNS-OARCs, etc. > >> > >> One of the biggest impediments to actually performing the rollover is > >> that some set of folk will not have performed RFC5011 style rollover, > >> whether because their software doesn't support 5011, because they have > >> statically configured a TA, because the bigger response makes them > >> sad, whatever. The fact that we cannot tell who has only has the old > >> key, and who has both makes the keyroll very scary - we cannot predict > >> who, and how wide scale the outage will be when the old key is > >> removed. > >> > >> I've written a draft that proposes a different way of performing root > >> key rollover that exposes who all has which key - this allows one to > >> know that 99.8% of resolvers have the new key, who has the old one, > >> and who will break. > >> It does this by encoding the current set of TAs that the resolver has > >> into a query, and using that to fetch the new keys. By watching > >> queries at the root one can see the population of people with each TA, > >> and watch that change over time. This was written for root key roll, > >> but is applicable to any TA in the tree. > >> > >> > >> I'd appreciate any feedback, the draft announcment is here: > >> Name: draft-wkumari-dnsop-trust-management > >> Revision: 00 > >> Title: Simplified Updates of DNS Security (DNSSEC) Trust > Anchors > >> Document date: 2015-06-29 > >> Group: Individual Submission > >> Pages: 8 > >> URL: > >> > >> > https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 > >> > >> > >> Abstract: > >>This document describes a simple means for automated updating of > >>DNSSEC trust anchors. This mechanism allows the trust anchor > >>maintainer to monitor the progress of the migration to the new trust > >>anchor, and so predict the effect before decommissioning the existing > >>trust anchor. > >> > >>It is primarily aimed at the root DNSSEC trust anchor, but should be > >>applicable to trust anchors elsewhere in the DNS as well. > >> > >>[ Ed note - informal summary: One of the big issues with rolling the > >>root key is that it is unclear who all is using RFC5011, who all has > >>successfully fetched and installed the new key, and, most > >>importantly, who all will die when the old key is revoked. A > >>secondary problem is that the response sizes suddenly increase, > >>potentially blowing the MTU limit. This document describes a method > >>that is basically CDS, but for the root key (or any other trust > >>anchor). Unlike the CDS record though, this record lives at a > >>special name - by querying for this name, the recursive exposes its > >>list of TAs to the auth server (signalling upstream) . This allows > >>the TA maintainer to predict how many, and who all will break. It > >>also allows the pre-publication of a key before using it, and so > >>avoids the need to double response sizes...] > >> > >>[ Ed note: Text inside square brackets ([]) is additional background > >>information, answers to frequently asked questions, general musings, > >>etc. They will be removed before publication.] > >> > >>[ This document is being collaborated on in Github at: > >>https://github.com/wkumari/draft-wkumari-dnsop-trust-management. > The > >>most recent version of the document, open issues, etc should all be > >>available here. The authors (gratefully) accept pull requests ] > >> > >> > >> > >> W > >> [0]: Full disclosure: Author. > >> > >> -- > >> I
Re: [DNSOP] DNS updates and classless in-addr.arpa delegation/CNAMEs
Section 3 contains a obvious error "192.0.2.1 -> 2.0.192.in-addr.arpa." should be "192.0.2.1 -> 1.2.0.192.in-addr.arpa." -- 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] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
Why, yes, I still do. (and it can be found in the IEtF archives) https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01 As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does it matter if the origin IP of the root zone being served is sporadically distributed? It seems that one could not presume to have the data to assert the penetration of the new keys nor the origin of the stale keys, if that information was diffused through the IP address space. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 29June2015Monday, at 16:28, David Conrad wrote: > Bill, > >> This looks very much like the draft that Olaf, Johan, and I wrote at the >> same time MSJ was proposing what we have now. >> You might want to talk to either Olaf or Johan for more details. > > Don't suppose anyone has a copy of that draft? > >> And yes, this will fail if any of the loopback drafts are deployed. > > Sorry, I must be missing something obvious. Why? > > Regards, > -drc > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
>>> And yes, this will fail if any of the loopback drafts are deployed. >> Sorry, I must be missing something obvious. Why? > As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does it > matter if the origin IP of the root zone being served > is sporadically distributed? It seems that one could not presume to have > the data to assert the penetration of the new keys nor the > origin of the stale keys, if that information was diffused through the IP > address space. Ah. I thought when you said 'will fail', you meant the scheme itself wouldn't work. Yes, we won't be able to see anyone who does root-loopback, but that is no different than the existing situation, right? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
On 29June2015Monday, at 19:07, David Conrad wrote: And yes, this will fail if any of the loopback drafts are deployed. >>> Sorry, I must be missing something obvious. Why? >> As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does >> it matter if the origin IP of the root zone being served >> is sporadically distributed? It seems that one could not presume to have >> the data to assert the penetration of the new keys nor the >> origin of the stale keys, if that information was diffused through the IP >> address space. > > Ah. I thought when you said 'will fail', you meant the scheme itself wouldn't > work. Yes, we won't be able to see anyone who does root-loopback, but that is > no different than the existing situation, right? > Actually, it makes it worse. _IF_ a scheme to simplify updates comes to fruition, in todays networks there are (presumptive) a dozen+1 roots with their associated IP’s (call it 26 ip addresses) that need to be monitored. The downside is the EXISTING unknown private roots who we don’t see PLUS the (again presumptive) number of new sites which will adopt root loopback to gain a “legitimate” root nameserver in their networks. When this happens in largish networks (lets pick on China) then we will have added yet another layer of operational coordination/complexity with the need to synchronize key rollovers between (very big) islands of trust. So it can be made to work, but the layers of gum, bailing wire, and duct tape are, IMHO, problematic. /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
