Subject: Re: To address or NAT to address?

From: Christian Huitema <[email-masked]>
Date: Wed, 01 Dec 1999 11:43:47 -0500

At 10:49 PM 11/30/99 -0500, Keith Moore wrote:

>note also that DNS is often slow, and seems less reliable than IP.
>by increasing the reliance on DNS you increase the probability of failure. 

Data point: out of 40,000 random DNS requests logged on my work station
over the last year, 20% underwent at least one retransmission, resulting in
service times larger than 2 seconds. The average packet loss rate on the
regular IP service only explain about half of these retransmissions, which
makes me suspect that a lot of additional losses are caused by congested
DNS servers. Increasing our reliance on the DNS is definitely not a good idea.
-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 01 Dec 1999 11:43:47 -0500

---

From: Cary FitzGerald <[email-masked]>
Date: Wed, 01 Dec 1999 13:36:57 -0800

Christian:

Is this something that you think is an inherent flaw in DNS?  Will this new class
of servers be less susceptible to congestion?

Cary.

---

From: Cary FitzGerald <[email-masked]>
Date: Wed, 01 Dec 1999 13:36:57 -0800

Christian:

Cary.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 01 Dec 1999 20:52:52 -0500

So we want some application level namespace and a system to translate
it to addresses. What characterstics should such a system have?  It
needs to be highly available, so you need replication among multiple
servers.  You can't concentrate all the data in one place so it needs
to be distributed, perhaps a good way of doing this would be to make
it hierarhical.  It would be good if short queries and answers could
be sent using UDP to avoid the setup and teardown overhead of TCP.  It
could be a directory system with complex queries but it really only
needs to be a name system that works by exact match.  And it should be
secure, which tends to make things more complex and slower, but will
frequently be necessary.

So, what are you suggesting other than re-inventing DNS and/or getting
DNS security actually deployed?  If you came up with something other
than DNS, why would it have any better performance?  How are you going
to stop some people from designating too few servers subject to too
many common mode failure mechanisms on inadequate machines with
inadequate connectivity regardless of the naming system your run?

Donald

From:  Christian Huitema <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Wed, 01 Dec 1999 11:43:47 -0500
References:  <Your message of "Tue, 30 Nov 1999 19:42:53 GMT."             <3.0.32.19
[email-masked]>

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 01 Dec 1999 20:52:52 -0500

Donald

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 01 Dec 1999 20:16:38 -0800

Christian,

> Increasing our reliance on the DNS is definitely not a good idea.

Hmmm.  This would appear to be the exact opposite of what the IETF has done
with IPv6.

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 01 Dec 1999 20:16:38 -0800

Christian,

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 01 Dec 1999 20:25:04 -0800

Cary,

> Is this something that you think is an inherent flaw in DNS?  

Inherent flaw in the DNS: probably not.  Inherent flaws in implementations of
DNS (including, of course, ISC's BIND) and things in front of the DNS:
probably.  It is far too easy to do the wrong thing.

And if this is true today, just wait -- DNSSEC and IPv6-related RRs create
entire new universes of "interesting" configuration options with some _really_
fun interactions.

> Will this new class

I am a bit skeptical that congestion is the problem.  I suspect
misconfiguration (lame servers, bad ACLs, broken firewall rules, etc.) is a
more likely cause that results in retransmissions.  

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 01 Dec 1999 20:25:04 -0800

Cary,

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Dec 1999 23:30:16 -0500

> probably.  It is far too easy to do the wrong thing.

this is worth elaborating: there are two major sources of problems:

1. DNS implementation bugs
2. mis-configuration 

the latter can be further divided into:

- mis-configuration of DNS itself (e.g. out of date glue records, forgetting to 
increment serial numbers when changing a zone, improperly incrementing 
serial numbers so that they wrap prematurely, misconfiguration of zone 
transfer information, etc.) 

- getting DNS out of sync with other software (e.g. MX record points
to a SMTP server which doesn't recognize itself as the mail exchanger
for that domain, or changing a DNS record to point to a new address
and failing to make sure that the old address remains valid until
the TTL on the old record has expired)

but yes, it is far too easy to do the wrong thing, partially because
there are so many wrong things that can be done.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Dec 1999 23:30:16 -0500

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 1999 09:53:30 -0600

> Hmmm.  This would appear to be the exact opposite of what the IETF has done

Well now. There is some truth in that (A6 records are quite complex...)
but NAT has generated some serious and complex dependencies on DNS too,
not to mention various load sharing techniques.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 1999 09:53:30 -0600

Brian

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 02 Dec 1999 08:27:45 -0800

Brian,

> not to mention various load sharing techniques.

With this in mind I hope that the same folks who complained about
increased dependencies on DNS by NATs, would be equally vocal in
complaining about increased reliance on the DNS by IPv6 (which claimed
to be an improvement over NATs).

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 02 Dec 1999 08:27:45 -0800

Brian,

Yakov.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 Dec 1999 10:09:23 -0800

> to be an improvement over NATs).

