Subject: The reverse lookup issue

From: "Christian Huitema" <[email-masked]>
Date: Wed, 3 Jul 2002 11:59:11 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Jul 2002 13:25:00 -0700

> that reverse lookup has very little practical value?

the practical value goes above and beyond those you've mentioned.  i expect
that many services, especially e-mail but also any other abusable service,
will continue to reject connections for which no "reverse lookup" is known.

we live on an increasingly irresponsible internet.  my root name server gets
more than a gigabyte of request traffic every day just from 10.0.0.0/8.  we
all get a huge amount of spam.

anything that makes it harder to locate a responsible party for a given IP
address (whether v4, v6, v8, or whatever) is automatically, unarguably "bad."

---

From: Jim Reid <[email-masked]>
Date: Thu, 04 Jul 2002 06:51:58 -0700

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> This misuse of reverse DNS is probably the single best
    Dean> reason to abolish it altogether.

Some applications and protocols rely on reverse lookups. The BSD line
printer daemon and r- protocols for example. Nobody would disagree
that these things are somewhat broken by relying on reverse lookups
for authentication and access control. But it's a fact of life that
they exist and are widely used. They can't be wished away, much as we
might like them to. Security software like SSH and TCPwrappers can
use reverse lookups. How do you propose to replace/modify them if
reverse DNS is killed?

    Dean> Reverse DNS has no bearing on the location of parties
    Dean> responsible for IP addresses.

It is quite often a more reliable indicator -- if only by establishing
where the reverse tree delegations end -- than anything else. ISPs
often fail to update the RIR whois database when they hand out
addresses to their customers and delegate the reverse tree to them.

---

From: "Jason Coombs" <[email-masked]>
Date: Sun, 7 Jul 2002 13:13:40 -1000

Aloha,

> This is a key management problem of epic proportions.

Key management for DNSSEC is a problem of epic proportions without secure
DDNS, secure reverse lookup, and secure reverse DDNS lookup. I've been
following DNSSEC with interest but have contributed nothing to the process.
Not that nay-saying is much of a contribution, but why does DNSSEC have to
preserve the distributed management feature of DNS?

Centralized authoritative controls would make key management a viable
proposition. Even for DDNS and reverse lookups. Real-time feedback would
then be possible as well, to push information about alleged IP-to-name
mappings (plural) back to the secure DNS where security notices can be
dispatched securely to administrative and technical contacts who need to
know when somebody arbitrarily begins to purport that their node's FQDN puts
it inside their domain.

Forged FQDNs in spam relay and other types of FQDN misrepresentation could
then be flagged in secure DNS and further actions taken against those people
(and nodes) responsible. Authentic, comprehensive forward and reverse
mappings would then be possible, giving real-time meaning to negative
responses (FQDN does not exist) that aren't possible today with DNS.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ted Lemon
Sent: Wednesday, July 03, 2002 1:04 PM
To: Eric A. Hall
Cc: [email-masked]; [email-masked]; Christian
Huitema
Subject: Re: The reverse lookup issue

> I would think that DDNS could handle the dynamic scenarios but perhaps I
> don't understand the problem.

How do you establish a security association between the DNS server for the
reverse zone and the node with the IP address?   This is a key management
problem of epic proportions.