Subject: 13 Root Server Limitation

From: Thomas Bocek <[email-masked]>
Date: Sun, 16 May 2004 21:13:24 +0200

Hi

I’m confused with the fact than the number of root servers is limited to 13.
>From RFC 3226:

"The current number of root servers is limited to 13 as that is the maximum
number of name servers and their address records that fit in one 512-octet
answer for a SOA record.  If root servers start advertising A6 or KEY records
then the answer for the root NS records will not fit in a single 512-octet DNS
message, resulting in a large number of TCP query connections to the root
servers."

A query send to one of the root servers with a long name (length 255) shows
that
the answer is 511 bytes, returning one A and 13 NS records. My question is: Why
are all 13 NS returned?

Thanks in advance

T. Bocek

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Peter Koch <[email-masked]>
Date: Sun, 16 May 2004 22:09:27 +0200

Hello Thomas,

{calculation of DNS response sizes is a topic for the IETF DNSOP WG
 <http://www.ietf.org/html.charters/dnsop-charter.html>. For the basic
 issues, the archives of the DNSOP mailinglist may help, or even more so
 (apart from direct replies) one of the DNS related Usenet newsgroups.}

> the answer is 511 bytes, returning one A and 13 NS records. My question is: W

The protocol requires (RFC 2181, 5.2) that RRSets be handed out completely.
Everything else would sooner or later result in "funny" effects and severe
operational problems. It is, however, arguable, whether or not the "A" RR
is really needed. Currently deployed software may lead to a "yes" here.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Sun, 16 May 2004 22:09:27 +0200

Hello Thomas,

-Peter

---

From: Dean Anderson <[email-masked]>
Date: Sun, 16 May 2004 18:22:13 -0400 (EDT)

On Sun, 16 May 2004, Thomas Bocek wrote:

> A query send to one of the root servers with a long name (length 255)
> shows that the answer is 511 bytes, returning one A and 13 NS records.
> My question is: Why are all 13 NS returned?

BIND adds an additional section that is optional. If this section weren't
provided, then more root servers could be added.  It has been pointed out
that this additional section information is ignored by most resolvers, and
so it useless, except to persons manually interpreting the output of DNS
query details. Some nameservers do not provide this additional data.  It
would be operationally advantageous to use a nameserver software on the
Root servers that did not provide the additional section.

However, I think your interest is in regard to DNSSEC deployment. There
are other problems with DNSSEC deployment, that limit or preclude
widespread utility. I can't cover them all in one message.  But suffice it
to say that DNSSEC isn't really secure, and that further, the root servers
operators have widely adopted a dubious anycast replication model that
won't work well with TCP and load-balancing BGP configurations that are
gaining the interest of ISPs. Such load balancing configurations will send
packets over different paths to the same IP address. This is significant
because an Anycast server is two (or more) physical servers with the same
IP address, but with different paths to each server to distribute load.  
Anycast will not cause problems with single packet UDP DNS queries, but
will have problems with load balanced, TCP connections, especially where
BGP load balancing configurations would be likely to send packets over
different paths (and thus to different anycast servers) within a very
short period of time, perhaps even sequential packets could sent over
different paths.

This dubious anycast configuration was discussed and "approved" by the
NAMEDROPPERS Working Group in late November, 2002. Unfortunately for the
anycast discussion, the list then became distracted by discussions
concerning procedural irregularities involving the AXFR-clarify Draft,
which would have altered the DNS AXFR and IXFR protocol to conform to the
non-standard ISC/BIND implementation, despite a number of other
implementations being able to follow the AXFR and IXFR specifications.  
This quickly developed into a discussion regarding abuse by the list
administrator (Randy Bush) with respect to Dan Bernstein, and so the
anycast discussion was abandoned.

As the IETF list members are perhaps unaware, the charges of abuse by ISC
and ISC-promoters is hardly new.  It is very hard to get real work done in
the DNS working groups as a result.  ISC/BIND promoters have the working
group tied up with gratuitous alterations to widely implemented protocols
(eg AXFR-clarify) and irrational and misleading changes (eg IN-ADDR
required) that have been demonstrated to either be security risks or
dangerously misleading security placebo's, and have tried to suppress
dissent on these issues by refusing to accept email, and in the past,
silently discarding email, and otherwise harrassing people who offer
reasoned and detailed objections. 

I and others would probably be more involved in issues like DNSSEC, and no
doubt more progress would be made, if it weren't for the distractions of
the mismanagement of the IETF and its working groups.

Dean Anderson
Av8 Internet, Inc

---

From: Dean Anderson <[email-masked]>
Date: Sun, 16 May 2004 18:22:13 -0400 (EDT)

Dean Anderson
Av8 Internet, Inc

---

From: Joe Abley <[email-masked]>
Date: Sun, 16 May 2004 19:01:17 -0400

On 16 May 2004, at 18:22, Dean Anderson wrote:

> ... and that further, the root servers

This is not the case with F (I can't speak for other operators 
deploying Internet-scope anycast services). The different paths are 
made available in order to provide redundancy and diversity, and 
absolutely not to share load.

If you have an example of someone enabling multi-path BGP hacks in 
order to allow selection of more than one path, and specifically one 
who has ever selected two or more paths to different nodes of F (that 
is, paths to 192.5.5.0/24) I would be very interested to hear about it.

Feedback and measurement data we have seen has not yet revealed an 
occurrence of this, and conversations so far with operators does not 
suggest there is much risk that we will. Your data will be interesting 
to hear, however, if you can pass it on.

> short period of time, perhaps even sequential packets could sent over

There is a risk that during a routing transition, when one path to 
192.5.5.0/24 is promoted over another due to a link failure or some 
other policy or topology change, a TCP transaction to an anycast node 
will fail. This is documented in both ISC technical notes written to 
describe what we are doing with F.

Our experience is that such route churn is of such a low frequency that 
the effect on extremely transient TCP DNS transactions is statistically 
negligible (and quite possibly indistinguishable from timeouts during 
reconvergence events to non-anycast servers). In addition, before the 
frequency of the route churn became sufficiently high to cause a 
problem, it would be well and truly damped to death by anybody running 
with common BGP damping parameters and the inability to talk to the few 
root servers which have anycast instances would be the last of your 
problems.

There's a specific section in ISC-TN-2004-1 which describes the 
applicability of cluster-scope anycast to protocols with longer-lived 
transaction times than DNS, and which warns implementers to test 
thoroughly since the opportunities for flows switching between hosts is 
greater there than in the global/BGP case. This is not the case you 
were talking about, but I mention it anyway for completeness.

Just thought I'd add some operational perspective to this particular 
point. I have no useful comments to make on the rest of your message, 
since I am neither a BIND developer nor a DNS/DNSSEC architect.

Joe

---

From: Joe Abley <[email-masked]>
Date: Sun, 16 May 2004 19:01:17 -0400

Joe

---

From: John Kristoff <[email-masked]>
Date: Sun, 16 May 2004 21:09:16 -0500

On Sun, 16 May 2004 19:01:17 -0400

> root servers which have anycast instances would be the last of your 

Not necessarily.  Common dampening parameters exclude some 'golden
networks' such as root name server networks from damping.  RIPE 229 and
Rob Thomas' Secure BGP template being perhaps the two most widely cited
guides that suggest such a practice.

John

---

From: John Kristoff <[email-masked]>
Date: Sun, 16 May 2004 21:09:16 -0500

John

---

From: jfcm <[email-masked]>
Date: Mon, 17 May 2004 04:32:36 +0200

Dear Dean,
Anycast is of no interest here. The regional disemination of Root Servers 
requested by the WSIS should not to be read as a dissemination of the NTIA 
root file, but as a regional/national redundant generation of the root 
file, with mutual cross verification. Each national/regional identical root 
file can then have 13 servers and enhance the reliablity of the whole 
system, providing root system failure / hacking / attack fall-out / DoS 
containment.

