At 15:27 -0500 12/5/06, Andrew Sullivan wrote:
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.
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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
