Subject: The reverse lookup issue

From: "Christian Huitema" <[email-masked]>
Date: Wed, 3 Jul 2002 11:59:11 -0700

As we are looking at evaluating various transition mechanisms, we will
need to address the reverse lookup issue, i.e. how to get the equivalent
functionality to "gethostbyaddr()", and whether we really need it.

I am specially interested by the solution in the case of unmanaged
networks, such as a home network. Today, it kind of works as follow: the
ISP allocates an IPv4 address to the home gateway or NAT; that address
belongs to the range of IPv4 addresses managed by the ISP; reverse
lookup are served directly by the ISP's DNS server. The level of service
varies a lot, but the dominant solutions are either a perfunctory
record, such as the ISP "example.net" mapping "64.5.6.7" to
"ip4-64-5-6-7.example.net", or no service at all.

The problem is particularly acute with "autoconfigured" solutions such
as 6to4, Teredo and to some extent ISATAP. The 6to4 router that builds a
prefix for "2002:4005:607" may or may not obtain a delegation of the
domain "7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa" -- that can be arranged if was
statically allocated and the ISP allocating the address is "64.5.6.7"
willing to delegate, but the operational implications are daunting.

Even if the 6to4 router actually obtains delegation, we are not out of
the woods. Unmanaged networks will typically use automatic address
configuration, specially as they want to enhance the users' privacy with
"privacy addresses." The only practical solutions there are either to
use an algorithm and generate perfunctory records (e.g.,
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.1.0.0.0.7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa
maps to 
ip6-abcdef01234567891000706050042002.example.net); or somehow forward
the DNS request to the host itself, which will answer with some
arbitrary value.

So, my question is, do we really need to invest in a reverse lookup DNS
tree for IPv6? Or should we not just "declare victory" and recognize
that reverse lookup has very little practical value?

-- 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: "Louis A. Mamakos" <[email-masked]>
Date: Wed, 03 Jul 2002 15:36:12 -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! ]

> that reverse lookup has very little practical value?

I think that about a decade ago (or so I it seems..) I suggested that
we abandon the notion of using the DNS to do address->name lookups.
Rather, define a simple standard service where a host can be asked
what it thinks it's name is.  In many cases, this does the "right
thing" in that you get a meaningful name at the time that the
address was allocated to someone (e.g., out of a DHCP pool or other
transient network connection.)

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

Or simply decide the practical value is small.

louie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 14:51:57 -0500

I am also somewhat skeptical about the value of reverse lookups, but people 
seem to like them, so I'm not sure if debating their value serves any 
purpose.   If the customer wants it, and it's a valid thing to do, who are 
we to tell them they can't have it?

This is a difficult problem to solve, though, with stateless addrconf, 
because the only device that can really update the DNS is the device that 
has configured its address, and that device might well not have any sort of 
security relationship with the owner of the address space.   Since reverse 
lookups to some degree go hand-in-hand with a desire to control use of 
addresses, it might make sense to say that we can only do this with 
stateful addrconf.

---

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

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

---

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

> that reverse lookup has very little practical value?

the practical value goes above and beyond those you've mentioned.  i expect
that many services, especially e-mail but also any other abusable service,
will continue to reject connections for which no "reverse lookup" is known.

we live on an increasingly irresponsible internet.  my root name server gets
more than a gigabyte of request traffic every day just from 10.0.0.0/8.  we
all get a huge amount of spam.

anything that makes it harder to locate a responsible party for a given IP
address (whether v4, v6, v8, or whatever) is automatically, unarguably "bad."

---

From: [email-masked]
Date: Thu, 04 Jul 2002 06:23:55 +0900

>functionality to "gethostbyaddr()", and whether we really need it.

	how about draft-itojun-ipv6-nodeinfo-revlookup-00.txt?
	(i know the IESG pushback for ICMPv6 node info query, and the
	deployment problem)

>that reverse lookup has very little practical value?

	as documented in draft-ietf-dnsop-inaddr-required-03.txt, if we
	could nuke reverse lookup tree it would be nice.  but there are
	apps that use gethostbyaddr(), we need something.

itojun

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 3 Jul 2002 23:53:07 +0200 (CEST)

> what it thinks it's name is.  In many cases, this does the "right

If you wish 'simple', you may as well use something very much akin to
ident(1431), or indeed, overload the existing ident protocol with a
slightly different request and answer.  Not that I'm seriously suggesting
that.

> transient network connection.)

As DNS operational folk have seen (MS, ddns by default), if you give the
user the ability to define their own name, they will attempt to declare
themselves to be 'all.high.and.mighty', and I really wouldn't like to see
that sort of string appearing in my access logs.

> the one in DNS PTR records, either.

If you wish vaguely reliable, you've got the existing (reverse) DNS at the
administrative mercies of providers/hopefully clued users.  Most PTR
records, if available, do have some sort of relationship to the
responsible person behind the host.

> Or simply decide the practical value is small.

The practical value of address to name mapping is large for the site
administrator; 'What is the host behind this IP address?'.  If the host in
question has been compromised, you can no longer trust _anything_ from
that host.  Hence, a requirement for address to name mapping does exist.
DNS, so far, appears to work in providing that functionality.

People outside your site may have policies (sometimes poorly thought out)
that require you to provide some level of address to name mapping.  This
may or may not alter your liking of doing such.

Regards,

--==--
Bruce.

Speaking for myself.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 03 Jul 2002 17:06:37 -0500

on 7/3/2002 1:59 PM Christian Huitema wrote:

> tree for IPv6?

Yes, it's useful and necessary to a variety of validation processes,
especially when used with double lookups (check PTR and A both ways).

I would think that DDNS could handle the dynamic scenarios but perhaps I
don't understand the problem.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Alain Durand <[email-masked]>
Date: Wed, 03 Jul 2002 15:39:56 -0700

> that reverse lookup has very little practical value?

You might want to look at draft-durand-ngtrans-dns-issues-00.txt
that tries to summarize some issues around DNS in IPv6 land
and the discussion last week in DNSop mailing list
about reverse lookups.

	- Alain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 18:04:25 -0500

> don't understand the problem.

