Subject: Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

From: Shane Kerr <[email-masked]>
Date: Thu, 10 Jun 2010 17:38:02 +0200

Stephen,

On Mon, 2010-05-31 at 10:25 +0100, Stephen Morris wrote:
> I think the local zones draft is just about there, but a couple more
> questions:
> 
> The last revision included the ORCHID addresses.  They are not
> routable but, unusually, they are time-limited - the assignment is set
> to be revoked in 2014.  So there is the question as to whether the
> address range should be in the draft (or should be marked with this
> caveat).
> 
> The ORCHID address range is taken from the IANA special purpose IPv6
> address block, which is reserved - amongst other things - for testing
> and experimental use.  Currently it also includes address assignments
> for TEREDO and benchmarking.  Should the draft mention this address
> range and/or these assignments?

I think excluding testing & experimental addresses is potentially
dangerous. For example, it is possible that one of these may need DNS
for an Internet-wide experiment.

In any case, I don't think there is much benefit by including these
blocks. I propose the ORCHID and the rest of the special purpose IPv6
addresses be left out of the list of local zones, and treated normally.

--
Shane

---

From: Derek Diget <[email-masked]>
Date: Fri, 11 Jun 2010 16:23:30 -0400 (EDT)

On Jun 10, 2010 at 17:38 +0200, Shane Kerr wrote:
=>On Mon, 2010-05-31 at 10:25 +0100, Stephen Morris wrote:
=>> I think the local zones draft is just about there, but a couple more
=>> questions:
=>> 
=>> The last revision included the ORCHID addresses.  They are not
=>> routable but, unusually, they are time-limited - the assignment is set
=>> to be revoked in 2014.  So there is the question as to whether the
=>> address range should be in the draft (or should be marked with this
=>> caveat).
=>> 
=>> The ORCHID address range is taken from the IANA special purpose IPv6
=>> address block, which is reserved - amongst other things - for testing
=>> and experimental use.  Currently it also includes address assignments
=>> for TEREDO and benchmarking.  Should the draft mention this address
=>> range and/or these assignments?
=>
=>I think excluding testing & experimental addresses is potentially
=>dangerous. For example, it is possible that one of these may need DNS
=>for an Internet-wide experiment.
=>
=>In any case, I don't think there is much benefit by including these
=>blocks. I propose the ORCHID and the rest of the special purpose IPv6
=>addresses be left out of the list of local zones, and treated normally.

Raising hand timidly....

Instead of listing the zones in section 4 (which then will get hard 
coded into implementations), follow section 6 and register the zones in 
the new/to-be-created IANA assignment registry.  This will force 
implementations to go look at the assignment registry and maybe more 
aware of the dynamic nature of some of these zones.  As the draft is 
now, some implementors probably will stop reading after section 5. :(

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 14:29:37 -0700

>Raising hand timidly....

In this group!? :-)

