ietf
[Top] [All Lists]

RE: rfc1918 impact

2003-10-17 16:31:39
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:

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

Dean Anderson wrote:

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.

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

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen(_at_)unfix(_dot_)org / 
http://unfix.org/~jeroen/

iQA/AwUBP45ElCmqKFIzPnwjEQKe7gCfT5/MWZ9pkkz9U+pnTYnUWKfuADcAn2wW
YeRsiz6r6NDRD7X44km5KBko
=t5WN
-----END PGP SIGNATURE-----






<Prev in Thread] Current Thread [Next in Thread>