How do you establish a security association between the DNS server for the 
reverse zone and the node with the IP address?   This is a key management 
problem of epic proportions.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 4 Jul 2002 08:21:55 +0859 ()

Christian;

> networks, such as a home network.

Wrong.

If a home network is unmanaged (by an ISP), it is not connected to
the Internet and is not a problem.

Instead, a home network can be wrongly managed.

Any kind of problem can be caused by creative wrong management,
which IETF can not forbid.

IETF, instead, can write documents on dull ways of management and
possibile consequences of the creativity.

						Masataka Ohta

---

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: "John M. Brown" <[email-masked]>
Date: Wed, 3 Jul 2002 18:27:29 -0600

yet if the host you are asking has been compromised then
it could give back an invalid name.   whereas the in-addr
tree is typically managed one or more levels above the
host, and often by a different party.  thus two or
more systems would have to be compromised.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Louis
> A. Mamakos
> Sent: Wednesday, July 03, 2002 1:36 PM
> To: Christian Huitema
> Cc: [email-masked]; [email-masked]
> Subject: Re: (ngtrans) The reverse lookup issue
>
>

---

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: Masataka Ohta <[email-masked]>
Date: Thu, 4 Jul 2002 10:16:25 +0859 ()

Christian;

> host configure its own address: automatic address configuration based on

DHCP is the best possible for autoconfiguration.

Any attempt beyond it is to make the Internet fool proof and your
issue is creativity of fools having nothing specifically to do with
reverse look up.

							Masataka Ohta

---

From: David Terrell <[email-masked]>
Date: Thu, 4 Jul 2002 00:17:38 -0700

On Wed, Jul 03, 2002 at 09:53:47PM -0400, Michael Richardson wrote:
>   Precisely *this* has been proposed.
>   I can't recall if it was Keith Moore or Bill Manning that had code to do
> exactly this using plug-ins to bind9.

Keith wrote a draft that proposed several mechanisms and debated
their reasonability.  I implemented one suggestion (not perfectly)
for bind9's sdb mechanism, that creates pseudoauthority records for
2002:abcd:efgh:: that point to 2002:abcd:efgh:magic-suffii.  It is
available here: http://meat.net/~dbt/code/rev6to4/

The other method (infer authority records from closest authority
records in IPv4 in-addr tree)  was implemented by Feico Dillema in
his self-described DNSALG totd, available at
http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html.

The draft is expired, though I've placed a copy of it at 
meat.net/~dbt/code/rev6to4/draft-ietf-ngtrans-6to4-dns-00.txt.
I do not have an archived copy of the -01 draft and it has 
expired.

-- 
David Terrell          | Step 1: "configure one system using your GUI"
[email-masked]           | Step 2: "now configure 1000 more"
Nebcorp Prime Minister |   - Casper H.S. Dik
http://wwn.nebcorp.com |

---

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

This misuse of reverse DNS is probably the single best reason to abolish
it altogether.

Reverse DNS has no bearing on the location of parties responsible for IP
addresses.  ipv4-65-14-33-11.example.com gives no information, and just
wastes time for those who have to create such silly entries, and waste the
memory of nameservers that have to store these meaningless entries.

		--Dean

---

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

> 1) In enterprise networks, reverse lookups provide a way to identify the

Do you mean within the organizations network? If so, this is better
handled by a enterprise whois database of internal address assignments
rather than in-addr.  In many very large organizations, there is no
central database. For example, when I worked for Hitachi, I depended on
the internic (subsequently ARIN) whois server to figure out which Hitachi
org had what address blocks. There were a lot! And back then only 3 people
were even remotely concerned about the issue--myself, a guy in Oklahoma,
and another guy in Japan. That was worldwide, for the 7th largest company
in the world. Most divisions were only concerned about the connection to
the divisions they transfered files with, and had no concern with global
connectivity.

The trouble with in-addr is that too much information is given out, or one
must run private nameservers, in which case too much information may be
given out to employees.

> compromised or mismanaged.

ISP's frequently don't give out any information on who the customer
is. The inverse lookups are usually just the ip address encoded by a
script that generates names from IP addresses.  As I said before, this is
meaningless, and a waste of time, Nameserver memory, and bandwidth.

> check that the name provided by the caller is not entirely bogus.

Most don't work this way. Those that do address checking merely check if
the reverse answer matches somewhat the corresponding forward.  The sort
of check you describe would fail when the SMTP server is handling multiple
virtual domains, since in that case you want to put in the virtual domain
sending mail rather than the reverse of the IP address. The virtual domain
can clue which customer is sending the mail. The IP address is known
already.

		--Dean

---

From: Jim Reid <[email-masked]>
Date: Thu, 04 Jul 2002 06:51:58 -0700

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> This misuse of reverse DNS is probably the single best
    Dean> reason to abolish it altogether.

Some applications and protocols rely on reverse lookups. The BSD line
printer daemon and r- protocols for example. Nobody would disagree
that these things are somewhat broken by relying on reverse lookups
for authentication and access control. But it's a fact of life that
they exist and are widely used. They can't be wished away, much as we
might like them to. Security software like SSH and TCPwrappers can
use reverse lookups. How do you propose to replace/modify them if
reverse DNS is killed?

    Dean> Reverse DNS has no bearing on the location of parties
    Dean> responsible for IP addresses.

It is quite often a more reliable indicator -- if only by establishing
where the reverse tree delegations end -- than anything else. ISPs
often fail to update the RIR whois database when they hand out
addresses to their customers and delegate the reverse tree to them.

---

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: bert hubert <[email-masked]>
Date: Thu, 4 Jul 2002 16:27:14 +0200

> use reverse lookups. How do you propose to replace/modify them if

Reverse DNS is already going the way of the dodo. I see no reason to
explicitly deprecate IPv6 reverse though. Already it is becoming hard to
explain many ISPs what this reverse thing is or why it is good.

Trying to make RFCs that do nothing but deprecate existing practice will
only put the IETF (further) out of synch with the real world by putting all
people using reverse DNS in a position where they are 'violating' an rfc!

Such behaviour causes inflation, leading to a devaluation of the power of an
RFC.

