Subject: anycast

From: Randy Bush <[email-masked]>
Date: Tue, 22 Oct 2002 11:50:43 -0700

smb made what seems like a good suggestion for how to prudently
deploy anycast root and gtld servers prior to dnssec deployment.

an isp runs one or more anycast slaves for root and/or gtld servers
within their autonomous system and filters out other announcements
of that address at their border.  just plain don't let it into your
igp.  think of it as a degenerate case of the massey nanog paper.

the question then becomes how to acquire an authentic copy of the
root and gtld zone files on a regular basis.  this may be as much
of a layer nine pain as a layer four one.

randy

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Oct 2002 16:47:31 -0700

>> the question then becomes how to acquire an authentic copy of
>> the root and gtld zone files on a regular basis.  this may be as
>> much of a layer nine pain as a layer four one.
> Zone transfer via your real IP address to either the hidden
> master, or B, C, or F.  IIRC, all three of the latter servers are
> wide open to AXFR for all the zones they host.

their choice of practice aside, i think we would want to be a bit
more cooperative and constructive about this.

randy

---

From: Brad Knowles <[email-masked]>
Date: Wed, 23 Oct 2002 01:44:25 +0200

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Wed, 23 Oct 2002 01:56:49 +0200

>of a layer nine pain as a layer four one.

project http://dot-root.com does not plan to be fully ready for a few weeks.

If we could be of help we would certainly be happy to support this.
We have tested for more than 18 months to get the root file updated.

We would need help in getting gTLD zone files: our purpose is to be purely 
experiemental but one of the root is to serve as a reference and a support 
for ccTLDs and Govs and is to a strict copy of the ICANN data (it currently 
supports the corect IPs for all the German, Autrian and Greek Name severs).

jfc

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/02

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Oct 2002 00:31:29 -0700

Root server anycast as it exists today has the benefit that the people
advertising the address are the people who are supposed to advertise the
address.  In theory, at least, there is an origin AS associated with the
root IP address that can and should be locked down.

You are proposing to destroy that relationship.  On purpose.

Maybe it's just me, but this seems like a really bad idea.  Might seem like
a good idea to folks in authoritarian governments who want to muck about
with the contents of the zone though.

Not sure how anyone would classify this as "prudent".

Rgds,
-drc
--------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Oct 2002 11:03:37 +0300 (EEST)

> with the contents of the zone though.

Having almost all of your customers' DNS lookups take 10 ms instead of 100
or 200 ms may also be of some value.

Definitely seems interesting to me, even though issues with keeping data 
up-to-date are of critical importance here.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Oct 2002 01:19:37 -0700

> or 200 ms may also be of some value.

This isn't how the DNS works.  See Sean Donelan's comments on the data CAIDA
has collected.  It would improve performance for the first querier at a site
(or some level of aggregation, depends on the caching infrastructure, of
course) every 8 days or so.

> up-to-date are of critical importance here.

There is nothing stopping any ISP from doing what Randy suggested today,
particularly given several of the root servers allow zone transfer.
Similarly, there is nothing stopping any ISP from advertising addresses for
(say) Google and making sure only government approved pages are returned.

To borrow a term from Mr. Bush, it would be "prudent" to wait for DNSSEC
signing of the root before going down the "pretend to be a root server"
road.

Rgds,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 23 Oct 2002 10:42:54 +0200

> of a layer nine pain as a layer four one.

Root zone is simple: 

-rw-r--r--   1 9998     213         14348 Oct 22 21:12 root.zone.gz
-rw-r--r--   1 9998     213            75 Oct 22 21:38 root.zone.gz.md5
-rw-r--r--   1 9998     213            72 Oct 22 21:38 root.zone.gz.sig

are available for ftp. The signature would be easily verified, had the key
been easy to find. I had to look for some time to find it... 

Layer nine is always unpredictable; though. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 23 Oct 2002 10:34:55 +0200

>  project http://dot-root.com does not plan to be fully ready for a few weeks.

	I have looked through a good portion of the site so far 
(including the charter, etc...), and it is still not clear to me just 
what exactly this group is proposing that they will do.  Clearly, a 
lot of work has been done to put this together, but this is not being 
communicated effectively to the casual observer.

