Subject: Re: (ngtrans) The reverse lookup issue

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Jul 2002 13:28:34 -0700

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

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.

that's a good thing.

--
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: Bill Manning <[email-masked]>
Date: Wed, 3 Jul 2002 16:35:12 -0700 (PDT)

As others have pointed out, the addressing structure maps the topology
while the naming structure maps the administrative structure. Sometimes
(rarely) they overlap. Most times they do not. My keys/certs are tied
to the node name (bloat.isi.edu) and not to the IP address, which can
and does change with some frequency. (any time the laptop moves).

 Cross-correlation is a good and useful thing.  
 The claim about the maintaince of the in-addr tree vs the
 maintance of the forward tree are interesting. 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.

--bill

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 3 Jul 2002 18:00:51 -0700

Reading this thread, there are three arguments for keeping the reverse
lookup:

1) In enterprise networks, reverse lookups provide a way to identify the
source of the traffic.

2) In general, it is better to have an information from a third party
(network provider) than from the host itself, since the host may be
compromised or mismanaged.

3) Some applications (e.g. SMTP servers) actually use reverse lookup to
check that the name provided by the caller is not entirely bogus.

My issues are mostly related to several IPv6 procedures that let the
host configure its own address: automatic address configuration based on
prefix advertised by the local routers, and transition procedures such
as 6to4 that allow a router or a host to configure an IPv6 address
prefix from an IPv4 address. So, what about the following:

1) In enterprise networks, it is possible to use dynamic DNS updates,
thus meeting requirement #1. (Using the same procedure in consumer
networks, or across domain boundaries, is much less likely.)

2) In consumer networks, the ISP will typically delegate a /48 or
possibly /64 prefix to the consumer -- to a host or a gateway. The
informative part (the third party information) is really only derived
from this prefix allocation; everything else can be made up by the user.
It is thus realistic to have the ISP enter a "catch-all" PTR record for
the prefix, providing a reasonable response to a PTR query. (If we end
up using dynamic DNS updates, the catch-all will only be used in prsence
of less specific information). This is essentially the solution proposed
in draft-durand-ngtrans-dns-issues-00.txt.

3) Applications such as SMTP relays may receive a generic record
(*.example.net ?) as a response to their reverse lookup. There should be
a way to compare this generic record to the name otherwise provided by
the caller, in order to gain a modicum of control. (Indeed, one
possibility is for the client app to first perform the reverse lookup
itself, and then use the result in SMTP.)

However, this leaves open the "auto-delegation" case, such as the 6to4
prefix. One possibility would be to have a generic record: 
	*.2.0.0.2.ip6.arpa IN PTR host.6to4.net
... But that would not be terribly informative. 

Another possibility is to enter a set of NS & PTR records under
.2.0.0.2.ip6.arpa that essentially mimic the in-addr.arpa tree, so that
*.1.0.2.0.3.0.4.0.ip6.arpa yields the same value as
1.2.3.4.in-addr.arpa, possibly complemented by some "generic" name-part.
A DNAME comes to mind, but let's not go there. Alternatively, one could
program an hard-wired short-cut in DNS resolvers and possibly DNS
servers as well.

Does this make sense?

-- Christian Huitema

---

From: Dean Anderson <[email-masked]>
Date: Wed, 3 Jul 2002 18:39:49 -0400 (EDT)

The party on either the forward or reverse end isn't definitely known, due
to the potential for spoofing. You can't trust dns, ever. <notwithstanding
dnssec, which might be useful for tld zones, and maybe by some more
sophisticated dns users, but I suspect will never make it into common use>

All of the reverse dns mythology is based on the idea that you can somehow
trust reverse dns differently than forward dns, and the huge assumption
that if the answers match, then you can _ASSUME_ they are correct, when
the stark truth is that you can't trust either of them because both can be
spoofed.

The only use I have for reverse DNS is to make traceroutes pretty.  That's
all. Nothing more than that.  Reverse DNS should only be allowed for
routers, to make traceroutes pretty.

Using reverse dns for anything else opens one up to .rhosts type of
security problems. There is no avoiding it, short of dnssec procedures,
and then only on the zones secured that way.  Indeed, I think you still
can't trust reverse DNS, since the resolver doesn't know if the reverse
zone is actually trustworthy, only that its been "secured".  If it proves
vulnerable to attack, then once again you can't trust DNS--ever--for
anything more pressing than the prettiness of traceroutes.

