Subject: Re: The reverse lookup issue

From: Masataka Ohta <[email-masked]>
Date: Sat, 6 Jul 2002 00:31:07 +0859 ()

Kre;

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

> All this leads to lots and lots of breakage.

Surely, with wrong management, there can be lots of breakage.

But, who, are you saying, will suffer from the breakage?

Those under the wrong management?

Or?

						Masataka Ohta

--
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: "Jeroen Massar" <[email-masked]>
Date: Fri, 5 Jul 2002 17:54:37 +0200

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

Robert Elz wrote:

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

There are currently a few 'applications' for PTR's/reverse lookups:
* traceroute reverse
But not everyone fills in 'useful' data anymore, and with v6 that will
probably end too.
Especially as you probably won't be letting a router do a dynamic DNS
update(1) or something :)

* IRC
Which really is the *only* reason most people want a PTR. "Look mummy I
look cool on IRC".
Especially with the dnsspamming, and yes I know the people who sell
domain names or provide
dns services like that a lot, it's their wallet getting filled, but
unfortunatly in the v4 world every
irc-vhost takes one IP of the stack that could have been used for
another user's end2end connection.
But maybe that's a better question for e2e and not for people providing
dns services...

* Logging purposes
If one logs into a box with SSH, the server will reverse+forward check
the hostname, and use
that in the logs and 'who' which is much clearer as
3FFE:8114:2000:240:290:27FF:FE24:C19F
for instance. These loggings also are done for other protocols like FTP
and SMTP. Some SMTP's
refuse service if the reverse+forward doesn't match, though that doesn't
happen a lot.

Summing up, the reverses are just cosmetical and usually bogus unless
you check reverse&forward
to be the same and even then: what's the use of 4.3.2.1 PTR
1-2-3-4.example.net or in v6 space:
4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.ip6.arpa
/int PTR 1234.1234.1234.1234.... :)

Requiring them to be there is 'insane', as we'll probably end up with
the above, though some ISP's
are known to use a big dictionary to fill them out, which is nice but
still isn't usefull ;)
Having the possibility to resolve them can be 'cosmetically nice' though
there isn't any other advantage.
If one need to know where an IP is at use the whois, but then there are
always people saying that
it wasn't 'designed' for that purpose. But it is still the single most
'secure' place of finding out the owner
and the abuse/contact addresses of an IP, which is probably where IP
lookups are mostly used for: reporting problems.

There are currently (afaik) two ways of handling 'reverse' lookups:
- PTR record in DNS
- icmp6 message to the host.

The first one (PTR) can be 'protected' from evil doing, the second one
can be easily spoofed and
doesn't really proove a thing as it can be invented by the admin of the
box.
But it's more usual for the host to know it's own/real/in-use hostname
than for DNS to know it.

(1) = Dynamic updates, will you really be going to let every user of
your ISP update the reverses?
In a company thats probably very different, if you got a nice tightly
controlled environment.
But then again, ofcourse we got
http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;)

Greets,
 Jeroen

---

From: David Terrell <[email-masked]>
Date: Fri, 5 Jul 2002 09:49:41 -0700

> refuse service if the reverse+forward doesn't match, though that doesn't

I hate having IPv6 literals in [wu]tmp.

With the emphasis that IPv6 is putting on renumberability, the
person with an address today may not be the same person with it
tomorrow.  If we can get the reverse DNS tree to follow addressing
(which is reasonably possible, even if we don't have DNAME in the
reverse tree) then your snapshot of who had the address two weeks 
ago when you're looking at your logs can be more useful than 
checking whois or whatnot.

> lookups are mostly used for: reporting problems.

whois can't give me a name to log.  whois already can't handle the
constant load from spam harvester runs.

> But it's more usual for the host to know it's own/real/in-use hostname

For the machines you're complaining about with regard to having
lame reverse (1-2-3-4.example.net), they're far less likely to have
a locally configured name that exists in the DNS.  This may change
as things like ddns become more popular.

-- 
David Terrell   | "To increase the hype, I'm gonna release a bunch
Nebcorp PM      | of BLT variants (NetBLT, FreeBLT, BLT386, etc)
[email-masked]    | and create artificial rivalries."
wwn.nebcorp.com |  - Brian Swetland (www.openblt.org)

---

From: Derek Atkins <[email-masked]>
Date: 05 Jul 2002 12:54:25 -0400

> your ISP update the reverses?

No, but the ISP trust's its own DHCP server to update its reverse
domain (which may involve updating a reverse-tree deleagation).  Note
that the client does not need to update the reverse tree itself; it
can provide its DNS hostname to the DHCP server and the DHCP server
updates the reverse tree.

> http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;)

Personally, I find the reverse tree both useful in my every day work
and also I can see a number of future uses, such as binding keys to IP
addresses.  From an IPsec perspective, all I know is that I want to
send a packet to host X (where X is some IP Address), and I need to
key that connection.  This requires either certificates with IP
addresses or DNS lookups based on IP Address.  I certainly prefer the
latter case, because generally certificates are based on the FQDN, not
the IP Address.

If I want to talk to 1.2.3.4 and get back a certificate claiming to be
for secure.host.net, how do I know I'm talking to the right machine?
OTOH, if I can query DNS for "4.3.2.1.in-addr.arpa. IN <some keytype
record>", which is DNSSec-protected, then I have a higher assurance
that I'm actually talking to the host I think I am.

>  Jeroen

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Jul 2002 12:37:29 -0500

> http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;)

If you are doing stateful addrconf, DNS updates are done by the DHCP server,
  not the client, so this isn't a problem.   Of course, you have to accept 
the name the client provides, or make one up, but this isn't a big problem 
either - if you don't want to do that, don't.

It is my impression that populating PTR records hasn't been considered a 
requirement for some time now.   The reason we do it is so that our users 
can successfully interoperate with people who insist on it.   An IETF 
mandate is not going to eliminate people who insist on it.