Just leaving out reverse from newer RFCs which obsolete earlier ones amounts
to the same thing.

Regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 4 Jul 2002 11:23:21 +0200

Michael Richardson wrote:

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
anyway different.
>   Citizens need control over their reverse maps. Period.

I agree to the fact that any person should be able to set up
his/her/it's/...
own reverse *BUT* seeing the fact that there are 'kiddos' coming up with
things like found in: http://www.garion.org/spamcalc/sorted.txt
excerpt and apologies for the bad language used:
8<-------------
3432 -
NA.PULA.SUJO.IN.CUR.SI.INTRE.MASELE.PANA.FACI.CA.LEANA.LU.VIOREL.DIN.DEA
L.bakan.OrG
3073 -
Screw.me.if.I.m.wrong.but.you.want.to.kiss.Dropsu.because.i.m.ircop.de
2759 - gov.edu.cc.com.ws.net.info.ro.sk.dk.co.uk.jp.ca.spy.org.ru
2449 -
drama.vietii.mele.prima.gagica.a.mea.avea.o.fata.de.desfacator.de.bere.s
poof.de
2082 - emma.and.weirdo.sitting.in.a.tree.d.o.i.n.g.it.doggiestyle.nu.
2020 -
Dropsu.e.ala.cu.sufletul.mare.dar.dont.asl.me.becuz.i.am.hijack.de
1743 -
nicu.plus.aneta.egal.pedofilie.si.aneta.plus.viorel.din.deal.egal.zoofil
ie.ipv4.de
1649 -
has.no.bandwidth.at.all.so.he.doesnt.belong.to.the.internet-elite.cx
1620 - roulez.and.feeva.is.the.king.of.the.turks.on.the.ircnetwork.de
1589 - i.put.my.foot.in.shit.and.now.it.is.a.shitfoot.com
1394 - IcH.wEiSs.IcH.SoLLte.GeHeN.UnD.IcH.WiLL.Ja.AuCh.AbErS.GehT.NeT
1296 - just.because.i.stink.doesnt.mean.i.am.a.heavy.drinker.net
1282 - fuck.with.me.and.get.anthrax.because.im.from.the.penismafia.com
------------->8
I don't really think it's always 'good' to allow it.
Though I have to admit that most of the crap seen on the list comes from
"ISP's" and
generally so called 'vhost' providers. They simply consume IPv4 space to
make 'nice'
reverses. In IPv6 IRCNet this is somewhat controlled due to the fact
that most opers
kline on sight (also in v4 space lately) and many tunnelbrokers watch
their reverses
so that these weird things don't pop up, also see
http://www.ipng.nl/index.php3?page=dnsspam.html
And yes it's mainly an IRC thing that people want to have good-looking
hostnames.

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.
Fortunatly we got RFC1178 already mentioning this, unfortunatly there is
no way of 
forcing/making IPspace owners abide these rules. And with dynamic
updates it isn't
quite easy to check it unless one logs the updates.

My suggestion would be to have reverses and maintain them, but for
endusers, and
yes I am also one of them, only allow reverse changes through some form
of
adminstrative step. Of course this al depends on the ISP and the ISP
itself can
go 'wrong' very easily (as said with all those vhost providers), but I
don't think
we should have to worry or even look at reverses for the last /64
assigned to a
cablemodem in terms of reverse dns management.

Another thing we could be looking at is saying that, as the last 64 bits
should usually
be on the same link that there must be a reverse for the first 64 bits
and there
should/can be reverses for the hostpart. Currently many SMTP servers
will do a forward/reverse
check and refuse service if there is a mismatch, we could say that if a
host doesn't have
a reverse it simply isn't set up correctly and probably should be
sending SMTP either and
refuse service, redirecting it to a local smtp which is set up by the
ISP with correct ACL's
and a matching forward/reverse. This in turn would kind of block spam
too.

>From reverse-dnsspam to UCE ;)

Greets,
 Jeroen

---

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: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2002 12:01:13 -0500

> memory of nameservers that have to store these meaningless entries.

It tells  you that the user (maybe) lives at example.com.   You can traipse 
up the in-addr chain looking for an SOA record, and see who's responsible 
for the zone.   Yes, "ipv4-65-14-33-11.example.com" doesn't say anything 
specific about the end user, but it is not completely worthless.

---

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: David Terrell <[email-masked]>
Date: Thu, 4 Jul 2002 14:31:06 -0700

> I do not have an archived copy of the -01 draft and it has 

(there never was any -01 draft, I am in error here.  Odd.  Sorry
for any confusion.)

-- 
David Terrell           | "The Court understands fully why licensing has many 
Nebcorp Prime Minister  | advantages for software publishers. However, this 
[email-masked]            | preference does not alter the Court's analysis that 
http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a 
  sale and not a license." - Judge Dean Pregerson, Softman v Adobe.

---

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

>  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

-----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: David Terrell <[email-masked]>
Date: Thu, 4 Jul 2002 16:01:42 -0700

> memory of nameservers that have to store these meaningless entries.

So, reverse DNS is useless because people can put useless information
into it.

> the divisions they transfered files with, and had no concern with global

In my organization, I use reverse DNS to track address assignments
to individual hosts and to identify the responsible admin for a
service quickly and easily.  It is a useful tool.

> must run private nameservers, in which case too much information may be

Ok, in-addr gives out too much information.  Which is it?

> meaningless, and a waste of time, Nameserver memory, and bandwidth.

My home machine has proper reverse DNS.  This makes it easy
for people who are having a problem with it to contact me
directly instead of having to go through my ISP to find out
who I am.  I consider that a feature.  If I did not want that
level of accountability, I would have my ISP reset reverse DNS
to some generic default.

> can clue which customer is sending the mail. The IP address is known

He's not talking about MAIL FROM, rather the name provided for
EHLO/HELO.

reverse DNS is an easy, loggable way of identifying the responsible
party for an address.  Sure, it's not always accurate but neither
is anything else on this internet.  whois can't support that kind
of load, nor should it.

-- 
David Terrell            | "the only part about medicinal marijuana that 
Prime Minister, Nebcorp  | bothers me is that, when I started chemo, all of 
[email-masked]             | my children and grandchildren told me they could 
http://wwn.nebcorp.com/  | get some for me if I needed it." -mrw's grandfather

