Subject: Re: (ngtrans) The reverse lookup issue

From: "Louis A. Mamakos" <[email-masked]>
Date: Wed, 03 Jul 2002 15:36:12 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> 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?

I think that about a decade ago (or so I it seems..) I suggested that
we abandon the notion of using the DNS to do address->name lookups.
Rather, define a simple standard service where a host can be asked
what it thinks it's name is.  In many cases, this does the "right
thing" in that you get a meaningful name at the time that the
address was allocated to someone (e.g., out of a DHCP pool or other
transient network connection.)

Sure, you can't "trust" this name.  Just like you can't really trust
the one in DNS PTR records, either.

Or simply decide the practical value is small.

louie

--
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: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 14:51:57 -0500

I am also somewhat skeptical about the value of reverse lookups, but people 
seem to like them, so I'm not sure if debating their value serves any 
purpose.   If the customer wants it, and it's a valid thing to do, who are 
we to tell them they can't have it?

This is a difficult problem to solve, though, with stateless addrconf, 
because the only device that can really update the DNS is the device that 
has configured its address, and that device might well not have any sort of 
security relationship with the owner of the address space.   Since reverse 
lookups to some degree go hand-in-hand with a desire to control use of 
addresses, it might make sense to say that we can only do this with 
stateful addrconf.

---

From: [email-masked]
Date: Thu, 04 Jul 2002 06:23:55 +0900

>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.

	how about draft-itojun-ipv6-nodeinfo-revlookup-00.txt?
	(i know the IESG pushback for ICMPv6 node info query, and the
	deployment problem)

>that reverse lookup has very little practical value?

	as documented in draft-ietf-dnsop-inaddr-required-03.txt, if we
	could nuke reverse lookup tree it would be nice.  but there are
	apps that use gethostbyaddr(), we need something.

itojun

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 03 Jul 2002 17:06:37 -0500

on 7/3/2002 1:59 PM Christian Huitema wrote:

> tree for IPv6?

Yes, it's useful and necessary to a variety of validation processes,
especially when used with double lookups (check PTR and A both ways).

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

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Alain Durand <[email-masked]>
Date: Wed, 03 Jul 2002 15:39:56 -0700

> that reverse lookup has very little practical value?

You might want to look at draft-durand-ngtrans-dns-issues-00.txt
that tries to summarize some issues around DNS in IPv6 land
and the discussion last week in DNSop mailing list
about reverse lookups.

	- Alain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 18:04:25 -0500

> 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.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 4 Jul 2002 08:21:55 +0859 ()

Christian;

> I am specially interested by the solution in the case of unmanaged
> networks, such as a home network.

Wrong.

If a home network is unmanaged (by an ISP), it is not connected to
the Internet and is not a problem.

Instead, a home network can be wrongly managed.

Any kind of problem can be caused by creative wrong management,
which IETF can not forbid.

IETF, instead, can write documents on dull ways of management and
possibile consequences of the creativity.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Jul 2002 19:16:29 +0700

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

  | 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?

There's actually an intermediate position.   That is, we keep the
reverse lookup tree, but we just make it clear that we no longer
expect people to populate it fully.   Or if they like, not to
populate it at all.

Applications can go on doing lookups there if they like, and if you're
an ISP and want traceroutes through your net to give out names, then
you can fill in the PTR records (on traceroutes I do over v4 today, I
think I get about 50% of the routes with names, of which about 75%
give any useful information at all).

If you're a user of an application that for some odd reason actually needs
the data, then you will add the entries to the DNS, because you actually
need the things.

But we just end the pretense that every allocated address is going to
have a PTR record somewhere.   It isn't true now, people just don't do
it (and as has been pointed out, often when they do, the result conveys
no useful information - that 1.2.3.4 maps to 1-2-3-4.example.com tells
us even less than is available from whois).

[email-masked] said:
  | using dns you get higher "trust splay" -- the party you're distrusting
  | about the reverse mapping is different from (and is probably
  | differently trustable) than the party you're distrusting about the
  | forward mapping.

