Subject: [DNSOP] AS112/local zones documents published -- and next steps

From: Peter Koch <[email-masked]>
Date: Thu, 14 Jul 2011 18:02:49 +0200

Dear WG,

with the recent advent of

        RFC 6303, Locally Served DNS Zones       [BCP0163]
        RFC 6304, AS112 Nameserver Operations
        RFC 6305, I'm Being Attacked by PRISONER.IANA.ORG!

I'd like to express thanks for the hard work to Mark, Joe, and William as the
editors of these three documents and everybody involved in getting these
reviewed and published.

While the first RFC received BCP status as desired, RFC 6305, intended
for end user consumption, did not make it to FYI. The reason is that during
processing the IESG decided to refrain from issuing new FYI numbers.
Discussion of the conclusion of the FYI series is happening on the RFC-Interest
and the main IETF lists.
Still, the document will be a useful reference to point concerned operators
to, independent of formal status.

With the trilogy published, there is new work in front of us.  Stephen and
me have reserved space on the Quebec agenda for a closer look at

        <draft-michaelson-as112-ipv6-00.txt>
        <draft-sotomayor-as112-ipv4-cull-00.txt>

Both drafts strive to extend the AS112 service and we'd like to ask for
reviews here.  The audience in Prague was already sympathetic to George's
and Geoff's proposal, but it seems prudent to look into this in a combined
way and then distribute or combine work as appropriate.  Please help
getting things forward by reviewing the documents and making suggestions
for how to address the topic.

-Peter

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Jul 2011 13:53:36 -0400

>        <draft-michaelson-as112-ipv6-00.txt>

So, it seems to me that there are various aspects to consider in the general area of extending the AS112 project for IPv6. These include:

 (a) IPv6 transport for AS112 nameservers (some work is already being done on this)
 (b) Inclusion of IPv6-related RFC6303-style zones on AS112 servers

The open issues on ggm's draft I think include:

 (1) whether this is the right draft to document (a) above
 (2) whether the list of zones specified is complete and accurate

In addition to these process questions there are some improvements that I could think be made to the IANA Considerations section, but those are largely editorial and non-substantive in this context.

(b) and (2) above also prompt the question of how we (more generally) might manage the zones served by AS112 nodes, given that there is only loose coordination between AS112 node operators and potentially a significant deployment of (globally) invisible AS112 nodes which serve captive audiences (enterprises, ISPs own customers, etc). There is a risk, depending on the update mechanism, that additional zones delegated to the existing AS112 servers might be lame on a significant number of servers, and the impact of that lameness ought to be assessed.

>        <draft-sotomayor-as112-ipv4-cull-00.txt>

wfm's draft (above) contains an analogous proposal to (b) above, but for various new v4-related reverse zones.

In addition we now have a registry of locally-served zones, per RFC6303, and we might consider mechanisms to update AS112 nodes from that registry (or constrain the procedures for updating that registry also to consider AS112 support for the zones, as they are added).

Finally, Stuart Cheshire's draft draft-cheshire-dnsext-special-names-01 proposes the creation of a registry of special-use names, and draft-cheshire-dnsext-multicastdns-14 requests that that the IANA reserves other domains such as ".local" and "254.169.in-addr.arpa" which (like the zones currently delegated to the AS112 servers) have only local significance.

It feels like there's an opportunity here to align these various registries and knit in some process relating to the AS112 project. What exists right now, together with what is proposed to exist, is a little messy.

Joe

---

From: Phil Regnauld <[email-masked]>
Date: Fri, 15 Jul 2011 17:40:22 +0200

>  (2) whether the list of zones specified is complete and accurate

	[...]

> (b) and (2) above also prompt the question of how we (more generally)
> might manage the zones served by AS112 nodes, given that there is
> only loose coordination between AS112 node operators and potentially
> a significant deployment of (globally) invisible AS112 nodes which
> serve captive audiences (enterprises, ISPs own customers, etc).

	... all of whom may have a voluntarily incomplete implementation
	of AS112 zones on, or upstream of, their recursive servers - not
	the least because they may themselves be using the networks that
	the reverse zones provide reverse information for.

> There is a risk, depending on the update mechanism, that additional
> zones delegated to the existing AS112 servers might be lame on a
> significant number of servers, and the impact of that lameness ought
> to be assessed.

	With regards to private AS112 announcement leaking from these
	servers ?  Or did you have other things in mind ?
	Would make sense to dig a bit deeper on the effect.

> In addition we now have a registry of locally-served zones, per
> RFC6303, and we might consider mechanisms to update AS112 nodes from
> that registry (or constrain the procedures for updating that registry
> also to consider AS112 support for the zones, as they are added).

	Got any ideas on that front already ?  And, where would the the "official"
	list of locally-served zones reside ?  draft-cheshire-dnsext-special-names-01
	suggest that "IANA needs to create a new registry of Special-Use Domain
	Names."

> It feels like there's an opportunity here to align these various
> registries and knit in some process relating to the AS112 project.
> What exists right now, together with what is proposed to exist, is a
> little messy.

	Sounds like a plan :)