Subject: (ngtrans) 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

---

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: 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: 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: "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: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2002 21:53:47 -0400

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

>>>>> "Christian" == Christian Huitema <[email-masked]> writes:
    Christian> 1) In enterprise networks, it is possible to use dynamic DNS updates,
    Christian> thus meeting requirement #1. (Using the same procedure in consumer
    Christian> networks, or across domain boundaries, is much less likely.)

    Christian> 2) In consumer networks, the ISP will typically delegate a /48 or

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

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

  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.

]       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 00:17:38 -0700

> 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: "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;

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

On Thu, Jul 04, 2002 at 06:51:58AM -0700, Jim Reid wrote:
> >>>>> "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?

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: 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: 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.
  DNSSEC signed reverses are extremely useful.

  Please see draft-richardson-ipsec-opportunistic-09.txt.

    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?

---

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

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

On Wed, Jul 03, 2002 at 06:43:04PM -0400, Dean Anderson wrote:
> 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.

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

On Wed, Jul 03, 2002 at 09:58:58PM -0400, Dean Anderson wrote:
> On Wed, 3 Jul 2002, Christian Huitema wrote:
> 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.

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.

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

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

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

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.

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

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

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.

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

> 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: Randy Bush <[email-masked]>
Date: Sun, 07 Jul 2002 10:43:58 -0700

[ namedroppers removed from cc:s as this is not a dns protocol issue ]

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

i find the term 'necessary' thought provoking.  as an operator and
user,

  o if you propose to remove an existing function/feature, i think
    you need to show why it is needed or enhancing (of the utility
    i get) to do so.

  o if you propose to add a new feature/function, i think you need
    to show why it is is needed or enhancing (of the utility i get)
    to do so.

randy

---

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:
> But the problem is your [wrong] _assumption_ that when forward and reverse
> 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.

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

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

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

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: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 16:06:09 -0700

On Mon, Jul 08, 2002 at 05:03:57PM -0400, Dean Anderson wrote:
> 
> 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).

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.

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

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.

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

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.

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

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