"You can't place any trust in an answer given by someone you don't know."

		--Dean

---

From: Jim Reid <[email-masked]>
Date: Thu, 04 Jul 2002 08:26:33 -0700

>>>>> "Jeroen" == Jeroen Massar <[email-masked]> writes:

    Jeroen> I agree to the fact that any person should be able to set
    Jeroen> up his/her/it's/...  own reverse *BUT* seeing the fact
    Jeroen> that there are 'kiddos' coming up with things like found
    Jeroen> in: http://www.garion.org/spamcalc/sorted.txt excerpt and
    Jeroen> apologies for the bad language used: 

    .... long list of garbage deleted ....

I fail to understand the point you're making. So what if kiddies are
putting stupid or obscene names in the reverse tree? There's nothing
stopping them. Or doing that in any other (forward?) zones they own.

---

From: Greg Hudson <[email-masked]>
Date: 04 Jul 2002 14:41:25 -0400

> routers, to make traceroutes pretty.

What special claim does traceroute have on looking pretty?  Why
shouldn't web server logs or wtmp files get to look pretty too?

I'd advocate a more general statement of this position.  Reverse DNS is
useful for humans--useful enough that I think it's worth preserving.  It
is not especially useful for automated processing, since the answer you
get back isn't very robust.  (You could do a forward lookup of the
result you get back, and see if that forward lookup is protected with
DNSSEC, but in the short and medium term you're not going to get very
many positives.)

---

From: [email-masked]
Date: Fri, 05 Jul 2002 07:51:14 +0900

>    > Yes reverses are good, but they are there for _administrative_ ease and
>    > for a teeny
>    > verification step, not for the fun of some 12 year olds.
>  I strongly disagree.
>  DNSSEC signed reverses are extremely useful.
>  Please see draft-richardson-ipsec-opportunistic-09.txt.

	DNSSEC-signed reverse solves some of the problem, but not all.

	solves:
	- guarantees that noone spoofs PTR records, i.e. ensures integrity
	  between the records held by authoritative nameserver and the response
	  you've got
	- address-to-key mapping and secure distribution of those keys, like
	  those used in opportuniistic encryption

	does not solve:
	- integrity between forward and reverse DNS records
	  (btw, with scoped IPv6 address, it's impossible)

itojun

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jul 2002 18:25:58 -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! ]

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

>>>>> "Jeroen" == Jeroen Massar <[email-masked]> writes:
    Jeroen> Michael Richardson wrote:

    Jeroen> A bit off topic to the rest, but I just have to mention it;

    >> I am profoundly unhappy with the notion that these networks are in
    Jeroen> anyway different.
    >> Citizens need control over their reverse maps. Period.

    Jeroen> I agree to the fact that any person should be able to set up
    Jeroen> his/her/it's/...
    Jeroen> own reverse *BUT* seeing the fact that there are 'kiddos' coming up with
    Jeroen> things like found in: http://www.garion.org/spamcalc/sorted.txt
    Jeroen> excerpt and apologies for the bad language used:

  And, so what?

  Does your software break?  Fix it.

  Are you the internet censor?

    Jeroen> Yes reverses are good, but they are there for _administrative_ ease and
    Jeroen> for a teeny
    Jeroen> verification step, not for the fun of some 12 year olds.
  
  I strongly disagree.

    Jeroen> My suggestion would be to have reverses and maintain them, but for
    Jeroen> endusers, and
    Jeroen> yes I am also one of them, only allow reverse changes through some form
    Jeroen> of
    Jeroen> adminstrative step. Of course this al depends on the ISP and the ISP

  Why?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jul 2002 20:54:55 -0400

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