>  We have tested for more than 18 months to get the root file updated.

	Meaning?

>  We would need help in getting gTLD zone files: our purpose is to
>  be purely experiemental but one of the root is to serve as a reference
>  and a support for ccTLDs and Govs and is to a strict copy of the ICANN
>  data (it currently supports the corect IPs for all the German, Autrian
>  and Greek Name severs).

	Many of the ccTLD zones are openly available for zone transfer. 
As of the last time I checked, of the 256 total known TLDs (not 
including the root zone) the following 163 TLDs (and the root zone) 
were available from at least one server:

		ac ad al am an ao ar arpa as au aw az ba bd bg bj bm bn
		bo bs bt bv bw by ci ck cl cm cr cu cv cy cz dj dz ec edu
		ee eg er es fi fj fm ga gb gd ge gg gh gi gl gm gn gov gp
		gs gt gu gw gy hn hr ht hu id ie il im in int io ir is je
		jo ke kg kh ki km kn kz lb lc lk lr ly ma mc mg mh mk ml
		mm mn mq mr ms mt museum mv mw my mz nc ne ng ni np pa pe
		pg pk pl pro pw py qa ro ru sa se sg sh si sj sk sl sm sn
		so st su sv sz tc tf th tj tm tn to tp tr tt tv tz ua ug
		uk um uy ve vg vi vn vu ye yu za zm zw

	I would encourage you to get a copy of the root zone from B, C, 
or F, and then try to do zone transfers from all the advertised 
servers for each TLD.  I went about it a slightly harder way -- I 
reconstructed the root zone from information publicly available 
elsewhere, and then got copies of all of the above.

	Note that I am going to be addressing this topic in my invited 
talk at LISA 2002.

---

From: Johan Ihren <[email-masked]>
Date: 23 Oct 2002 12:16:59 +0200

Måns Nilsson <[email-masked]> writes:

Måns,

> are available for ftp. The signature would be easily verified, had
> the key been easy to find. I had to look for some time to find it...

That's not the important issue. 

The real issue as I see it is, exactly as drc put it, "proposing to
destroy [the relation between an origin AS and the root prefix]. On
purpose".

Johan

---

From: Jim Reid <[email-masked]>
Date: Wed, 23 Oct 2002 04:37:18 -0700

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> Having almost all of your customers' DNS lookups take 10 ms
    Pekka> instead of 100 or 200 ms may also be of some value.

Unlikely. There are very few situations where DNS latency *really*
matters. The occassional lookup to a root server -- which is all a
well behaved name server should need to do -- is not one of them. You
seem to be overlooking the fact that name servers cache. The first
lookup of some name could take 200ms (or more) but subsequent lookups
of that name will be answered from the server's cache for the RR's TTL
value which is probably measured in hours or days. Against that
background, the sort of nano-optimisation you appear to be advocating
is pointless. Why care about shaving 100ms or so off *one* DNS lookup
out of thousands or millions of lookups? What is the justification for
engineering an "optimal" solution for just that one lookup?
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Oct 2002 15:03:12 +0300 (EEST)

> engineering an "optimal" solution for just that one lookup?

I believe the discussion was also about those servers possibly having 
ccTLD and gTLD data.

Imagine a situation where you could get every xxx.yyy name without going 
outside of your AS?

For the first lookup in the root servers, the opmization is .. "premature" 
to quote D. Knuth.. :-)

---

From: Peter Koch <[email-masked]>
Date: Wed, 23 Oct 2002 14:22:48 +0200

> (say) Google and making sure only government approved pages are returned.

this includes ISPs being advised by local or regional authorities to implement
such or similar optimizations. Unfortunately this is too far away from fiction
to be called paranoia.

> signing of the root before going down the "pretend to be a root server"

I'd like to second that. There are various proposals for "alternative"
or "optimized" root server groups/systems which do or do not add additional
TLDs or which "only perform better" in that they provide "accurate" information
compared to the official root zone's content (where some operational changes
currently suffer from interesting delays).

While you can't stop them and probably do not even need to, I'd rather not see
any such approaches endorsed by an IETF working group. I still believe RFC 2826
is a good thing.

-Peter

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Oct 2002 06:56:17 -0700

A correction.

