Subject: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 4 Apr 2012 08:20:34 -0400 (EDT)

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Apr 2012 05:41:24 -0700

> 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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2012 14:53:54 +0000

On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote:
> 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.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2012 16:31:00 +0100

Joe Abley <[email-masked]> wrote:
>
> 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.

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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northerly 5 to 7, occasionally 4 at first, increasing gale 8 later
in north Fitzroy. Moderate or rough, becoming very rough later in north
Fitzroy. Showers. Moderate or good.

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Apr 2012 09:23:31 -0700

> subject to a SOA sanity check.

monster.hopcount.ca is serving the fake (empty apart from apex SOA/NS and glue) root zone (and nothing else).

hopcount.ca. has delegation

  empty.hopcount.ca. NS monster.hopcount.ca.

I tested

  unbound 1.4.9
  unbound 1.4.13
  BIND 9.8.1-P1
  Google DNS
  OpenDNS

by sending queries "EMPTY.HOPCOUNT.CA/IN/A" and "EMPTY.HOPCOUNT.CA/IN/PTR".

OpenDNS lied about the answer when I asked for an A, but that's to be expected with their public service (and I guess suggests that there's nothing remarkable about empty.hopcount.ca as far as it is concerned). All other nameservers gave a prompt NXDOMAIN.

I think the observation that this is not actually the same as what the domainers do (since these are negative responses, and domainers return answer section data) is a good one, but I don't see the problem you mention in the wild. Admittedly I only tested a small set of servers.

Joe

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Apr 2012 18:05:26 +0100

Joe Abley <[email-masked]> wrote:
> [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  <[email-masked]>  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.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Apr 2012 18:31:52 +0000

> which BIND is pedantic. Sorry.

bind has a lot of non-pedantic behaviour available as options, but
rarely as the default. if it's important to be able to pass through an
incoherent nxdomain then please say why?

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Apr 2012 12:32:14 -0400

> 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…

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...

> 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…

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)...

> I am very happy to spend time on this.

Me too. This seems both interesting *and* useful...

W

> 
> 
> Joe
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Apr 2012 08:48:53 +1000

+1.

I think a cleaner, simpler coordination framework for how to get things added AND REMOVED from AS112 makes a lot of sense.

I say removed, because at least some discussion has revolved around people wanting domains on there that others believe they have future use of. So de-delegation from AS112 is really important.

I would also like to re-iterate that I think this complements local-delegations. The two techniques should co-exist.

-G

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Thu, 26 Apr 2012 13:10:23 -0400 (EDT)

Alright, some time on my plate ...

> 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…

+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.

> 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