Under the current deployement the DNS reference is not the network reality, 
nor the TLD Managers and Regiistrants decision. This is in blattant 
opposition with the "Internet core values" the IETF draft describes. The 
reference is a single master file on which ICANN/IANA acknowledges having 
no direct power. This is not something the Tunis 2005 meeting will accept 
when you consider the positions in Geneva 2003, so we are better off 
presenting an acceptable solution.

All the more than regional root file compilation addresses the IPv6 
concern: each root sever system may have only a few machines. If only 1/10h 
of the countries run a root compilation/server system, we could have from 
60 to 240 root servers. 20 root servers system would be a good back-up and 
for the users to chose from (RFC 883). The cost would ^probably be lower as 
the load on each machine will be much lower than today. Most of the 97.5% 
illigitimate load on the existing single system will probably only partly 
export to others. This means that we could decrease the load on an aveage 
root server machine down to 0.25% of the today load.

I know that you do not trust DNSSEC, but accessing randomly two or three 
different root server systems to verify a received info is another way 
towards security without taking risk of implementing a new system as 
DNSSEC. Even if this results in 3 times more traffic the load per machine 
would stay around less than 1% of the today load and the load on the 
network would probably be reduced with information travelling more locally.
jfc

At 00:22 17/05/04, Dean Anderson wrote:

> > I'm confused with the fact than the number of root servers is limited 
> to 13.
> > From RFC 3226:
> >

---

From: jfcm <[email-masked]>
Date: Mon, 17 May 2004 04:32:36 +0200

Dear Dean,

---

From: Joe Abley <[email-masked]>
Date: Mon, 17 May 2004 00:54:14 -0400

> guides that suggest such a practice.

The point I was trying to make was not that the path to the anycast 
roots would be dampened, but that topology oscillations that caused 
path changes with that frequency might well cause everything else to be 
dampened, or cause the prefixes announced from the supposedly-affected 
AS to become dampened in other ASes.

This was intended to be degenerate-case handwaving.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 17 May 2004 00:54:14 -0400

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 May 2004 10:11:16 +0200

> to hear, however, if you can pass it on.

This is pretty much impossible with Cisco equipment, as in order to 
load balance, the different routes must all be learned from the same 
neighboring AS. (So if everyone used Cisco equipment the AS paths would 
have to be identical.) Additionally, the default way to do this is send 
all packets towards the same IP address over the same link. Other 
vendors also bend over backwards to avoid packets from the same session 
being distributed over more than one link. (The idea is that reordering 
packets is bad. However, sometimes the measures to avoid it are worse.)

But as long as we're dissing anycast root DNS servers: how many of the 
root servers are being anycast now or in the future, and how many 
won't? As we've seen a few times with .org, and thought we saw with 
.org many more times, over-enthusiastic anycasting isn't without its 
dangers.

---

From: Joe Abley <[email-masked]>
Date: Mon, 17 May 2004 11:22:43 -0400

On 17 May 2004, at 04:11, Iljitsch van Beijnum wrote:

> neighboring AS. (So if everyone used Cisco equipment the AS paths 
> would have to be identical.)

It may be worth noting here that with the style of Internet-scope 
anycast deployment we're doing with F (ISC-TN-2003-1) each anycast node 
operates as a globally-unique AS, so even if a single AS was peering 
with F-root nodes in different places it ought not to be possible for 
traffic from a single TCP transaction to be split between nodes.

> .org many more times, over-enthusiastic anycasting isn't without its 

It seems to me that prudence and diversity are best served through a 
mixture of anycast and unicast nameservers in an NS set, the latter to 
provide path diversity and local stability to topologically distant 
regions and the former to accommodate any practical issues that might 
arise with the latter.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 17 May 2004 11:22:43 -0400

Joe

---

From: Bill Manning <[email-masked]>
Date: Mon, 17 May 2004 08:41:46 -0700 (PDT)

% But as long as we're dissing anycast root DNS servers: how many of the 
% root servers are being anycast now or in the future, and how many 
% won't? 

	http://www.rssac.org/ 

	check the 17th & 18th meeting minutes.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Bill Manning <[email-masked]>
Date: Mon, 17 May 2004 08:41:46 -0700 (PDT)

http://www.rssac.org/ 

--bill

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 13:36:21 -0400 (EDT)

> absolutely not to share load.

I don't have the list of roots using anycast handy (I think might have
been published on Namedroppers though), and I don't remember if F was 
amoung them.

> is, paths to 192.5.5.0/24) I would be very interested to hear about it.

It is conceptually very simple:  Setup 2 anycast servers (S1 and S2) on
several paths (AS-A and AS-Y, different AS numbers)  Have an ISP connect
to both of those paths, and then have that ISP do fine grained load
balancing to prefixes available over those paths. Packets will go to each
anycast server.  This will not cause a problem with UDP, since the entire
connection transaction is in one packet. But TCP will have a minumim of 3
packets.  2 packets will go to server S1, and one packet will go to server
S2.  Neither S1 nor S2 will have a complete TCP connection, and so both
will fail.

> to hear, however, if you can pass it on.

This is because most (vast bulk?) traffic to the root's is UDP. It may
also be the case that no ISPs are doing fine-grained load balancing to the
specific paths which happen to go to the root servers using anycast.  
However, this configuration is just a matter of chance.  One can't make
operational plans based on essentially false assumptions that a) no one
does TCP DNS queries, and b)  no one does fine grained load balancing, or
c) no one does fined grained load balancing on the paths that lead to
anycast root servers.

Anycast only works on UDP, and only one single packet transactions with no
other state.  If your application cannot meet those requirements, it is
unsuitable for anycast.  UDP DNS meets those requirements. TCP DNS does
not.

> > Anycast will not cause problems with single packet UDP DNS queries,
> > but will have problems with load balanced, TCP connections, especially
> > where BGP load balancing configurations would be likely to send
> > packets over different paths (and thus to different anycast servers)
> > within a very short period of time, perhaps even sequential packets
> > could sent over different paths.
> 

This is a course-grained route switch. There is no way to avoid such
connection failure, because one server containing the TCP state, failed.  
As has been pointed out, such route changes are infrequent.  Route churn
is a minor problem, and unrelated to fine-grained load balancing, in which
packets are simultaneously sent over two different paths.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 13:36:21 -0400 (EDT)

--Dean

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 May 2004 14:17:38 +0200

>> My question is: Why are all 13 NS returned?

[snip]

> NAMEDROPPERS Working Group in late November, 2002.

To the best of my knowledge there where root-servers anycasted way 
before this date. And I have no idea why the namedroppers mailinglist 
(or the IETF for that matter) would have to approve how the 
root-servers are operated?

> Unfortunately for the

I've got no idea what this has to do with the number of root-servers.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 May 2004 14:17:38 +0200

[snip]

- - kurtis -

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 16:51:01 -0400 (EDT)

On Mon, 17 May 2004, Kurt Erik Lindqvist wrote:

> before this date. 

This may be true, but it certainly wasn't widespread.

> And I have no idea why the namedroppers mailinglist (or the IETF for
> that matter) would have to approve how the root-servers are operated?

I have no idea why anyone would bother to ask a group of DNS protocol
experts about a DNS protocol-affecting change to the operation of root
namerservers, either. The insanity. Go figure.  Why not just go do it, and
see what breaks? Screw the possible false assumptions. Besides, if it
doesn't break on my shift, it wasn't my fault.  Who needs engineers when
you have operators?  People worry too much.

Of course, this same line of thought led to the 3 Mile Island meltdown,
when the __operators__ decided on their own to shut off the emergency
cooling pumps. By the time the engineers came in and told them to turn the
pumps back on it was too late. Although, it could have been worse if
delayed longer.  But it wouldn't have happened at all if the operators
hadn't turned off the emergency cooling pumps.  Moral: Just because you
can operate something, and know _how_ to make changes, doesn't mean you
know what changes are safe or wise to make.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 16:51:01 -0400 (EDT)