DNS is supposed to be a way to resolve domain names into IP addresses.
How else would one get an IP(v6) address from a domain name other
than by using DNS?  Am I missing something here?

Whether to use DNS to resolve a name into a non-address foobar might be
debatable.
Whether to use DNS to resolve a name into an IP(v6) address is not.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 Dec 1999 10:09:23 -0800

Regards,
Charlie P.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 02 Dec 1999 13:50:43 -0500

Cary,

We should really conduct this debate on a more appropriate list, e.g.
end2end-interest. But the answer is yes, we have a basic architecture
problem. The stability of the Internet, today, is ensured by the TCP
congestion avoidance mechanisms. In case of congestion, the routers drop
packets, and as soon as enough packets have been dropped, enough TCP
connections diminish the size of their windows and the congestion is eased.
A corrolary is that congested parts of the Internet have to constantly drop
a rather large fraction of packets, in order to ensure that TCP regulates
itself. My numbers tell me that the prevalent drop rate is between 1 and
5%, depending of the network, etc.

The drop rate has an inconvenient effect on DNS.  DNS requests are sent
over UDP, and rely on timers to repeat the transaction if either the
request or the response is lost. The observed transaction repeat rate will
be about twice the packet loss rate. DNS implementations use fixed timers,
set to 2 or 3 seconds. So, each transaction failure induces an additional 2
or 3 second delay. A single DNS query requires 2 or 3 transactions. We can
thus deduce that packet loss rates between 1 and 5% imply that 4 to 20% of
DNS queries experience at least one retransmission.
-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 02 Dec 1999 13:50:43 -0500

Cary,

---

From: Christian Huitema <[email-masked]>
Date: Thu, 02 Dec 1999 14:04:43 -0500

>than by using DNS?  Am I missing something here?

The IPv6 A6 record, which I helped design, map a host name to a tuple of
(prefix length, prefix name, binary suffix). The prefix name is a DNS name.
In order to actually get the address, one should go read the A6 record(s)
of the prefix, then combine prefix(es) and suffix to obtain address(es).
The idea is to facilitate renumbering by storing the prefix(es) in exactly
one place.

One could say that this structure implies an "increased reliance on the
DNS", in the sense that one will need to access two records instead of one
in order to obtain the address. In fact, we may need more than two
transactions, if the prefix itself is built from another prefix. On the
other hand, there are at least three ways to diminish this reliance:

1) DNS server can provide a copy of the prefix-name's A6 record in the
"additional information" field of responses, so that the second transaction
can be served from the cache,

2) In "Intranet" environments, a working set of prefixes will be present in
the cache anyhow,

3) In really constrained environment, network managers may choose to
arbitrage between ease of renumbering and reliance on the DNS, and set the
prefix length to zero, thus falling back to IPv4 like operation.

In short, this issue was discussed at length in the IPv6 working group, and
the benefits of easy renumbering/reconfiguration were deemed to exceed the
"extra reliance."
-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 02 Dec 1999 14:04:43 -0500

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 02 Dec 1999 14:01:42 -0800

Charlie,

> DNS is supposed to be a way to resolve domain names into IP addresses.

As a hammer is supposed to be a way to pound nails.  However, when it is
perceived that all you have is a hammer, it is amazing what begins to look
like nails.

