- NANOG - lists.nanog.org

Re: Follow-up to "ROOT SERVERS"
by Sean Donelan 25 Aug '00

25 Aug '00

Thank you for an excellent report on BIND's issues handling zone files under these circumstances, even though Chris Clough described the problem as a minor hiccup invisible to end users. Now other name server operators have the opportunity to review their own practices in case they have a similar problem, and keep an eye out for updates from Nominum.

2 1

Re: Follow-up to "ROOT SERVERS"
by Kai Schlichting 25 Aug '00

25 Aug '00

At Friday 10:24 AM 8/25/00, "Verd, Brad" <bverd(a)netsol.com> wrote: >NSI is modifying the current zone generation process to eliminate the >existing small interval during which the com zone database file is not >present on this nameserver. Until then, NSI is manually querying the root >zone to ensure no delegations have been automatically dropped. > It's unbelievable how people cling to inadequate solutions that no longer serve their needs adequately. Why are we still relying on the zone AXFR mechanism with plain, unauthenticated TCP transfers going to or from IP host that could temporarily be located in outer Mongolia (no offense) if one decides to use BGP announcements as a temporary "relocator"? Strategically such relocation would happen minutes before such zone transfers start. There is a small number of zones that are too important to go missing, corrupted or hijacked: Why are these all-important zones not transferred via a secure (and likely freely available) mechanism like SCP (part of ssh) using RSA authentication? Why isn't the same done for a checksum file for each zone, which is then compared to the transferred file, with DNS servers only reloading the zone on a SIGHUP once the authenticity and correctness of the zone has been confirmed? The number of parameters to verify correctness should be in the single digits: approximate length of zone(s), serial #, presence of zone(s), SOA info, other cursory checks. Anything missing? Pages should be blasted out to key people within seconds, and the server detecting the fault should hold "status quo" until it either solves the problem itself, or receives manual help. All of this takes at most a few hours to implement : whip up a bunch of Perl scripts (throw in a few weeks of beta testing!), it won't work less reliable than what we have right now, apparently : I have done similar secure shuttling of files for applications in the financial industry where correctness and prevention of loss in transport was everything, but timing came right after. That software is still in use today, with (as I believe) virtually no maintenance or bugfixes applied in the last 2 years, and what could have been 10KB of code, became about 50 as interaction with an NT server was required...

1 0

Reminder - NANOG proposal deadline
by Susan R. Harris 25 Aug '00

25 Aug '00

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 20 * * October 22 - 24, 2000 * * * * * * * * * * * * * * * * * The North American Network Operators Group (NANOG) will hold its 20th meeting in Washington, D.C., between October 22 - 24, 2000. The meeting will be hosted by AOL. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. NANOG meetings, held three times each year, include two days of short presentations, plus afternoon/evening tutorial sessions. Meetings are informal, with an emphasis on relevance to current backbone engineering practices. The conference draws around 500 participants, mainly consisting of engineering staff from large national service providers, and members of the research and education community. Now in its fifth year, NANOG evolved from the NSFNET "regional-techs" meetings, where technical staff from the regional networks met to discuss operational issues of common concern. With the emergence of the commercial Internet, NANOG meetings evolved to include a broader base of providers, network operators, and researchers. The meeting will be held at the Renaissance Washington DC Hotel. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Coordination of inter-provider QoS - Deployment experience with queueing disciplines (CAR, RED) - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Reports from next-generation networks (Internet2, CA*net, etc.) - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - BGP case studies - MPLS fundamentals - External route selection - IP multicast technologies - Distributed content caching in large IP networks ------------------------------------------------------------------------------ HOW TO PRESENT Submit an informal one- or two-paragraph abstract describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is September 11, 2000. While the majority of speaking slots will be filled by September 11, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by September 25, 2000. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ------------------------------------------------------------------------------

1 0

Re: Community NO-EXPORT
by Danny McPherson 25 Aug '00

25 Aug '00

No, BGP synchronization does indeed refer to the requirement that the destination network be available via the IGP. If it were just the BGP NEXT_HOP value it wouldn't be of much use, as intermediate nodes perform forwarding based on the DA in the packet and [if not synchronized] won't find a match. As a result, the packet will be discarded. Of course, most folks simply have full mesh IBGP (perhaps via RR or confeds) and so there's no reason too enable [or not disable] BGP synchronization. -danny > Color me confused, but isn't the synchronization waiting on the > NEXT_HOPs showing up in your IGP, not the actual BGP route? > > After all, the issue is this: > > BR-A - (your internal network) - BR-B > > A route shows up at BR-A with a nexthop of some interface on BR-A > (or the loopback interface of BR-A). It is then propogated via > iBGP to BR-B. > > It is only unsafe to install said route and propogate it BR-B's peers > if the route's nexthop is not reachable by BR-B. > > This is a far cry from having to inject your BGP into your IGP. > > I will note that this isn't how Cisco has it documented, and I don't know > how they actually treat the sync issue. The documentation actually > says it does wait for the route to show up in the IGP.

