Subject: Re: (ngtrans) The reverse lookup issue

From: Masataka Ohta <[email-masked]>
Date: Thu, 4 Jul 2002 10:16:25 +0859 ()

Christian;

> My issues are mostly related to several IPv6 procedures that let the
> 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

--
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: 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 21:58:58 -0400 (EDT)

On Wed, 3 Jul 2002, Christian Huitema wrote:

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

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.

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

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.

> 3) Some applications (e.g. SMTP servers) actually use reverse lookup to
> 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: 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

On Wed, 3 Jul 2002, Paul Vixie wrote:

> > 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?
> 
> 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: 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: "Jeroen Massar" <[email-masked]>
Date: Thu, 4 Jul 2002 11:23:21 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

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

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

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

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

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

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.

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