Subject: FW: IPv6 and Dynamic DNS

From: "Cutler, James R" <[email-masked]>
Date: Wed, 4 Aug 1999 14:47:04 -0400

Terry Lambert wrote:

<text omitted
In your opinion, what is the proper purpose of reverse
records, if one is not to look them up, or trust their
contents should one be so "foolish" as to look them up?

<text omitted>

What is the rationale for not allowing a machine, granted
a particular address, to set its reverse record?

<text omitted>

Cutler Replied:

In today's network, reverse records are generally created for the
convenience of the network provider. They are useful for simplifying log
analysis, especially for things like sendmail logs and traceroute. In well
controlled networks, reverse records are invaluable for diagnostics for
other application environments. There is nothing "foolish" about this.

Assuming any security implication of reverse resolution, though, would
generally be foolish.

A typical rationale for not allowing a machine to set it's reverse record is
that it is the responsibility of DHCP to do so.  Another is that the network
provider may desire to label the addresses with permanent labels, regardless
of what mobile users may or may not happen to use them.  Again - this is for
the convenience of the network provider. 

Nothing an end user does (which requires a TCP/IP connection) should require
knowledge of either the assigned address or the reverse lookup of the
assigned address.

NOTE.  The position stated above is independent of IPv4 versus IPv6, or even
the address assignment method - it applies to static address assignments as
well.

Conclusion:

It is probably unwise to complicate Stateless Autoconfiguration in IPv6 with
any DNS issues. 

As I understand it, the Draft Standard implicitly assumes some prior
knowledge of destination addresses, or at least a nameserver address. Where
this is not viable, DHCP is always an option for host stack configuration.
The DHCP provider will then make the decision on how and whether to do any
DNS updates at all.

---

From: Terry Lambert <[email-masked]>
Date: Wed, 04 Aug 1999 13:43:31 -0700

Cutler, James R wrote:
> In today's network, reverse records are generally created
> for the convenience of the network provider. They are
> useful for simplifying log analysis, especially for things
> like sendmail logs and traceroute.

You can't trust a reverse record for logging, unless you
(minimally) also log the IP address.

This is truly minimal, in that it requires a human to be
able to determine that "somenthing fishy is going on", by
somehow realizing that the IP address and the DNS name
do not, in fact correlate.

Human beings, being what they are, are unlikely to notice
logging of intrusions, etc., unless the domain name doesn't
match the one they are expecting.

To alleviate this, most programs that rely on reverse
records for logging purposed will do a forward lookup
of the reported name, and if the result does not match
the IP address being reversed, note the fact at a high
importance that the name is probably being spoofed.

> In well controlled networks, reverse records are
> invaluable for diagnostics for other application
> environments. There is nothing "foolish" about this.
> 
> Assuming any security implication of reverse resolution,
> though, would generally be foolish.

I think your statement about highly controlled
environments contradicts your statement about security
implications.  If the environment is controlled, then
implications may be safely drawn.

> A typical rationale for not allowing a machine to set
> it's reverse record is that it is the responsibility of
> DHCP to do so.

This rationale, incorrectly assumes the existance of a
DHCP service.  Ad hoc networking was one of the intended
design goals of IPv6.  Additionally, much work has been
done to support ad hoc networking of IPv4 hosts, including
current drafts which document the process which is used
by Windows 98 in the absence of a DHCP server.

> Another is that the network provider may desire to label
> the addresses with permanent labels, regardless of what
> mobile users may or may not happen to use them.  Again -
> this is for the convenience of the network provider.

This is most generally applied to dialup lines in the
absence of DDNS.  Note that DDNS does not require DHCP
to implement login based name assignment; updates may
result from RADIUS authentication, instead.

Indeed, common practice for POP provisioning is to
purchase POP access from a large provider, such as
UUNET.  The routing requirements for address block
assignmnets in IPv4 dictate that, in order to minimize
the size of the the routing tables required to that
which will fit into a routers memory, the destination
for the POP has no control over even static IP address
assignments.

That is, DHCP is not an apropriate, nor even a capable,
technology for implementing such topologies, since the
address blocks are assigned to the terminal servers,
not some DHCP server somewhere.

The communication mechanism between the POP provider
and the intended back end server (in general, the RADIUS
"realm") is via proxy of RADIUS acconting records to the
back end server.

DDNS updates for such transient connections may _only_
be made as a result of the RADIUS traffic.

> Nothing an end user does (which requires a TCP/IP
> connection) should require knowledge of either the
> assigned address or the reverse lookup of the assigned
> address.

On this we agree.

On the other hand, practical realities which result from
the lack of a DNSSEC umbrella covering the _entire_ DNS
deployment as it currently exists means that, while nothing
the end user does should require knowledge of either the
assigned address or the reverse lookup of the assigned
address, the same is not true of _servers with whom the
end user intends to communicate_.

> NOTE.  The position stated above is independent of IPv4
> versus IPv6, or even the address assignment method - it
> applies to static address assignments as well.

Theoretically, yes.

Practically, servers _are_ using, and _will continue
using, for the forseeable future_, the correlation
between IP address block assignments (with an implied
trust in the central assignment authority and its
delegates) and domain name assignments (with an implied
trust in the central assignment authority and its
delegates).

If you don't like this, then you need to establish standards
which can be used in place of this.

But this trust model is Best Current Practice, as it stands
today.

> Conclusion:
> 
> It is probably unwise to complicate Stateless Autoconfiguration
> in IPv6 with any DNS issues.

For a full DNSSEC IPv6, I agree with this statement, as well.

> As I understand it, the Draft Standard implicitly assumes
> some prior knowledge of destination addresses, or at least
> a nameserver address.  Where this is not viable, DHCP is
> always an option for host stack configuration.

Stack configuration, or just default route and DNS server
location configuration?  IMO, stacks should autoconfigure.

> The DHCP provider will then make the decision on how and
> whether to do any DNS updates at all.

Service Location Protocol, via multicast, is another
(probably better than wedging DHCP into IPv6 and making
exceptions for autoconfiguration) option.  With it you
can ask "where is my default route?" or "where is my DNS
server?" without having to ask for an address assignment
at the same time.

Consider the network capable device which you would rather
not have to expliciitly configure, either at the front
panel, or via a DHCP configuration record somewhere (e.g.
a printer, scanner, document capture device, network
attached storage, IPv4 NAT gateway, SOCKS-5 proxy, default
home page, POP3 server, SMTP relay server, HTTP proxy,
any-other-browser/PC-option-you-can-think-of-configuring,
etc.).

A future which requires DHCP is a future which requires
humans to configure things they ought not have to
configure.

The set of things which fall into the category of things
which humans ought not have to configure?  Everything.

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
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.