>now, some implementors probably will stop reading after section 5. :(

Good call. +1

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Jun 2010 12:12:04 +1000

> >now, some implementors probably will stop reading after section 5. :(

The zone listed are intended to be stable enough in usage that they
can be frozen in code.  Zones added to the registry should be of a
similar level of stability.  It would be a very rare event for a
zone to be removed from the registry and it would take decades, if
ever, that the zone would be untainted.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Jun 2010 19:51:14 -0700

>ever, that the zone would be untainted.

Probably true, but not relevant to the discussion. The idea is to force implementers to look at the registry so that they see *future* additions to it, even if they get there from reading this RFC-to-be.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Tue, 15 Jun 2010 04:10:56 +0000

> Probably true, but not relevant to the discussion. The idea is to force implementers to look at the registry so that they see *future* additions to it, even if they get there from reading this RFC-…

	I'll note in passing that the "Martian" prefix list took less than 30 days
	to be declared "valid to use prefixes" and it has taken decades to eradicate
	them as "Martians" (by killing off code which chose to freeze them because of the
	stability of classful addressing)...  there are still vestigages of this cruft
	around.   I can not and do not share Marks naive presumptions about the stability
	of prefix use.  Guess I've been burned by that assumption twice - don't want to
	be bit by it a third time.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Jun 2010 14:32:54 +1000

In message <p0624080cc83c9ae0548d@[10.20.30.158]>, Paul Hoffman writes:
> Probably true, but not relevant to the discussion. The idea is to force imple
> menters to look at the registry so that they see *future* additions to it, ev
> en if they get there from reading this RFC-to-be.

You can't force anyone to do anything.  If this was split in two (one part
saying look in registry and the other half saying this is the priming list)
it still wouldn't help as developers may just read the second document.

Mark

---

From: Chris Thompson <[email-masked]>
Date: 15 Jun 2010 18:53:22 +0100

>it still wouldn't help as developers may just read the second document.

A tentative suggestion: maybe lists of this sort ought to be distributed
via the DNS itself, with nameserver software encouraged to fetch them
dynamically and act accordingly. Something along the lines of

 local-zones.arpa. PTR 0.in-addr.arpa.
                   PTR 127.in-addr.arpa.
                   PTR 254.169.in-addr.arpa.
                   ...
                   PTR 8.e.f.ip6.arpa.
                   PTR 9.e.f.ip6.arpa.
                   ...

Not that this would stop some implementors fetching the current value
and fixing it in their code...

One would want local.zones.arpa (or whatever) to be signed, of course!

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Jun 2010 09:06:17 +1000

> One would want local.zones.arpa (or whatever) to be signed, of course!

Which doesn't work in some of the senarios where you want this code
to come into play, i.e. firewalls that let RFC 1918 reverse queries out
but not let the replies come back.  The idea is to prevent the queries
leaving the nameservers in the first place.
 
Mark

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Jun 2010 13:15:06 +0200

> it still wouldn't help as developers may just read the second document.

here's where I think we are:

The document serves three purposes:

1) it establishes and/or encourages a practice to serve certain zones
   locally an any recursive resolver (thus BCP)

2) to make the list non-static and maintainable, it establishes an IANA
   registry with a policy and guidance (thus BCP)

3) from where it came from initially and to make (1) actually helpful,
   it seeds this registry giving due space to explanations for choices
   as well as considerations on thise prefixes/domains deliberately
   not chosen.

(1) is basicly done and understood
(2) is covered in the IANA considerations section but while that section
    refers to a formal policy it does not offer guidance for review.
    We should capture the considerations from the most recent as well as
    previous discussions like this:

    "Additions to the registry will not have and instantly relieving
     effect on those authoritative servers otherwise targetted with
     the queries to locally served zones, it can be expected that
     implementations will refresh the list of zones to serve occasionally
     or based on their update cycles.  For the same reason it can not
     be expected that deletions from the registry will allow the
     removed domain name to be resolved on the public Internet any time
     after such removal."

Regarding (3), while it is useful to seed the registry as broad as
possible, it is safe to err on the side of refusal that to "poison"
a prefix by essentially making it non-reverse-mappable.
That said, there is consensus to drop section 4.7 and not to add
the ORCHID prefix (resp. its reverse mapping domain name) to the registry.

On a more editorial side, the document should state its threefold purpose
in the introduction.

The -14 version should then be ready to go to the AD together with the
two AS112 drafts as a bundle, meking the cross references resolvable.

-Peter (with hat and Stephen's advice)

---

From: [email-masked]
Date: Thu, 17 Jun 2010 14:19:57 +0000

>      removed domain name to be resolved on the public Internet any time

	"ANY TIME"??  ever?  

	how about "... deletions from the registry will allow the domain
	names to be resolved on the public Internet at some reasonable
	time after removal from the registry."

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

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Jun 2010 18:21:52 +0200

> 	time after removal from the registry."

thanks.  Given our limited experience with eternity, this text is not
only more precise but also better suggests that one cannot be sure in either
direction.

-Peter