> than by using DNS?  Am I missing something here?

Yes.  The DNS has grown a bit from a simple lookup mechanism.
 
Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 02 Dec 1999 14:01:42 -0800

Charlie,

 
Rgds,
-drc

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 02 Dec 1999 18:01:01 -0500

g'day,

> perceived that all you have is a hammer, it is amazing what begins to look

Actually, I think it would be as accurate to say "DNS is a distributed
database service. The first application was name to IP address
translation, but it's now used for a number of such applications." 

As someone pointed out in another message in this thread, if you started
designing a new distributed, scalable database service for the Internet,
you'd probably come up with something that looks a lot like DNS. You're
likely to add some things specific to your application, but the basics
would be the there.

> Yes.  The DNS has grown a bit from a simple lookup mechanism.

Actually, it's still a relatively simple lookup mechanism (boolean
domain names, anyone? :-) The interesting thing is how many different
applications for this technology there are, with more coming along. Some
of these new applications would benefit from changes to the technology
(such as adding support for various types of searching, for example) but
because of the mission critical nature of the initial existing services
the community is loath to take experimenting too far. At some point you
have to wonder if this is not having a chilling effect on innovation and
whether the technology wouldn't benefit from moving some of this stuff
out of the current service and legacy root.

					- peterd

-- 
------------------------------------------------------------------
              
              "Suddenly, nothing happened"

-----------------------------------------------------------------

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 02 Dec 1999 18:01:01 -0500

g'day,

					- peterd

---

From: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 15:25:54 -0800

>to be an improvement over NATs).

Yakov,

Observing that IPv6 has increased reliance on DNS, as does NAT, would
not invalidate claims that IPv6 is an improvement over NAT; the claimed
improvement is not solely, or even primarily, one of reduced DNS reliance.

(Since you brought it up, I'll pedantically point out that IPv6 does
not rely on the DNS at all -- it works just fine in the absence of a DNS
service, unlike some of the NAT variants and the direction in which NAT apparently must evolve to keep up with the growth and functional demands
of the Internet.)

Steve

---

From: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 15:25:54 -0800

Yakov,

Steve

---

From: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 15:36:29 -0800

>Yes.  The DNS has grown a bit from a simple lookup mechanism.

David,

I think the point Charlie was making is that IP addresses are precisely
the kinds of nails that the DNS was designed to hammer.  Are you
claiming that because the DNS has been used to pound other things,
it is no longer any good for hammering (IP address) nails?

Steve

---

From: Steve Deering <[email-masked]>
Date: Thu, 2 Dec 1999 15:36:29 -0800

David,

Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Dec 1999 15:41:27 -0800

>translation, but it's now used for a number of such applications."

As opposed to the long and continuing history of talking about (and 
specifying) uses for the DNS that are more than name/address mapping, what 
other functions are actually done (on a wide scale) today?

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Brandenburg Consulting
Tel: +1.408.246.8253          675 Spruce Drive       Fax: +1.408.273.6464
[email-masked]   Sunnyvale, CA 94086 USA    www.brandenburg.com

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Dec 1999 15:41:27 -0800

d/

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Dec 1999 15:57:42 -0800

> Are you claiming that because the DNS has been used to pound other things,

hypothesis: the net dns traffic is not significantly more than the email
            traffic about the dns.

<g>

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Dec 1999 15:57:42 -0800

<g>

randy

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 02 Dec 1999 20:05:24 -0500

Hi Dave,

> other functions are actually done (on a wide scale) today?

Actually, Dave I'm not sure I was trying to go where you seem to be
going with this. I was referring to some of the things we've been seeing
on this list - things like supporting IPv6, supporting NATs, supporting
the people looking at IP telephony applications, providing MX mail
services, to name a few. Yes, there are other potential uses that
haven't taken off and I've also been working with people interested in
using DNS technology for such things as ecommerce naming applications,
but frankly given the whole ICANN/NSI/Trademark Lobby/TLD mess I suspect
it's not feasible or desirable to touch the current DNS root tree with a
barge pole for that. The DNS technology clearly has multiple uses, but
proposing changes to the legacy root has become an extremely political
exercise, of late...