--Dean

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 May 2004 23:40:54 +0200

> 	check the 17th & 18th meeting minutes.

Result:

Unicast: A, E, H, L
Anycast: B, C, D, F, G, I, J, K, M (now or planned)

The thing that worries me is that apparently, there is no policy about 
this whatsoever, the root operators each get to decide what they want 
to do. The fact that .org is run using only two anycast addresses also 
indicates that apparently the ICANN doesn't feel the need to throw 
their weight around in this area.

Now obviously anycasting is a very useful mechanism to reduce latency 
and increase capacity and robustness. However, these properties are 
best served by careful design rather than organic growth. If we 
consider the number of actual servers/server clusters and the number of 
root IP addresses as given, there are still many ways to skin this cat. 
One would be using 12 unicast servers and anycast just one address. 
However, this only creates partial benefits, especially with regard to 
robustness in the presence of denial of service attacks. But at the 
other extreme, 13 unicast addresses, there are problems as well. For 
instance, if a network enjoys good local/regional connectivity, it may 
very well see the anycast instances for all roots behind some common 
infrastructure. When this piece of infrastructure fails, it may take 
considerable time before BGP converges and mean root reachability 
reaches acceptable levels again.

It seems to me that any design that makes the root addresses seem as 
distributed around the net as possible would be optimal, as in this 
case the changes of an outage triggering rerouting of a large number of 
root addresses is as small as possible. In order to do this, the number 
of root addresses that are available within a geographic region (where 
"region" < RIR region) should be limited.

(Just having the roots close is of little value: good recursive servers 
hone in to the one with the lowest RTT anyway, so having one close by 
is enough. However, when this one fails it's important that after the 
timeout, the next root address that the recursive server tries is 
highly likely to be reachable, in order to avoid stacking timeout upon 
timeout. A couple 100 ms extra round trip delay doesn't mean much in 
cases where the recursive server suffers a timeout anyway.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 May 2004 23:48:44 +0200

> S2.  Neither S1 nor S2 will have a complete TCP connection, and so both

As I've said before, this isn't how things work in practice, as actual 
load sharing towards a destination over two different AS paths doesn't 
happen, and when load sharing is done, it's almost always in a way that 
keeps packets belonging to a single TCP session together. (You really 
don't want to see what happens to TCP performance with 100% out of 
order packets.)

And even if this happened it would very likely be non-fatal, as at some 
point retransmissions will make it trough so the TCP session works. As 
most data is going from the server to the client, and ACKs work 
cumulative, the performance hit is probably not too catastrophic.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 May 2004 23:40:54 +0200

Result:

Unicast: A, E, H, L

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 May 2004 00:03:53 +0200

On 17-mei-04, at 22:51, Dean Anderson wrote:

> Moral: Just because you

Hm, maybe we should get some of the people who wrote the most popular 
DNS software to run some root servers?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 May 2004 00:03:53 +0200

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 19:16:32 -0400 (EDT)

On Mon, 17 May 2004, Iljitsch van Beijnum wrote:

> > It is conceptually very simple:  Setup 2 anycast servers (S1 and S2)
> > on several paths (AS-A and AS-Y, different AS numbers)  Have an ISP
> > connect to both of those paths, and then have that ISP do fine grained
> > load balancing to prefixes available over those paths. Packets will go
> > to each anycast server.  This will not cause a problem with UDP, since
> > the entire connection transaction is in one packet. But TCP will have
> > a minumim of 3 packets.  2 packets will go to server S1, and one
> > packet will go to server S2.  Neither S1 nor S2 will have a complete
> > TCP connection, and so both will fail.
> 

You are describing Cisco load balancing. The cisco behavior is due to the
effects of its route cache, which uses cache flow data to keep flows
together (but only when cef is turned on). This is not a feature of its
BGP handling, but a "feature" of its packet routing engine. Cisco is not
the only router vendor, and certainly not the only one interested in
fine-grained load balancing.  Most people interested in load balancing
consider this cisco behavior undesirable, and leaving a lot to be desired.

Also, as long as the out-of-sequence packets arrive within the window
frame, there is no degradation in performance (this is one benefit of
segment windows), even if they are 100% non-sequential. I think you are
referring to some pathological out of order cases: If the frame were to
get full before the next-up packet were received (ie complete reverse
order), then there would be a problem. But just because every *pair* or so
of packets arrives out of order doesn't mean there will be any degradation
in performance. That would still be 100% out of order, but not
pathologically so.

> cumulative, the performance hit is probably not too catastrophic.

Possibly.  Or you might just get a RST from the other server. I think
retransmissions just makes the problem intermittent, and slow, and consume
more connection resources on the nameserver(s).

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 19:16:32 -0400 (EDT)

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 19:45:02 -0400 (EDT)

On Tue, 18 May 2004, Iljitsch van Beijnum wrote:

> > Moral: Just because you can operate something, and know _how_ to make
> > changes, doesn't mean you know what changes are safe or wise to make.
> 

Hmm. Good suggestion.  But maybe first we should find some small group of
people that can write software that *complies* with DNS standards, (as
this tends to suggest that they understand the standards) and not go off
implementing rash, unnecessary, and gratuitous variations (ie BIND 9 AXFR,
IXFR non-compliance), and then try to have the protocol documents
gratuitously changed to make their implemenation conformant and make a
number of other implementations non-conformant, but only long after
they've released the non-compliant software into production and written
books describing their non-compliant software as though it were standards
compliant.  Second, while Bind is the most popular nameserver, it has
spurred the most efforts at reimplementation. I can think of very few
other projects that so many people desperately need, but don't want to be
a part of.  I was also part of the namedroppers list back in the late
80's/early 90's, and contributed Bind patches back then, but found it so
difficult to work with that I didn't want to bother for 10 years. Now, I 
can't avoid it.

Also, that group (if we are thinking of the same group) of people didn't
actually _write_ the software, they are just maintaining it, and have made
some modifications to it, and have applied modifications made by others,
and have even made modifications to the protocol after discussing those
modifications with many others.  But along the way they've added a great
deal of security vulnerabilities, too.  It is not that I mean to say they
are stupid, but that their unilateral judgement can't be trusted.

So, how to tell the operators from the engineers, and how to tell the
engineers from the maintenance engineers.  How to keep the bad judgements
of one person or a small group of people from affecting the whole world
internet?? Tough one, I admit.  Could posing questions to a protocol list
at sensible junctures suffice? Say, junctures where proposed operational
modifications affecting the protocols are discussed and vetted first?  
Nah.  That's asking too much.

But seriously, their attitude of "they know better than others" is their
first (but not only) mistake. 

So, I'm also just wondering, where was this operational change discussed
before it was implemented? Anywhere? Because the first I heard of it was
November '02.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 17 May 2004 19:45:02 -0400 (EDT)

--Dean

---

From: Bill Manning <[email-masked]>
Date: Mon, 17 May 2004 18:08:55 -0700 (PDT)

% 
% On 17-mei-04, at 17:41, Bill Manning wrote:
% 
% > % But as long as we're dissing anycast root DNS servers: how many of 
% > the
% > % root servers are being anycast now or in the future, and how many
% > % won't?
% 
% > 	http://www.rssac.org/
% 
% > 	check the 17th & 18th meeting minutes.
% 
% Result:
% 
% Unicast: A, E, H, L
% Anycast: B, C, D, F, G, I, J, K, M (now or planned)

	And in this brave new world, anycast may not equal anycast... :)
	Consider VRRP.  Is that anycast?  If not, why not?
	Any instance of localised load-balancing. Is it anycast?
	What are the distinctions btwn local/remote loadbalancing?

	None (to my knowledge) of the roots have a consistant view of
	a shared anycast vision, so you should not read too much into
	the summaries found in the RSSAC notes.
	