---

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: Robert Elz <[email-masked]>
Date: Fri, 05 Jul 2002 19:16:29 +0700

Date:        Wed, 3 Jul 2002 11:59:11 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, my question is, do we really need to invest in a reverse lookup DNS
  | tree for IPv6? Or should we not just "declare victory" and recognize
  | that reverse lookup has very little practical value?

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.

Applications can go on doing lookups there if they like, and if you're
an ISP and want traceroutes through your net to give out names, then
you can fill in the PTR records (on traceroutes I do over v4 today, I
think I get about 50% of the routes with names, of which about 75%
give any useful information at all).

If you're a user of an application that for some odd reason actually needs
the data, then you will add the entries to the DNS, because you actually
need the things.

But we just end the pretense that every allocated address is going to
have a PTR record somewhere.   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).

[email-masked] said:
  | 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.

With IPv6 (and increasingly with IPv4) this is simply not generally true.
The information from the DNS is originating at the host that created it
in either case - with the DNS there's the extra step of an intermediate
agent involved, but all it is going is conveying to whoever asks is the
information the host told it to give out.    That's just the same as if
the end-host were asked directly.   The only difference is that the DNS
is perhaps more likely to be there to answer the question sometime after
the host has vanished - I used to think this was a valuable property,
but I have re-considered, it just isn't worth the pain.

[email-masked] said:
  | Yes, it's useful and necessary to a variety of validation processes,
  | especially when used with double lookups (check PTR and A both ways). 

Since you certainly cannot reply on anything in a PTR record not just
being supplied by the host itself, you may as well just ask the host what
its name is - even better, do that as part of the protocol of interest,
rather than as some extra add on.   The validation any of this provides
was useful only in the days when some human manually typed in all of the
names of the hosts on his/her network.   That just isn't what happens any
more.

[email-masked] said:
  |  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. 

This is not surprising at all.   The forward tree is allocated to anyone
at all, with no requirement for a "DNS operators licence" before a domain
will be handed out.   A forward domain is a practical necessity for most
operations on the internet, and is also used as a vanity piece (and squatting),
where whether the domain works or not isn't relevant, only that it exists
(but in the domains that matter, existence isn't allowed without delegation,
but delegation accuracy isn't verified).

All this leads to lots and lots of breakage.

On the other hand, in-addr.arpa domains aren't required for almost anything.
That tends to mean that they're only set up by people who have some kind of
clue what they're doing.   Consequently it isn't at all surprising that
what exists out there is better looked after than the forward domains.

If anything, this is evidence for lowering the expectation that reverse
lookups will succeed - just because it is providing evidence that this
is the current state of the world.

[email-masked] said:
  | Getting rid of reverse zones simply guarantees that we have no
  | useful diagnostic information. 

No, you still have the addresses.   Those are more useful for most
diagnostics anyway.

As the percentage of addresses which map to meaningful names drops
further and further (and it is doing so, no question about it) the
futility of attempting to pretend that people who haven't filled in the
reverse tree are somehow derelict in their duty will become more and
more obvious.

Although the message I sent a while ago to dnsop read as if I was
suggesting that we should delete the IP6.{INT,ARPA} trees completely,
that isn't my position (it wasn't phrased as well as it should have
been).   Leave the things for anyone who really wants to use them.
Just stop trying to tell people that they *have* to use them.  Personally
I'm sick of doing lots of work just so all the rest of you get prettier
log files...

kre

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Jul 2002 22:26:45 -0400 (EDT)

> use reverse lookups. How do you propose to replace/modify them if

Easy. This can already be turned off in ssh and tcpwrappers. Everyone will
just have to turn it off.  The printer daemon and the rcmds will have to
have ip addresses in the .rhosts, hosts.equiv, and hosts.lpd files.  
Actually, I think this will work without code changes.

> addresses to their customers and delegate the reverse tree to them.

More reliable than RIR? I haven't heard of RIR spoofing.  

But I think you are talking maintenance. Maintenance of reverse trees was
what got this going...  And maintenance is an operational issue that is
made easier or harder by standards.  Removing reliance on reverse lookups
might make it easier for ISPs to keep up better whois records, which are
made public or not made public depending on the ISP's policies.

Also, I'm not saying that reverse lookups haven't ever been useful. But
the utility is such that one cannot depend on it.

		--Dean

---

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

> 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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2002 07:53:30 -0400

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

>>>>> "David" == David Terrell <[email-masked]> writes:
    >> exactly this using plug-ins to bind9.

  Thank you for posting with the details.

    David> Keith wrote a draft that proposed several mechanisms and debated
    David> their reasonability.  I implemented one suggestion (not perfectly)
    David> for bind9's sdb mechanism, that creates pseudoauthority records for
    David> 2002:abcd:efgh:: that point to 2002:abcd:efgh:magic-suffii.  It is
    David> available here: http://meat.net/~dbt/code/rev6to4/

    David> The other method (infer authority records from closest authority
    David> records in IPv4 in-addr tree)  was implemented by Feico Dillema in
    David> his self-described DNSALG totd, available at
    David> http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html.

  I didn't realize that these were seperate suggestions - we do DNSALG, and
if we find nothing, we try the magic-suffii. Although now that I think about
it, the likelyhood of there being any NS records at the leaf of the IPv4 tree
is pretty much zero.

  Is there a plan to go forward with any of this?
  It simply seems like the right solution to me.

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 5 Jul 2002 17:54:37 +0200

> expect people to populate it fully.   Or if they like, not to
<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.

---

From: David Terrell <[email-masked]>
Date: Sun, 7 Jul 2002 03:48:07 -0700

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: "Toshi Yamasaki" <[email-masked]>
Date: Sun, 7 Jul 2002 19:10:44 +0900

As one of the commercial IPv4/IPv6 service operators, I have almost the same
issues as Huitema has, and am feeling that reverse lookup might NOT be
NECESSARY in both IPv4 and IPv6 enviroment.

1) Site (or ISP) admins may often want  to identify the source of traffic
per host. Reverse lookup is one of the good ways to do so, but there are
several other good ways and what method to use is none of 3rd party's
business.