>>>>> "itojun" == itojun  <[email-masked]> writes:

    itojun> 	DNSSEC-signed reverse solves some of the problem, but not all.

    itojun> 	solves:
    itojun> 	- guarantees that noone spoofs PTR records, i.e. ensures integrity
    itojun> 	  between the records held by authoritative nameserver and the response
    itojun> 	  you've got
    itojun> 	- address-to-key mapping and secure distribution of those keys, like
    itojun> 	  those used in opportuniistic encryption

    itojun> 	does not solve:
    itojun> 	- integrity between forward and reverse DNS records
    itojun> 	  (btw, with scoped IPv6 address, it's impossible)

  By this, you mean that:
     host1.example.com -> 3ffe::00c0:ffee -> host2.example.com

  ?

  Yes, we have to continue checking this problem. Since both AAAA and PTR
records are 1:n mappings, we will always have this problem.

  Getting rid of reverse zones simply guarantees that we have no useful
diagnostic information.

  Yes, reverse zone for scoped IPv6 addresses is a local matter.

---

From: [email-masked]
Date: Mon, 8 Jul 2002 15:28:17 +0000 (UCT)

> >>>>> "bill" == bmanning  <[email-masked]> writes:
> 
>     bill> 	and the whois data get has only one instance and is
>     bill> always correct...  :)
> 
> Except when your ISP hasn't bothered to tell the RIR that they've
> handed you some chunk of the address space that the RIR assigned to
> them.
> 

	notice the smiley...  the last count I made was
	~70 whois servers, many with "replicated" data
	and no means to keep the data in sync. rWhois
	was a valient attempt but has yet to gain traction
	(and it has its own warts).

	The whole argument seems to boil down to that
	age old split,  "do I delegate responsiblity to 
	others or not."

	the net is getting larger. What are we doing to increase
	"clue density"?  

--bill

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Jul 2002 09:53:24 -0700

> 	when forward and reverse match, you have potentially -two- 
> 	distinct administrative regimes that agree on the target of
> 	the delegation.  Based on the heirarchical nature of the DNS,
> 	I can follow delegation chains, increasing my confidence in 
> 	the answer.  

Well, there are obvious loopholes in this reasoning. Suppose that the
organization "example.com" has managed to optain the network prefix
2001:0123:4567::/48, and delegation of the corresponding subtree
"7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa". Suppose then that this organization
writes two scripts in its DNS server, that perform as follow:

1) any request to find a PTR record for
"0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arp
a" 
is served by providng an automatic response: 
"2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com"
In which the local name part is simply derived from the requested
address;

2) any request to find an AAAA record for 
"2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com"
Is served by providing the automatic response:
2001:1234:4567:0001:FEDC:BA98:7645:3210
In which the address is simply a parsing of the last name part.

Bingo -- the forward and reverse address do match!

In fact, I would expect many organizations to do just that, possibly
with an exception for a few servers and hosts for which they really want
to provide a mnemonic name. It has quite a few advantages, such as not
revealing to the outside the structure of the corporate network. This
would solve most of the reverse lookup issues for the delegated address
spaces. It does not however solve the issue with 6to4.

-- Christian Huitema

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 08 Jul 2002 13:25:44 -0400

I noticed the "whois considered useful" a few days ago. In another universe,
unfortunately proximal, the protocol running on port 43 is either for mining
personal identifiers, or for trademark infringement discovery, or for "law
enforcement".

Issues like correctness, consistency, completeness -- these aren't what is
controlling the policiers of whois data.

Eric

---

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

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Jul 2002 16:33:08 -0400 (EDT)

Still a [wrong] +++ assumption +++:

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.

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.

Whois can be scaled with replication, and you can obtain local copies if
you really do a lot of analysis.  Restrictions on whois use presently
apply to abusive uses only.

		--Dean

On Mon, 8 Jul 2002, Mathias Koerber wrote:

> Add to that the fact that mass-WHOIS lookups are in at least some
> cases frowned upon or restricted already, so that using WHOIS information
> to check through only a short log of anything may not even be possible
> 
> mk
> 
> --On Monday, July 08, 2002 01:35:16 PM +0000 [email-masked] wrote:
> 
> > 	and the whois data get has only one instance and is always
> > 	correct...  :)
> >
> > 	Its not ideal, but its much stronger than a single lookup
> > 	into a whois database. Of course both whois and dns depend
> > 	on the integrity of the routing system. And DNS does have a
> > 	defined method for checking the validity of a response (DNSSEC)
> > 	while whois has no such integrity checks.
> >
> >
> >>
> >> But the problem is your [wrong] _assumption_ that when forward and
> >> reverse match, you have "identified someone responsible". You haven't
> >> done anything of the sort. Garbage in just matches garbage out. If you
> >> have the IP address, you will be able to find out (eg from DHCP logs)
> >> who was assigned that IP address at a certain time, and you'll be able
> >> to find the DHCP server owner starting from whois records. If you have
> >> only the reverse DNS, you have nothing.  Even if the reverse matches the
> >> forward, you still have nothing.
> >>
> >> If your assumption were true, then reverse DNS might be warranted. But
> >> your assumption is false, and it has proven very difficult to eradicate
> >> that false assumption. Because of the difficulty of that eradication, and
> >> the danger posed by the misplaced trust, in comparison with the minor
> >> cosmetic benefits of having it, reverse DNS needs to be deprecated.
> >>
> >> 		--Dean
> >>
> >> On Sun, 7 Jul 2002, David Terrell wrote:
> >>
> >> > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote:
> >> > >
> >> > > 2)  3rd party may want to identify the source of traffic to complain
> >> > > about spam or abuse, not  necessarily per host but per /48. What 3rd
> >> > > party want is not the FQDN but the contact (tech-c or admin-c) of
> >> > > the source,  per /48. Whois db is enough to get the contact.
> >> >
> >> > One justification behind TCP wrappers paranoid mode (require reverse,
> >> > require that reverse and forward match) is that whois data can
> >> > easily become stale, but tcp wrappers will enforce that reverse DNS
> >> > will at least identify someone responsible for the domain (because
> >> > forward matches).
> >> >
> >> > I like being able to identify the source of traffic in my logfiles
> >> > without having to run whois against every single entry.  This becomes
> >> > more crucial with IPv6 (addresses are harder to remember and identify
> >> > easily), not less.  I do not think that deprecating the reverse
> >> > tree is warranted or acceptable.
> >> >
> >> >
> >>
> >>
> >> --

---

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:

> Whois is much more trustworthy, since the administrative domain is
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.

> 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: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 08 Jul 2002 21:03:40 -0400

> On 7/8/02 1:33 PM, "Dean Anderson" <[email-masked]> wrote:
> > you really do a lot of analysis.
> 
> Can you say HOSTS.TXT?  I knew you could.

There is a difference. The data published by the NIC as HOSTS.TXT was
ephemerally accurate. The data published by whois publishers has the
endearing property of being persistently inextant or inaccurate.

HOSTS.TXT, partially shredded. 

Cheers,
Eric

---

From: Dean Anderson <[email-masked]>
Date: Tue, 9 Jul 2002 16:55:27 -0400 (EDT)

Yes, 'with DNSsec'. Supposing DNSsec _can't_ be spoofed (another
assumption with uncertain truth), A signed garbage domain is still
garbage. You don't know who or where the stuff in your log came from.  
Your resolver is happy, though.  The bad guy just registers a domain with
no information, signs up nameservice with no information. If thats not
sufficient, they just deregister the domain.

And I still don't expect that many domains will be secured with DNSsec, so
what's in your logs could still be spoofed.

Since you don't have any IP's, you have nothing to go on.

		--Dean

On 8 Jul 2002, Derek Atkins wrote:

> Dean Anderson <[email-masked]> writes:
> 
> Not with DNSSec.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 9 Jul 2002 17:11:16 -0400 (EDT)

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

Whois is a client/server architecture that can be delegated and
replicated.  It is just as scalable as DNS, and having fewer complications
than DNS, is arguably more scalable with less compute, bandwidth, and
memory overhead.  It has no comparision with HOSTS.TXT.

Putting everything in DNS simply because you can't figure out how to write
software is an unnecessary drain on DNS servers everywhere. I suppose one
doesn't need LDAP, or any other protocol. I suppose one could even
implement remote shells with DNS.  Maybe we can do backups with DNS.  I'd
like to be in charge of that committee.

Square Peg, Round hole: In some places the peg is too big for the hole. In
others, its too small. This is exactly the sort of problem you have with
using reverse DNS for authentication.  

