Subject: RE: Removing features

From: "Michel Py" <[email-masked]>
Date: Wed, 15 Oct 2003 00:11:56 -0700

Kurtis,

> Kurt Erik Lindqvist wrote:
> There are a hell of a lot traceroutes going on then...

As pointed out by Keith privately, traceroutes are not the only culprit.
Telnet to a host from a private IP, it does a reverse lookup on your IP,
etc. Basically everything that triggers a reverse lookup adds to the
pain, but if reverse lookup is configured correctly on the local DNS
server it removes the pain for all apps as well.

> Now, why don't people do this?

Ask George Carlin.

Michel.

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Oct 2003 10:26:17 -0400

On Wed, 15 Oct 2003 00:11:56 -0700

> server it removes the pain for all apps as well.

great.  now we'll have NAT boxes intercepting outgoing DNS traffic also.

---

From: [email-masked]
Date: Wed, 15 Oct 2003 11:42:24 -0400

> great.  now we'll have NAT boxes intercepting outgoing DNS traffic also.

The really bad part is that they'll on the average do as good a job of intercepting
DNS traffic as they do of filtering outbound 1918-sourced packets in general. After
all, the root DNS boxes shouldn't ever see a 1918 packet unless (a) some site isn't
egress filtering properly *and* (b) their ISP isn't ingress filtering at the edge.

Egress *and* ingress filtering.  Belt and suspenders design.  Too bad there's so
many sites that still manage to leave their fly open anyhow.....

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Oct 2003 12:03:28 +0200

We should keep nice and descriptive subject-lines...

Michel Py wrote:

<snip>

| etc. Basically everything that triggers a reverse lookup adds to the
| pain, but if reverse lookup is configured correctly on the local DNS

A lot of the arguments seem to contain the phrase "If <foo> is
configured correctly then ...". Now what does that teach us?

	Cheers Leif

---

From: Dean Anderson <[email-masked]>
Date: Wed, 15 Oct 2003 22:14:13 -0400 (EDT)

Remember that Reverse lookups are optional. Many people who start of
saying "if reverse dns is configured correctly..." don't seem to
understand that reverse DNS is also properly configured when it is turned
off.

The abuse, and the numerous security vulnerabilities which have been
introduced by the improper use, as well as the difficulties in IPv6 (both
technical and administrative) has prompted discussion on both DNS working
groups to consider removing Reverse DNS altogether.  As it stands, Reverse
DNS is probably not going to be working or widely used in IPV6, which has
an alternate ICMP host information query so that reverse DNS is not
necessary for the most useful purpose of reverse DNS: traceroute.

The good news is that all this nonsense ends with IPv6.

		--Dean

On Wed, 15 Oct 2003, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE/jRtv8Jx8FtbMZncRAg8eAJsEhg6/LOQgaZW3FtSkdiffbp2TvwCgx+x1
> dpuw7nwHC2Z8BlAx+qoKyBc=
> =7TZn
> -----END PGP SIGNATURE-----
>
>
>

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 16 Oct 2003 09:11:16 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Dean Anderson wrote:

> Reverse DNS is probably not going to be working or widely used in 
> IPV6, which has

I think you underestimate the 'power' of Reverse DNS.
The primary reason that tunnelbrokers are so popular, with even
the non-technical folks, is simply because of Reverse DNS :
  - Reverse DNS gives a nice host on IRC -

Ofcourse ICMP host information could solve that.
But afaik there is no 'secure icmp host information' packet yet.
And we are going to get at dnssec one day.

Next to the vanity host usage of reverse dns there is also
the usage for reverse dns in logs, reverse in 'who' output
and probably many other reasons. Loganalyzing tools are
another popular example of reverse dns usage. Ofcourse
that can be solved too with icmp's, but icmp's don't work
when the host in question is offline, ofcourse one is to
wonder if the host is offline if the dns is not offline
or that the IP is in use by another host etc...
Next to that reverse usually matched forwards, if reverse
is split from forward lookups there is going to be a difference.

Greets,
 Jeroen

---

From: Dean Anderson <[email-masked]>
Date: Fri, 17 Oct 2003 19:20:25 -0400 (EDT)

So far, DNSSEC doesn't solve this problem.  I don't think the reverse DNS
problem is intended to be solved by DNSSEC.

  Quick poll: Does anyone actually think that DNS can be made globably
invulnerable, and positively trusted, yet usable?

DNSSEC won't solve a number of problems of intentional false information.
It only works in cooperative environments, and is limited in many ways.
These limitations still make DNS generally untrustable, which makes in
inappropriate for logs and most other uses.  I don't think the
implementors expect it to be widely deployed, but useful in some special
cases.

Also, logs should definitely NOT be using reverse DNS.  This is one of the
many improper uses of Reverse DNS.  One must always log the IP address. If
you have a lot of extra time, and space in the log, the current value of
the reverse lookup may be interesting, but it it not meaningful.