I mis-remembered the comment (posted to NANOG) from Sean Donelan I
referenced.  Specifically, Sean said:

> DNS clients "need" to communicate with root servers infrequently.
> CAIDA (http://www.caida.org/projects/dns-analysis/) data measurements
> show an average (50th-percentile) DNS client contacts the root name
> servers less than 8 times in a week.

8 times a week is a bit different than once every eight days, ne?  Apologies
for any confusion.  However, I still stand behind the underlying concept --
the way DNS works makes this sort of optimization superfluous.

> I believe the discussion was also about those servers possibly having

I'm not aware of the discussion -- all I saw was Randy Bush posting a bad
idea, purportedly coming from Steve Bellovin.  Sounds like further
machinations by the "DNS Cabal"(tm) (:-) if it is necessary).

> Imagine a situation where you could get every xxx.yyy name without going

All things being equal, I'd agree that this sort of decentralization is
good.  Unfortunately, all things aren't equal -- there is currently no way
to determine if the root data returned is "corrupted".  When there is a way
(e.g., when the root zone is DNSSEC signed), I'd think it'd be a good idea
to hold off encouraging people from pretending to own address space they
don't have a right to.

Note that this is different than what some of the root servers are currently
doing wrt anycast.  Those root servers are announcing the address space they
have been delegated from their AS.

Rgds,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 23 Oct 2002 16:27:18 +0200

> That's not the important issue.

Oh. I understand. And stand corrected. My solution was too simple.. ;-)

> destroy [the relation between an origin AS and the root prefix]. On

"...Unless it is substituted by another form of trust, ie. dnssec"?

Or am I oversimplifying again?

+46 70 681 7204         KTHNOC
                        MN1334-RIPE

---

From: Jim Reid <[email-masked]>
Date: Wed, 23 Oct 2002 08:07:24 -0700

>>  Unlikely. There are very few situations where DNS latency
    >> *really* matters. The occassional lookup to a root server --
    >> which is all a well behaved name server should need to do -- is
    >> not one of them. You seem to be overlooking the fact that name
    >> servers cache. The first lookup of some name could take 200ms
    >> (or more) but subsequent lookups of that name will be answered
    >> from the server's cache for the RR's TTL value which is
    >> probably measured in hours or days. Against that background,
    >> the sort of nano-optimisation you appear to be advocating is
    >> pointless. Why care about shaving 100ms or so off *one* DNS
    >> lookup out of thousands or millions of lookups? What is the
    >> justification for engineering an "optimal" solution for just
    >> that one lookup?

    Pekka> I believe the discussion was also about those servers
    Pekka> possibly having ccTLD and gTLD data.

News to me. But even so, what I said *still* holds. It applies equally
well to the TLD servers and zones as the DNS root.

    Pekka> Imagine a situation where you could get every xxx.yyy name
    Pekka> without going outside of your AS?

This is how things were done on the old ARPAnet before DNS was
invented. The HOSTS.TXT file did not scale. Have you any evidence to
show how such a scheme -- whether implemented with name servers or not
-- would work better today? Would anyone notice, let alone care about,
any performance improvement? [For one lookup out of many thousands
remember.] Oh, and I'd like to see your solution for getting the ~2Gb
of .com or ~1Gb of .de propagated to name servers on every AS in a
reasonably timely manner. Hey, and why stop at xxx.yyy name lookups
per AS? Why not have every stub resolver host these zones itself? :-)

I'm not convinced that even if we discount DNS caching, there is much
to be gained wrt DNS latency by having a name server for "important"
zones -- for some definition of important -- inside every AS. [It may
be better for other reasons, like compartmentalising the crap from
broken clients or making DDoS attacks against the infrastructure for
these zones a lot harder.] Most important zones are served or should
be served by name servers at good internet exchanges. So all you'd
maybe save is the overhead of sending a packet out from your AS,
across the Gigabyte Ethernet or whatever at the IX to the important
name server and back again. This might even be a shorter and quicker
path than routing the packets to/from the hypothetical LAN segment at
the same IX where my AS has its critical name servers for those
important zones.
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: "John M. Brown" <[email-masked]>
Date: Wed, 23 Oct 2002 11:04:03 -0600

