Subject: Re: A6 benefits?

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 19 Jan 2001 14:32:53 -0500

In message <[email-masked]>, "D. J. Bernstein" writes:
>Steven M. Bellovin writes:

>
>Client-side indirection means that every client will check, slightly
>less than once per TTL, with every ISP of every server that it uses
>regularly.

Except, of course, for caching.
>
>The overall effect on Internet traffic is small either way, but it's
>much smaller with server-side indirection---and the user doesn't have to
>wait for it.
>
>> AAAA is especially problematic if DNSSEC is used, since 
>> that would require resigning the entire zone -- and that's expensive.
>
>People change their zones all the time. If DNSSEC can't deal with that,
>it's in even more trouble than I thought.

Most people don't change the entire zone that often; only the changed 
records need to be resigned (plus those on either side of an insertion 
or deletion).  With AAAA, if your ISP renumbers you (possibly because 
it itself has had to renumber), you have to resign the entire zone.  
More precisely, you have to resign every record in the zone.

		--Steve Bellovin, http://www.research.att.com/~smb

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Jan 2001 22:39:03 -0000

> Except, of course, for caching.

That's not an exception. As I said, the client checks slightly less than
once per TTL.

How many addresses has your site's DNS cache looked up in the past week?
How many different ISPs are involved? One thousand? Ten thousand?

Client-side indirection means that you have to check every one of those
ISPs for changes. Server-side indirection means that you have to check
one ISP, namely yours, for changes. The frequency of checks per ISP is
somewhat higher for server-side than for client-side, but client-side
involves vastly more ISPs.

Bottom line: This is not a benefit for A6.

> Most people don't change the entire zone that often;

Here at UIC, for example, we have EECS splitting into CS and ECE. All
the machines in eecs.uic.edu are going to be given new names. Are you
saying that this trivial operation would pose serious CPU-time problems
if we were using DNSSEC?

Are there any other benefits for A6?

---Dan

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 23 Jan 2001 16:41:59 -0600

> involves vastly more ISPs.

Whoa!  I think I detected a bogon.

If you're setting TTLs in order to catch a site S renumbering within
a time Tr, then compare the two cases

Case 1: DNS master for S checks all the upstream prefixes and
generates a set of complete address records for hosts in site S (be
they AAAA or A6 with prefix len = 0).

Case 2: The zone file for S indirects the prefixes at some level to
data held by its upstream provider(s) using the A6 prefix name field.

In case 1, the zone must bound the TTL of every address record by Tr.

In case 2, the provider(s) must bound the TTL of their portion of the
address by Tr.  (Or, S's zone must provide an indirection with TTL
bounded by Tr.)  The A6 records owned directly by the host may have
TTLs much longer that Tr, depending on what the site knows about its
own habits and practices.

So in case 1 clients of site S must re-fetch every address record
they need at a frequency approximately 1/Tr.

In case 2, they only need to fetch the common prefix record at the
rate 1/Tr.

> Bottom line: This is not a benefit for A6.

Bottom line: there is such little experience with A6 that people's
thinking is sometimes a bit muddy.

				Matt Crawford

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Jan 2001 01:51:18 -0000

Matt Crawford writes:
> I think I detected a bogon.

That's because you're not paying attention.

Consider a future world with 10000000 sites, each with one DNS cache and
a few DNS servers and a bunch of miscellaneous computers. Let's say each
site looks up addresses at 10000 different ISPs every week.

Client-side indirection, such as A6, means that those address lookups
have to be supplemented by queries to all the ISPs. The cache sends at
least one query per ISP every week, even if the TTLs are longer than
that; caches don't (and shouldn't) save information for longer than a
week. Total work: at least 100000000000 queries per week.

Server-side indirection means that each site has to watch for changes at
its own ISP. Ten queries per week will be more than enough even if we
want to allow a change every day. Total work: at most 100000000 queries
per week. Pushing, instead of pulling, would be even less expensive.

How can anyone claim that 100000000 queries per week is ``more polling''
than 100000000000 queries per week? This is completely ridiculous.

(I'm not saying that the traffic is noticeable either way.)

> thinking is sometimes a bit muddy.

Your thinking, for example.

---Dan

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 24 Jan 2001 09:44:14 -0600

> That's because you're not paying attention.

Strike "not".

> than 100000000000 queries per week? This is completely ridiculous.

You're comparing apples to worms.  In one case, you've counted the
queries needed for each site to keep its own address records up to
date, and in the other case you've counted the queries needed for
each site to keep its cache of correspondent sites' addresses up to
date.

(Unless you meant that each site is a leaf on a 10000-deep tree of
address delegations, which isn't possible with a 128 bit address.)

				Matt