[DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-09.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 : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename: draft-ietf-dnsop-rfc4641bis-09.txt Pages : 70 Date: 2012-02-14 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-09.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi WG, Review from Stephen and Peter resulted in a new version of DNSSEC Operational Practices, Version 2. Besides editorial changes, the most important changes are: * The third school of thought for rolling a KSK that is not a trust anchor (in section 3.2.1), that it should only be done when it is known or strongly suspected that the key can be or has been compromised, is extended with: or when a new algorithm or key storage is required. * In section 4.1.1.2 on Double Signature Zone Signing Key Rollover, a recommendation on the duration on the new DNSKEY phase was removed, it was being too conservative. * Section 4.3.5.1. on Cooperating DNS operators adds clarifying text for Figure 9: Rollover for cooperating operators. * An additional, clarifying diagram for the alternative approach on rollover for cooperating operators is given in Figure 14, Appendix D. Best regards, Matthijs On 02/14/2012 11:46 AM, internet-dra...@ietf.org wrote: 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 : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename: draft-ietf-dnsop-rfc4641bis-09.txt Pages : 70 Date : 2012-02-14 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-09.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOjxkAAoJEA8yVCPsQCW5AH0H/AyvPq0j8IZ2mgbh7B03I9ES jn75pcNuWfP1Cmk62BvuZKO1ij4geDYS6PlX0Lyyk+uJpkBn/ataRABfm0BnpOyp ermVMEHyZs7n7bld6N1GuUXKRVADFT+jxZ5ZtovUu+2Ft6+RgERNsC+3B4g0NBfl UaawuOo3hZ29JYu0aofIk4oI1j2ARhiJ39j4MN4/6iYSEygdH/qW5hirg2MdnImR lhkNVA+uynhb0ZhLEop6R6yG8DsIilGHlg6nQ8yk/dJfvkAtsKrcQXXJxBH6Sh7N /8SieCLLlXnCym46r41O/tKkT/JVWk146CPSkX7n/tbRGELEOJF4xzzy5B4GS8U= =m7XX -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
At 21:39 + 2/9/12, bmann...@vacation.karoshi.com wrote: I think that starting work on such a draft is a great idea -BUT- in the mean time do not let perfect get in the way of good enough. I beleive Terry agreed with that line of thnking. Of the existing Operators, A, B, E, G, H, J, L, and M have made positive comments and worked on upgrading this base text provided by one of the Operators. Is your opinion / argument strong enough to stop work on this draft? As David says, why is this document being republished? Is there some deadline? This is a document not code, and not even a first document but a revision. If a revision is not perfect at the time it is published, it's pretty much not worth publishing. Especially an update document - we already have an RFC on this, why update it with another RFC that inaccurately describes the state of the world. My concern is that future RFPs and contracts will cite this as a document to comply with. That is when it becomes my pain, even if the job at hand is not operating a root server. I especially like Joe's point #3. That said, I'd love to see a revamped version, if you have the time to copy-edit/reorgnize the document. I do not recommend publishing the document as is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Mon, Feb 06, 2012 at 07:12:56PM +, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote a message of 49 lines which said: Any more? One governance question. As far as I know (I am not a root name server operator), several of the root name servers already comply with the (very strong) requirments of this document. But not all. If the document is published, what will happen of them? In other words, what is the goal of the document? Exercice some pressure or more? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 14 Feb 2012, at 16:34, Stephane Bortzmeyer wrote: One governance question. As far as I know (I am not a root name server operator), several of the root name servers already comply with the (very strong) requirments of this document. But not all. If the document is published, what will happen of them? We report them to the Internet Police's Root Server Department. :-) To be less flippant, I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not. In other words, what is the goal of the document? Exercice some pressure or more? IMO RFC2870bis is probably never going to be aligned with what is actually done to run a real root server. Discussion of some of those practices probably won't be in the public domain for a while anyway. That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 6:17 AM, Edward Lewis wrote: At 21:39 + 2/9/12, bmann...@vacation.karoshi.com wrote: Is your opinion / argument strong enough to stop work on this draft? As David says, why is this document being republished? A question I'll note has not been answered. My concern is that future RFPs and contracts will cite this as a document to comply with. Agreed. A BCP on how best to provide a highly resilient DNS service would probably be useful. The document in question isn't close. At best, it feels like a bit of self-congradulatory back-patting for those root server operators that actually come close to what the document describes. At worst, it can be seen as an attempt at obfuscation of the fact that the root server operators (with one notable exception) are _NOT_ subject to RFPs, contracts, or any other form of enforcement. That said, I'd love to see a revamped version, if you have the time to copy-edit/reorgnize the document. I do not recommend publishing the document as is. +1 Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 8:56 AM, Jim Reid wrote: I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not. And if no acceptable answer is provided? Sorry, rhetorical question: can't stop myself from kicking the brown stain that used to be a dead horse. That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 2/14/2012 5:20 PM, David Conrad wrote: ... I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1. there are a lot of important non-root dns servers, and the collected wisdom of all of there operators would be a good thing to gather and peer-review and publish. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 9:22 AM, Paul Vixie wrote: are you sharing insider knowledge from your time as IANA GM here? Nope. i thought that ICANN and VeriSign were both under enforceable contracts with respect to their role as root name server operators. As far as I'm aware (and happy for any of the root operators to correct me), the only actual contract is between U.S. Dept. of Commerce and VeriSign for the operation of the A (and J?) root server(s). That's part of the irrationality of root service -- it isn't even clear between whom contracts should be. inside baseball warning. the agreement signed between ISC and ICANN on january 23 2008 is not enforceable in that it does not specify any recourse for either party due to any nonperformance by the other party. Yep. We acknowledge you exist, you acknowledge we exist, and we might think about discussing the possibility of perhaps considering doing some undefined stuff someday in the future. Or maybe not. With that said, it was a step in the right direction. Not aware of any further steps, but I haven't been paying attention. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02
Dear DNS community, FYI: There is currently a document in GEOPRIV WGLC that makes use of NAPTR records in the reverse DNS hierarchy, and employs a tree-walking algorithm to locate records at points other than terminal points in the hierarchy (e.g., /32 and /48 instead of /128). If you have comments on this draft, please reply to geop...@ietf.org by 27 Feb 2012. Thanks a lot, --Richard Begin forwarded message: From: Alissa Cooper acoo...@cdt.org Date: February 14, 2012 10:20:28 AM EST To: GEOPRIV WG geop...@ietf.org Subject: [Geopriv] WGLC: draft-ietf-geopriv-res-gw-lis-discovery-02 This is a GEOPRIV Working Group Last Call for comments on draft-ietf-geopriv-res-gw-lis-discovery-02 Please send your comments to the GEOPRIV list by 27 February 2012. As always, please remember to send a note in if you've read the document and have no other comments other than its ready to go - we need those as much as we need I found a problem. ___ Geopriv mailing list geop...@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] BCP for important name servers?
On 14 Feb 2012, at 17:20, David Conrad wrote: That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1 Though until that comes along RFC2870(bis) is probably the best hammer- shaped object for that nail-shaped problem. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP for important name servers?
On Feb 14, 2012, at 10:16 AM, Jim Reid wrote: On 14 Feb 2012, at 17:20, David Conrad wrote: That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1 Though until that comes along RFC2870(bis) is probably the best hammer-shaped object for that nail-shaped problem. A few people have asked, but we haven't gotten any real answer, on what the nail-shaped problem is. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