% The thing that worries me is that apparently, there is no policy about 
% this whatsoever, the root operators each get to decide what they want 
% to do. The fact that .org is run using only two anycast addresses also 
% indicates that apparently the ICANN doesn't feel the need to throw 
% their weight around in this area.

	ICANN has no say in the matter, with the exception of "L".
	There is nothing binding the root operators to a single policy
	with regard to deployment.  But thanks for noticing. :)

% It seems to me that any design that makes the root addresses seem as 
% distributed around the net as possible would be optimal, as in this 
% case the changes of an outage triggering rerouting of a large number of 
% root addresses is as small as possible. In order to do this, the number 
% of root addresses that are available within a geographic region (where 
% "region" < RIR region) should be limited.

	Er... geography != network topology.

--bill

---

From: Bill Manning <[email-masked]>
Date: Mon, 17 May 2004 18:08:55 -0700 (PDT)

% 

	

--bill

---

From: Paul Vixie <[email-masked]>
Date: 18 May 2004 00:16:49 +0000

[email-masked] (Iljitsch van Beijnum) writes:

> to do.

The table is round.  Policies are discussed as a group but set individually.
The result is a service which has never been "down hard", not ever, not for
any millisecond out of the last 15 years.  This is "strength by diversity."

> The fact that .org is run using only two anycast addresses also indicates
> that apparently the ICANN doesn't feel the need to throw their weight
> around in this area.

Apparently you have your facts wrong about how much sway ICANN had about
the anycasting of .ORG, but those details aren't mine, let others speak.

> best served by careful design rather than organic growth.

Careful design by whom?  Organic compared to what?  I assure you that f-root
has grown by careful design.  It's only organic in that we go where we're
invited rather than having a gigantic budget that could be used as a leash.

Check out <http://www.isc.org/ops/f-root/> and the list of mirror sites, and
look for some sponsors you know, and call them, and ask why they sponsored
f-root and whether they're happy about it.  Then find someone in that region
and ask them to do "dig @192.5.5.241 hostname.bind chaos txt" and tell you
whether they're talking to a local f-root.  What could scale better, or
allocate resources more efficiently?  (Central planning didn't help USSR.)

> If we consider the number of actual servers/server clusters and the
> number of root IP addresses as given, there are still many ways to skin
> this cat.  One would be using 12 unicast servers and anycast just one
> address.

Who is "we", though?  That's always the excluded middle of this debate.  I
know who I am -- a root operator.  But who are "we"?  And which of the
million different answers to "who are 'we'?" would you like to see govern
the choice of "who gets to decide how this stuff ought to work?"  E.g., I'm
sure, without even having heard it, that you wouldn't want the choice of
"who decides?" governed by Dean Anderson's answer to "who are 'we'?"

> "region" < RIR region) should be limited.

In counterpoint, it seems to me that any unified design will make the system
subject to monoculture attacks or ISO-L9 capture, and that the current 
system which you call "unplanned and organic" (but which is actually just
"diversity by credo") yields a stronger system overall.

> cases where the recursive server suffers a timeout anyway.)

What would help overall DNS robustness would be if more DNS clients used
recursion, and cached what they heard (both positive and negative).  A
frightfully large (and growing) segment of the client population always
walks from the top down (I guess these are worms or viruses or whatever)
and another growing/frightful segment asks the same question hundreds of
times a minute and doesn't seem to care whether the response is positive or
negative, only that it has to arrive so that the (lockstepped) next (same)
query can be sent.

If you'd like to unify something, perhaps it could be DNS client behaviour
and network-owner recursive caching forwarder design.  And while you're at
it, please outlaw those fiendish DNS-based load balancers.  f-root should
still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums,
and the 500X load 10 years later is due to client stupidity, not population
growth or backbone speed increases.
-- 
Paul Vixie

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 May 2004 14:58:17 +0200

On Tue, 2004-05-18 at 02:16, Paul Vixie wrote:

<SNIP>

> growth or backbone speed increases.

Paul, and other rootserveroperators (good scrabble word :), what would
your answer/problem/arguments/... be if an ISP would decide to inject
routes to the root-servers into their local network and point these
request to a local dns cache(s), which would have the correct routes to
the the global rootservers of course.

It is of course kind of hijacking the connectivity what is happening
here. And might this be an idea for a BCP for ISP's?

Or another thought that have been raised recently on the 6bone list:
Would it be an idea to have 2+ independent globaly routable prefixes,
thus in IPv4 2x at least /24 and in IPv6 2x /32 which are allowed to be
anycasted by anyone, just like the 6to4 stuff currently. So that ISP's
could point these prefixes to their local dns caches, similar to the
above but: documented which prefixes those are and no evil hijacking.
This could also allow for DNS-client to have hardcoded addresses of
these caching DNS prefixes lightening the load on the root servers as
with anycast you will always get an answer from the closest one, if all
is well and murphy is on his day off of course ;)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 May 2004 14:58:17 +0200

<SNIP>

Greets,
 Jeroen

---

From: Joe Baptista <[email-masked]>
Date: Tue, 18 May 2004 12:55:31 -0400 (EDT)

> growth or backbone speed increases.

Not completely due to client stupidity,

http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/

it is however a factor :)

regards
joe baptista

---

From: Joe Baptista <[email-masked]>
Date: Tue, 18 May 2004 12:55:31 -0400 (EDT)

regards
joe baptista

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 May 2004 19:30:15 +0200

> it is however a factor :)

If you would have even read the CAIDA article you would know why AS112
has been built and that misconfigured _clients_ perform the queries.
Also if clients would be using local ISP supplied DNS caches, that would
be correctly configured there would be a lot less of a problem.

Adding your .god/satan and whatever tld you are trying to advertise
won't help at all with the fact that clients are trying to get the
RFC1918 and other reverses from the root servers which simply do not
exist. That the register even took the article just tells something
about their quality, having over 70% advertisement in a 'article'...

FYI read up on:
http://www.as112.net
http://www.chagreslabs.net/jmbrown/research/drafts/draft-brown-pvtipdns-01.html

And the current CAIDA work at:
http://www.caida.org/projects/dns-analysis/

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 May 2004 19:30:15 +0200

FYI read up on:
http://www.as112.net

Greets,
 Jeroen

---

From: jfcm <[email-masked]>
Date: Tue, 18 May 2004 18:01:05 +0200

Dear Paul,
pardon me for the previous response. I could not resist!
This post of yours is a very important one as it expresses, from experience 
and in IETF wording, what I try to convey from another origin, experience, 
modelization, architectural logic and culture.

>any millisecond out of the last 15 years.  This is "strength by diversity."

This is exactly what French and now Eurospeak call "concertation". The very 
basis of the emerging European Constitutional culture based upon 
subsidiarity and granularity. Another less confusing word for English 
speakers, less related to French specific thinking, and corresponding to 
the level of the concerned issue is "intergovernance".

>invited rather than having a gigantic budget that could be used as a leash.

This is what we call subisdiarity. To actively (helping when needed) 
respect the responsibilities of those depending on (not from) you. I am 
sure that as F-Root Manager you do not mess within your mirror sites 
management, but are always ready to help on need.

