Subject: [dnsop] IANA section of draft-andrews-full-service-resolvers-01

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 8 Nov 2005 17:38:29 -0800

Dear colleagues,

In the working group meeting I just mentioned that the IANA section  
of  draft-andrews-full-service-resolvers-01 should clearly mention  
who has change control of the registry.

I'd suggest something along the lines "This registry can be amended  
through IESG reviewed RFC publication" which is, as I've been  
informed, the highest hurdle one can throw up in order to prevent  
unwanted modifications to the 'blacklist'.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 08 Nov 2005 18:44:25 -0800

--On 8. november 2005 17:38 -0800 "Olaf M. Kolkman" <[email-masked]> 
wrote:

>
> Dear colleagues,
>
>
> In the working group meeting I just mentioned that the IANA section  of
> draft-andrews-full-service-resolvers-01 should clearly mention  who has
> change control of the registry.
>
> through IESG reviewed RFC publication" which is, as I've been  informed,
> the highest hurdle one can throw up in order to prevent  unwanted
> modifications to the 'blacklist'.

The highest hurdle is "standards action".... that might be overkill....

---

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Nov 2005 12:04:17 -0800

At 17:38 -0800 11/8/05, Olaf M. Kolkman wrote:
>Dear colleagues,
>
>
>In the working group meeting I just mentioned that the IANA section of draft-
>andrews-full-service-resolvers-01 should clearly mention who has change
>control of the registry.

I'd like to suggest a completely different tack.

The document ought to be a standalone recommendation saying basically 
"because of the havoc any one element, be it an DNS recursive server 
or not, can inflict on the unfettered Internet, a DNS resolver should 
not send certain queries to the general network.  Instead the 
queries, as documented herein, ought to be either answered 
authoritatively by the recursive server or be answered by 
administratively forwarding the queries to specific local server. 
Queries for the following domains are to be handled this way..." 
followed by the domains that today we want believe ought to be 
handled this way.

The impact of this is that RFC6372 (my prediction of the number for 
this, if it happens at all) will be used as a tool in two ways.

BIND 14.9.0 will feature a "rfc6372 not-in-effect;" means that BIND 
does not load in pre-configured zones (like it does for the 
root.hints).  (Of course an explicit "type forward" or "type 
{master|slave}" for any zone overrides the canned definitions.)

AOL will declare that it's recursive servers are RFC6372 compliant, 
in the same way many companies are ISO9001 compliant.  Or perhaps 
someday someone will try to license recursive servers and use this as 
one of the criteria.  (You never know where policy may pop up next.)

I don't mean to suggest the implementation, but how the document can 
successfully be used.

If someday there is a change to the list of domains, a new RFC can be 
cut.  I bet the pain of that will be less than having to manage a 
registry - or even debate the registry and then get it initially set 
up.

(Note - written with a tongue-in-cheek style.  Any similarity to any 
living organizations, current or past, is purely a coincidence.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story:
Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis
to get home from a conference.  (Cities changed to protect his identity.)
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Nov 2005 09:06:29 +0200 (EET)

On Tue, 8 Nov 2005, Olaf M. Kolkman wrote:
> draft-andrews-full-service-resolvers-01 should clearly mention who has change 
> control of the registry.
>
> I'd suggest something along the lines "This registry can be amended through 
> IESG reviewed RFC publication" which is, as I've been informed, the highest 
> hurdle one can throw up in order to prevent unwanted modifications to the 
> 'blacklist'.

I support the document.

It depends on what category draft-andrews-full-service-resolvers-01 is 
aiming for.  Given its nature, the target should maybe be BCP given 
that we need IETF-wide review of this.  Then updating the list should 
require Standards Action.  In any case, the IANA considerations need 
to be appropriately spelled out.

Below are some editorial nits.

editorial
---------

  Configuration Issues Facing Full Service DNS Resolvers In The Presence
                      of Private Network Addressing
                 draft-andrews-full-service-resolvers-01

==> the title etc. is not very intuitive compared to the abstract

    site-local addresses howsever, sacrificial servers for C.E.F.IP6.ARPA

==> typo

       255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */

==> should the whole 255.IN-ADDR.ARPA be covered? should 0.0.0.0 be 
covered ? what about site-local v4/v6 multicast addresses?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2005 16:05:07 +1100

> to be appropriately spelled out.

	It was always intended to be BCP.

>     site-local addresses howsever, sacrificial servers for C.E.F.IP6.ARPA

	Thanks
 
> covered ? what about site-local v4/v6 multicast addresses?

	I was being conservative.  I'll follow w.g. advice on this.

	As for general multicast the reverse space for IPv4 multicast is
	currently populated.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html