3) Reverse lookup has been being used  by MTA and public FTP sites as a
simple authentication or a method, but it's not an enough method for
authentication.

4) If we assume (or hope) IPv6 be deployed to everyone including residential
users who doesn't care about technical issues, we shouldn't force end-users
about technical managements which is NOT NECESSARY.

So, I'd say that ISPs should delegate responsibility to manage the reverse
lookup zone, IF the CUSTOMERs REQUESTE, but shouldn't force them to be
delagated the zones and maintain them.

I know it's better that reverse lookups are maintained by all end-users
correctly, but tell me, somebody,  the reasons why it is NECESSARY.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 7 Jul 2002 12:00:48 -0500

> correctly, but tell me, somebody,  the reasons why it is NECESSARY.

I don't think anybody's asserting that it _is_ necessary.   The question is,
  how do you do it if you want to do it?

---

From: "Jason Coombs" <[email-masked]>
Date: Sun, 7 Jul 2002 13:13:40 -1000

Aloha,

> This is a key management problem of epic proportions.

Key management for DNSSEC is a problem of epic proportions without secure
DDNS, secure reverse lookup, and secure reverse DDNS lookup. I've been
following DNSSEC with interest but have contributed nothing to the process.
Not that nay-saying is much of a contribution, but why does DNSSEC have to
preserve the distributed management feature of DNS?

Centralized authoritative controls would make key management a viable
proposition. Even for DDNS and reverse lookups. Real-time feedback would
then be possible as well, to push information about alleged IP-to-name
mappings (plural) back to the secure DNS where security notices can be
dispatched securely to administrative and technical contacts who need to
know when somebody arbitrarily begins to purport that their node's FQDN puts
it inside their domain.

Forged FQDNs in spam relay and other types of FQDN misrepresentation could
then be flagged in secure DNS and further actions taken against those people
(and nodes) responsible. Authentic, comprehensive forward and reverse
mappings would then be possible, giving real-time meaning to negative
responses (FQDN does not exist) that aren't possible today with DNS.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ted Lemon
Sent: Wednesday, July 03, 2002 1:04 PM
To: Eric A. Hall
Cc: [email-masked]; [email-masked]; Christian
Huitema
Subject: Re: The reverse lookup issue

---

From: Doug Barton <[email-masked]>
Date: Sun, 7 Jul 2002 18:26:58 -0700 (PDT)

> check that the name provided by the caller is not entirely bogus.

FWIW, I agree with all three of these points. I manage forward and reverse
dns for our company, with over 15,000 internet-connected systems in both
public and private space. We make extensive use of reverse dns to aid in
debugging problems, both with our own systems and those of 3rd parties.

Doug

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Jul 2002 01:15:54 -0400 (EDT)

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

---

From: [email-masked]
Date: Mon, 8 Jul 2002 13:35:16 +0000 (UCT)

and the whois data get has only one instance and is always
	correct...  :)

	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.  

	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.

---

From: Mathias Koerber <[email-masked]>
Date: Mon, 08 Jul 2002 22:53:39 +0800

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:

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

-- 
Mathias Koerber
[email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 08 Jul 2002 08:10:05 -0700

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

---

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

> handed you some chunk of the address space that the RIR assigned to

	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: 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: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 10:33:21 -0700

On Mon, Jul 08, 2002 at 01:15:54AM -0400, Dean Anderson wrote:
> match, you have "identified someone responsible".

Given a reverse dns of foo-10-27-123-99.example.net and a forward that
matches, I can reasonably assume that I can email 
{root,postmaster,[email-masked] and probably reach someone who can
take care of a problem I am having with a machine; and I am more likely
to get a response from the tech contact under whois example.net than
I am from the contact in whois -a 10.27.123.99.

Whois data is far more frequently out of date; a single whois request
causes a much higher load on the whois server than a single reverse
DNS request; and most importantly there is no way for a clued person
to enforce that whois is somewhat correct when a connection is made.

> reverse DNS, you have nothing.  Even if the reverse matches the forward,

DHCP?  Are you assuming these are internal netblocks that I own?

> cosmetic benefits of having it, reverse DNS needs to be deprecated.

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.

-- 
David Terrell           | "Anyone want to start a fund for students
Nebcorp Prime Minister  | that vow not to work at MS?"
[email-masked]            |  - Libor Michalek
http://wwn.nebcorp.com/

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Jul 2002 13:15:51 -0500

on 7/8/2002 12:15 AM Dean Anderson wrote:
> done anything of the sort. Garbage in just matches garbage out.

The garbage is in two different zone partitions, each of which have to be
updated at the replication master by somebody with access rights (in the
common case). So even if the hostname labels are lies, the zones will
still be correct. EG, you can make your PTR foobar.IBM.COM but if the
IBM.COM doesn't have a forward match then I'm less inclined to believe it
is true, and without access to the IBM.COM zone you'll get caught sooner
or later since I can track you down through your IN-ADDR path.

There are a bunch of security holes that make this less than 100%
trustworthy but it is perfectly reasonable as a first-pass approximation.
For large organizations with multiple netblocks, a well-managed IN-ADDR
space with double-lookups is a requirement for basic first-pass access
restriction controls.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 08 Jul 2002 17:31:43 -0400

> especially when used with double lookups (check PTR and A both ways).

Like many other contributors to this thread, I happen to consider those
validation processes to be, for the most part, broken, and I'd rather hasten
their demise than hand them a crutch with which to hobble into the IPv6
world.

Yet, I recognize that reverse DNS has its uses, outside the realm of
authentication. At the very least, it makes "traceroute" output more
readable. Beyond that, I'd be a hypocrite to say that reverse DNS is
*useless*, since I actually use reverse DNS extensively in the homegrown
system we use here for maintaining our DNS.

I don't think anyone (?) in this discussion thinks that reverse DNS is
*useless*, i.e. devoid of any practical application. We're only debating the
*degree* to which it is useful (and, potentially, the degree to which it
might be harmful as well, e.g. fostering bad security practices and/or a
false sense of security).

But that's only looking at one side of the cost-benefit equation. The
benefit is small but non-negligible; what is the cost? I have to apologize
for not following the IPv6-related discussions as closely as perhaps I
should have. How painful is it to implement reverse DNS for IPv6 (assuming
that we resist the temptation to add extra bells and whistles and just stick
with a straight address-to-name mapping mechanism)? Maybe the benefit is
worth the cost, maybe it isn't. I certainly can't make up my mind on that
without knowing both sides of the equation...

- Kevin

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Jul 2002 17:03:57 -0400 (EDT)

> I am from the contact in whois -a 10.27.123.99.

You can _ASSUME_ anything. That doesn't make the assumption true.  I know
I have far better luck contacting whois contacts than I do domain
contacts, especially domains associated with some kind of abuse or
cracking.  A whois record usually represents a real business. Even when
the email address and phone number doesn't work, the business can still be
found. 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).

> DHCP?  Are you assuming these are internal netblocks that I own?

In IPv6, it is expected that there will be more DHCP use. Who owns the
address today will be different from who owns it in 2 weeks.  That
information (to whom it was assigned and when) will be logged in a DHCP
log.

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

Whois servers can be scaled up. And you can get local copies.  Most people
don't need to make these lookups frequently, so your assertion that whois
load will increase exponentially is false. And frankly, I think that whois
lookups should be far easier to process than DNS lookups, so even if it
did increase by a lot, it should be more than compensated by the reduced
reverse lookup load, and corresponding traffic.

		--Dean

---

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

---

From: David Conrad <[email-masked]>
Date: Mon, 08 Jul 2002 15:49:35 -0700

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.

Rgds,
-drc

---

From: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 16:06:09 -0700

> and is used] is a lot of trouble for securing something worth $10).