>allocate resources more efficiently?  (Central planning didn't help USSR.)

Right. The only problem "we" (myself to start with, but also several Gov 
such as Brazil, India, China, etc. etc. as expressed at WSIS and many many 
others) have is that if Root servers are not centraly planned, they 
broadcast the same centraly planed and edited file. Also that this central 
editing imposes constraints due to the 13 limitation. Apart from the 
political issue, this makes that file and the a-root a world economy, life, 
security, single points of failure. This is something that the "we" quoted 
above do not accept.

>"who decides?" governed by Dean Anderson's answer to "who are 'we'?"

There is a very good response to that. RFC 883. It says "we" are the users, 
in saying that no one will be forced to use DNS data he did not chose. It 
seems a realistic simple way to make the table totally round (or at least 
rounder): if no one ask for more than the today situation, it is OK. If 
some ask for more, let them do it. ICANN ICP-3 gives pretty good and 
reasonable rules about their experimentation and implementation constraints.

>"diversity by credo") yields a stronger system overall.

Here is where I disagree: with the "core value" reading (cf. IETF 
description draft by Harald). You are right about what you say. But this is 
not to be a creed. This is to be architectural efficiency. This is pure 
cybernetics - cynernetics as the technical science of autonomous systems 
(where mathematics are for abstract systems and physics for inert systems). 
This would probably permit you to agree with Dean on a conceivable common 
framework where his concerns and your preriquisites would be addressed.

>growth or backbone speed increases.

You are damned right! This is exactly what we try to build right now with 
the AFRAC project (the DNS root is _not_ the only one concerned, both as a 
root reference and in the way it is used or can be denied service). We are 
concerned by DNS, adressing, etc. data, but also by geosocietal and defense 
information: every information and source code necessary for tier and tier 
applications (everyone interoperating)

1. first target: distribution of the root machines through a root server 
matrix and core network - containing local root information to make it a 
need. Decrease of the pressure, risk containement, new data, new services.

2. second target : a user MITM providing "hardware, software and brainware 
firewalling". At root system level it means that the user is to cache his 
root system. The reason why he will do it is that his root system will 
_not_ be the default public root system. It will be his own version of it, 
adding his local, private space management and views. Once set-up, calling 
on the root system would actually pollute his root system, so he will not 
do it.

Private roots are not subject to DoS. They certainly permit to survive a 
few hours, days and even probably months. In adding all the root themes we 
can objectively consider today for ubiquist new services, plus a "first 
necessity" software kit and root, we are probably talking of an ASN.1 
structure of less than 20 compacted K (comparable to anti-virus updates).

The figures I discussed in a previous memo, show that we could then come 
back to a "486DX2". However discussing of root server the way we consider 
them today would be quite meaningless.

jfc

PS. I do not consider here the problem of the loggers which is another 
(mainly legal) issue.

---

From: jfcm <[email-masked]>
Date: Tue, 18 May 2004 18:01:05 +0200

Dear Paul,

jfc

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 18 May 2004 21:34:26 +0200

--On Tuesday, May 18, 2004 18:01:05 +0200 jfcm <[email-masked]> wrote:

> matrix and core network - 

Yes, this is already done. It works, even if it is not top-guided as you
envision.

> containing local root information to make it a

This is unnecessary and prone to failure. 

> 2. second target : a user MITM providing "hardware, software and
> brainware firewalling". At root system level it means that the user is to
> cache his root system. 

Which part of the present caching resolve server does not provide this
service today? Aren't you reinventing the wheel here? 

> few hours, days and even probably months. In adding all the root themes
> we can objectively consider today for ubiquist new services, plus a
> "first necessity" software kit and root, we are probably talking of an
> ASN.1 structure of less than 20 compacted K (comparable to anti-virus
> updates).

Private roots are subject to confusion, mis-directed micromanagement by
local admins, overly sensitive to local politics, split-vision of what must
by design be unified, and endless user frustration. I have tried this in a
large corporate network, and it was, even there with a clear chain of
command, a horrible mess. Never, ever again will I take anything like it
outside a lab (except to kill it).

> them today would be quite meaningless.

You have a strong passion for doing something to fix the DNS system. I
suggest you channel this passion towards trying to fix all the b0rkened
clients (cf. the studies of root server load refered to earlier here)
before you try to impose breakage onto the well-functioning root server
system. 

-- 
Måns Nilsson                    MN1334-RIPE
http://vvv.besserwisser.org     +46 706 81 72 04

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 18 May 2004 21:34:26 +0200

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 May 2004 00:09:25 +0200

> 	the summaries found in the RSSAC notes.

Which is exactly the problem.

> 	Er... geography != network topology.

So people keep telling me...

In reality, geography is a decent predictor of round trip time, 
although the relationship isn't a simple linear one. (Ie, I can predict 
that I'll have an RTT of around 250 ms to most Japanese destinations 
and around 150 ms to most Californian destinations, even though I'm 
closer to Japan than to California.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 May 2004 00:17:39 +0200

> any millisecond out of the last 15 years.  This is "strength by 

I applaud diversity. The point of my message was that it would be 
harmful if all root servers would all act alike and therefore suffer 
from the same unreachability problems seen from a certain place in the 
net if there is an outage.

However, diversity and lack of policy aren't the same thing. If the 
root operators didn't communicate, it would be possible for all of them 
to select the same DNS server software. That would be a bad thing. The 
anycast issue is similar.

> the anycasting of .ORG, but those details aren't mine, let others 

I find this peculiar as ICANN imposes a heavy set of requirements on 
people who want new TLDs, why can't they do the same for existing ones? 
(This is a rhetorical question.)

> Careful design by whom?

Anyone.

> Organic compared to what?

Compared to purposeful design.

> I assure you that f-root has grown by careful design.

I know the root operators are very responsible people and do a great 
job.

However, I'm not convinced that 13 great parts automatically make a 
great whole.

> Who is "we", though?  That's always the excluded middle of this debate.

I didn't have a specific "we" in mind, but let's make it the internet 
engineering community. I'm not saying we should make these decisions 
during the IETF plenary (or on this mailinglist for that matter) but I 
do believe someone has to do something. The strength of the IETF is 
that its results generally reflect the collective wisdom and support of 
the participants. (The weakness that many great things that don't have 
this support don't get done, but that's another issue.)

> "diversity by credo") yields a stronger system overall.

I was only talking about a design for root anycasting. I'm sorry if 
this wasn't clear.

>> timeout.

> recursion,

This is certainly true, but I find it unfortunate that you skip over my 
point. It's easy to claim 100% uptime when sitting 10 meters from a 
server, but it's what real users see that counts. From that viewpoint, 
the root servers have certainly experienced service level degredations 
in the past 15 years. Good anycast design rather than just let it 
happen can minimize this in the future.

> and cached what they heard (both positive and negative).  A

I feel your pain, but unfortunately the IETF isn't in the position to 
do anything against bad protocol implementations, even the ones that 
aren't part of software that's illegal in most jurisdictions in the 
first place.

Still, this problem once again proves my point that we really need a 
mechanism that allows receivers to stop malicious traffic from reaching 
them.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 May 2004 00:17:39 +0200

Anyone.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 May 2004 18:54:49 -0400 (EDT)

> any millisecond out of the last 15 years.  This is "strength by diversity."

This isn't quite true. There have been multiple server failures. And if I
recall, I think that there have been quite a few servers (like 12 of 13)  
that have been down at one time in this timeframe.

But I haven't been keeping close track.  If someone has been keeping
operational stats (like outage date, cause, postmortem) on the roots, I'd
appreciate a pointer to this...

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 May 2004 19:03:52 -0400 (EDT)

> invited rather than having a gigantic budget that could be used as a leash.

Do you mean "Careful Design" like the non-standard changes in Bind 9 AXFR
and IXFR?  I don't think we can take too much of that sort of thing in the
operation of the root servers before we have serious problems.

Unilateral action is not a good thing. There is no point in having an IETF
(Remember the "Internet __Engineering__ Task Force" in IETF) if you just
implement whatever you think OK at the moment (AXFR mods, IXFR mods,
Anycast, and probably more that we just don't yet know about)

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 18 May 2004 19:03:52 -0400 (EDT)

--Dean

---

From: jfcm <[email-masked]>
Date: Wed, 19 May 2004 01:38:21 +0200

Dear Måns,
your points would be well taken if we were talking of the same thing (you 
will note that I was very carefull quoting ICP-3). When was the last time 
IETF discussed the way to respond ICANN's ICP-3 call? (what I am try 
doing). There is a resulting difference of perspective.