Its not that reverse dns is totally useless, its that the utility value is
less than the cost of the risk posed by its misuse as an authentication
method, and the cost of garbage put in log files instead of useful
information, such as the IP address.  This misuse has a significant cost,
and the utility is mostly, perhaps even completely, cosmetic.

		--Dean

---

From: Derek Atkins <[email-masked]>
Date: 09 Jul 2002 18:10:06 -0400

> Since you don't have any IP's, you have nothing to go on.

Dean, you're talking apples and oranges.  First you say that domains
can be spoofed.  I maintain that DNSSec can protect against that.
Then you go off and talk about registering phantom domains and setting
up fake records to those phantom domains.  What kinds of attacks are
you worried about?  From where I sit you can't seem to make up your
mind and every time someone points out a flaw in your argument you
change it.

What other people are worrying about is the quazi-ephemeral nature of
IPv6 addresses.  A domain name is going to last a couple years in the
databases.  An ipv6 address is less likely to last quite so long
(according to some).  Having an IP address that has changed hands 5
times is much less useful than a domain-name.

Does it mean the domain name is _REAL_?  No.  However if forward and
reverse match (and the PTR does not point to itself), you have some
validation about the existence of the domain.  For example, while I
can put a PTR to foo.ibm.com in my reverse domain, it's highly
unlikely that I can get ibm.com to put it in their forward domain.

Who cares if the answer is spoofed?  We're not running military or
life-or-death systems using this.  It's a tool, like everything else,
and a significant piece of the community find the tool useful.
Perhaps tools should log both the IP Address _and_ the PTR record (and
maybe whether the forward record matches).

Should reverse domains be _MANDATORY_?  Hell no.  Should it be
RECOMMENDED, yes.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 09 Jul 2002 21:39:06 -0400

> the end of the useful part of the discussion.

You may be right.

> memory overhead.  It has no comparision with HOSTS.TXT.

954 doesn't mention delegation or replication. Neither does 812, nor does 742.

If you are discussing an implementation, could you be specific as to which
you are referring to?

Eric

---

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: Dean Anderson <[email-masked]>
Date: Wed, 10 Jul 2002 11:11:02 -0400 (EDT)

> can be spoofed.  I maintain that DNSSec can protect against that.

The problem is the improper use of reverse dns for authentication and
access control. There are multiple ways that reverse dns-dependency can be
exploited, both with and without DNSsec. I'm sorry if that isn't clear.

The fundamental harm is using reverse DNS as the basis for 1)
authenication/validation 2) logging of the communication.  Logging is to
identify when, what, and who. If you can't identify "who", because you
used a reverse DNS entry that has only cosmetic value, you have failed in
the logging task.

When people put host.example.com in their firewall configuration, this can
be spoofed, and access granted inappropriately.  DNSsec _could_ (big
assumption) _possibly_ fix that case (only that case) _if_ the specific
domain in question is signed, and DNSsec can't be spoofed.

However, DNSsec cannot fix the case of validation, nor can it solve the
logging problem.  DNSsec only protects the domain that is signed.  Even if
DNSsec is "widely" deployed, it is unlikely that everyone would use it,
and even unlikely that many would use it.  If DNSsec were required, then
it is still possible, as I said, to register a fake domain for a short
time to put useless data in your logs or satisfy your "validation" check.  
There is no way to strengthen DNS to make your "validation" assumption
true, even including DNSsec.

The problem isn't specific to IPv6. It is the same on v6 and v4.

You have no validation of the existance of the domain, except through
whois for the domain, which as was pointed out, can easilly be faked on
many domain registries.  That reverse and forward match means exactly
nothing. By contrast, the Address space registries are usually dealing
with businesses and so their records are much more trustworthy. I have yet
to see an ARIN record with 000-000-0000 as the phone and no address, and
no name. Sometimes the addresses and phone numbers are wrong, because the
businesses have moved, but the businesses can still be found. The only
thing that is even remotely tangible is an IP address.

The next thing you'll say is that the reverse record comes from the
address registry: It doesn't. It is often delegated to the end user, who
can set it to garbage.  Then your "validation" may succeed, but your log
entry is useless. (This is without spoofing---They could still be spoof
the same useless garbage).  If you had the IP address instead, it would
not be so useless.

The expected "quasi-ephemeral" nature of IPv6 address just makes the
current reverse system even harder to maintain than it is now, so
"validation" demands are even sillier than they are now.  

