Mailing List Archive

> For those not at the last IEPG mtg, this was discussed with the trade off
> being 13 host routes vs coordinating root cache updates for 20-30 million
> end nodes.

Luckily, as Havard points out, this seems to work now. Don't folk have real
work to do?

randy
- - - - - - - - - - - - - - - - -

Let's also analyze the cost of wasting the remainder of /24s in this
special case. Much worse has happened.

> > For those not at the last IEPG mtg, this was discussed with the trade off
> > being 13 host routes vs coordinating root cache updates for 20-30 million
> > end nodes.
- - - - - - - - - - - - - - - - -

-> > For those not at the last IEPG mtg, this was discussed with the trade off
-> > being 13 host routes vs coordinating root cache updates for 20-30 million
-> > end nodes.
->
-> Luckily, as Havard points out, this seems to work now. Don't folk have real
-> work to do?
->

Unfortunately, this doesn't work now. Our name servers get tens of thousands
of hits a day for a former root, c.nyser.net, a machine that hasn't existed for
quite some time.

Scott...

***************************
Scott Stansbury
NYSERNet, Inc.
125 Elwood Davis Road
Syracuse, NY 13212-4311
315-453-2912 Ext. 253
scotts@nysernet.org
****************************
- - - - - - - - - - - - - - - - -

At 09:06 AM 9/9/96 -0400, Jon Zeeff wrote:
>
>Let's also analyze the cost of wasting the remainder of /24s in this
>special case. Much worse has happened.

It would be a bad precedent for IANA to be promoting such a waste of space
when they are promoting space conservation for everyone else. "Do as I say,
not as I do" is a bad policy.

Justin Newton
Internet Architect
Erol's Internet Services

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

Provider Based Aggregation Zealots:

I tend to agree with Karl D. on this matter. Maybe we should just
let the Zealot's of Aggregation continue to trespass into IP
address space territory and then just launch a legal assault.

Many of you must have nothing in life to do but continue to
promote a bad policy and try to manipulate those whom do
not agree. I highly suggest you stop before angering people
who have the financial means to launch a legal warning
counter strike.

We, of course, do not wish to promote a legal battle nor to
be counter-productive. What is important to remember, however,
is to understand that any attempt to encroach, tresspass,
dominate, re-engineer, the existing 'free-space' in /24 will
be a very unpleasant and difficult task.

Do everyone a favor on the network and 'move on to more productive'
tasks. Continuing in this 'dominate all IP address space' direction
by providers is not constructive.

Anyone on the list who can refer an attorney experiened in IP and
telecom, please feel free to refer them to me. I am happy to
continue the lead in opposition to 'complete submission' to
the provider based paradigm.

And I promise, it will not happen.

Best Regards,

Tim
- - - - - - - - - - - - - - - - -

In a previous message, Tim Bass wrote:
>
>
> Provider Based Aggregation Zealots:
>
[snip]
>
> Many of you must have nothing in life to do but continue to
> promote a bad policy and try to manipulate those whom do
> not agree. I highly suggest you stop before angering people
> who have the financial means to launch a legal warning
> counter strike.


I presume your arguments against heirarchical routing are available
for analysis by newcomers such as myself?

Like the guy in the oil filter ads says, "sooner or later, you'll
pay"....

--
David Carmean WB6YZM DC574 <dlc@silcom.com>
System/Network Administration, Silicon Beach Communications
Unsolicited commercial e-mail not accepted. Violators will be LARTed.
- - - - - - - - - - - - - - - - -

Date: Mon, 09 Sep 1996 10:42:02 -0400
From: Scott Stansbury <scotts@franklin.nysernet.ORG>
Message-ID: <199609091442.KAA20704@franklin.nysernet.ORG>

Unfortunately, this doesn't work now. Our name servers get tens of thousands
of hits a day for a former root, c.nyser.net, a machine that hasn't existed for
quite some time.

There's absolutely nothing you can do about those, they're the
result of old software with old configurations. Changing at the
end nodes is the only thing that will ever fix that problem.
Certainly changing the root nameserver addresses isn't going to
make any difference (unless you can somehow guarantee that none
of the old root addresses has any kind of nameserver sutting at it,
that at least would motivate the old end sites a little).

Given that the end nodes have to be updated to make things better,
it seems that the best solution is to motivate them to upgrade
the software (it isn't exactly a difficult task) so that the
problem of changing root addresses (and lots of others) mostly
goes away.

Magic stable root addresses isn't likely to be much of a long term
help, regardless of how well they can be propogated, or what kind
of message it sends wrt address & routing table slot conservation.
If anything, taht is likely to just encourage people to keep using
nameserver code that should have been retired years ago.

kre
- - - - - - - - - - - - - - - - -

folks is this appropriate for namedroppers list?

thanks
/jim
- - - - - - - - - - - - - - - - -

>
> Given that the end nodes have to be updated to make things better,
> it seems that the best solution is to motivate them to upgrade
> the software (it isn't exactly a difficult task) so that the
> problem of changing root addresses (and lots of others) mostly
> goes away.
>

One thing I noticed about the beta versions of Netscape that
was quite annoying at first: they expired. However, they
succeeded in forcing me to upgrade my software.

Has anyone thrown around the idea of having freeware servers expire
(or at least give you lots of warnings/errors). I'm not talking
about every 3 months like Netscape, but every couple of years.

I know this sounds dangerous from a production standpoint, but
having unpatched versions of sendmail x, etc around is also
dangerous. Nowadays, compromised security on another system often
forces one to track down denial of service attacks from that system.
You can always bandaid the problem (except
possibly with mail or ntp'ed systems) by changing the date on the
systems. And you can always make available "grandfathered" versions
that run after the expire date for those people that absolutely
have to run the old version. (or let the people change their own
source code)

Better yet, make it a compile time flag and let the people that
want a nonexpiring version change it. Most people use the default
on everything anyways (and those are the people that will never upgrade
or patch their software).



allan
allan@bellsouth.net
- - - - - - - - - - - - - - - - -

In message <3234ACE7.6B37@bellsouth.net> Allan Chong wrote:
>Has anyone thrown around the idea of having freeware servers expire

More apropos to this particular thread, how about having the
root cache file expire? Put an expiration date in as a fake
record in the file, and have bind warn (but probably *only*
warn) if the file is "out of date".

Bill
- - - - - - - - - - - - - - - - -

I wasn't going to answer this, but someone forwarded me yet another copy
(I got it on namedroppers and nanog and iepg, too) saying that they thought
this was a good idea. I don't, and I will explain the why of that below.

I would like to call y'all's attention to the fact that there is a huge
overlap between the nanog and iepg and namedroppers mailing list, and it
is unlikely in the extreme that this thread has been of value in all three
places. Therefore please note, respect, and emulate my "Reply-To:" header.

> More apropos to this particular thread, how about having the
> root cache file expire? Put an expiration date in as a fake
> record in the file, and have bind warn (but probably *only*
> warn) if the file is "out of date".

One more beer and I'd've said that the above was "just plain silly." Instead
I'll note that the age of a cache file isn't conclusive proof that it's bad.
We call it "out of date" but what we mean is that is that it's "wrong."

I will add, probably to BIND-4.9.5++ (which is looking more and more like it's
going to be called BIND-8.1, to get it into synch with Sendmail's versioning),
a feature such that when the startup bootstrapping happens, if the NS RRset
for "." retrieved from one of the servers in your root.cache file does not
match the NS RRset for "." in that root.cache file, BIND will complain.

This catches other forms of wrongness than just date differences, and I think
it will make the net a better place. Note that I will _not_ add a feature by
which the root.cache file is overwritten by data from the network, until and
unless we can do so under the DNSSEC umbrella.
- - - - - - - - - - - - - - - - -

Hi!

I haven't had time to read the messages, flames, sarcasm, etc.
on the strong stand and reaction to another rebirth of the ZOA
movement to control all old Class C ( now called /24 space ).

However, based on names like Vixie, and our difference in opinion
on this matter, and Paul's continued support of 'world IP address
space domination', I think I can guess what he is saying (or flaming)
without reading alll messages.

Instead of the term 'toxic waste dump' being applied to the historically
significant /24 space before provider based address domination.
I prefer the term:

IP Address Space of the Free Internet Citizens better know
as..........

THE NEUTRAL ZONE

Even the Romulans and the Federation have a Neutral Zone. I suggest
we learn from the brillant mind of Roddenbury and avoid trying
to dominate the 'neutral zone'.

Best Regards,

Tim

PS: I'm away from my linux children on travel for a few days and
will have to respond to the flamage on this controversial
subject in a delayed fashion. However, it is my hope that
the ZOAs find something more constructive to do besides
assault the neutral zone. Despite their rhetoric, they
will fail and their efforts will destablize the net.




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

Note the reply-to header, and please respect/emulate it.

tb> I haven't had time to read the messages, flames, sarcasm, etc.
tb> on the strong stand and reaction to another rebirth of the ZOA
tb> movement to control all old Class C ( now called /24 space ).

This explains why you are uninformed.

tb> However, based on names like Vixie, and our difference in opinion
tb> on this matter, and Paul's continued support of 'world IP address
tb> space domination', I think I can guess what he is saying (or flaming)
tb> without reading alll messages.

I think that you are wrong, severally. I don't like the idea of
proxy aggregation but I have said nothing about it on the current
thread. "Names like Vixie". Hmmm, I like that. I think I see a
new .signature quote somewhere in the above paragraph.

What Paul has offered his continued support for is ``world domain name
domination,'' not ``world IP address space domination.'' Tim, this is
not even half baked. I don't think you've even got an oven over there.

tb> THE NEUTRAL ZONE

Better known as THE TWILIGHT ZONE, actually, both because it's murky and
full of superstitious but interesting nonsense, and because we're seeing
the twilight of its once bright day. Tim, you called it significant, and
I agree except that I also think that the rotary dial telephone was quite
significant in its day -- and completely inappropriate on THIS day.

tb> PS: I'm away from my linux children on travel for a few days and
tb> will have to respond to the flamage on this controversial
tb> subject in a delayed fashion. However, it is my hope that
tb> the ZOAs find something more constructive to do besides
tb> assault the neutral zone. Despite their rhetoric, they
tb> will fail and their efforts will destablize the net.

There's no way to force someone to peer, or to carry your routes. If they
make the business decision that they can only carry N routes in their core,
and that they want the maximum possible number of endpoint addresses to be
represented by those N routes, then they will pick the N largest prefixes.

If you aren't in one of those, you may find yourself lacking connectivity.

You can whine and bitch and yes, even moan, but other people have business
decisions to make and the TWD is getting more and more expensive to keep.

Some of us are trying to find ways to shrink since it has a lot of stuff
that doesn't need to be represented by /24's -- either nets which could be
trivially renumbered into larger (sigh, yes, provider assigned) prefixes,
or stuff that could be aggregated with neighbors (as I did with my /23).

If we can make it shrink, then the value of N will not exceed the core
router capacities as it will otherwise shortly do. On the other hand Cisco
can probably cons up a 256MB router and people with worldwide networks can
afford to buy them, and if the business decision merits it, the money will
be spent and the TWD (or TNZ, or TTZ) will stop seeming like a problem.

I don't expect that last to happen, since a lot of allocated but previously
unadvertised networks are getting dusted off and put into use, and a lot
of the growth we're seeing isn't from new NIC allocations at all. This means
the TWD is potentially much larger than it seems today, and some kind of
route filters in 192-space are probably coming soon to a provider near you.

Meanwhile maybe you and Karl D. should finish that router he was talking
about a while back, that represented a full IPv4 of /32's as a bitmap or
whatever it was. If you build it, folks will buy it, and you'll be a hero.

A whacky hero, sort of like the Scarlet Pumpernickel, but a hero anyway.
- - - - - - - - - - - - - - - - -

> In message <3234ACE7.6B37@bellsouth.net> Allan Chong wrote:
> >Has anyone thrown around the idea of having freeware servers expire
>
> More apropos to this particular thread, how about having the
> root cache file expire? Put an expiration date in as a fake
> record in the file, and have bind warn (but probably *only*
> warn) if the file is "out of date".
>
> Bill
>
Anyone actually looked at the behaviour of the following line in
a modern bind?

stub . 198.41.0.4 128.9.0.107 192.33.4.12 128.8.10.90 192.203.230.10 192.5.5.241 192.112.36.4 128.63.2.53 192.36.148.17 CACHE/root

This will build the equivalent of "cache . CACHE/root" and keep
it up to date. The only think that isn't there is a check that
the address list given is current.

It also puts the root server configuration details with the rest
of the configuration details.

Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 9325 3148 INTERNET: marka@syd.dms.csiro.au
MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka
- - - - - - - - - - - - - - - - -

>
> I would like to call y'all's attention to the fact that there is a huge
> overlap between the nanog and iepg and namedroppers mailing list, and it
> is unlikely in the extreme that this thread has been of value in all three
> places. Therefore please note, respect, and emulate my "Reply-To:" header.

Honored, and respected.

> > More apropos to this particular thread, how about having the
> > root cache file expire? Put an expiration date in as a fake
> > record in the file, and have bind warn (but probably *only*
> > warn) if the file is "out of date".
>
> One more beer and I'd've said that the above was "just plain silly." Instead
> I'll note that the age of a cache file isn't conclusive proof that it's bad.
> We call it "out of date" but what we mean is that is that it's "wrong."

But is there any *harm* in re-fetching a new copy when the old one is
"out of date"--not wrong, simply "out of date". I think that's the
real thrust of this debate; what is the safest technique to use to
make sure 90% of the client named's have at least reasonably up-to-date
information. I know I'd be happier on my DNS servers to know that
the daemon itself was fetching a new copy of named.cache on a
periodic basis, perhaps once every three months, especially if it
was using something similar to a zone transfer, with consistency
checking to make sure the data that arrived matched the data that
was sent.

I'm sure it's a pipe dream, but I'd like to think it's
a reasonable one.

> I will add, probably to BIND-4.9.5++ (which is looking more and more like it's
> going to be called BIND-8.1, to get it into synch with Sendmail's versioning),
> a feature such that when the startup bootstrapping happens, if the NS RRset
> for "." retrieved from one of the servers in your root.cache file does not
> match the NS RRset for "." in that root.cache file, BIND will complain.

Er, don't you mean BIND-8.8?? If you're running sendmail-8.1, maybe
you need _your_ version to expire. :-)

> This catches other forms of wrongness than just date differences, and I think
> it will make the net a better place. Note that I will _not_ add a feature by
> which the root.cache file is overwritten by data from the network, until and
> unless we can do so under the DNSSEC umbrella.

Can you have it fetch the different, possibly newer version, and
save it as a temp file, and mail root with the location of the
temp file, and request to review, and possibly install it? I
don't necessarily condone blindly overwriting named.cache, but
fetching a temp copy under a named-cache-datestamp filename
would help considerably... :-) But then again, I guess I'm
a bit lazy that way.

Thanks for considering this!

Matt Petach
mpetach@netflight.com


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