-> > 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 ****************************
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
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.
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
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
participants (8)
-
Allan Chong -
Bill Fenner -
Mark Andrews -
Matthew Petach -
Paul A Vixie -
Robert Elz -
Scott Stansbury -
Tim Bass