But the essential silliness of the proposition that there is some meaning
to be attached when forward and reverse match is independent of v4 and v6.

The problem is that reverse dns is being used inappropriately as snake
oil, and people like you keep insisting that there is meaning to something
that is meaningless, and you cause significant harm by doing so.  That is
why we should deprecate reverse dns. Yes, that basically ruins it for
everyone who liked the cosmetic uses.  But the alternative is worse.

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Jul 2002 13:06:36 -0500

I don't know of _anybody_ who still uses the reverse map to do 
authentication.   Once in a while I hear about people who still use telnet,
  but that's a rarity nowadays.   I suppose there's probably someone out 
there who still uses rsh, but they're probably at least taking pains to 
make sure that the packets are never exposed outside of their corporate 
network.

My point is that nobody here is saying that we should be using the reverse 
map for authentication.   So why do you keep bringing it up?

The only thing we're talking about here is using the reverse map for 
validation.   Validation is a tricky term.  In some cases, it means 
"verifying that the data is correct."   In other cases, it means 
"corroboration."   In this case, I think we are all talking about 
corroboration, not verification.   Corroboration just means that you have 
two entities who agree on something.   It doesn't mean the something is 
correct.

In theory, we can never depend on corroborated data, because the mere fact 
that two unknown entities who might actually be the same entity claim that 
something is true does not mean that it is true.   I don't think there is 
a single person here, Dean, who would debate this point with you.

The debate is not over whether corroborated data can be depended upon, but 
rather whether corroborated data can be useful.   And it seems that most 
people agree that it can be useful, with a few notable exceptions, yourself 
included.   Despite these exceptions, we do seem to have pretty broad 
agreement on is that we should *recommend*, not *require*, that people set 
up reverse domains.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Jul 2002 20:38:50 -0400 (EDT)

> If you are discussing an implementation, could you be specific as to which

Rfc2167 has all of the delegation and replication stuff.

		--Dean

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 11 Jul 2002 10:26:01 -0400

> Rfc2167 has all of the delegation and replication stuff.

Oh. The protocol running on port 4321. Not the protocol running on port 43.
That might account for some misunderstanding.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Jul 2002 15:30:19 -0400 (EDT)

And you're one of the people who thinks there is agreement where this
isn't any.   Funny, that is the same problem you have with reverse DNS. I
wonder if its some unidentified disease of the center of the brain that
processes meaning and significance... ;-)

		--Dean

On Thu, 11 Jul 2002, Ted Lemon wrote:

> > I don't think we have agreement even for that - there are plenty of people
> > who actually want the IP6.ARPA (and IP6.INT) - and maybe even IN-ADDR.ARPA
> 
> Right, you're one of the people who doesn't agree.   Of course you don't 
> think we have agreement.
> 
>

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Jul 2002 15:37:55 -0400 (EDT)

On Thu, 11 Jul 2002, Ted Lemon wrote:

> To be a little less opaque, let me just point out that what you are trying 
> to do here is to solve problem in a standard that can't be solved in a 
> standard.   There is a reason why people set up services that expect the 
> forward and reverse to match.   It's a useful sanity check in some cases, 
> and it's handy for logging in many cases.

Well, at the risk of saying "no, its not", I'll just say "No, its not a
useful sanity check, and its not handy for logging." These are the things
reverse DNS should NOT be used for.

> My worry is that you, and perhaps Dean, are arguing that PTR records should 
> basically go away, and I think the reason you want them to go away is 
> because you believe they are being misused, and if they aren't there they 
> can't be misused.   So you're arguing that we should get rid of very useful 
> functionality in order to force people to stop misusing it.
> 
> Baby.   Bathwater.   Need I say more?

Baby toys. Cute, Sparkly, but choking hazard.  Clearly, its needs to go,
since the children can't handle the responibility or understand the
implications. 

But I'll shutup now, and let other people disagree.

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2002 17:52:33 -0500

> reverse DNS should NOT be used for.

Yes, you've stated this several times.   Stating it several times doesn't 
make it true.

> since the children can't handle the responibility or understand the

Right, you've said this too.   Several times.   Thanks.   I didn't quite 
understand it the first time.   :'}