There is no information on the internet guaranteed to be true, and that
is correct regardless of encryption, information source, or anything else.

However, reverse DNS is a lightweight method to identify a name for a 
host that cannot be easily replicated using another method.  If a 
central TCP server identifying addresses would have scaled, DNS would
never have been created.  Reverse DNS has value.  Your statement that you
do not find it to be valuable are interesting, but not sufficient to 
convince me that the value I have derived from said service where 
chimerical.

> information (to whom it was assigned and when) will be logged in a DHCP

Much work has gone into making DHCP completely unnecessary for IPv6
deployment, though of course DHCPv6 does exist.

Regardless, you only buttress my position.  Reverse DNS today, when you
connect to my machine, is far more likely to have useful information that
may point me to you than whois will in a month when that netblock has 
been reassigned by your upstream.  whois is not loggable in-band.  DNS
is.

> authentication.  So, "yes".

r* should die; agreed.  So what?  SSH's RSARhosts authentication
method uses reverse DNS securely.

You assume that authentication is the only purpose of this data.
You're wrong.  It has informational value to me, there are ways 
in which reverse DNS records can be cryptographically verified 
using another service that is secure.

> reverse lookup load, and corresponding traffic.

A scalable protocol for a global name and address resolution already
exists, why are you trying to duplicate it, badly, with a TCP
service?

---

From: Derek Atkins <[email-masked]>
Date: 08 Jul 2002 19:32:18 -0400

> untrustworthy administrative domain to be matching garbage.

Not with DNSSec.

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

---

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

> 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: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Jul 2002 22:55:21 -0500

> Whois is much more trustworthy, since the administrative domain is

The A RR for whois.internic.net is immune to spoofing?

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Jul 2002 23:09:38 -0500

> validation processes to be, for the most part, broken, and I'd rather
> hasten their demise than hand them a crutch with which to hobble into
> the IPv6 world.

Just a clarification that I specifically used "validation" and not
authentication, nor even authorization.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 09 Jul 2002 10:27:51 +0200

No. Restrictions on whois is not only related to abusive use.
Privacy regulations in various jurisdictions also put heavy
restrictions on whois use. The same is true for storing and using
local copies.

	jaap

---

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

---

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

---

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: Danny Mayer <[email-masked]>
Date: Tue, 09 Jul 2002 20:14:29 -0400

At 05:03 PM 7/8/02, Dean Anderson wrote:
>  A domain name registration record represents $10. Sometimes less.

You are not really securing the domain as much as you are making the
user secure in that he has received a valid answer to a lookup for that
domain. The difference may seem subtle, but the domain does nothing
with the data, it's the client that uses it.

Danny

---

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: 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: "Eric A. Hall" <[email-masked]>
Date: Wed, 10 Jul 2002 13:38:04 -0500

> I don't know of _anybody_ who still uses the reverse map to do

Nor should they. In point of fact, the only security service that reverse
PTRs are useful for is proving that something *IS NOT* something, simply
because they did not claim to be. At that point, the only real threat to
IN-ADDR spoofing is a DoS attack, keeping otherwise legitimate hosts from
connecting to a service.

---

From: Robert Elz <[email-masked]>
Date: Thu, 11 Jul 2002 16:03:31 +0700

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

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

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
delegations to go away, so no-one can set up a reverse domain, even if
they want to.   That doesn't sound anything like agreement to recommend
that it be done...

I wouldn't go that far, but nor would I recommend that people set up
reverse delegations.

What I would agree with is explaining to people what they're good for,
and why they might want to do it, but stopping short of actually
recommending that it be done.   I'd also want some strong words in there
though about how the data should not be used (which would not of course
prevent anyone who felt strongly enough from going ahead ad doing it anyway).

kre

---

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: "Andy W. Barclay" <[email-masked]>
Date: Thu, 11 Jul 2002 07:55:12 -0700

> prevent anyone who felt strongly enough from going ahead ad doing it anyway).

I'm assuming that your last sentence was incomplete here.
You really meant ot say that "the data should not be used for 
authentication" right?

"should not be used" is silly.

FWIW, I use the information in reverse DNS all the time. I don't 
authenticate with it, but I still find it usefull for information
purposes.

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

Tell a man that there are 300 billion stars in the
universe, and he'll believe you.... Tell him that a
bench has wet paint upon it and he'll have to touch it
to be sure.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2002 10:05:00 -0500

> 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: Ted Lemon <[email-masked]>
Date: Thu, 11 Jul 2002 10:31:46 -0500

