Re: What problem were we trying to solve again? (was Re: RadicalSurgery proposal: stop doing reverse for IPv6.)

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On Wed, 26 Mar 2003 13:08:32 -0500, 
>>>>> Rob Austein <sra+dnsop@hactrn.net> said:

> George's original problem, paraphrased, was "the RIRs are putting some
> work into maintaining reverse trees, and would like to know whether
> anybody thinks this is useful."  The answer boiled down to "yes, some
> people think that this is useful."

I think this is oversimplification, for example, according to the
latest message from George (attached).  But, anyway,

> Jimmei appears to be asking a different question, but I haven't yet
> figured out quite what it is.  Jinmei?

I was probably unclear, and perhaps made a logical leap.

I wanted to see a consensus (if we can reach it) on how much we should
(continue to) rely on reverse mapping.  In particular, I'd like to
know cases where reverse mapping must be provided and other approaches
cannot apply.

For example, the address to name mapping for traceroute can be
provided by ICMP node information messages (of course, it depends on
whether intermediate routers support and allow the ICMP, and reply a
useful node name.  But similar arguments apply to DNS reverse mapping
as well.)

Some servers reject connections if the remote address does not have a
DNS PTR (i.e. reverse) record or the "gethostbyname(gethostbyaddr())"
check fails.  However, I don't understand if such a policy provides a
benefit that can outweigh disadvantages like denial of "non-bad" users
or connection setup delay.

Some spam filters regard an e-mail message as a spam if the sender
address does not have a DNS PTR record.  This may be a good first
filter, but may also have a disadvantage to reject a valid message
(which happens to be sent from an address that does not have a PTR).
Also, many other spams are also sent from a "valid" address in terms
of the DNS reverse mapping.  If we really want to start rejecting
spams, we'll need a more intelligent filter after all (this is at
least the case for me).  So, again, I don't understand if this
filtering really provides a benefit that can outweigh the
disadvantage.

Of course, this kind of issues are relatively matter-of-taste ones,
and it will be very difficult, or at least ineffective, to make
administrators to change these policies.  However, if we can agree on
some "moderate" usage of reverse mapping that provides a good tradeoff
between benefits and disadvantages, we can perhaps move to the ideal
operation gradually.  At least I don't think the current practice
provides a good tradeoff.

Regarding messages from George, if we can move to a slightly different
operation which is less dependent on reverse mapping, some of his
frustration (e.g., load of top level servers) might be mitigated.  On
that point I think my points is related to his message.

>> > Security usage of reverse is so absurd (given that DNNSEC will not help if
>> > someone tries to put another domain as RDATA in PTR records) that it is
>> > irrelevant. 
>> 
>> Can we all really agree on this point?  I know many people in this
>> thread (regardless of their position about reverse mapping) said a
>> similar point, but I still see those who believe in the "security
>> benefit" of reverse mapping.

> It's more complicated than that.
(snip)

I admit the word "security" was too broad, as others also pointed
out.  I tried to be more concrete above, so I won't respond to this
part.

I hope I'm clear this time, even though others may still disagree with
me.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

---

To: Edward Lewis <edlewis@arin.net>
Cc: dnsop@cafax.se
From: George Michaelson <ggm@apnic.net>
Date: Thu, 20 Mar 2003 05:08:25 +1000
Delivered-To: jinmei@shuttle.wide.toshiba.co.jp
In-Reply-To: <a05111b1dba9e69938578@[130.129.133.242]>
Sender: owner-dnsop@cafax.se
Subject: Re: Radical Surgery proposal: stop doing reverse for IPv6.

ok. in that spirit:

	top down delegation in reverse IPv6 works well to the ISP level. 
	ie, where delegation of responsibility over address resource follows
	BCP, then the mechanism to perform DNS reverse management follows in
	a natural manner. We do this. It works.

	it doesn't look to scale well for dynamic edge-host registration
	without confronting some inherently non-scaleable problems: /64
	(and /32 Ipv4 holders) don't have a sane way to promote themselves 
	into the process if more than one intermediate layer of address
	resource holder doesn't want to participate. There are very real
	issues with the probity of taking an edge resource claim, and
	lodging DNS reverse over the head of an intermediate resource
	manager.

	synthesized DNS looks to maybe offer ways out of this, the fusion
	of the ideas would suggest that down to the level of some address
	resource holder, a mechanism for dynamic synthesis on-the-fly would
	be interesting. Its not clear how DNSSEC would work over this.

	6to4 will scale well for large, centrally managed stable-IPv4 located
	gateways. dyanmic (short lifetime) services fall into one of the
	problems noted above.

	some people clearly want reverse. Few people who are providing
	registration services, or writing applications, place much value in
	it, but thats subjective. as long as its wanted, and community 
	supports the overheads, there is no reason to stop. but we do need
	to be clear where the limits lie on what its offering.

	I'll keep my subjective personal view that we should stop. Nothing
	you said Ed, appears to contradict the reasons why I think that.

cheers
	-George
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

---