Subject: RE: (ngtrans) The reverse lookup issue

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

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

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

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

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

Bingo -- the forward and reverse address do match!

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

-- Christian Huitema

--
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: Mon, 8 Jul 2002 10:53:04 -0700

> Bingo -- the forward and reverse address do match!

Yes, but in the DNS world that means that someone has delegated
7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa to the same group to whom .com
zone operator has delegated example.com.  How about that.  Two
distinct administrative regimes.  And I can generally map example.com
more accurately than I can map 2001:0123:4567::, because the DNS
contact database generally has the same information used for DNS
billing; whois does not.  I also can't send email to 
abuse@2001:0123:4567::, I can send email to [email-masked].

> spaces. It does not however solve the issue with 6to4.

Nope, draft-ietf-ngtrans-6to4-dns-00.txt[*] really needs some working
group attention, and I think it needs the opinion of the DNS folks;
ngtrans doesn't necessarily know the right way to do automatic
delegations.

* - mirrored here, the draft has expired....
    http://meat.net/~dbt/code/rev6to4/draft-ietf-ngtrans-6to4-dns-00.txt

-- 
David Terrell             | "Any sufficiently advanced technology 
Prime Minister, Nebcorp   | is indistinguishable from a rigged demo."
[email-masked]              |  - Brian Swetland
http://wwn.nebcorp.com/

---

From: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 11:00:48 -0700

On Mon, Jul 08, 2002 at 10:53:04AM -0700, David Terrell wrote:
>                                   And I can generally map example.com
> billing; whois does not.

This sentence doesn't make any sense, sorry :).  ARIN/APNIC/RIPE 
whois has virtually zero need to match reality, because billing is
not done through it; forward DNS whois does (in most cases).

Mapping an address to a name is useful, even if the most specific
namepart is not.  Even if you don't think everybody should use it
all the time, that's not a good enough reason to get rid of it.

Dave, who plans on putting a * IN PTR notused.meat.net. in his 
ipv6 reverse DNS zone somewhere....

-- 
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: Rob Austein <[email-masked]>
Date: Mon, 08 Jul 2002 17:19:30 -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! ]

> ngtrans doesn't necessarily know the right way to do automatic

To be fair: Keith has been trying to get me to work with him on that
draft for over a year now, but I keep forgetting about it and he's too
polite to remind me.

I agree that it needs more attention.

---

From: Robert Elz <[email-masked]>
Date: Tue, 09 Jul 2002 10:27:03 +0700

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

  | 1) any request to find a PTR record for
  | "0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arp
  | a" 
  | is served by providng an automatic response: 
  | "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com"

Christian, right idea, but poor implementation.   That one allows
people to conclude that there is an "example.com" in there which
is some kind of useful information (it isn't, but people believe it).

The automatic response is much more likely to be
2001-1234-4567-0001-FEDC-BA98-7645-3210.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa

And then this becomes ...

  | 2) any request to find an AAAA record for 
  | "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com"

Any attempt to find the AAAA (A6...) record for
2001-1234-4567-0001-FEDC-BA98-7645-3210.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa

  | Is served by providing the automatic response:
  | 2001:1234:4567:0001:FEDC:BA98:7645:3210
  | In which the address is simply a parsing of the last name part.

And of course, all of this is server out of the same pseudo-zone.
Pseudo in that all of the data in the zone, (perhaps excluding SOA and
NS records, if they exist at all) is created on the fly based upon
queries received (and most likely given a TTL of the order of years,
so the server minimises the number of queries it gets - caches will
tend to put an upper bound on that, so "years" wouldn't actually work,
but still the max possible TTL for each cache is achieved).

And then..

  | Bingo -- the forward and reverse address do match!

Exactly - and the node that asked the query has precisely no information
it didn't have before it started.

  | In fact, I would expect many organizations to do just that,

Yes.   More than that, I'd expect that sites will offer servers to
do exactly that for free (just as you can get forward DNS servers now
for "free" - which means that you have to suffer looking at their web
advertising every time you do something...)

With such a site, all that's needed is that when you're delegated an
address block, you list the magic site's DNS servers as being responsible
for the IP6.ARPA domain.   Most likely you would have had to set the
server up first (or they wouldn't be able to get you to their site, and
hence to view their advertising...) and perhaps they would allow you to
enter some specific data in case you do want to have some particular
addresses mapped to names.

With all this of course, there is precisely no information available in
the DNS which in any way relates the address to any useful contact information
for the user of the address.   Yet it satisfies the letter (and the
practical requirements) of the "rule" that some would like to see imposed.

All that is needed for us to reach this state, is to keep telling people that
they're *required* to implement IP6.ARPA domains for their address blocks.
If they're not required, or expected, to (and people stop attempting to force
them by idiotic, then no-one will bother with this nonsense,
they just won't bother having an IP6.ARPA zone at all, or if they have one,
it will have in it only the PTR records that the net admin wants to make
public.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 09 Jul 2002 12:01:27 +0700

Date:        Tue, 09 Jul 2002 10:27:03 +0700
    From:        Robert Elz <[email-masked]>
    Message-ID:  <[email-masked]>

Oops, I sent the message half way through a thought, after being distracted
by non-electronic communications...

  | All that is needed for us to reach this state, is to keep telling people
  | that they're *required* to implement IP6.ARPA domains for their address
  | blocks.

  | If they're not required, or expected, to (and people stop attempting to
  | force them by idiotic

This was supposed to go on to say "idiotic refusals to allow incoming
connections (FTP, SMTP, ..) where the IP6.ARPA info isn't available)"

  | , then no-one will bother with this nonsense,
  | they just won't bother having an IP6.ARPA zone at all, or if they have one,
  | it will have in it only the PTR records that the net admin wants to make
  | public.

kre

---

From: David Terrell <[email-masked]>
Date: Tue, 9 Jul 2002 12:04:18 -0700

> it will have in it only the PTR records that the net admin wants to make

Even if I don't _require_ reverse DNS, I'd be happy to block such 
addresses just as a FU to those who do it.

Very few people are insisting that we write "ip6.arpa records must
be filled out for every address"; but I resist the claim that
{ip6,in-addr}.arpa is useless on the face of it.  Opt-in, sure, but
useful nonetheless.

-- 
David Terrell          | "Let it be known that i think of Ashcroft as a 
[email-masked]           | power-hungry Conserv-a-monkey who wouldn't know the 
Nebcorp Prime Minister | Constitution if he tore it up and used it for 
http://wwn.nebcorp.com | toilet paper."  - Sean Willis