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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
