Subject: RE: (ngtrans) The reverse lookup issue

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Jul 2002 11:02:19 -0700

> Yes, but in the DNS world that means that someone has delegated
> 7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa to the same group to whom .com
> zone operator has delegated example.com.  How about that.  Two
> distinct administrative regimes.  And I can generally map example.com
> more accurately than I can map 2001:0123:4567::, because the DNS
> contact database generally has the same information used for DNS
> billing; whois does not.  I also can't send email to 
> abuse@2001:0123:4567::, I can send email to [email-masked].

Well, the owner of 7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa presumably also has
delegation of some direct DNS name space, maybe "example.net" instead of
"example.com". So, two situations can occur. The delegation of the DNS
address tree matches the actual routing delegation, in our case to
"example.com", and things are fine. Or, second case, the ISP could not
for some reason delegate the DNS address tree to the user of the prefix.
In that case, the ISP can still use the trick I was describing; the
addresses will resolve to "ip6.example.net" instead of
"ip6.example.com"; or perhaps "ip6-customer-xyz.example.net" if the ISP
is inventive. We will still get some reverse mapping, and it will still
be semi-informative.

-- 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: "Loomis, Rip" <[email-masked]>
Date: Mon, 8 Jul 2002 18:46:40 -0400

(List of CC addresses trimmed significantly, since I'm assuming
that most people read one or the other list...)

I disagree with a number of Dean's recent points, and I'll try to
address them in some coherent fashion:

Dean Anderson wrote on Monday, 08 July, 2002 15:33:
> You don't have two administrative domains. You don't even 
> have one, since
> both forward and reverse replies can be spoofed, or set by an
> untrustworthy administrative domain to be matching garbage.
> 
> Whois is much more trustworthy, since the administrative domain is
> trusted.
Rather than discussing relative trust, or probability of
correct/unspoofed data, let's stick to basic principles:
1.  Reverse DNS (PTR) information is frequently incorrect or
    incomplete (my statement/opinion).
2.  In some cases, organizations *intentionally* hide their
    reverse lookup data to make mapping (by an attacker) more
    difficult.  In other cases, organizations simply can't be
    bothered to keep it up to date (my statement/opinion).
3.  However, reverse DNS information is currently useful to many
    folks for troubleshooting/information gathering--both within
    enterprise networks, and across the 'Net (my statement/opinion).
4.  Christian's original message was in relation to 6to4 transition,
    and "how to get the equivalent functionality to gethostbyaddr(),
    and whether we really need it."

I believe that in spite of all its shortfalls, it's a useful piece
of information--and should not be deprecated.  In a large enterprise
network where I *don't* control IP range allocation, reverse lookup
is much more useful than whois...or are some of you working for
companies/organizations that actually run internal whois servers
for internal IP address range delegations?

If reverse lookup is deprecated for IPv6, then certain types of
network misconfiguration/possible attack will get *harder* to
deal with, not easier.

> Given a domain name taken from reverse/forward lookups, you 
> know nothing
> whatsoever about the originator. It could be completely 
> misleading. Given
> an IP address, you can find out who it was.
Given a choice between more information and less when investigating
an event, I would prefer more.  It does not appear to be an
impossible burden to many DNS admins.

> Whois can be scaled with replication
If it were that easy then it would already be more scaled...

> and you can obtain local copies if you really do a lot of analysis.
Which is pointless if what I want is *current* information that
requires an automated lookup.  Again, whois contains a lot of
wonderful information...but is not a silver bullet for every situation.

Previously, Dean Anderson wrote on Monday, 08 July, 2002 16:04:
> A domain name registration record represents $10. Sometimes less.
> DNSSEC (when it is used), will get you to someone who paid 
> $10 and didn't leave any addresses or phone numbers. (one could
> say DNSSec [if it works, and is used] is a lot of trouble for
> securing something worth $10).
Ladies and gentlemen--I note for you an apples and oranges comparison
in the above statement.  The amount something *costs* has no direct
relationship to what it is *worth*.  www.amazon.com is worth substantially
more than $10, regardless of what amazon.com cost to register.  *That*
is why DNSSEC is worthwhile for at least some folks.  There are other
folks out there who don't even care about domain names--but if DNS
information can be spoofed then information flow stops and people
might die or many shekels be lost.  (For some of those cases,
registration of domain names are free because they're inside an
existing hierarchy--that doesn't mean that the domain names are
only "worth" $0.)

> > Just because DNS is sometimes wrong doesn't mean that it's useless.
> > Forward DNS is sometimes wrong, should we eradicate that too?  If
> > we push people off to whois, the load on whois servers will go up
> > exponentially and we'll end up needing to bring it back anyway.
> 
> You should not be using it for authentication.  Forward and 
> reverse DNS is useless for authentication. Its use should be
> eradicated from authentication.  So, "yes".
I generally agree that "reverse lookup equals forward lookup" is
not a robust means of authentication.  One could equally say that
in current technology, biometric fingerprint readers are not a
robust means of authentication (based on recent "gummi" research).
That does not mean, however, that it cannot be useful as a data
point or as a portion of a multi-factor system.  Perfect is (in some
cases) the enemy of good enough, and security is not an absolute.