Unfortunately, I still don't understand your point.   I get lots of good 
use out of the reverse mappings, and I really haven't seen any evidence of 
widespread misuse of them.   Have you?   Care to elaborate?   You seem to 
be very happy to keep repeating your basic reasons for objecting, but when 
someone asks you to justify them, you do not do so.

---

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

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 13:07:56 -0400 (EDT)

Ditto. You made objections about my objections, but you just restated that
there is meaning to the state when reverse and forward match.

You didn't offer any evidence that there is any meaning to such a state,
except you and some others commonly make that assumption. That others make
the same assumption isn't proof the assumption is true.

And you asserted that DNSsec makes the objections I raised go away. But I
showed that it only makes some problems go away, not all problems, and in
some cases, DNSsec makes no problems go away.  So your objection is
incomplete, and does't address my objections.

Essentially, we are just circling about the meaning of the state when
reverse and forward match. So in that respect, we are at an impasse.  I
suppose we have to bumble forward somehow.

Frankly, I think I've offered credible evidence that there isn't any such
meaning, and I've shown there are specific harms to the assumption that
there is such meaning.  All you've offered is that its handy and some
people use it this way, and that DNSsec might help.  I don't think you've
made a positive case for retention of Reverse DNS.

Do others?  Robert?

		--Dean

On Fri, 12 Jul 2002, Ted Lemon wrote:

> No, no, this is precisely the point, Dean.   You stated two objections, and 
> when people pointed out the problems with your objections, you stated them 
> again, without addressing the problems that were raised.   Just now you 
> restated them once more, again without addressing those problems.
> 
> I am tempted to once more restate my arguments about your objections, but 
> it seems pointless - we could go around like this forever.   This is why 
> working groups are only required to reach "rough" consensus - sometimes 
> there will be someone who, perhaps rightly, but as a minority, simply will 
> not budge from their firmly held opinion that what is being proposed is 
> wrong, and shouldn't happen.   So we blunder forward and see what happens.
> 
> 
> --

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 19:14:03 -0400 (EDT)

On Fri, 12 Jul 2002, David Terrell wrote:

> Yes, but then I can break your claimed superior solution of rwhois 
> by simply spoofing the A{,AAA} record of the rwhois server. :)

Someone (you?) already said that. I replied that doing this is much harder
than the former, since the rwhois spoofer does not know _when_ I'll make
that lookup. Inconveniently (for the spoofer), its made some variably long
time after his bad activity. By contrast, the Reverse/Forward DNS
(logging, validation, authentication, etc purpose) spoofer _knows_ when
this lookup will be made. Conveniently, its made at roughly the same time
as his bad activity.

> A node to name mapping is a fundamental necessity for various pieces
> of functionality on the internet.  Let's not forget that that
> mapping, like all others, should be verified and hopefully signed;
> but it's not a trivially removable component of the architecture
> of the internet today.

This is a new objection, unless I missed it before. If so, I'm sorry.

What exactly would break irreparably without reverse DNS?

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2002 22:26:11 -0500

> this lookup will be made. Conveniently, its made at roughly the same time

Let us take as an axiom that we should only log IP addresses and never log 
reverse DNS information.   If that's so, then when I go to figure out, 
after the fact, who owns the IP address, I have two tools available to me 
- the rwhois database, and the DNS.   Both are useful.   If there is 
information in the rwhois database, I can use it.   If there is information 
in the DNS, I can use it.   It is not the case that either bit of 
information is definitely true or definitely false; rather, both pieces of 
information provide me with clues.   If I do the lookup later on, the 
attacker can't know when, whether it's a DNS lookup or an rwhois lookup.

But because of the axiom we have chosen, we have forgone one of the clues 
we might have used in our search for the culprit - we have not recorded the 
information in the DNS at the time of the event.   Like the other two 
pieces of information, the information from the DNS is a clue, not a 
provably true statement.   But we have one less clue.   I agree with you 
completely that logging just the information from the DNS is wrong; what we 
disagree on is whether the information from the DNS is useful.