2 1

k.gtld-servers.net (Informational Message)
by Verd, Brad 25 Aug '00

25 Aug '00

Informational Message: As of 2000 EDT Thursday, The Network Solutions Registry is currently experiencing connectivity issues with k.gtld-servers.net. We have traced it to a routing issue with an ISP that we traverse and are currently working with them to rectify the situation. -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

1 0

Re: FCC's NRIC to start monitoring ISP Reliability
by Sean Donelan 24 Aug '00

24 Aug '00

Is this only for ISPs? There have been two failures involving root/GTLD servers in the last month. Although NSI posted some messages about what they had done, I never saw any explaination about why it happened. g.root-servers.net had problems transferring or loading zones. It also returned NXDOMAIN instead of dropping out of the DNS system during its problems. Why did this happen? Again this week, problems with various root servers. NSI has said it will keep us advised. But other folks have suggested NSI can't really say what happened for fear of upsetting folks like DISA. If NSI can't report about root server activities who can? There is the DNS Root Server System Advisory Committee. But it isn't really set up to investigate incidents or provide public reporting on the activities of the root servers.

1 0

Community NO-EXPORT
by Dave Cahill 24 Aug '00

24 Aug '00

Community NO-EXPORT I have AS1 connected to AS2 via two different paths and different routers |-------------------| |--------| | |---------| |-----OTHERS | AS1 | | AS2 | | 192.168.0.0/16 | | | | |---------| |-----OTHERS |-------------------| |--------| I advertise my class B range from AS1 for example 192.168.0.0/16 on both routers but to achieve some load-sharing I addvertise 192.168.0.0/17 on one router and 192.168.128.0/17 on the other router as well. I setup a community NO-EXPORT for the /17 so AS2 won't advertise them out to other AS's. The question In AS2 BGP selects the best route and /17 should be selected because of the longest match rule. BGP places the /17 in its routing table. BGP should only UPDATE the other IBGP Peers with its routing table entry (IE Each router won't send it's entire BGP database). So if the /17 will be sent to other IBGP with the community NO-EXPORT how do other AS's learn about the /16 ? Dave Cahill

5 4

Re: ROOT SERVERS ***Important Message Please Read***
by Sean Donelan 24 Aug '00

24 Aug '00

On Wed, 23 August 2000, "Verd, Brad" wrote: > This problem stems from an issue with an NSI server from which the roots, > stated above, perform a named xfer. We are taking appropriate actions to > prevent this or similar incidents from happening in the future. Hardware problem? Software problem? Procedural problem? Internal problem? External problem? Was it something you could control or something you could not control? Is this something other servers doing delegations could experience? If so, how could other operators prevent this from happening? Why didn't automated processes pick up the problem? What should be checked and improved so automated processes could detect the problem in the future?

1 0

Whats the consensus on content-bridge.com?
by Hank Nussbacher 24 Aug '00

24 Aug '00

Just announced: http://www.content-bridge.com/ Will this have a profound affect on CDNs or is it just marketing hype? Fairly major players like America Online, Digital Island, Exodus, Genuity and Inktomi to ignore. Articles: http://boston.internet.com/news/article/0,1928,2001_444391,00.html http://www.forbes.com/tool/html/00/Aug/0823/mu6.htm http://www.thestreet.com/_yahoo/brknews/internet/1051099.html -Hank

1 0

ROOT SERVERS ***Important Message Please Read***
by Verd, Brad 24 Aug '00

24 Aug '00

***Important Message Please Read*** This evening it was brought to the attention of the Network Solutions Registry that four of the thirteen root servers were not responding with the NS Set for the COM zone's name servers. The root servers in question were not responsible for the com zone, but in normal operation they would point to the com zone's name servers as a redirect. B.root, j.root, g.root and m.root were the servers in question. This problem stems from an issue with an NSI server from which the roots, stated above, perform a named xfer. We are taking appropriate actions to prevent this or similar incidents from happening in the future. As of 1950 EDT all root servers have a correct root zone and are answering correctly. We are still investigating the cause of this incident, and we will keep you apprised of any developments. Thanks, Brad -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

1 0