In the case of r-protocols -vs- SSH, I can easily explain why
SSH should be used and the r-protocols eradicated.  It's not so
obvious to me here why "reverse lookup equals forward lookup"
is hugely inadequate for all uses.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com

---

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 9 Jul 2002 23:43:54 -0400

Dean Anderson wrote:
> Well, the exaggerations are getting more extreme, so perhaps
> we've reached the end of the useful part of the discussion.

I still strongly disagree with most of the points you're
trying to make, and you've not attempted to rebut my last
message on the subject--or convingly addressed several other
messages which were more coherent/concise IMHO.  I'm not sure
why your statement above should be considered productive.

With all due respect, please educate me.

  --Rip

---

From: "Loomis, Rip" <[email-masked]>
Date: Fri, 12 Jul 2002 10:46:45 -0400

Dean--
Thanks for a well-written summary of your issues.  Now that
I've read the last few messages from you and kre, I would have
to allow that you do have valid concerns.  However:

> Logging allows useless information to be logged, obscuring or in lieu of
> what little useful indentifying information that is available, and would
> have been used instead, if Reverse DNS were not available, such as the
> IP address.

I disagree that the logged information is always useless.  Your statement
appears to be based on the fact that since anyone who controls their
reverse DNS can change it to $whatever, the information cannot be
relied upon.  For the more typical (currently) case where most users
do not control their reverse DNS, I would state that it is *sometimes*
useful.  Identifying when the information is useful and how to use
it does seem to be a problem for a lot of folks--I just don't agree
that the IETF should take away the baby toys.

> Authentication allows persons to gain access inappropriately.
No, authentication *prevents* people from gaining access inappropriately,
if one's authentication system(s) are properly implemented.

> Authentication and Validation are almost the same.
Not in my opinion.  I generally don't expect anyone except users who
have some associated authorization to be authenticating.  Validation
(to me) refers more to "does this (connection attempt or whatever) seem
to be reasonable and I should therefore allow it."

If a mail server I control receives an incoming connection attempt on
port 25 from a system that claims to be "mail.hghChEEpnow!.net" but
in fact shows up in the reverse map as "dsl-1-2-3-4.bigisp.net", then
why should I not use this information to help in the decision on
accepting the incoming connection attempt?  (Note that I'm not saying
I would make a decision based on this one data point alone--but it
could be one data point towards a decision.)

>Authentication seems to mean shell access is given.
No, authentication means authentication.  Shell access, or other access,
is a function of the authorizations granted to the entity which has
authenticated.

> "Validation" creates a false impression of confirmed identity, and a
> false feeling of comfort that might lead one into granting priveleges
> without further checks.
No, validation means that I have validated a set of information against
a set of criteria, and I believe that I the set of information is
useful.  It doesn't necessarily mean that identity is confirmed--but
in the example above, it's reasonable to think that identity has been
(at least partially) denied.

> DNSsec could mitigate some of these harms in the cases where DNSsec is
> used, but not all of the harms. In the cases where DNSsec isn't used,
> all of these harms could apply to these misuses.
I personally believe that without DNSSEC, there are many fundamental issues
with the DNS protocols today that will continue to bite us in the butt.
Reverse lookup is only one of them.  Therefore, if anything I believe
that DNSSEC _will_ be more widely used, and that some of your harms
will have their effect reduced--particularly inside certain large
enterprise networks.

> [...] it causes people not to give proper attention to issues such as
> logging and the assumptions made due to a "comfort level" obtained when
> Reverse and Forward DNS match.  I think it was a similar attitude or
> perhaps a false sense of comfort that led to significant security
> problems in the r-commands.

You've brought up the r-commands before, and I still don't see the
specific link.  I agree that reverse DNS information has been and
still can be used in-appropriately for authentication, which gives
a false sense of comfort.  That's significantly different in my mind
from the (remarkably bad in hindsight) assumptions behind the r-commands.

> These is probably not a complete list of harms.  But I think it is
> sufficient, when stacked against the cosmetic benefit, to warrant
> serious consideration of removing Reverse DNS from IPv6.

I agree that you have clearly stated some potential issues.  However,
I don't think that any of them are so grievous (individually or as
a whole) to cause reverse DNS to be harmful.  For certain specific
cases, reverse DNS remains useful IMHO (particularly inside large
enterprise networks)--and I believe that it can continue to be useful
in an IPv6 world.  

The biggest reason that I could see (and that at least some folks
mentioned at one time) to support deprecating reverse DNS would be
to allow organizations to hide internal information.  There are
already other solutions/mechanisms to address the separation of
internal/external DNS information, and getting rid of reverse DNS
entirely would be a poor solution for that other class of problems.
(I mention it in passing only for completeness.)

  --Rip