> prevent anyone who felt strongly enough from going ahead ad doing it 

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.

They are wrong to *expect* it to work - it's an incredible hassle for me 
when I'm doing testing on a network and name service isn't working that I 
have to wait a minute for the lookup to timeout before I can log into 
another machine, and I'd bloody well like it if people wouldn't code their 
clients and servers to insist on doing the lookup without being configured 
that way.

I'd also really like it if, e.g., openssh wouldn't spew out a panicky 
message about a man-in-the-middle every time I use it to ssh into a machine 
that *has* a valid DNS setup, but that gets its IP address from DHCP and 
therefore doesn't have a consistent IP address.

So we do agree that people are abusing the DNS in ways that don't make 
sense.   A machine's IP address is not its identity, and the information 
about the machine in the DNS isn't its identity either.   What we don't 
agree on is that this means we shouldn't recommend that people set up 
reverse zones.

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?

---

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

---

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

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

> 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: Dean Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 01:02:51 -0400 (EDT)

> someone asks you to justify them, you do not do so.

Well, I think I did state a valid objection. I apologize if I wasn't
clear. I'll try to summarize the issues.  kre and I (at least) are in
agreement.  

I think your use ("handy for logging and validation") ought to be
classfied to be misuse, and therefore there is widespread misuse of
Reverse DNS for just those purposes.

Your disagreement is that your use isn't actually misuse, and that it
should be OK to use Reverse DNS for authentication or "validation", and
logging.  You have argued that when reverse and forward maps match, that
there is some kind of useful meaning to be implied from this.  I think I
have shown through several examples that, in fact, there is no meaning
that can be attached should it happen that forward and reverse match, and
therefore validation is also a misuse of Reverse DNS.  This is the crux of
the disagreement, I think.

It is a frequent misconception that reverse DNS can be used for logging,
and authentication or validation, and therefore a "widespread misuse of
Reverse DNS."

My objection then is that reverse DNS is often misused. When used
properly, reverse DNS has only cosmetic use, and thus only a minor
benefit. The misuse can result in a number of bad things happening, from
improper authentication to useless logging.  Because of the misuse, in
comparison with the minor cosmetic benefit, I think Reverse DNS should be
deprecated.