Having your customers get proper and valid data, seems more 
important than the query time.  Queries to the Root servers
should be a "rareish" thing as your local servers should be
caching those results.

So if it takes me 100ms to get a reply from a root, I won't
be asking it again for that data for quite some time, eg
hours, days, etc.

john brown
le geek

> 
> Having almost all of your customers' DNS lookups take 10 ms 
> instead of 100 or 200 ms may also be of some value.
>

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Thu, 24 Oct 2002 14:40:07 +0200

At 10:34 23/10/02, Brad Knowles wrote:
> what exactly this group is proposing that they will do.  Clearly, a lot 
> of work has been done to put this together, but this is not being 

I thank you for this comment. We are at organization phase until the year 
end. I proposed our cooperation since this is the kind of support we want 
to provide. Our target is to only to offer a turrn-key comprhensive test 
bed (machines, support, test users, test name spaces, monitors, etc.) to 
DNS related experiments and international name space related efforts. We 
want to be neutral to the carried studies a part from the operational 
aspects of having parallel roots systems collecting data in parallel, 
mutually monitoring their operations and offering compartive test results.

We would certianly appreciate every help to better present and develop the 
project: it is open to everyone.

>>  We have tested for more than 18 months to get the root file updated.

making the idea progress. Testing stability and learning to trust each 
other. Developping tools for automatic root generation. Having monitoring 
program tested. No big things but which take time.

>Many of the ccTLD zones are openly available for zone transfer. As of the 
>last time I checked, of the 256 total known TLDs (not including the root 
>zone) the following 163 TLDs (and the root zone) were available from at 
>least one server:
>

Thank you for this precious information in maintaining our IANA table.

>I would encourage you to get a copy of the root zone from B, C, or F, and 
>then try to do zone transfers from all the advertised servers for each 
>TLD.  I went about it a slightly harder way -- I reconstructed the root 
>zone from information publicly available elsewhere, and then got copies of 
>all of the above.

Did you find discrepancies with the internic ftp file?

>Note that I am going to be addressing this topic in my invited talk at 
>LISA 2002.

Where is that?
Are you in Brussels? I plan being there on Nov 22 for a presentation at the 
Haute Ecole?
Regards.
jfc

---

From: Brad Knowles <[email-masked]>
Date: Fri, 25 Oct 2002 02:39:37 +0200

At 2:40 PM +0200 2002/10/24, J-F C. (Jefsey)  Morfin wrote:

>  I thank you for this comment. We are at organization phase until
>  the year end. I proposed our cooperation since this is the kind of
>  support we want to provide. Our target is to only to offer a
>  turrn-key comprhensive test bed (machines, support, test users,
>  test name spaces, monitors, etc.) to DNS related experiments and
>  international name space related efforts. We want to be neutral to
>  the carried studies a part from the operational aspects of having
>  parallel roots systems collecting data in parallel, mutually
>  monitoring their operations and offering compartive test results.

	Interesting.  Have you talked to the folks at ISC, Nominum, Men & 
Mice, Stiching NLnet, and ISDN?  I think each of these groups might 
be interested in such an organization.

>  Did you find discrepancies with the internic ftp file?

	Actually, I didn't think to check.  I will do that before my talk.

>>Note that I am going to be addressing this topic in my invited talk
>>  at LISA 2002.
>
>  Where is that?

	LISA 2002 is in Philadelphia Pennsylvania (US) this year.  If you 
can't make it there, I am currently discussing the possibility of 
bringing this same presentation to RIPE in January (with some 
additional testing results).

	I'll also be at BSDCon Europe 2002, the week after LISA.

>  Are you in Brussels? I plan being there on Nov 22 for a presentation
>  at the Haute Ecole?

	I do live in Brussels, but I work for a Dutch consulting company, 
and I am currently spending four hours a day, four days a week, 
driving up to a customer site near Eindhoven.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 25 Oct 2002 13:20:14 +0200

At 2:39 AM +0200 2002/10/25, Brad Knowles wrote:

>  	Interesting.  Have you talked to the folks at ISC, Nominum, Men
>  & Mice, Stiching NLnet, and ISDN?  I think each of these groups
>  might be interested in such an organization.

	Oops, sorry.  I meant SIDN (the folks who run .nl), not ISDN.  Sigh....