- I talk of real world when you talk of the current (unsecure and 
overloaded?) implementation of the current DNS architecture.
- I do not want to fix the DNS, I want to free me from it: it was not 
designed to support the current load and it is not managed in a way the 
Govs will ultimately accept. So, trying to patch the broken current usage 
to make it work as before is of no real interest. At least IMHO. [I have a 
user' side point of view].

The problem we face is an old and too large unique system with a robust yet 
overloaded engine. With all the problems which come with it. We have to 
split the zones of usage and risks. Either it is planned by IETF or it is 
done by the users. I suggest it is done together.

The novelty of Titanic were waterproof compartiment. Yet she sunk. The 
world has an unique DNS zone today.

Let me review the points where we fully agree and how.

>Yes, this is already done. It works, even if it is not top-guided as you

I do not envision it as top guided. What we plan is a service of a few 
separate machines, collecting the national root matrix data (meaning: all 
what is national and above) and concerting towards a unique version, among 
themsleves and with other national equivalent agencies. (NB. this concerns 
DNS among many other real time distributed mutually managed directories).

Let take an example, there is a unique time in nature. Yet there are many 
reference clocks in the world, and that does not work badly.

Then the agreed file will be made available to 10 to 250 regional master 
root severs (one by local business area - probably paid by cities - to 
support the addition of the local data),. We do not think DNS control and 
machine power, we think surety, security, stablity, distributed servicing. 
Ultimately this means probably a national coverage of 1000 machines  With 
the same global and national data.

> > containing local root information to make it a need. Decrease of the 
> pressure, risk containement, new data, new services.

Right. But this is as unnecessary as liberty.
Prone to failure? OK, but failure on what ? Today the big failure is that 
we are not free to chose and to develop. The system is not RFC 883 
compliant. I cannot chose my data. The root system is not IETF core value 
compliant, decision is not on the edges.

Anyway, you can chose the directory system you want. If you do not like it 
you do not use it. The only rule is (well worded in ICP-3) not to pollute 
others' space. The DNS root is a 15 K (compressed) file you can update 
every three months without losing access (but for some ccTLD like mine 
because ICANN does not want to enter a third/forth secondary) and RIPE does 
not want to respond ...

>service today? Aren't you reinventing the wheel here?

:-) We do not speak of the same thing here. You only refer to the 15 K root 
file and to the 20 years old way to use the internet.

If you want people to change their poor habits, you can only propose them 
better ways for you as part of better services to them. Cache is of no use 
for them, it is of use for you. Let clarify what you want, and what they 
want. Let not just continue an old solution because you did not think of 
something new and better.

You want to reduce the calls to your system, right? Let stop the "cache" 
idea which is something of _your_ system ibn theirs, and propose them an 
update of _their_ system - like anti-virus updates (ever heard that 
anti-virus run huge 50x1G systems? And let discover what a user system can 
bring more to its user owner. So when the user has started using and 
enjoying _his_ system, you will obtain what you want.

>local admins, overly sensitive to local politics, split-vision of what 
>must by design be unified, and endless user frustration. I have tried this 
>in a large corporate network, and it was, even there with a clear chain of 
>outside a lab (except to kill it)

We are not talking of the same thing. You talk of a system where you have 
admins. Bloody centralization :-) Are you asking GWB everytime you want to 
call a friend on the phone ? This is what some people do on the DNS and we 
want them to stop. Calling on the rrot is like calling an operator. Do you 
do it often ? I is not the nightmare of creating, training and managing an 
Operator Corp with local branches.

How many times a year do you call an operator ? How many times a year do 
you think you really need to update your root file?

>before you try to impose breakage onto the well-functioning root server

I am sorry. But I have a strong passion for restoring the name space the 
way we created it and the way the users need it, as par of the many tools 
and services necessary to support networked interoperations. The DNS 
concept is good and can partly do it, if it is not centralized. The root 
server load is purely an architectural illness. That illness is due to the 
fear of pullution.  For years IETF and ICANN saw the question as "do we 
want to risk pollution or do we want to risk critics from civil rights and 
from open roots opponents?"

The question today is "do we want to risk a total collapse of he network 
and a forced quick and disorganized innovation or to eventually accept that 
innovation is necessary and to smoothly work towards it", according to 
ICP-3 which calls on IETF fro experimentation ? Again IETF does not 
respond. Fixing the broken architecture is the only way to fix the broken 
clients - unless you get a cop behind every user (and it will not work 
because there will be too many cops plus too many clients).

Take care.
jfc

---

From: jfcm <[email-masked]>
Date: Wed, 19 May 2004 01:38:21 +0200

Dear Måns,

Take care.
jfc

---

From: Joe Baptista <[email-masked]>
Date: Tue, 18 May 2004 21:09:34 -0400 (EDT)

> appreciate a pointer to this...

Outage reports and an outage archives maintained by the legacy root
operators would be nice.

I also rmember many incidents over the years involving root server outages
- but it's never official.  usually someone discovers a problem and
sometimes a root operator responds.  Usually in NANOG.

cheers
joe baptista

---

From: Joe Baptista <[email-masked]>
Date: Tue, 18 May 2004 21:09:34 -0400 (EDT)

cheers
joe baptista

---

From: grenville armitage <[email-masked]>
Date: Wed, 19 May 2004 11:33:35 +1000

> > that have been down at one time in this timeframe.

I have fond memories of a time when list participants knew the difference
between a _service_ and a _server_

gja

---

From: grenville armitage <[email-masked]>
Date: Wed, 19 May 2004 11:33:35 +1000

gja

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 19 May 2004 09:02:24 +0200

--On Wednesday, May 19, 2004 01:38:21 +0200 jfcm <[email-masked]> wrote:

> Dear Måns,
> your points would be well taken if we were talking of the same thing 

We talk about the scalability and stability of a global name-to-number
system. Between us lies some disagreement on how this should be achieved;
that is all. 

>> > 1. first target: distribution of the root machines through a root
>> > server matrix and core network -
> what is national and above) and concerting towards a unique version,
> among themsleves and with other national equivalent agencies. (NB. this
> concerns DNS among many other real time distributed mutually managed
> directories).

This can be done with caching. You essentially propose a system where two
things are done:

* Remove the centralism needed for speedy updates. Right now, a new root 
  zone including delegation data can be made available within 48hrs, 
  including purge of the old one. 

* Initiate a government-to-government negotiation procedure. I see only 
  delay and intervening politics here. Remember -- this is not the length
  of the Meter or the UTC we are talking about, it is names! Names that do
  to peoples irrational brains what flags and marching music used to do in
  the nation-states of the early 20th century. 

> machine power, we think surety, security, stablity, distributed
> servicing. Ultimately this means probably a national coverage of 1000
> machines  With the same global and national data.
 
How does this differ from the current anycast developments? I see, for the
anycast cases where I have spoken to root admins, that local economies
effectively sponsor an instance of one or more of the root servers, and all
is well. If the prefix is just locally announced, one gets
compartmentisation should this be desired. 

> compliant, decision is not on the edges.

You can choose to run another root zone. You may mix this data with the
global version, but doing any of those is an invitation to pain (and your
email address will end up in /dev/null (a.k.a. loonybox) in a lot of
peoples email systems. The DNS system was designed (much like E.164) to be
The One system. Any attempts to break that are painful. 
 
> Anyway, you can chose the directory system you want. If you do not like
> it you do not use it. 

Correct. 
 
>> > brainware firewalling". At root system level it means that the user is
>> > to cache his root system.
>> 
> :-) We do not speak of the same thing here. You only refer to the 15 K
> root file and to the 20 years old way to use the internet.
> 
> better ways for you as part of better services to them. Cache is of no
> use for them, it is of use for you. Let clarify what you want, and what
> they want. Let not just continue an old solution because you did not
> think of something new and better.

