March 2000 - Test - lists.nanog.org

Re: Alternative to BGP-4 for multihoming?
by Patrick Evans 14 Mar '00

14 Mar '00

On Tue, 14 Mar 2000, Pete Templin wrote: > On Tue, 14 Mar 2000, Marc Slemko wrote: > > > Saying "the clients's primary DNS" is misleading. There is no way to know > > what the "primary" DNS server is for a zone, and there may not even be > > what is typically known as a primary. > > What if it's a UUNet resold modem to a client of iAmerica - what server > gets used then? We know that UUNet's DNS servers are likely to not be > located close (in net terms) to the client, and how do we know what DNS > servers are being assigned to the client? > User's machine contacts caching nameserver x to do a lookup. Nameserver x contacts authoritative nameserver y, which then works out where x is before returning an RR that's good for wherever x is. If n isn't net.near to the user's machine, then something's a bit weird. If part of a dialup ISP's internal network falls over, you hardly want every single user's resolvers to fail! > Or what if my clients get assigned dns servers in 192.168.254/24? Sounds > to me like it's not a valid geographic identifier. > I'd hope that nameserver would talk to the world with a real source address, which y would then use to do a proximity test, rather than a 1918 address - at least it should if it actually wants to get a response. What address the client-side interface uses is neither here nor there. -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre

1 0

Re: Alternative to BGP-4 for multihoming?
by Randy Bush 14 Mar '00

14 Mar '00

> Once the client's DNS request has worked its way over to the primary DNS > for the distributed web-servers, 3DNS has each of the other 3DNS boxes > (located adjacent to the other distributed servers) ping the *clients* > primary DNS. 3DNS then returns the URL for the web-server whose 3DNS > machine is 'closest' (fewest hops) to the clients DNS machine. you may want to seriously reread the previous sender's message. the point is that in the modern post-2182 world, many of the client's nameservers are vastly net.distant from the client. psg.com nameserver = DNS.LIBRARY.UCLA.EDU psg.com nameserver = RAIN.PSG.COM psg.com nameserver = ARIZONA.EDU it is best common practice. randy

3 2

Re: Alternative to BGP-4 for multihoming?
by brandon＠rd.bbc.co.uk 14 Mar '00

14 Mar '00

> you may want to seriously reread the previous sender's message. the point > is that in the modern post-2182 world, many of the client's nameservers are > vastly net.distant from the client. > > psg.com nameserver = DNS.LIBRARY.UCLA.EDU > psg.com nameserver = RAIN.PSG.COM > psg.com nameserver = ARIZONA.EDU sure but which one are they most likely to be using for their resolver (in firewalled environments it may be none of those)? Lots will use one fairly local to them for resolution and that could be the one making the request of the hosting providors server (assumptions about which ones would recurse etc.). There will always be a few that use one a continent away but nobody is expecting 100% on this are they? brandon

3 2

Re: Alternative to BGP-4 for multihoming?
by Joe Loiacono 14 Mar '00

14 Mar '00

> >Checking the path to my DNS servers tells you NOTHING about the >path to my hosts. Right. But your situation is not the one being looked at, as you don't have geograpically distributed web servers. I believe for that situation 3DNS, et. al., can work. Once the client's DNS request has worked its way over to the primary DNS for the distributed web-servers, 3DNS has each of the other 3DNS boxes (located adjacent to the other distributed servers) ping the *clients* primary DNS. 3DNS then returns the URL for the web-server whose 3DNS machine is 'closest' (fewest hops) to the clients DNS machine. Thus, for example, clients in Asia can get to a server in Asia. I think that's the gist of it, if not the specifics... Joe Joe Loiacono Phone: (301) 794-2509 Computer Sciences Corporation Fax: (301) 794-9480

1 0

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 13 Mar '00

13 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