[DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
All, It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have posted version 03 for your consideration. Thanks, wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
On 2012-04-04, at 08:20, William F. Maton Sotomayor wrote: It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have posted version 03 for your consideration. I think that we need a better mechanism to avoid lame delegations to the AS112 servers, given their loosely-coordinated nature. The add/drop problem for those servers (the difficulty in requesting zone changes across from a potentially wide and unknown population of server administrators, and being effectively unable to measure whether those changes are complete) is a fundamental weakness in the 112 project as it is operated today. I like the idea that came up in Québec (which I shall attribute to Warren Kumari since I've seen other people do that, although I was not in the room at the time) that the add/drop problem is a lot simpler if every AS112 node hosts the zone $ORIGIN . @ SOA ... NS something NS sensible and answers authoritatively on the addresses corresponding to something and sensible, returning NXDOMAIN for everything in the entire namespace apart from . (for which they ought never receive queries anyway). This is ugly to some eyes, but it works for domainers and it ought to work for us too. Any zones that were subsequently delegated to something and sensible (e.g. as part of an IANA action) would be immediately supported with no need for changes on any of the nodes offering service for something and sensible. Given the installed base of AS112 servers, and again given their loosely-coordinated nature, I would suggest assigning one new IPv4 /24 and one new IPv6 /48 prefix, with both something and special getting one address out of each. We could then encourage AS112 operators to host the empty root zone on nameserver listening to the appropriate addresses, originating the new prefixes from AS 112, using the mailing list and associated resources mainly managed by William. Once by some measure the new prefixes are propagating and nameservers are answering, we could redelegate the zones currently delegated to blackhole-1.iana.org and blackhole-2.iana.org to the new servers, and retire 192.175.48.0/24. I think renumbering is worthwhile since we have no way of measuring the extent to which AS112 servers are actually deployed (e.g. there may be many deployed for private use inside ASes that we can't easily see.) Enough public AS112 server operators are responsive on William's list that I don't see a problem in getting sufficient buy-in to a new scheme such as this to make it viable quickly, however. I think the work to be done in dnsop could be summarised as: - update RFC 6304 and 6305 as necessary - write something that cleans up and unifies the various registries that currently contain RFC 6303-like names, with appropriate IANA actions (ipv4-cull contains some references in section 2, see also draft-cheshire-dnsext-special-names) - write something that provides guidance for future document authors on when they should specify an IANA action to add a new zone to the grand unified as112 registry and cause a delegation to something and sensible to happen. This document (as112-cull) attempts to do some of this work, but I don't see a reason to bite off small mouthfuls if we can expend a small amount of extra effort and eat the whole sandwich at once. I am very happy to spend time on this. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote: It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have posted version 03 for your consideration. i think it should be adopted, but i have no time to work on it, so my vote may not count. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
Joe Abley joe.ab...@icann.org wrote: On 2012-04-04, at 11:31, Tony Finch wrote: I think BIND treats NXDOMAIN replies with the wrong authority as a FORMERR. Domainers are returning positive replies which BIND does not subject to a SOA sanity check. [real test] All other nameservers gave a prompt NXDOMAIN. Thanks for checking that. I obviously mis-remembered the exact way in which BIND is pedantic. Sorry. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Plymouth: Cyclonic mainly northerly, becoming northeasterly, 4 at first in east, otherwise 5 to 7, but occasionally gale 8 in west. Very rough at first in northwest, otherwise moderate or rough. Showers. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A)
After a long delay, I have revisited the DNSSEC Operational Practices, Version 2 I-D and performed a full review from scratch for the most recent draft version, draft-ietf-dnsop-rfc4641bis-10. For convenience, and to accommodate message size limitations, I have split my review comments into 3 parts: (A) Technical flaws, (B) Editorial flaws, and (C) Editorial nits Only the first two parts will be sent to the dnsop list, the bulky third part is given as fodder to the authors only. Here we go with part (A); please consider to provide feedback for the items below on the list. (A) Technical flaws (A.1) Normative set of documents defining DNSSEC In Section 1, 1st para, the draft says: This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the | DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to | deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 | [RFC4035]). [...] However, the DNSSEC WG once has made the decision to include some other documents into the list of what should be regarded as the integral set of core documents defining DNSSEC[bis]. IIRC, that decision has been made in late 2009, and consequentially it has been recorded in the AXFR RFC (see section 2, page 7 of RFC 5936). These additions are: - RFC 4509 , - RFC 5155 , - RFC 5702 , and - draft-ietf-dnsext-dnssec-bis-updates (now at draft version -16 and expected to be submitted to the IESG very soon, likely in parallel to this memo). Therefore, I suggest to amend the above see list in the draft by adding these four documents, and accordingly to promote the References to them to Normative (the dnssec-bis-updates I-D needs to be added to the References). (A.2) Section 1.1 -- improper/imprecise description of key usage Section 1.1 improperly talks about public key usage in _key exchanges_. However, in the context of DNSSEC, the public part of asymmetric key pairs are used for _signature verification_ , and only that usage is relevant for this document. So please change: OLD: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in key exchanges. ^ NEW: [...] It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the | public part that is used in signature verification. ^^ (A.3) Section 3.4.1 -- improved section title In Section 3.4, | 3.4. Cryptographic Considerations ... I suggest to make the title of Section 3.4.1 more precise. OLD: | 3.4.1. Key Algorithm NEW: | 3.4.1. Signature Algorithm or: | 3.4.1. Digital Signature Algorithm or: | 3.4.1. Digital Signature and Hash Algorithms (A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA Given the pressure by important governmental/international stakeholders in support of Elliptic Curve (EC) cryptography and the large amount of DNS response packet space consumed by RSA (and DSA) keys and signatures, I strongly recommend to give the reader a glimpse of perspective on ECDSA usage with DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor queue in state RFC-Editor and already supported by major DNS implementations. For instance, it would IMO make sense to add at the end of Section 3.4.1 or 3.4.2 a new paragraph like this: | Operators concerned with performance and key/signature size issues | related to RSA and DSA usage with DNSSEC should follow the ongoing | standardization -- and consequential implementation -- progress for | the use of digital signature algorithms based on Elliptic Curve (EC) | Cryptography with DNSSEC, which promises much shorter key and | signature sizes than RSA/DSA for equivalent cryptographic strenght. | In particular, the use of ECDSA with DNSSEC is now specified | [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in | the foreseeable future. (A.5) Section 4.1.1.2, 2nd bullet below Figure 3 and 2nd-to-last para For completeness and consistency with other parts of the document, I strongly recommend to expand on the present text and explicitly mention the propagation delay that needs to be taken into consideration, beyond the TTL-based cache expiry period. (See also the dnsop-dnssec-key-timing draft.) a) 2nd bullet OLD: new DNSKEY: At the New DNSKEY stage (SOA serial 1) DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need | to continue until all data from version 0 of the zone has expired from remote