Our disagreement revolves around what is proper use and what is misuse of
reverse DNS, and maybe more specifically whether there is any significance
for the state when Reverse DNS and Forward DNS match.  If such a state is
meaningless (since as I argue, it can't be meaningful), then there is much
misuse of reverse DNS by the people who assume it has meaning when it has
no meaning.

I think there are specific harms to each of the misuses:

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.

Authentication allows persons to gain access inappropriately.  
Authentication and Validation are almost the same. Authentication seems to
mean shell access is given.

"Validation" creates a false impression of confirmed identity, and a false
feeling of comfort that might lead one into granting priveleges without
further checks.

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 don't think you dispute the harms so much as you simply dismiss them as
unimportant. This attitude towards them, I think, is probably also a harm,
since 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.

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.

		--Dean

---

From: Greg Hudson <[email-masked]>
Date: 12 Jul 2002 10:17:16 -0400

> the disagreement, I think.

Of course there is meaning.  It means "this domain is listed in the DNS
as the name for this address, and it is not a complete forgery (although
it might be meaningless)."  A fine thing to log.  Log the IP address
too, since as you pointed out, the name might go away.

I wouldn't call this logging a purely aesthetic benefit.  You can use
that information to collect statistical data ("look, 30% of our
connections are from IBM") as long as you're willing to accept that
organizations can hide themselves from that collection (don't expect to
find out that another 30% of your connections are coming from the NSA).

> and authentication or validation, and therefore a "widespread misuse of

There are historical examples of use for authentication (I'm still
unsure what you mean by "validation"), but I'm not aware of any recent
examples.  I think your "widespread misuse" is pretty much limited to
the occasional logging of domain names without also logging IP
addresses.

With forward DNSSEC, of course, it's fine to use reverse DNS for
authentication, as long as you don't want to give anyone negative access
rights (and aren't worried about IP spoofing, for whatever reason).  If
I want to say "only these hosts can log in here," reverse DNS works as a
hint.  An inline statement in the protocol would work just as well, if
the protocol allows for that; I'm not saying that this is a great idea,
just that it works.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2002 10:14:08 -0500

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2002 14:58:51 -0500

> the same assumption isn't proof the assumption is true.

I personally use, and get value out of, ptr records in the in-addr.arpa 
domain.   This is my own personal experience.   You can't contradict this 
- I have observed it directly.   Maybe it doesn't match your experience, 
but it doesn't have to, because the argument you've made here attempts to 
disprove the premise that the system is useful.   The fact that quite a few 
people have stepped forward and said "I personally get real, meaningful 
benefit out of the system as it is" is sufficient to invalidate any 
argument that you make to the effect that "the system is not useful."

You make a second argument, where you attempt to prove that the system is 
incorrectly used as an authentication mechanism, and therefore should be 
eliminated so as to discourage this use.   Here, your statement is a 
positive one - you are trying to prove that something is true.   So your 
reason has to support your argument.   That is, you have to give evidence.
    Several people, including me, have asked you to say just who it is that 
is using the system as an authentication mechanism, and how prevalent this 
use is.   You have not done so.

Several of us have stipulated that if, for example, use of r-commands were 
still common, that would be a bad thing, and we'd want to discourage that,
  but none of us have seen any evidence that this is in fact so.   Indeed, I 
made a pretty basic statistical case for the idea that it actually *can't*
  be true - an argument against which you have presented no counterargument.
    So again, your argument fails to convince, in this case because you have 
not brought forth any evidence to support it, and you have not even 
attempted to invalidate any of the counterarguments that have been 
presented.

If you are just trying to convince yourself, that's fine, but you already 
know you are right, so you needn't argue about it in public.   If you are 
trying to convince *us*, you have to use arguments that actually have that 
effect.   And if you are just trying to vote, well, I know what your vote 
is now, and, barring some successful argument you or kre may make, you know 
mine also.

---

From: Doug Barton <[email-masked]>
Date: Fri, 12 Jul 2002 14:48:52 -0700 (PDT)

> there is meaning to the state when reverse and forward match.

Several of us have stated that FOR US, there is meaning. Some of us are
even smart enough to know that the meaning is limited to certain scopes.
You obviously believe that there is no meaning whatsoever to reverse
records. I'm happy to acknowledge that for you that might be true, but I
think that enough people have disagreed with you at this point to show
that your point of view is far from universal.

> the same assumption isn't proof the assumption is true.

I alluded to some specific cases in my brief post, but I don't see any
point in providing further details because you've obviously made up your
mind.

Doug

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Jul 2002 16:58:53 -0400 (EDT)

> too, since as you pointed out, the name might go away.

It could be a complete forgery. As a complete forgery, it might not be
actually listed in DNS. So your statement is false. If you log it, you've
just logged a false statement.  I assert that is a harm.

> find out that another 30% of your connections are coming from the NSA).

This has the implied assumption that most or all of your traffic is
"honest", by which I mean that the connections aren't spoofed, and there
isn't anyone trying to skew your logs.  You would be much better off by
analyzing the IP addresses into route netblocks, AS numbers or using Whosi
information directly to find out where most of your traffic is comming
from.  'Log skewing' has happened, and isn't a purely theoretical
possibility.

> the occasional logging of domain names without also logging IP

Actually, I think validation was Ted's term. By it, I think he meant the
same thing you said in your first paragraph: [It means "this domain is
listed in the DNS as the name for this address, and it is not a complete
forgery (although it might be meaningless)."]

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
obtained when reverse and forward match.

As Ted mentioned that authentication would be possible with DNSsec, let me
take a minute to put down some thoughts about that.

If I recall the dates properly, BSD4.3 was released in 1986, and DNS was
invented that same year, or slightly earlier. It seems to me it is likely
the rcmds were developed with a hosts file, and then a resolver with
reverse DNS introduced later. So perhaps the rcmds weren't developed with
a "false" sense of security--the hosts file could be trusted.  It was the
seemingly innocuous change to use the resolver with reverse DNS that
introduced the exploitable security flaw.

What I'm getting to, is that one might develop applications that depend on
DNSsec with trustable reverse DNS, and then make a similar seemingly
innocuous change to not using DNSsec, and in doing so introduce a similar
exploitable security flaw.  This is a risk of having Reverse DNS.

> the protocol allows for that; I'm not saying that this is a great idea,

Agreed, subject to the limitation that the "trusted" domains _must_ use
DNSsec, and that DNSsec must be proven to be unspoofable. I'm not sure if
one can claim DNSsec can't be spoofed just yet. <This doesn't mean I
personally know the answer, but rather I think the answer is still an
unknown>. Should DNSsec turn out to be spoofable, then this becomes false.
This could be an example of that "seemingly innocuous change", I was
talking about above.

		--Dean

---

From: David Terrell <[email-masked]>
Date: Fri, 12 Jul 2002 15:41:34 -0700

> This could be an example of that "seemingly innocuous change", I was

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

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.

---

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

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

> but it's not a trivially removable component of the architecture

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?

> 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: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Fri, 12 Jul 2002 11:46:03 -0400

>Reverse DNS for just those purposes.

This discussion has no relevance to the DNS protocol, this is a
philosophy discussion.
Please DO NOT post any more messages to namedroppers on this subject.

         Olafur DNSEXT co-chair.

---

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

---

From: Robert Elz <[email-masked]>
Date: Mon, 15 Jul 2002 12:50:31 +0900

Date:        Thu, 11 Jul 2002 07:55:12 -0700
    From:        "Andy W. Barclay" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm assuming that your last sentence was incomplete here.
  | You really meant ot say that "the data should not be used for 
  | authentication" right?
  | 
  | "should not be used" is silly.

Yes - but what it said was "about how the data should not be used."
That is, I wasn't actually saying what it should say, just that
it should say some things about inappropriate uses.

If we ever got to agree on at least this much, then we could
start the debate about what uses are inappropriate and should be
warned against.

  | FWIW, I use the information in reverse DNS all the time. I don't 
  | authenticate with it, but I still find it usefull for information
  | purposes.

Yes, so do I, though I find I use the -n options to ping/traceroute
much more often than I omit them.   But the fact that I (or you) like
to make use of other people's work doesn't mean they should forced,
requested or even just encouraged, to provide it.

kre

---

From: Derek Atkins <[email-masked]>
Date: 15 Jul 2002 00:23:50 -0400

> requested or even just encouraged, to provide it.

I find that I use the -n options when I want to rule out a DNS
problem.  Once I'm sure that the network is up via -n, I kill
ping/traceroute/mtr and re-run without -n to see where it's actually
going.

My take on where we are now is that there is enough use to NOT
depricate reverse-resolution, but perhaps add some language in
the Security Considerations that say something to affect of:

"Using DNS Reverse Resolution for Authentication is dangerous."

-derek

---

From: Robert Elz <[email-masked]>
Date: Mon, 15 Jul 2002 16:39:26 +0900

Date:        15 Jul 2002 00:23:50 -0400
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

We have already been asked to stop this on namedroppers, it probably
really belongs on dnsop, the last message I posted before I saw that
request, but since this is still here, just one last message from me.

  | My take on where we are now is that there is enough use to NOT
  | depricate reverse-resolution,

Personally, I never wanted to actually deprecate it.   What I want to
do is get rid of the expectation that it is supposed to be done.
That is, that networks that don't bother to set up reverse delegation
stop being treated as a lower form of life which should be denied all
kinds of service.

So...

  | but perhaps add some language in
  | the Security Considerations that say something to affect of:
  | 
  | "Using DNS Reverse Resolution for Authentication is dangerous."

Of course, no-one would object to that.  But that's not enough.
Something more to the effect of

	There is no requirement to configure reverse delegations
	for assigned network numbers.   Applications should not
	refuse service to an incoming connection merely because no
	reverse delegation for the source network address exists.

is what is required.   The first sentence merely states the status
quo anyway - no-one is being forced to make a reverse delegation.
The second is really a logical consequence of deciding that the
first is OK.

kre