October 2003 - Test - lists.nanog.org

Re: Need a DNS expert
by Andrew - Supernews 20 Oct '03

20 Oct '03

>>>>> "Geo" == Geo <georger(a)getinfo.net> writes: Geo> Got something really weird going on and I need a bit of help Geo> from someone who is really good with dns. Geo> Domain elby.ch Geo> seems to resolve from some DNS servers but not from others. Can Geo> you see anything that might break dns resolution for this Geo> domain? Yes, you've got _way_ too many levels of referrals before any glue records show up. The chain looks something like this: .ch servers return referral elby.ch -> ns{1,2}.elbyns.de with no glue. .de servers return referral elbyns.de -> ns{1,2}.aixns.de with no glue. .de servers return referral aixns.de -> ns0.ns0.de,ns2.ns2.de with no glue. .de servers return referral ns0.de/ns2.de -> ns*.denoc.de with glue. When I tried it with the squish.net dns checker (turn on "show resolving of referrals" to see the awful details of the referral chain) I got at least one query timeout, so the results were: 10.7% of queries will end in failure at 62.116.163.62 (ns2.ns2.de) - failed to resolve ns2.elbyns.de due to 62.116.163.62 - failed to resolve ns1.aixns.de due to 62.116.163.62 - query timed out 10.7% of queries will end in failure at 62.116.163.62 (ns2.ns2.de) - failed to resolve ns1.elbyns.de due to 62.116.163.62 - failed to resolve ns1.aixns.de due to 62.116.163.62 - query timed out 39.3% of queries will be returned by 62.116.130.76 (ns1.elbyns.de) elby.ch. 86400 IN A 213.130.59.30 39.3% of queries will be returned by 62.116.162.15 (ns2.elbyns.de) elby.ch. 86400 IN A 213.130.59.30 But the squish.net checker has no limit on referrals - many resolvers, especially older BIND, will just time out chasing the referrals unless it already has them cached. -- Andrew, Supernews

1 0

Re: Notice Periods
by Michael.Dillon＠radianz.com 20 Oct '03

20 Oct '03

>So -- how much notice would the operator community want before >deploying new software? What about for enterprises? (We all know that >stuff *can* be deployed more quickly in emergency circumstances. We >also know the problems that that can lead to, which is why we generally >want testing and controlled deployment.) >From the technical point of view, in order to provide proper design, technical review and testing prior to deployment, I would think that there should be a minimum of 3 months notice. >From the political point of view I agree with the person who said "after Verisign's contract expires". In other words, the notice should be given prior to contract renewal so that the action can be discussed as part of the contract renewal process. However, the actual deployment should not happen until at least 3 months after contract renewal to allow for technical activities. It is not appropriate to require network operators to take actions to adapt to a change that may or may not occur depending on some policy approval process. The two notice periods need to be decoupled so that the policy approval is done first and then the technical notice period begins. --Michael Dillon

1 0

Verislime NSI details
by David Lesher 20 Oct '03

20 Oct '03

FWIW: http://www.washingtonpost.com/wp-dyn/articles/A38293-2003Oct16.html .... VeriSign Inc. announced yesterday that it will sell Network Solutions, the Herndon-based registrar of Internet addresses, for $100 million in a deal that will allow VeriSign to retain exclusive control of the valuable .com and .net database. VeriSign, which acquired Network Solutions in 2000 for $15 billion in stock, said it agreed with Pivotal Private Equity, an Arizona-based investment firm, to sell the unit by the end of the year. VeriSign will keep a 15 percent stake. .... {Me thinks Verislime paid SAIC way too much....} -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1

Green peering stickers
by Dan Lockwood 20 Oct '03

20 Oct '03

Although I fail to have one of the stickers, if there is anyone at the meeting that is operating in the northern California area and would like to discuss peering please send me a message off-list. I'm interested to learn what other operations are in the area. Thanks! Dan Lockwood

3 3

Paging Jim McBurnett
by Dr. Jeffrey Race 20 Oct '03

20 Oct '03

