Re: What problem were we trying to solve again? (was Re: Radical

[Dean Anderson <dean@av8.com>]

The very thing we have demonstrated is that reverse provides no indication
of the strength of the relationship between the operator of a network and
the operator of a host.  None whatsoever.  People using reverse as a
strength indication are assuming the DNS data in reverse is authentic, and
that more than one entity is controlling the forward and reverse zones.
Such an assumption is invalid.  As has been shown, this is a harmful use
of reverse.  The addition of the word "unauthenticated" to your
description does not remove the false assumption made and the harms of
that false assumption.

One of the things Jinmei is saying is that there are alternatives for the
convenience functions, such as traceroute's use of reverse.  ICMP does
fullfill this useful function for IPV6.  This is a step forward. It also
shows that reverse is unnecessary in IPV6.

A so-called "reverse mapping failure" may be "indicated" when the provider
has multihomed hosts, so that forward doesn't match reverse. Or simply
isn't doing reverse (as they may optionally decide not to do).  This isn't
a "failure", and doesn't indicate anything is wrong.

Given the harms of reverse,
Given the complications of doing reverse in IPV6,
Given the alternatives for its useful convenience functions in IPV6,

There is no need to have Reverse in IPV6.


On 27 Mar 2003, Paul Vixie wrote:

> jinmei@isl.rdc.toshiba.co.jp (JINMEI Tatuya / ¿ÀÌÀãºÈ) writes:
>
> > 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.
>
> the reverse mapping function provided by PTR RR's in both ipv4 and ipv6
> provides an unauthenticated but still useful indication of the strength of
> the relationship between the operator of a network and the operator of a
> host on that network.  icmp, for example, wouldn't do this.
>
> very few host//network configuration errors shown by a failure in reverse
> mapping are limited to just reverse mapping failures -- there's almost
> always something else wrong, of which a reverse mapping failure is the
> mere "tip of the iceberg."
>
> problems related to maintaining the reverse mapping, either via synthesis
> or dynamic update or preallocation or whatever, are really just problems
> in trying to support a strong enough relationship between the operator of
> a network and the operators of hosts on that network, if the number of
> hosts grows the way we expect it to.  that's a technical problem, let's
> solve it, rather than declaring a priori that the gain isn't worth the pain.
> --
> Paul Vixie
>
> #----------------------------------------------------------------------
> # To unsubscribe, send a message to <dnsop-request@cafax.se>.
>


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