Re: IPv6 and Dynamic DNS

[Terry Lambert <terry@whistle.com>]

Cutler, James R wrote:
> 
> Can we backstep a bit and better define the business and
> technical need for updating DNS reverse entries?  It seems
> clear that most usage is either:  1. for the convenience
> of the service provider, or 2. for "poor man's security".
> Is there another.

I think it's mostly "poor man's security", so things like
"sendmail" won't balk at talking to you.

I believe the theory is that you can trust forward mappings,
because of who owns the delegation, but you can't trust
reverse mappings, mostly for the same reasons.

To establish a trusted peer identity, a "getpeername()" is
issued.  We know that they aren't lying about their IP
address becuse everyone disables source routing, and
because they want packets back from us.

We then do a "gethostbyaddr()" to get the canonical name,
and then we look it up to see if it had the same IP address,
because we trust the domain to serve us the IP address we
are expecting.  If we don't get this, then someone who
owns the IP address, but not the domain, is spoofing us
with an invalid name in their reverse map.


I don't know how "poor" this really is; we are only
interested in establishing that the forward and reverse
mappings are transitive, so we know that whoever has
the legally delegated ownership of the domain is who we
are talking to, so that we can hold the domain owner
accountable for the actions of an IP address.

We may, additionally, use this to ensure that the domain
claimed in data over the protocol transaction matches the
domain of the owner of the IP address.  This means that
we hold the machine with that IP address accountable for
providing valid data.

This is a widely deployed SPAM countermeasure, based on
the theory that:

o	Domains are expensive
o	IP address blocks are expensive
o	"Burning" either of these in order to SPAM should
	be a more expensive proposition than the value of
	SPAM'ming in the first place.

This is also widely deployed for accounting records (logging,
billing, etc.).


> It seems clear to me that autoconfiguration is the
> favored approach for small or temporary networks. The
> choice for large networks, as for example - EDS Intranet,
> may well be different. This implies that DNS updates from
> autoconfiguration may well not be a requirement.

I think you need to make a distinction between:

o	Machines you trust, because they are installed
	behind your firewall

o	Machines you trust because they are your customers

o	Machines you trust because the trust is temporary

o	Machine you don't trust, but which someone else
	might, based on their forward and reverse mappings
	being transitive

I think the question comes down to a succinct "who owns
the address assigned during autoconfiguration?".

I think the answer is "partly the assignor, and partly
the assignee".  Then the question becomes "if I trust
them enough to give them an address, why don't I trust
them enough to accept a reverse mapping update from that
address telling me who they think they are?".


You could even be more explicit, and ask the question
like this: "for a laptop in an airport access point, a
telecommuting center, or a "wired" boardroom in which
business between two companies is being conducted, how
can I establish reverse mappings so that the laptop is not
crippled in capability vis a vis a permanently installed
workstation?".

You might also ask "how can I do this such that I don't
have to start trusting certificates and scanning laptop
IR ports/WaveLAN cards as they enter my premesis?".


I think this argument boils down to "why be protective
of the reverse mappings at all, if they aren't useful for
something about which we need to be protective?".


One might take the view that, in the future, there will
be no explicit Intranets, and what we now think of as
an Intranet will be replaced by a virtual Intranet which
consists of a VPN and some way to authenticate it to "get
inside".

In such a world, do we need to establish individual
identity (setting aside the desirability of getting
billed per-packet, which varies depending on whether or
not you are a telco, and the personal privacy issues),
or merely establish proxy identity, ala "they're inside,
they must be trustworthy people".

"Inside", in this case, being "the reverse mapping
matches the forward mapping", until we can get around
to implementing the world, above.


-- Terry Lambert
-- Whistle Communications, Inc.
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.