Re: IPv6 and Dynamic DNS

[Dean Anderson <dean@av8.com>]

Having reverse dns mappings is no security at all.  Both are easily
spoofed.  Having a valid reverse map does not make the connection any more
or less trustworthy.  Only really stupid admins make trust decisions based
on DNS information.

Indeed, there is another just as invalid "security" idea that one should
never use reverse mappings because the information might be used by
crackers.  Woe unto anyone who needs to get these two "security conscious"
networks to speak to each other.   One will not put out reverse maps, the
other will not trust anyone whose reverse maps are not "correct".

This is about as silly as believing that using RFC1918 addresses enhance
security because they are "unroutable". Lets just let both of these go into
the history of foolish ideas.

Please don't build this foolishness into DNS.  That would be a disaster.

		--Dean

Around 03:57 PM 8/3/1999 -0700, rumor has it that Terry Lambert said:
>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.
>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc                  dean@av8.com
           LAN/WAN/UNIX/NT/TCPIP          http://www.av8.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++