I, on the contrary, argue that cache is good. It is a carefully balanced
engineering compromise between distributed and centralised load. Again,
instead of fixing what works (albeit with a bit too much load to be
comfortable.) I suggest fixing the cases where caching is not used, ie. 
broken resolvers and clients. 

> anti-virus run huge 50x1G systems? And let discover what a user system
> can bring more to its user owner. So when the user has started using and
>> > Private roots are not subject to DoS. They certainly permit to survive
>> > a few hours, days and even probably months. In adding all the root
>> > themes we can objectively consider today for ubiquist new services,
>> > plus a "first necessity" software kit and root, we are probably
>> > talking of an ASN.1 structure of less than 20 compacted K (comparable
>> > to anti-virus updates).
>> 
>> must by design be unified, and endless user frustration. I have tried
>> this  in a large corporate network, and it was, even there with a clear
>> chain of  command, a horrible mess. Never, ever again will I take
>> anything like it  outside a lab (except to kill it)
> 
> admins. Bloody centralization :-) 

I have yet to see a computerised information service that does not need
maintenance by competent staff. 

> Are you asking GWB everytime you want
> to call a friend on the phone ? 

No, the ITU. Pest or Cholera? 

> This is what some people do on the DNS
> and we want them to stop. Calling on the rrot is like calling an
> operator. Do you do it often ? I is not the nightmare of creating,
> training and managing an Operator Corp with local branches.

You are utterly confused. One thing here is correct -- the brokenness of
certain clients and their associated malware. Let's fix that. Or have you
given up? The other thing is a synchronisation problem. That is *really*
hard; do believe me. 

> How many times a year do

Twice a day, if I remember correctly. Current serial on i (the "real" i in
Stockholm, if you happen to distrust anycast.) is 2004051801, suggesting
that it was updated yesterday. 

Even if every update does not contain new data, there must be, for business
reasons, a way to reasonably quickly propagate data, with very short notice.

> server load is purely an architectural illness. That illness is due to
> the fear of pullution.  For years IETF and ICANN saw the question as "do
> we want to risk pollution or do we want to risk critics from civil rights
> and from open roots opponents?"
> 
> and a forced quick and disorganized innovation or to eventually accept
> that innovation is necessary and to smoothly work towards it", according
> to ICP-3 which calls on IETF fro experimentation ? Again IETF does not
> respond. 

I am still very concerned about pollution. It cannot be avoided if central
control is abandoned. Period. 

Further, I think that the Internet community with the root server ops
leading the way have responded with innovation -- with anycast, supported
by traffic data, and research clearly showing where the problems are. The
problems are identified, but the solution proposed is not palatable to all
-- and cannot be. But I have strong confidence in the system, because I see
it work despite the horrifying load. And it has never, ever, been down.

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 19 May 2004 09:02:24 +0200

Correct.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 May 2004 18:56:54 +0000

> the the global rootservers of course.

if someone injects 192.5.5.241 (or any route which covers it) anywhere
that a dns client will see it whose owner has not explicitly agreed to
have their f-root service modified in this way, and then modifies the
service (which means does something with the queries other than forward
them to an ISC-owned server) then we would of course file a lawsuit of
some kind, even if it meant opening an ISC office in some new place in
order to have "standing."

> is well and murphy is on his day off of course ;)

as far as i know, this would have to be done by iana rather than by ietf,
and the risk/reward tradeoff is such that it's not likely to see daylight.
last time i heard it discussed, the final determination was "better the
evil that we already know."

AS112 uses unowned anycast and it works well, but then, if wrong answers
were sent back by an AS112 server, it wouldn't exactly hurt anybody.
root name service seems more sensitive, to my eye.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 May 2004 18:56:54 +0000

---

From: Joe Baptista <[email-masked]>
Date: Wed, 19 May 2004 09:28:29 -0400 (EDT)

> order to have "standing."

I suggest you check isp's in the asia pacific region.  Standard practice
in some cases to intercept all dns including root traffic.  So i'm sure F
is one of them.

regards
joe baptista

---

From: Joe Baptista <[email-masked]>
Date: Wed, 19 May 2004 09:28:29 -0400 (EDT)

regards
joe baptista

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 19 May 2004 18:05:13 +0200

> appreciate a pointer to this...

So although you don't know, you still like to claim that 12 out of 13 
have been down? That's quite a serious allegation. I'd like that have 
that proved or taken back.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 19 May 2004 18:12:58 +0200

> overloaded?) implementation of the current DNS architecture.

In what way overloaded? Do you have any pointers? Proof? Data?

> The problem we face is an old and too large unique system with a 
> robust yet overloaded engine. With all the problems which come with 
> it. We have to split the zones of usage and risks. Either it is 
> planned by IETF or it is done by the users. I suggest it is done 
> together.

Again, overloaded engine in what way?

> Then the agreed file

Agreed by whom?  In what way?

