New IPv4 blocks allocated to RIPE NCC
[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 77.0.0.0/8 and 78.0.0.0/7 from the IANA in August 2006. We will begin allocating from these ranges in the near future. The minimum allocation size for these four /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that two pilot prefixes are being announced from each /8. Details of the prefixes, 'pingable' target names and addresses for each prefix can be found on our web site at: http://www.ris.ripe.net/debogon/debogon.html Best regards, -- leo vegoda Registration Services Manager RIPE NCC
Re: New IPv4 blocks allocated to RIPE NCC
On 31 Aug 2006, at 10:52GMT+02:00, leo vegoda wrote: [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 77.0.0.0/8 and 78.0.0.0/7 from the IANA in August 2006. We will begin allocating from these ranges in the near future. The minimum allocation size for these four /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. Typo. That's three /8s, not four. Sorry. -- leo vegoda Registration Services Manager RIPE NCC
Re: Spain was offline
Do you know how to contact your network provider without looking up e.g. www.example.com (network provider web site)? IS TCPWRAPPER configured to lookup names before allowing an operator login on a critical server? Do you know your name servers IP addresses? If the PSTN phone numbers don't work, do you have a INOC-DBA phone? If the INOC-DBA phone numbers don't work, do you have a PSTN phone number? Do you have your own mirrors of TLDs that are important to your users, i.e. .com, your .xx country domain, etc.? --Michael Dillon
OT - Cable suppliers in the UK (pref. London)
Sorry for the OT post, but I'm in a bind. Can anyone point me towards a supplier in the UK (preferrably London) that would have fiber (terminated) in stock for pickup/same day courier delivery? I need about 60m of terminated SM fiber. Thanks! -Dave
Re: Spain was offline
On 31-Aug-2006, at 05:13, [EMAIL PROTECTED] wrote: Do you have your own mirrors of TLDs that are important to your users, i.e. .com, your .xx country domain, etc.? You seem to be suggesting that ISPs run stealth slaves for these kinds of zones. This may have been a useful pointer for ISPs in days gone by, but I think today it's impractical advice. ccTLD managers these days either already restrict zone transfers for privacy reasons, or are being encouraged to do so as a matter of best practice. Established gTLD zones like COM are sufficiently large and are updated so frequently that even if they were made available for AXFR the chances are good that most ISPs would struggle to host the zone, and any local instance would provide degraded service to their customers instead of the improvements in performance that presumably were the point of the exercise. Even where zone transfers are available and ISPs are able to run stealth servers there is always the risk that master server ACLs (or the master servers themselves) will change without warning, leaving the stealth slave serving authoritative but stale data, which is guaranteed to make the helpdesk phone ring sooner or later. For zones that are being made available on anycast servers, ISPs may be able to lobby/pay the zone operator to install an anycast instance in their network. However, in general, the days of ISPs being able to set these things up on their own and see benefit from them are past, in my opinion. Joe
Re: Spain was offline
You seem to be suggesting that ISPs run stealth slaves for these kinds of zones. Not really. In today's world such simplistic solutions don't work. For zones that are being made available on anycast servers, ISPs may be able to lobby/pay the zone operator to install an anycast instance in their network. However, in general, the days of ISPs being able to set these things up on their own and see benefit from them are past, in my opinion. I believe that there are still some things that ISPs can do which cannot simply be bought on the market. For instance, most ISPs runs simple caching servers for their DNS queries where they keep any responses for a short time before deleting them. It's so simple that it is built into DNS relays as an option. An ISP could run a modified DNS relay that replicates all responses to a special cache server which does not time out the responses and which is only used to answer queries when specified domains are unreachable on the Internet. For instance, if you specified that all .es responses were to be replicated to the cache and that your DNS relay should divert queries to the cache when .es nameservers are *ALL* unreachable, then the impact of this type of outage is greatly reduced. You could specify important TLDs to be cached this way as well as important domains like google.com and yahoo.com. The actual data cached would only be data that *YOUR* customers are querying anyway. In fact, you could specify that any domain which receives greater than x number of queries per day should be cached in this way. The volume of data cached would be so small in todays terms that it only needs a low-end 1U (or single blade) server to handle this. Since nothing like this exists on the market, the only way for ISPs to do this is to roll their own. Of course, it is likely that eventually someone will productize this and then you simply buy the box and plug it in. But for now, this is the type of thing that an ISP has to set up on their own. --Michael Dillon
RE: Spain was offline
I wish the article had more info since I have been wondering how a software upgrade downed the entire zone. Wasn't there any backup servers? Did they not test the upgrade before hand? I know I'd lose my job if I upgraded our dns servers all at once with out testing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fergie Sent: Wednesday, August 30, 2006 3:26 PM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: Spain was offline Netcraft: [snip] A botched software update at Spain's central domain registry knocked as many as 400,000 sites offline for several hours Tuesday, according to the Esnic registry. The error left Internet users unable to access domains using .es, the country code top-level domain for Spain. [snip] More: http://news.netcraft.com/archives/2006/08/30/thousands_of_span ish_web_sites_knocked_offline_by_software_error.html - ferg -- Gunther Stammwitz [EMAIL PROTECTED] wrote: He colleagues, Spain (at least the .es-part) was offline nobody reported it...? What's going on? In the past you were faster... Gunther -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Spain was offline
On 31 Aug 2006, at 16:30, Joseph Jackson wrote: I wish the article had more info since I have been wondering how a software upgrade downed the entire zone. Oh, loads of ways. Wasn't there any backup servers? Well, a quick poke suggests, assuming a reasonably traditional setup, that ns1.nic.es is the master, and there are various slaves, not necessarily directly under their control. ns1.nic.es appears to be running BIND 9.3.2, and there's other versions running on the other nameservers. So if it *was* a software update of BIND, it's probably not global. OTOH, I can believe that somebody broke a Perl script critical to it and it rolled out a valid, but empty, zonefile which the secondaries faithfully replicated. Not that I've watched cascading DNS failures at too many places with bits of crufty Perl, oh no... Actually, it amazes me that this sort of thing doesn't happen more often. Did they not test the upgrade before hand? I know I'd lose my job if I upgraded our dns servers all at once with out testing. It's Europe, it's harder to fire people. There's probably a bit of scapegoating and shooting of messengers going on, but it's quite likely that the root cause is a general process failure that's not attributable to a single individual.
Re: Spain was offline
On Thu, 31 Aug 2006 17:30:37 BST, Peter Corlett said: OTOH, I can believe that somebody broke a Perl script critical to it and it rolled out a valid, but empty, zonefile which the secondaries faithfully replicated. Not that I've watched cascading DNS failures at too many places with bits of crufty Perl, oh no... ISTR some database extract failing in a new and unusual way a few years ago, and about 1/3 of the entire .com domain evaporolated for several hours pgp8BpoPzVDGq.pgp Description: PGP signature
Re: Spain was offline
On Thu, 31 Aug 2006 13:03:38 -0400, [EMAIL PROTECTED] wrote: On Thu, 31 Aug 2006 17:30:37 BST, Peter Corlett said: OTOH, I can believe that somebody broke a Perl script critical to it and it rolled out a valid, but empty, zonefile which the secondaries faithfully replicated. Not that I've watched cascading DNS failures at too many places with bits of crufty Perl, oh no... ISTR some database extract failing in a new and unusual way a few years ago, and about 1/3 of the entire .com domain evaporolated for several hours This is an old, old story -- such failures have been with us for a long time. Not all that many years ago, the entire (US) 800 number system was down for a similar reason -- the program that populated the production database from the back end master copies hiccupped, and things got *very* confused. For many more stories like this, see the archives of the RISKS Digest (http://www.risks.org). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Spain was offline
* Michael Dillon: The volume of data cached would be so small in todays terms that it only needs a low-end 1U (or single blade) server to handle this. The working set is larger than you think, I fear. I've been running something like this since summer 2004, and the gigabytes pile up rather quickly if you start with an empty database. If you restrict yourself to A records for plain SLDs and SLDs prefixed with www., the task becomes somewhat easier (because you get rid of all that PTR-related stuff, and the NS RRs take their share, too). Of course, you can squeeze quite a bit of RAM into one rack unit, so your comment probably isn't that far off in the end. 8-) Since nothing like this exists on the market, the only way for ISPs to do this is to roll their own. Of course, it is likely that eventually someone will productize this and then you simply buy the box and plug it in. But for now, this is the type of thing that an ISP has to set up on their own. Well, the data I collect is not authoritative enough for that purpose. My intent was to capture everything that could be served to some host on the network, while taking the possibility of broken resolvers into account. That's why I store the data without verifying its authenticity (which is generally very hard to do because DNS is not globally consistent). Plugging things directly into the caching resolver would give you access to its verification logic, but ISPs aren't really fond of doing this to their resolvers.
Re: Spain was offline
On 8/31/2006 at 8:22 AM, [EMAIL PROTECTED] wrote: [snip] An ISP could run a modified DNS relay that replicates all responses to a special cache server which does not time out the responses and which is only used to answer queries when specified domains are unreachable on the Internet. For instance, if you specified that all .es responses were to be replicated to the cache and that your DNS relay should divert queries to the cache when .es nameservers are *ALL* unreachable, then the impact of this type of outage is greatly reduced. You could specify important TLDs to be cached this way as well as important domains like google.com and yahoo.com. The actual data cached would only be data that *YOUR* customers are querying anyway. In fact, you could specify that any domain which receives greater than x number of queries per day should be cached in this way. From what I've inferred from some other comments about the failure, it seems that the DNS servers were not unreachable or otherwise unavailable, but rather that the .es zone data was corrupted. Such a failure wouldn't trip the backup system you describe. How does an automated system tell the difference between a real NXDOMAIN and a erroneous one? It would take human intervention to turn it on in many potential failure modes. How much of a window is there where the ISP can positively identify a failure and start up their backup before the TLD, or whatever external DNS entity, gets its own act together? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: Spain was offline
* From: Sean Donelan * Date: Wed Aug 30 20:02:13 2006 On Thu, 31 Aug 2006, Gunther Stammwitz wrote: Spain (at least the .es-part) was offline nobody reported it...? What's going on? In the past you were faster... DNS operational problems were briefly discussed on the DNS operations mailing list earlier. [EMAIL PROTECTED] host ns1.nic.es ns1.nic.es has address 194.69.254.1 [EMAIL PROTECTED] host ns2.nic.es ns2.nic.es has address 194.69.254.38 [EMAIL PROTECTED] host www.nic.es www.nic.es has address 194.69.254.54 [EMAIL PROTECTED] host www.red.es www.red.es is an alias for web.red.es. web.red.es has address 194.69.254.50 No idea what happened, and I don't read spanish, but the network configuration infers the registry(auth) and the registrar(nic) are one in the same. No surprise in the ccTLD. They are responsible for the uptime. There is a comment period taking place related to the ICANN IANA root zone checks. This made me think of it. http://www.icann.org/announcements/announcement-18aug06.htm -M [ ObOffTopic: Maybe Paris Hilton can teach then about separation?] -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: comast email issues, who else has them?
Mark Jeftovic wrote: Has anyone ever managed to open a dialogue with symantec (or comcast) about that fscked up proprietary RBL they are using? We're on the verge of just giving up on comcast I know Sender Verification Callback has its issues, but maybe it would make sense to only accept email from Comcast after verifying that they accept email from you? Might be more effective than diplomacy in this case :) -- What is important? What you want to be true, or what is true?
RE: comast email issues, who else has them?
Has anyone ever managed to open a dialogue with symantec (or comcast) about that fscked up proprietary RBL they are using? We're on the verge of just giving up on comcast I know Sender Verification Callback has its issues, but maybe it would make sense to only accept email from Comcast after verifying that they accept email from you? Might be more effective than diplomacy in this case :) I've taken the rather extreme approach of bouncing everything through Gmail first. Let's see them block Google. ;-) Tony
