[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The reverse lookup issue



As we are looking at evaluating various transition mechanisms, we will
need to address the reverse lookup issue, i.e. how to get the equivalent
functionality to "gethostbyaddr()", and whether we really need it.

I am specially interested by the solution in the case of unmanaged
networks, such as a home network. Today, it kind of works as follow: the
ISP allocates an IPv4 address to the home gateway or NAT; that address
belongs to the range of IPv4 addresses managed by the ISP; reverse
lookup are served directly by the ISP's DNS server. The level of service
varies a lot, but the dominant solutions are either a perfunctory
record, such as the ISP "example.net" mapping "64.5.6.7" to
"ip4-64-5-6-7.example.net", or no service at all.

The problem is particularly acute with "autoconfigured" solutions such
as 6to4, Teredo and to some extent ISATAP. The 6to4 router that builds a
prefix for "2002:4005:607" may or may not obtain a delegation of the
domain "7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa" -- that can be arranged if was
statically allocated and the ISP allocating the address is "64.5.6.7"
willing to delegate, but the operational implications are daunting.

Even if the 6to4 router actually obtains delegation, we are not out of
the woods. Unmanaged networks will typically use automatic address
configuration, specially as they want to enhance the users' privacy with
"privacy addresses." The only practical solutions there are either to
use an algorithm and generate perfunctory records (e.g.,
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.1.0.0.0.7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa
maps to 
ip6-abcdef01234567891000706050042002.example.net); or somehow forward
the DNS request to the host itself, which will answer with some
arbitrary value.

So, my question is, do we really need to invest in a reverse lookup DNS
tree for IPv6? Or should we not just "declare victory" and recognize
that reverse lookup has very little practical value?

-- Christian Huitema

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>