I should like to point out to you that spoofing the DNS is not *quite* as 
easy as you claim.   When I go to look up a new PTR record, I probably don'
t just go to the NS record that's conveniently in my cache and send the 
request to that IP address, because I don't have the NS record in my cache 
yet.   In fact, what I do, most likely, is go to the highest zone I've 
cached, which is probably in-addr.arpa, or if I'm lucky maybe 204.in-addr.
arpa, and look up the NS record there.   Then I work my way down.

So the attacker has to do a pretty difficult job - it has to send in the 
attack that we're logging, and also guess not one but two or more 
transaction IDs that my name server will generate, *and* it has to guess 
what I have in my cache, *and* it has to get the forward lookup right as 
well, and it has to get the timing right so that the answers come soon 
enough that they are used, but late enough that they don't anticipate the 
requests.   *Or* it has to be on the local network.   Doing this on the 
local network would be a challenge, but definitely doable.   Doing this as 
a remote attack would be a truly impressive feat.

But you are quite right that we can't trust the information the name server 
returns, unless we have DNSSEC, and maybe not even then.   Does that render 
it useless?   No.   It's still a clue.   It's still useful.   Of course it 
shouldn't be taken as gospel, but it's useful.   So your reasoning still 
isn't valid - you still haven't disproven the premise that logging the 
reverse zone information from the DNS is useful, nor have you proven, as 
you assert, that logging this information causes harm.

> What exactly would break irreparably without reverse DNS?

We would lose a piece of the puzzle that's available to us now.   Baby.   
Bathwater.   Need I say more?

> But as I said, a false sense of comfort leads one to grant access that
> should not be granted with the information available.  This is sort of
> thing may have led to the r-cmd problem, and it could still happen, as
> other kinds of access is granted based on the false sense of comfort

You are absolutely right.   If people were using the information from the 
DNS in this way, it would be Bad.   Really Bad.   We would want to take 
some kind of action to discourage this practice, perhaps even the course of 
action you propose.   But rounded to the nearest hundred, nobody is using 
the information in the DNS this way.   So why are we even talking about 
this?

---

From: Dean Anderson <[email-masked]>
Date: Sun, 14 Jul 2002 15:57:59 -0400 (EDT)

> attacker can't know when, whether it's a DNS lookup or an rwhois lookup.

With the exception that a spoofer can make the DNS information false. When
the Rwhois information is false, its due to adminstrative error by the
rwhois authority.

> disagree on is whether the information from the DNS is useful.

Except that as a clue, it could be misleading, and whether it is
misleading is under the control of the bad people.  This is somewhat
analogous to the testimony of convicted criminals. You can't be sure of
whether they are telling the truth, or attempting to frame someone else.

> easy as you claim.   When I go to look up a new PTR record, I probably don'

"Easy" depends on either skills or tools.  For example, there are now
plenty of tools to root linux boxes. Such tools are used by people who
don't have any skills at administering linux boxes or even how the
exploits work, as I have directly observed with analyzing rooted linux
boxes.  There could be tools to spoof reverse DNS.

> a remote attack would be a truly impressive feat.

It was easy enough to exploit rcmds vulnerabilities remotely.  It could be
harder with more random transaction ids, but as we know, there aren't
truly random numbers.  So the task becomes "trivial" again once you can
predict the random number sequence.

> shouldn't be taken as gospel, but it's useful.   So your reasoning still 

And how are we to argue against those who say it should be "taken as
gospel"?

> Bathwater.   Need I say more?

Yes. You should say more.  I can't think of anything that would break,
except the illusions of many people have the reverse DNS is something
absolutely trustworthy, and absolutely necesary before any trust should be
given.

> the information in the DNS this way.   So why are we even talking about 

OK. So you agree that if people are putting too much trust in reverse DNS,
then it would be reasonable to remove Reverse DNS.

I think a lot of people are using reverse DNS in this way. Recent
discussions on Nanog revolved around the "evil" of ATTBI not delegating or
populating reverse DNS.

I would like to propose a compromise as a way to bumble forward:  I could
be happy with optional reverse DNS provided there were very strong
statements made which indicate that the answers given by Reverse DNS have
no special meaning even if "coroborated" by forward DNS, and that DNS
shouldn't be used for logging, or authentication, or any sort of
validation purpose, and that Reverse DNS is an optional, purely cosmetic
service. Would you agree to this?

		--Dean