On 13 Oct 2003 20:15:22 +0700, MAILER-DAEMON(a)asianet.co.th wrote: >Hi. This is the qmail-send program at asianet.co.th. >I'm afraid I wasn't able to deliver your message to the following addresses. >This is a permanent error; I've given up. Sorry it didn't work out. > ><jmcburnett(a)msmgmt.com>: I have mail for you (being bounced as above). Please advise me a fax # or better e-mail address Jeffrey Race

1 0

bad link to real stream
by Mark Radabaugh 19 Oct '03

19 Oct '03

http://www.nanog.org/mtg-0310/network.html has "To watch the meeting live, check the links on the main conference page. " - the link is bad. The real real feed is at ??? Mark Radabaugh Amplex (419) 720-3635

2 2

Use squid cache at NANOG29
by John Kristoff 19 Oct '03

19 Oct '03

NANOG29 attendees, Help make my SSH sessions more responsive, use the squid cache. :-) <http://www.nanog.org/squid.html> John

1 0

Upcoming change of source AS for i.root-servers.net
by Johan Ihren 19 Oct '03

19 Oct '03

Friends, As part of the long term ambition to provide the Internet root nameservers with extremely stable homes in all possible respects we plan to change the source autonomous system for i.root-servers.net from AS8674 (NETNOD INTERNET EXCHANGE) to AS29216 (dedicated as I.ROOT-SERVERS.NET) We hope that after this change i.root-servers.net will never have to change source AS again. We intend to implement this change next week during the NANOG29 conference. Please note: a) This is a planned operation, not an emergency. b) We will not change the IP adress of the i.root-servers.net service, only the source AS. c) We will not change any of the several servers providing the i.root-servers.net service in any way. It will be the same servers at the same locations providing exactly the same service as usual. Regards, Johan Ihrén Autonomica

1 0

Verio outage
by Alex Yuriev 19 Oct '03

19 Oct '03

There is a aparently a major outage in Verio-land between Boston and Baltiore, touch as far away as Pitts. Alex

1 0

Re: IAB concerns against permanent deployment of edge-based filtering
by bmanning＠karoshi.com 19 Oct '03

19 Oct '03

> On 18 okt 2003, at 23.28, bmanning(a)karoshi.com wrote: > > and if they are useful to the folks on my network, the ports > > will be opened up. > > This is where we are disagreeing. > > Remember: > > - The Robustness Principle: "Be conservative in what you do, be liberal > in what you accept from others." [Jon Postel, RFC 793] > - The Principle Of Least Astonishment: A program should always respond > in the way that is least likely to astonish the user. [Traditional, > original source unknown] yup. remember those. > Because of this, if not the overall explicit stated (by IETF) goal is > that filtering should NOT happen, it will happen. its happend for years and is implicitly allowed. > Yes, it is an ISP, regardless of transit or edge, which is responsible > for their network. thank you. > It is my belief that statements like this from the IAB will help, as > ISP's and customers of ISP's both can see what the IAB think the goal > of operations is. Customers can say "hey, IAB says this, why don't you > run your network that way". The ISP can then explain (and in some cases > it of course makes sense what the ISP say). Such a statement from the IAB might be construed improperly, in much the same way as you claim RFCs are "improperly" interpreted by various and sundry ISP/commercial folks. If I get a customer who says "hey, IAB says this, why don't you run your network that way" and my response will be someing along the lines "vendors bugs e.g. the cisco IOS attacks via chargen, daytime et.al. or Microsoft RCP weaknesses - FIRST/CERT/SANS recommendations to mitigate DDOS. We can have a working, productive network or we can have an IAB compliant network." Now its not the IAB's fault that implementations make local optimizations or overlook coding weaknesses. The IAB should provide a sound architectural framwork and direct the IESG/IETF to advance robust, well defined protocols done the standards track (they should also encourage publication and development of novel ideas, via experimental/informational RFCs, but that is another topic). However, in the absence of the network police, (you know, the interoperability squad) it is impossible for me to put a whole lot of credence on the IAB telling me that it would be best if I would ensure that filters are only transitory. Thats nearly the same a telling me that being healthy is good. That said, no filters are permenant, some just last longer than others, depending on when problems are fixed. Cast in a different light, let me ask you this, is it better to ship products with "security" turned off or turned on? > paf >

1 0