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