Implementors are starting to get a clue:  I've noticed that the UTMP on
several platforms only stores the IP address for IPv6.  Many a breakin has
been hard or impossible to trace due to improper use of reverse DNS in
logging. Sometimes it is impossible to detect! How do you know that the
access from the_very_long_host.another_long_zone.some_doma---oops, out of
space for hostname--was unauthorized?  Anonymous Mail Relay abuse was made
possible because the early SMTP implmentors didn't put the IP address in
the Recieved header, but the reverse DNS, which we subsequently found out
to be useless.  Ironically, one of our current DNS chairs, Rob Austein,
argued against putting the IP address in the header in 1986,
unintentionally bringing us this scourge. I guess if you screw something
up bad enough, you get management (Sorry Rob ;-)  The BSD R-command
exploits are due to improper trust in reverse DNS.  The list goes on, and
includes _everthing_ (that I've heard of) except for traceroute, which is
using reverse DNS only for what amounts to transient pretty printing.
Transient, frivolous use, like in traceroute, is the only appopriate use
for reverse DNS.  All other use that I've seen so far is inappropriate,
and leads to a vulnerability of one sort or another.

Anyway, this is getting afield a little for the IETF list, and probably
belongs on one of the DNS lists.

Perhaps all that is important is to remember that "properly configured
Reverse DNS" includes having no reverse DNS at all.

		--Dean

On Thu, 16 Oct 2003, Jeroen Massar wrote:

> Version: Unfix PGP for Outlook Alpha 13 Int.
> Comment: Jeroen Massar / [email-masked] / http://unfix.org/~jeroen/
>
> iQA/AwUBP45ElCmqKFIzPnwjEQKe7gCfT5/MWZ9pkkz9U+pnTYnUWKfuADcAn2wW
> YeRsiz6r6NDRD7X44km5KBko
> =t5WN

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 18 Oct 2003 02:46:25 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Dean Anderson wrote:

> So far, DNSSEC doesn't solve this problem.  I don't think the 
> reverse DNS problem is intended to be solved by DNSSEC.

IMHO "reverse" is just the same as ordinary domains.
Where DNS is a phonebook for internet name mappings.

> invulnerable, and positively trusted, yet usable?

I trust on the word of Miek Gieben and as he says it is so, I
have to go with that it will be trusted and usable.

> DNSSEC won't solve a number of problems of intentional false 

You won't be able to 'spoof' anymore, which solves the
intentional false information part.

> It only works in cooperative environments, and is limited in 

Everything is based on cooperation, nobody is 'forced' to
implement a specification and people can invent their own etc.
You might want to followup to the dnssec-wg why you think it
is limited btw.

<SNIP>

> Also, logs should definitely NOT be using reverse DNS.  This 
> is one of the many improper uses of Reverse DNS.
> One must always log the IP address. If
> you have a lot of extra time, and space in the log, the 
> current value of the reverse lookup may be interesting,
> but it it not meaningful.
> Implementors are starting to get a clue:  I've noticed that 
> the UTMP on several platforms only stores the IP address for IPv6.
> Many a breakin has been hard or impossible to trace due to improper
> use of reverse DNS in logging.

I realize that all too well, unfortunatly some don't:
http://www.freebsd.org/cgi/query-pr.cgi?pr=22595
(Check the dates btw :)

They should log both the IP and the reverse.

> Sometimes it is impossible to detect! How do you 
> know that the access from 
> the_very_long_host.another_long_zone.some_doma---oops, out of
> space for hostname--was unauthorized?  Anonymous Mail Relay 
> abuse was made possible because the early SMTP implmentors
> didn't put the IP address in the Recieved header, but the
> reverse DNS, which we subsequently found out to be useless.

Reverses should be checked with the forward mapping ofcourse.
If both of these answers come in over DNSSEC then you are 100%
sure that this host has this name. But still one wants to
log the IP because DNS-TTL later the hostname is out of your
cache and possibly out of the entire DNS system.

> and includes _everthing_ (that I've heard of) except for 
> traceroute, which is using reverse DNS only for what amounts
> to transient pretty printing.

Traceroute doesn't check the forward beloning to a reverse
and I have seen an number of jokers using 'nice' hostnames
next to that there are very easy ways of spoofing traceroutes,
rotorouter anyone ?:)

> Anyway, this is getting afield a little for the IETF list, 
> and probably belongs on one of the DNS lists.

Ack.

> Reverse DNS" includes having no reverse DNS at all.

Ack.

Greets,
 Jeroen

---

From: Markus Stumpf <[email-masked]>
Date: Sat, 18 Oct 2003 22:04:58 +0200

> Reverse DNS" includes having no reverse DNS at all.

Reverse DNS is just a zone in the in-addr.arpa domain. And there is more
to reverse DNS than just a untrustworthy PTR record.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"