My question is still there - is the current mission critical nature of
the simple DNS name->IP address lookup service having a chilling effect
on innovation in DNS technology? The fact that people have proposed
other services based upon this technology and they haven't flown may
actually be a sign of that chilling effect, or it may just be a
commentary on the services proposed. I don't pretend to know the answer
to that, but given how often I've heard "the DNS is mission critical and
can't be changed if it breaks the core service" I would prefer at least
to have a "test tree" for exploring outlandish ideas. My own solution
was to set up and experiment with independent roots, but can this work
in a global Internet context? If I talk about multiple roots I suspect
I'm liable to be tarred with a couple of pretty messy brushes.

I do think there's an issue here, but don't know how to broach it
without appearing to be taking sides in the ICANN wars...

					- peterd

   "In other news tonight, General Franco is still dead"

---

From: Peter Deutsch <[email-masked]>
Date: Thu, 02 Dec 1999 20:05:24 -0500

Hi Dave,

					- peterd

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 02 Dec 1999 19:05:17 -0800

Steve,

> the kinds of nails that the DNS was designed to hammer.  

And I agree.

> Are you

Not at all.  The DNS is (still) a wonderful system for translating IP
addresses to names and vice versa.  I'm a bit skeptical that the other things
the DNS has been pressed into action to do is optimal, but I also see the
"nail-ness" of many problems.  My point was that suggesting that reliance
should not be placed on the DNS has been, is, and most likely will be contrary
to what happens in the real world.

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 02 Dec 1999 19:05:17 -0800

Steve,

And I agree.

Rgds,
-drc

---

From: Bill Fink <[email-masked]>
Date: Thu, 2 Dec 1999 23:40:18 -0500 (EST)

> the benefits of easy renumbering/reconfiguration were deemed to exceed the

I'm glad this idea of decoupling site prefix and internal site
address is finally getting some serious attention.  I've always
felt this was critical to the success of being able to actually
renumber a site fairly painlessly.  I'll have to check out the
details of the A6 DNS draft.  I proposed something very similar
way back in March of 1995, but it wasn't given much attention
then.  Now if we could only have an alternate stateful address
configuration method than the backwards one of DHCPv6, one that
generated an IPv6 address directly from the host's domain name
rather than from a layer 2 MAC address, we'd really be in business.
Maybe that too will come eventually.  I've included my earlier
message to the ipng e-mail list as historical perspective (my
original original message is at the very end).

						-Bill

---

From: Bill Fink <[email-masked]>
Date: Thu, 2 Dec 1999 23:40:18 -0500 (EST)

-Bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 2 Dec 1999 21:40:20 -0800 (PST)

> My point was that suggesting that reliance

Someone who used to work here at ISI had a saying, "There are no urgent
DNS problems."  I did not believe then and am finding less reason to
do so as time progresses.  An interesting viewpoint is espoused in the
recent draft by Akien et.al. on Middleware.  According to that draft,
we are headed into an Infrastructure that will not work w/o available
support services e.g. policy db, CA/key servers, DHCP/DNS, ad.nausea.

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Thu, 2 Dec 1999 21:40:20 -0800 (PST)

-- 
--bill

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 3 Dec 1999 00:38:23 -0800 (PST)

> out of the current service and legacy root.

The one-line summary I heard for the work of the proposed RESCAP working
group (http://www.ietf.org/ietf/99nov/rescap-agenda-99nov.txt) is "to do
stuff we'd like to do with DNS but can't quite make it do."

 - RL "Bob"

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 3 Dec 1999 00:38:23 -0800 (PST)

- RL "Bob"

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:27:47 +0100

>DNS servers. Increasing our reliance on the DNS is definitely not a good idea.

(Wow - a real measurement! Can this be the IETF list....? Thanks!)

Question: Out of those 8.000 retransmitted DNS queries, do you have any 
data on how many eventually returned data, versus how many resulted in 
NXDOMAIN or no data?
There used to be a bug with caching of negative responses....

                            Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:27:47 +0100

Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:40:14 +0100

At 20:05 02.12.99 -0500, Peter Deutsch wrote:

>on innovation in DNS technology?

Definitely. And that's a sign of sanity.

>  The fact that people have proposed

Yes.

OTOH, nobody stops you from running a set of DNS servers on port 53000, 
with resolvers in the applications configured to match.
Guaranteed noninterference.

                      Harald A

>-
>This message was passed through [email-masked], which
>is a sublist of [email-masked]. Not all messages are passed.
>Decisions on what to pass are made solely by Harald Alvestrand.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:40:14 +0100

Yes.

                      Harald A

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:35:35 +0100

At 18:01 02.12.99 -0500, Peter Deutsch wrote:

>domain names, anyone? :-)