> You want to reduce the calls to your system, right? Let stop the 
> "cache" idea which is something of _your_ system ibn theirs, and 
> propose them an update of _their_ system - like anti-virus updates 
> (ever heard that anti-virus run huge 50x1G systems? And let discover 
> what a user system can bring more to its user owner. So when the user 
> has started using and enjoying _his_ system, you will obtain what you 
> want.

Why would I want to reduce the number of calls on my system? My system 
is doing just fine...

- - kurtis -

---

From: jfcm <[email-masked]>
Date: Wed, 19 May 2004 21:46:53 +0200

>In what way overloaded? Do you have any pointers? Proof? Data?

Dear Kurt Eric,
Let not play this, please. Either you think after careful personal study 
(or you believe) that the current system is the best solution the world 
needs, and that it only calls for some users to be more educated in using 
it - and we are on planets apart. This is fine with me, and the end of a 
non existing debate.

Or you think the DNS does not match the IETF "core values" in being 
centralized (I do not make that "core value" as described by Harald a 
creed, I think they are often outdated, but I fully agree they are a 
technical minimum). And, together with ICANN, you think IETF is the right 
place to respond ICANN's call for more (ICP-3). So you try to understand 
the problem and to imagine solutions. This is what we did. And I explain 
the solutions we are subsequently working on.

>Again, overloaded engine in what way?

I just report on our follow up on this premise. If you do not see it, I 
cannot help with details. Just with the alternative. Yu are the judge.

The DNS "engine" is made of all the root/name servers and resolvers.
- either you are satisfied with their present tools, organization, 
limitations and resulting service, then again I cannot discuss it.
- or you are not, and then the question is to know if your disatisfaction 
results from the used solution or from the way this solution is implemented.

IMO the problem is not with the solution (software) but with its 
architectural deployment and usage. This permits a smooth transition, using 
existing and proven building blocks and expertise. But I think that speed 
if the essence. One may also disagree.

>Agreed by whom?  In what way?

Let me elaborate quickly. The target is not to obtain a file which pleases 
anyone as today, but a file which reports on the TLD Managers entries. So, 
the point is not who does it but the number of identical independent 
results. What follows is for one single national service.

- National because of the legal and political aspects in many aspects (risk 
containment, sensitive information intelligence leaks, justice obligations, 
etc.).
- But subsidiarity applies to the regional, local, corporate, private 
granularities (I explained what this means in my first mail).
- this means that security and verification will probably repeated 20 to 50 
times accross the world. Once a day in each country could mean every hour 
for global issues such as the DNS (the protocol is the same for every root 
information [time, radio frequencies, weather, hospital situation, etc])

The process we retained is to have at least four different independent data 
collection processes (whatever the processes, starting with a simple 
duplication of the NTIA file in the case of the DNS legacy root). The 
reason for at least 4 is to have at a majority if needed, even if one is down.

There must be five conditions for the result to be accepted (there could be 
more?)
1. there must be no reported alarm (nominal situation) on our monitoring system
2. all the results must be identical
3. there must not be an abnormally large difference with preceding copy 
(variance max to be tuned from experience) - to allow reasonable updates if 
permitted.
4. visual review by the four collection managers is positive
5. there must be no significant (similar to 3) with other partenering root 
files on common part of the root matrix.

If these 5 conditions are not met there will be an investigation and 
concerted agreement to be reached among collection managers, or a "no go" 
and escalation to Execom and to BoD (or Gov). These conditions (or more) 
can be made legal and imposed before a State endorses a Root Service for 
its own use and for legal transactions.

There is a possible alternative: the decision of the Government in case of 
national vital crisis. The role of the collection managers will be to 
advise how to reduce pollution in such cases - this may call for 
international concertation [exemple: the "ambassador lounge" at ITU 
(telephone is real time, no 48 hours delay). A doctrine is to be set-up as 
part of Digital Warfare (US say Cybernetic Warfare). Experience in Mines, 
Electronic or Nuclear Warfares shows this is possible.

>Why would I want to reduce the number of calls on my system? My system  is 
>doing just fine...

What is your system ?

In the case discussed the problem is the current increasing load on current 
servers. That load and that type of calls are inappropriate. The 
architecture is to be changed (all the more than it permits DoS). Keeping 
daily updated files of much larger size than the root file is carried by 
many people around the world more efficiently, more securely and with less 
of constraints to innovative usages.

But again, the very nature of the DNS permits such transition to be 
transparent. So if you love the current architecture, it is OK with me. As 
long as you do not pollute what we do and we do not pollute what you do 
there is no problem. This discussion only concerns those (with ICANN ICP-3) 
who want to experiment and work on the resulting experience, towards a 
better response to the people and Gov demands.

I just describe what we have started working on, with scarce resources, 
along those lines for more than two years. And what we target from then on.
jfc

---

From: jfcm <[email-masked]>
Date: Wed, 19 May 2004 21:46:53 +0200

Dear Kurt Eric,

What is your system ?

---

From: Paul Vixie <[email-masked]>
Date: 19 May 2004 22:16:36 +0000

there are two things that i think it's important that everybody understand.

first, anyone who posts from roll accounts like "[email-masked] (jfcm)"
tends to be dismissed as a troll.

second, anyone who seriously uses the term "legacy DNS root" tends to be
dismissed as a loon.

i now return control of your television set to the loons and trolls...
-- 
Paul Vixie

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 20 May 2004 16:17:42 +0200

We must be talking about two different Internets.

- - kurtis -

On 2004-05-19, at 21.46, jfcm wrote:

> Let not play this, please. Either you think after careful personal 
> study (or you believe) that the current system is the best solution 
> the world needs, and that it only calls for some users to be more 
> educated in using it - and we are on planets apart. This is fine with 
> me, and the end of a non existing debate.
>
> technical minimum). And, together with ICANN, you think IETF is the 
> right place to respond ICANN's call for more (ICP-3). So you try to 
> understand the problem and to imagine solutions. This is what we did. 
> And I explain the solutions we are subsequently working on.
>
> I just report on our follow up on this premise. If you do not see it, 
> I cannot help with details. Just with the alternative. Yu are the 
> judge.
>
> - or you are not, and then the question is to know if your 
> disatisfaction results from the used solution or from the way this 
> solution is implemented.
>
> architectural deployment and usage. This permits a smooth transition, 
> using existing and proven building blocks and expertise. But I think 
> that speed if the essence. One may also disagree.
>
>> > Then the agreed file
> Let me elaborate quickly. The target is not to obtain a file which 
> pleases anyone as today, but a file which reports on the TLD Managers 
> entries. So, the point is not who does it but the number of identical 
> independent results. What follows is for one single national service.
>
> - National because of the legal and political aspects in many aspects 
> (risk containment, sensitive information intelligence leaks, justice 
> obligations, etc.).
> - this means that security and verification will probably repeated 20 
> to 50 times accross the world. Once a day in each country could mean 
> every hour for global issues such as the DNS (the protocol is the same 
> for every root information [time, radio frequencies, weather, hospital 
> situation, etc])
>
> The process we retained is to have at least four different independent 
> data collection processes (whatever the processes, starting with a 
> simple duplication of the NTIA file in the case of the DNS legacy 
> root). The reason for at least 4 is to have at a majority if needed, 
> even if one is down.
>
> There must be five conditions for the result to be accepted (there 
> could be more?)
> 3. there must not be an abnormally large difference with preceding 
> copy (variance max to be tuned from experience) - to allow reasonable 
> updates if permitted.
> 5. there must be no significant (similar to 3) with other partenering 
> root files on common part of the root matrix.
>
> concerted agreement to be reached among collection managers, or a "no 
> go" and escalation to Execom and to BoD (or Gov). These conditions (or 
> more) can be made legal and imposed before a State endorses a Root 
> Service for its own use and for legal transactions.
>
> There is a possible alternative: the decision of the Government in 
> case of national vital crisis. The role of the collection managers 
> will be to advise how to reduce pollution in such cases - this may 
> call for international concertation [exemple: the "ambassador lounge" 
> at ITU (telephone is real time, no 48 hours delay). A doctrine is to 
> be set-up as part of Digital Warfare (US say Cybernetic Warfare). 
> Experience in Mines, Electronic or Nuclear Warfares shows this is 
> possible.
>
>> Why would I want to reduce the number of calls on my system? My 
>> system  is doing just fine...
>
> What is your system ?
>
> In the case discussed the problem is the current increasing load on 
> current servers. That load and that type of calls are inappropriate. 
> The architecture is to be changed (all the more than it permits DoS). 
> Keeping daily updated files of much larger size than the root file is 
> carried by many people around the world more efficiently, more 
> securely and with less of constraints to innovative usages.
>
> transparent. So if you love the current architecture, it is OK with 
> me. As long as you do not pollute what we do and we do not pollute 
> what you do there is no problem. This discussion only concerns those 
> (with ICANN ICP-3) who want to experiment and work on the resulting 
> experience, towards a better response to the people and Gov demands.
>
> I just describe what we have started working on, with scarce 
> resources, along those lines for more than two years. And what we 
> target from then on.
> jfc
>
>

---

From: Paul Vixie <[email-masked]>
Date: 19 May 2004 22:16:36 +0000

---

From: jfcm <[email-masked]>
Date: Thu, 20 May 2004 23:12:14 +0200

>i now return control of your television set to the loons and trolls...

A part from documenting a root server manager mentality, I fail to see the 
use of such a mail.

1. I ran a seach of my IETF folder for "legacy DNS root". It only listed 
your mail....

I said "the NTIA file in the case of the DNS legacy root". In the context 
of responses to ICANN's ICP-3 call for DNS deployment R&D and 
experimentation (we work on this for two years now, while IETF did not even 
considered) it means: "in the case of the current root file system we use 
the current reference file". This is what you do twice a day, don't you?. 
Should your comment result from a Frenglish fault of mine, that you would 
be teasing, it would call for an immediate apology. Otherwise in my world 
one may disagree with others - in seriously documenting why - but one does 
not despise their work. Those who do that have a name.

2. Being arrogant does not make you wrong. [email-masked] was only a patch 
due to some past ietf mailing list problem. It lasted. I will resume using 
my regular mail name. Thx.
jfc

First they ignore you, then they laugh at you, then they fight you, then 
you win. Gandhi.

---

From: jfcm <[email-masked]>
Date: Thu, 20 May 2004 23:12:14 +0200