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

2011-07-15 Thread Phil Regnauld
Joe Abley (jabley) writes:
 
  (b) Inclusion of IPv6-related RFC6303-style zones on AS112 servers
  (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 :)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2011-07-14 Thread Peter Koch
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2011-07-14 Thread Joe Abley

On 2011-07-14, at 12:02, Peter Koch wrote:

 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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop