- Test - lists.nanog.org

Re: "Stale" root-server
by Paul Vixie 14 Mar '00

14 Mar '00

> Are there standards for operations of a root DNS server? Yes. RFC 2010 was written by two root name server operators. Another document, with broader authorship, is due to replace it soon. > I would think that checking and making sure that your zone files are > current would be either something you could do once a day or at the > minimum write a script to check the serial against the current date and > start yelping if it was too far out of date. That's not in RFC 2010, but it is something that NetSol does, and notifies the operator of any machine who falls behind in the way G currently has. (This is only fair, since NetSol's internet connectivity has been historically weak, and the usual cause of a root server being behind is that NetSol didn't have enough bandwidth to ship COM that day on top of everything else it does.) -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

1 0

"Stale" root-server
by Forrest W. Christian 14 Mar '00

14 Mar '00

I just came across the fact that one of the root servers (G) has a stale .com zone. (Serial number from 3/10). Of course, my primary DNS server seems to prefer G (or any other root server with a problem for that matter). I did call the number for the NOC listed and let's just say that although they said that "the responsible person would be notified" I got the impression that fixing the problem wasn't going to be on the top of their list and probably was going to wait till the next business day. I also was told that "They got a call like this friday" (which was the last day the data was synched. Are there standards for operations of a root DNS server? I would think that checking and making sure that your zone files are current would be either something you could do once a day or at the minimum write a script to check the serial against the current date and start yelping if it was too far out of date. If I was responsible for a root server, making sure it was up with the "correct" (quotes added thanks to our favorite registry/ies) data would be my top priority. - Forrest W. Christian (forrestc(a)imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

2 1

Filtering policies
by Timothy Brown 14 Mar '00

14 Mar '00

I apologize in advance if this subject has been regurgitated. I would imagine it has, but a quick search of NANOG archives reveals nothing. What is the "party line" among providers as regards to BGP route filtering? I have a customer with a /24 (grandfathered) who now seeks to multi-home. Is their /24 globally routable? There's no way they can justify anything less specific than a /22. Are there any other solutions? Regards, Tim -- Timothy | tim (at) tux (dot) org | 4FE3 6D8E 5F7A 61E9 27B9 | NSP/ISP/ASP Brown | Encrypted Mail Preferred | 9220 B6E5 F181 4A94 11C3 | Engineer

3 2

Re: "Stale" root-server
by Doug Barton 14 Mar '00

14 Mar '00

"Forrest W. Christian" wrote: > > I just came across the fact that one of the root servers (G) has a stale > .com zone. (Serial number from 3/10). Of course, my primary DNS server > seems to prefer G (or any other root server with a problem for that > matter). You can add the following to recent versions of BIND 8 to avoid this problem. server 192.112.36.4 { bogus yes; }; Yes, that begs the question of how this could be allowed to happen/continue/etc..... Enjoy, Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix"

1 0

Re: Hi, we're from the government and we're here to help
by Sean Donelan 14 Mar '00

14 Mar '00

On Fri, 10 March 2000, Patrick Greenwell wrote: > I believe this to be such a common communication protocol and procedures > for handling issues to be of great necessity and desireability. If 10% of > the vast number of people that have expressed their opinions on these > issues were each willing to put up a little money, we could solve this > problem once and for all. I used to work for a company which spent several hundred thousand dollars every year on memberships to various groups, and more money to send people to various meetings. My question always is when somone proposes forming yet another group, which groups should I drop my support so I can join your new group? If all the existing groups are broken, CERT, CIX, CNRI, FIRST, IETF, IOPS, NANOG, RIPE, etc, can any of them be fixed? Or is a new group the only option. In reality money isn't the biggest issue. I was naive once, and created a business plan for a new group. ISPs and VCs were willing to give me lots of money. The real problems were time, people and information. Companies are more than willing to join new groups, and add their logos to the membership page. But too often their engineers are told they are not allowed to contribute or acknowledge any issues or problems. All they can do is say "Here" when roll is called. I can start setting up the infrastructure tommorrow, but until something happens to permanently scare the heck out of the boards and stockholders, any new group will just be a shell.

3 2

San Jose Telephone Problems 3/10-3/17
by Sean Donelan 14 Mar '00

14 Mar '00

I'm sure this has absolutely nothing to do with me moving to the San Jose area :-) On friday a contractor cut four major Pacific Bell cables. About 11,000 circuits were affected. The affected area is roughly bordered by Interstate Highways 880 and 680 and Trimble and Berryessa roads. Pacific Bell estimates it won't have the cables repaired until Friday March 17. One cable I can understand. Two cables, ok you didn't realize the first strange noise was a cable. Three cables, accidents come in threes. Four cables?

1 0

San Jose Telephone Problems 3/10-3/17
by Sean Donelan 14 Mar '00

14 Mar '00

I'm sure this has absolutely nothing to do with me moving to the San Jose area :-) On friday a contractor cut four major Pacific Bell cables. About 11,000 circuits were affected. The affected area is roughly bordered by Interstate Highways 880 and 680 and Trimble and Berryessa roads. Pacific Bell estimates it won't have the cables repaired until Friday March 17. One cable I can understand. Two cables, ok you didn't realize the first strange noise was a cable. Three cables, accidents come in threes. Four cables?

1 0

Re: Alternative to BGP-4 for multihoming?
by Paul A Vixie 13 Mar '00

13 Mar '00

> The URL for ifdefault in your post didn't work... oops. ftp:// not http://. ftp://ftp.vix.com/pub/vixie/ifdefault/ works.

1 0

Alternative to BGP-4 for multihoming?
by Hank Nussbacher 13 Mar '00

13 Mar '00

Radware has a product called Linkproof and claims that it negates the need for BGP-4 and portable IP addresses: http://www.radware.com/product/lproof/Default.htm I have a customer that requires multihoming and they want to use Linkproof and I want them to do BGP-4. Does anyone have any experience using this as an alternative to BGP-4? Thanks, Hank

13 14

Re: Alternative to BGP-4 for multihoming?
by Vern Paxson 13 Mar '00

13 Mar '00

> TCP performance is affected by congestion symmetry, since TCP uses the > spacing of ACK packets to control the spacing of data packets. True, but this is a second order effect. The strongest effects are (1) loss rate on the forward path, and (2) bottleneck throughput on the forward path (these two being related). TCP is much more tolerant of lost acks than lost packets - you have to lose an entire flight of acks before it really kills you. So I suspect the match-the-outgoing-hop-with-the-incoming-hop approach is working better for some other reason. Perhaps it's reflecting that Web surfing is in fact bidirectional, and often not all that assymetrically (a small request fetches a small item). In that case, congestion symmetry will help, since both directions are forward paths at some point. Vern

1 0