ietf
[Top] [All Lists]

Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard

2010-01-05 06:47:06
At 00:50 05/01/2010, John R. Levine wrote:
For the sink.arpa, it would be good to explain why we want this name to
exist.

We *don't* want the name to exist; that's the point of the draft. I presume that's what you meant?

It would still be nice to put in an explanation of the motivation for adding SINK.ARPA when its semantics and operations, at least for clients, appear identical to whatever.INVALID.

There are two parts to this, the sink.arpa for all practical purposes
will function just like .invalid, the only difference is the name space
that the name resides in. According to RFC 3152 IAB recommends that arpa
be the domain for addressing and routing special needs.
Based on this it seems logical to set up a framework for any special purpose
names in there instead of the Root zone.

The ARPA domain can be tuned better to the needs of negative caching than the
root zone, having a negative caching of a week in ARPA will not cause any problems. Currently the root has one day, if in the future there are
frequent adds/deletes of names in the root zone the operators may
want to lower that value.


         Also, if your goal is that applications not have special logic
for sink.arpa you should *say* that:

Yeah. As far as I know, it is quite uncommon for applications to hard code treatment of .INVALID. But you seem to be saying that they do, and that causes problems that SINK.ARPA would solve. Tell us what they are.


There is one case where knowledge and special handling of the name may
cause problems:
  DNS "Liers" i.e. specialized DNS resolvers that make all
  non-existing name exist that do not generate "lie" for sink.arpa.

In this case the name can not be used as test of the resolvers truthful ness.
If an application knows about the name that is not a problem as all that will do is
to avoid a name lookup, and this is exactly the reason we want the name to be
have explicit semantics that can not change and are under IETF/IAB "control" not
ICANN's.

How sink.apra or other specialized names in ARPA can be used we leave to application
specialists.

Olafur
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>