RFC 2673.
Sorry, just couldn't resist :-)

            Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 03 Dec 1999 09:35:35 +0100

RFC 2673.

            Harald

---

From: Christian Huitema <[email-masked]>
Date: Fri, 03 Dec 1999 09:08:58 -0500

>There used to be a bug with caching of negative responses....

All the 40,000 requests that I mentioned were eventually successfull. At
the same time, there were an additional set of requests, about 2,000, that
were not successful. The reasons for not succeeding vary from
misconfiguration to bad input, e.g. trying obsolete URLs. The unsuccessful
queries are not considered in the statistics.
-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 03 Dec 1999 09:08:58 -0500

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Dec 1999 07:59:30 -0800

Bill Fink wrote:

>         Now if we could only have an alternate stateful address
> Maybe that too will come eventually.

DHCPv6 does allow the client to include its domain name as part of
a DHCP Request, which a DHCP Server could use to identify the
right address for the client on the originating network link.
We expected that the domain name might be used for exactly this
purpose.

Isn't this what you want?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Dec 1999 07:59:30 -0800

Regards,
Charlie P.

---

From: Bill Fink <[email-masked]>
Date: Fri, 3 Dec 1999 17:47:59 -0500 (EST)

> Isn't this what you want?

DHCP has its purposes, but it shouldn't be a required component
of an Internet system.  The routing and DNS systems should be
sufficient if properly designed.  The fewer systems you have to
manage and thus the smallest amount of interactions between those
systems provides the simplest, most manageable, and robust overall
system.  Anyone who has worked with ATM software knows that its
complexity and multiple interdependent systems has made it a
complete nightmare to manage and troubleshoot, and I would hate
to see that happen to IPv6 (although I'm sure that there are
some who would argue that it's already getting there).  I totally
believe in the KISS principle that Steve Deering adhered to in
the basic protocol design, and I think that the supporting network
infrastructure should be handled the same way.

I have never seen any documentation about how the dynamic updates
are supposed to be handled between the DHCPv6 and DNS systems,
although I haven't been following recent developments that closely,
so it's possible I may be behind the times (if so please point me
at the appropriate draft(s) to read and I'll gladly do so).  Without
this in place, I can't see how any large scale serious deployment
of IPv6 can go forward.

The way I believe stateful address configuration should work is
basically as follows.  The host should be configured with its
hostname, domain name, and possibly a security key.  It would
then multicast a DNS request with site local scope, providing
its hostname, domain name, subnet (from router advertisement),
and MAC address (and possibly the security key).  By the way,
this might be another use of site-local addresses, for the
source address in this request.  The DNS server would then
look up the hostname (validating the request using the security
key if present and a secure domain), construct an IPv6 address
out of the site prefix, subnet, and MAC address info (or optionally
could generate a random address in place of the MAC address), and
send that back to the host using its site-local address.  The host
would validate the reply (using the security key if present) and
would be in business.  The address lifetime values would need to
be added to the DNS info for the host's address, but that's where
they really belong anyway.

Routing system.  DNS.  That's it, all that's really necessary.
If you need additional info like a boot file name or such, that's
where I would see DHCP coming into play.  But for basic addressing
requirements, keep it all in the DNS.  It should make life much
simpler all around.

						-Bill

---

From: Bill Fink <[email-masked]>
Date: Fri, 3 Dec 1999 17:47:59 -0500 (EST)

-Bill