Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
Alright, some time on my plate ... On Wed, 4 Apr 2012, Joe Abley wrote: 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 +1. It's needs more testing admittedly, and I think having an extra prefix as a test to demonstrate how it would work would be beneficial before operational roll-out, but I'm getting way ahead of this already. As George subsequently stated, there needs to be a deletion process just as there's a removal process. - 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. Yeah, cull is actually part I of II, the second draft was destined to include a process for adding/removing plus maintaining AS112 servers in general, an exposition on lameness in AS112, etc. But that can be rolled into a possible bis. I am very happy to spend time on this. I as well. 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 Apr 4, 2012, at 8:41 AM, Joe Abley wrote: 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 Yah, guilty as charged, although you may be thinking that I had thought this through more / wasn't just spouting the first thing that came into ma heid... $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. And after some though I posted this on the as112 list: https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000212.html A number of the operators seemed supportive (and I'm fairly sure I threatened to write it up as a draft but then got sidetracked)... 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. Me too. This seems both interesting *and* useful... W Joe ___ 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
[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
