Subject: [DNSOP] ISSUE 10 reverse-mapping-considerations

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Dec 2006 15:27:32 -0500

Dear Colleagues,

At the late meeting in San Diego, I said when discussing the open
issues list for the reverse-mapping-considerations draft that I had
some language that I'd send to the list for discussion before
updating the document.  Here is that text.

Issue 10 is the extent to which this document applies to RFC 3330
space; and in particular, to RFC 1918 space.  

I propose to add the following text to section 4.1 ("Delegation
Recommendations"):

   Some IP addresses on the Internet are assigned for special use. 
   These addresses are described in [RFC3330].  In general, for
   addressess that are expected to work as a regular part of the
   public Internet, the same considerations should be taken into
   account as for any other address.  In the case private-use
   [RFC1918] networks, the policies around reverse mapping are a
   local consideration to the same degree that the addresses are
   private.

The point of that "to the same degree" bit at the end is to allow
people to point out to those whose reverse queries are leaking out to
AS112 a better practice for how to configure their DNS.  I didn't add
the reference to draft-andrews-full-service-resolvers because I've
had the impression people would prefer not to hold this up while
something else makes it through editorial revision.

I plan to incorporate this text in the next revision, barring any
objections.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 07:31:09 -0500

>    local consideration to the same degree that the addresses are

I hate this issue.  I'm glad I'm not the stuckee for this document.

Perhaps what needs to be conveyed is that the DNS response to a 
reverse map query for an address ought to reflect what is supposed to 
be seen at the address.

If A and B are both local to one administration, then it doesn't 
matter whether A and/or B are special use or not.

If A and B are in different administrations, then if B asks about A, 
B is told what it is supposed to know about A.  In that case, if A is 
special use and B shouldn't be seeing it, then there shouldn't be any 
DNS answer (configured).  A doesn't have to have the same appearance 
to a different administration that it has to the same administration.

Perhaps a special comment ought to be made about "leaking" although I 
think spending too much time of that is a waste of an RFC's time. 
"Leaking" has to be defined (answering incorrectly to a query, 
usually by giving an answer that is true for just a subset of the 
network but is not applicable to the querier) and a recommendation 
for avoiding it might be included.

In trying to nail this down, I had come up with a non-exhaustive list 
of 7 kinds of relationships between two addresses, including "things 
are now broken" and "they are supposed to communicate".  But the list 
was too long with the explanations, even for a mail list, to be 
useful.

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

Dessert - aka Service Pack 1 for lunch.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 07:31:09 -0500

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Dec 2006 10:47:14 -0500

> reverse map query for an address ought to reflect what is supposed to 

I like that as a general statement of the point of all of this. 
Since the point is to make this a "considerations" document, surely
the general statement is enough? 

> Perhaps a special comment ought to be made about "leaking" although I 

I avoided talking about that because I think it's already covered in
the Mark Andrews draft about defaults for local zones.  I'm happy to
put a reference in, but the sense I got in San Diego and previously
was that people didn't want that, because the reference might hold up
the draft and we've been waiting long enough.  

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Dec 2006 10:47:14 -0500

A

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 11:09:30 -0500

>the draft and we've been waiting long enough.

It's all kinda "funny" (as mentioned in the movie "Fargo":

Mr. Mohra: Oh, he was a little guy. Kinda funny lookin'.
Officer Olson: Uh-huh. In what way?
Mr. Mohra: Oh, just in a general kinda way.)

If you can pull off the generalization, that's the best thing to do. 
When it comes to specifics, it seems to me that often, especially as 
far down the road we are with DNS cruft & history, there's the 10% of 
the cases that warrant 90% of the attention.  If I were teaching a 
class on this, I'd assign the students to read a text that talks the 
general case but then stress the odd-ball case in lecture.

For the most part, the recommendation to "use your head will lead you 
the right way" is what's needed.  Tell them folks out there what you 
want them to hear about you.  But often times administrators don't 
have the time to use their heads and rush into something that results 
in leaks.  (It's not that they can't use their heads - they just 
don't have the time to learn and implement fully.)  What everyone 
else sees and is stung by is the leaking.

What to do about the reference?  Mumble.  Ummm.  Well, maybe you can 
gloss over it by saying "just be careful to not answer queries 
inappropriately" and either avoid the term leak - or do what is in 
the old RFCs - just define it yet again without detailing it.  (I 
think "lame delegation" is defined in two or three different RFCs.)

I was going to include the absolutely best answer to your dilemma, 
but I ran out of letters trying to write this email's conclus
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 11:09:30 -0500