With IPv6 (and increasingly with IPv4) this is simply not generally true.
The information from the DNS is originating at the host that created it
in either case - with the DNS there's the extra step of an intermediate
agent involved, but all it is going is conveying to whoever asks is the
information the host told it to give out.    That's just the same as if
the end-host were asked directly.   The only difference is that the DNS
is perhaps more likely to be there to answer the question sometime after
the host has vanished - I used to think this was a valuable property,
but I have re-considered, it just isn't worth the pain.

[email-masked] said:
  | Yes, it's useful and necessary to a variety of validation processes,
  | especially when used with double lookups (check PTR and A both ways). 

Since you certainly cannot reply on anything in a PTR record not just
being supplied by the host itself, you may as well just ask the host what
its name is - even better, do that as part of the protocol of interest,
rather than as some extra add on.   The validation any of this provides
was useful only in the days when some human manually typed in all of the
names of the hosts on his/her network.   That just isn't what happens any
more.

[email-masked] said:
  |  The last data
  |  that we collected on in-addr.arpa and the Mice/Men data on
  |  the forward tree indicates that the in-addr tree is actually
  |  better maintained...   Go figure. 

This is not surprising at all.   The forward tree is allocated to anyone
at all, with no requirement for a "DNS operators licence" before a domain
will be handed out.   A forward domain is a practical necessity for most
operations on the internet, and is also used as a vanity piece (and squatting),
where whether the domain works or not isn't relevant, only that it exists
(but in the domains that matter, existence isn't allowed without delegation,
but delegation accuracy isn't verified).

All this leads to lots and lots of breakage.

On the other hand, in-addr.arpa domains aren't required for almost anything.
That tends to mean that they're only set up by people who have some kind of
clue what they're doing.   Consequently it isn't at all surprising that
what exists out there is better looked after than the forward domains.

If anything, this is evidence for lowering the expectation that reverse
lookups will succeed - just because it is providing evidence that this
is the current state of the world.

[email-masked] said:
  | Getting rid of reverse zones simply guarantees that we have no
  | useful diagnostic information. 

No, you still have the addresses.   Those are more useful for most
diagnostics anyway.

As the percentage of addresses which map to meaningful names drops
further and further (and it is doing so, no question about it) the
futility of attempting to pretend that people who haven't filled in the
reverse tree are somehow derelict in their duty will become more and
more obvious.

Although the message I sent a while ago to dnsop read as if I was
suggesting that we should delete the IP6.{INT,ARPA} trees completely,
that isn't my position (it wasn't phrased as well as it should have
been).   Leave the things for anyone who really wants to use them.
Just stop trying to tell people that they *have* to use them.  Personally
I'm sick of doing lots of work just so all the rest of you get prettier
log files...

kre

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 08 Jul 2002 17:31:43 -0400

> especially when used with double lookups (check PTR and A both ways).

Like many other contributors to this thread, I happen to consider those
validation processes to be, for the most part, broken, and I'd rather hasten
their demise than hand them a crutch with which to hobble into the IPv6
world.

Yet, I recognize that reverse DNS has its uses, outside the realm of
authentication. At the very least, it makes "traceroute" output more
readable. Beyond that, I'd be a hypocrite to say that reverse DNS is
*useless*, since I actually use reverse DNS extensively in the homegrown
system we use here for maintaining our DNS.

I don't think anyone (?) in this discussion thinks that reverse DNS is
*useless*, i.e. devoid of any practical application. We're only debating the
*degree* to which it is useful (and, potentially, the degree to which it
might be harmful as well, e.g. fostering bad security practices and/or a
false sense of security).

But that's only looking at one side of the cost-benefit equation. The
benefit is small but non-negligible; what is the cost? I have to apologize
for not following the IPv6-related discussions as closely as perhaps I
should have. How painful is it to implement reverse DNS for IPv6 (assuming
that we resist the temptation to add extra bells and whistles and just stick
with a straight address-to-name mapping mechanism)? Maybe the benefit is
worth the cost, maybe it isn't. I certainly can't make up my mind on that
without knowing both sides of the equation...

- Kevin

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Jul 2002 23:09:38 -0500

> validation processes to be, for the most part, broken, and I'd rather
> hasten their demise than hand them a crutch with which to hobble into
> the IPv6 world.

Just a clarification that I specifically used "validation" and not
authentication, nor even authorization.