Subject: RE: (ngtrans) The reverse lookup issue

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 14 Jul 2002 15:03:10 +0200

To fire up this flamable debate again... so first lets sum the lot up:
(ref: ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/current ;)

Pro's for reverse:
- 'easy' lookup of an IP to a hostname and domain.tld.
- In enterprise networks, reverse lookups provide a way to identify the
source of the traffic.
- 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.
- Some applications (e.g. SMTP servers) actually use reverse lookup to
  check that the name provided by the caller is not entirely bogus.
- "I am profoundly unhappy with the notion that these networks are in
anyway different.
  Citizens need control over their reverse maps. Period." *)
- One can deduce a bit where an address is delegated to.
- Whois is "stale" (?)
- whois is not loggable in-band.  DNS is.

Con's against reverse:
- Whois should contain all the contact info for an IP block.
- Not everbody (non-techy people ;) knows how to configure it so why
  burden them with it.
- Unmanaged/autoconfigged networks probably won't have any reverses.
- ISP "example.net" mapping "64.5.6.7" to "ip4-64-5-6-7.example.net"
-
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
- draft-itojun-ipv6-nodeinfo-revlookup-00.txt (ICMPv6 node query)
- "if you give the user the ability to define their own name,
  they will attempt to declare themselves to be 'all.high.and.mighty'."
- Advertisements in the reverse.
- Reverse don't always match forwards, so applications using it must
  check both otherwise "firewall.fbi.gov" pops up everywhere.
- Reverse dns is an assumption, it doesn't have to be true.
- "idiotic refusals to allow incoming connections (FTP, SMTP, ..)
  where the IP6.ARPA info isn't available)"

Other/more documented Pro/Con's:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-inaddr-required-03.
txt
http://www.ietf.org/internet-drafts/draft-durand-ngtrans-dns-issues-00.t
xt

Problem with:
 - 6to4/ISATAP/Teredo, who/what sets up an NS to which server(s).

As you see in the above list some arguments are that sometimes
reverse is more up-to-date/accurate than the reverse or vice versa.
What about if we simply use TXT records in the reverse zones.
We could then, at least for IPv6 zones, require that reverse zones
contain an TXT "RP: [email-masked]" for each NS entry.
This would at least allow people to lookup to which ISP/Company/person
this block of addresses belong. But the big but, this information should
have been already recorded in the whois database.
So either we drop whois for reverse -> not done.
Or we keep these informations synced one way or the other.
"RP"/Responsible Person can ofcourse be extended with "tech-c",
"admin-c", "AS", "company" and some other to be determined tags.

But then again, maybe this comes down to something very different:
Scalable/Distributed whois.

Greets,
 Jeroen

*) Though, why should they if they don't even know how to configure it?
PS: anybody come around finding
"we.hire.administrators.for.big.money.at.company.de" in your logs ? :)

---

From: Alain Durand <[email-masked]>
Date: Sun, 14 Jul 2002 07:05:33 -0700

> (ref: ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/current ;)

There is going to be a discussion about this issue in dnsop
on Tuesday afternoon. I will present issues from
draft-durand-ngtrans-dns-issues-00.

	- Alain.

---

From: [email-masked]
Date: Sun, 14 Jul 2002 23:34:03 +0900

>draft-durand-ngtrans-dns-issues-00.

	if possible could you summarize whatever discussed on the mailing list
	as part of your slot?

itojun

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Jul 2002 07:34:33 +0900

<AD hat on>

> To fire up this flamable debate again.

this is a dns operations issue, not a v6 tansition issue.  these
things are handled in dnsop.  there is a relevant dnsop draft,
draft-ietf-dnsop-inaddr-required-03.txt.  this discussion belongs
there.  the ngtans wg is far from sufficiently successful in its
actual work that it should be looking at doing the work of other
wgs.

randy