It's Friday... I have been considering a suitable measure for IP latency. Inspired by the knowledge that at least one network protocol uses micro-fortnights as a unit (RFC 995), I respectfully offer the following modest proposal for consideration. We typically measure latency in msec, which is just so mundane and last millennium. Given that the speed of light is a constant, we can easily map between time and distance with the simple formula d=ct. Since our proposed new unit is purely nominal, we will use the speed of light in vacuo. In this post-modern world, why not use a tried and true, human centered measure. I like the cubit. It has stood the test of time, plus it has the word 'bit' in it. Now, typical values of latency produce a number of cubits that is rather large, so for most networks we will need to scale up the the mega-cubit (Mcubit). Those of us firmly wedded to powers of two may prefer the IEC standard nomenclature for powers of two prefixes of MiCubit (pronounced mebicubit). Which leads to the observation that the current distance from my workstation to Xtra is 3.47Mcubits, Cisco is 23Mcubits away, www.theregister.com is 34Mcubits away, and I am only 0.45 mebicubits from Paradise. Draw what comfort you may from this. -- Michael Newbery IP Architect TelstraClear Limited - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
At 2/08/02 16:48, Michael Newbery wrote:
It's Friday...
I have been considering a suitable measure for IP latency. Inspired by the knowledge that at least one network protocol uses micro-fortnights as a unit (RFC 995), I respectfully offer the following modest proposal for consideration.
I did not realise that the use of this natural unit was so widespread. My knowledge of its application was hitherto limited to its application in Vax/VMS v1 and v2. However, I am pleased to learn that it has a longer history, and a potentially useful future as part of the Internet infrastructure. regards, James - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
You may have noticed Netgate experienced some network problems this morning. The outage combined with clueless telecom DNS design meant that reverse name resolution for 202.37.240.0/23 which they delegate to us failed for approx 30 minutes.
Non-authoritative answer: 37.202.in-addr.arpa nameserver = defiant.netgate.net.nz 37.202.in-addr.arpa nameserver = reliant.netgate.net.nz 37.202.in-addr.arpa primary name server = defiant.netgate.net.nz responsible mail addr = soa.netgate.net.nz serial = 2002070901 refresh = 43200 (12 hours) retry = 3600 (1 hour) expire = 7200000 (83 days 8 hours) default TTL = 86400 (1 day)
37.202.in-addr.arpa nameserver = defiant.netgate.net.nz 37.202.in-addr.arpa nameserver = reliant.netgate.net.nz defiant.netgate.net.nz internet address = 202.37.245.17 reliant.netgate.net.nz internet address = 202.37.245.20
If you were also a victim of this needless stupidity, please contact telecom and demand they arrange for slave name service for above zone from two additional well connected name servers OUTSIDE their network. That way next time their stuff breaks, DNS queries have a fighting chance of being answered. -PWM "Hell, there are no rules here - we're trying to accomplish something!" Thomas A Edison - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, 4 Aug 2002, Peter Mott wrote:
If you were also a victim of this needless stupidity, please contact telecom and demand they arrange for slave name service for above zone from two additional well connected name servers OUTSIDE their network. That way next time their stuff breaks, DNS queries have a fighting chance of being answered.
How can this be? The core of their network has high nines reliability. No, it's true - I've seen it on TV. These servers mustn't be part of the core. (:-) It's a good point Peter makes - there seems little point in having redundant nameservers on the same network. I suspect they're not the only guilty ones here - you'd do well to check your particular provider. Now listen carefully, grandma - this is an egg and if you.... When setting up servers start with outside your own network, then on a network with a different backbone provider and offshore for even better redundancy. - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, Aug 04, 2002 at 12:39:32PM +1200, Andy Linton wrote: It's a good point Peter makes - there seems little point in having redundant nameservers on the same network. I suspect they're not the only guilty ones here - you'd do well to check your particular provider. Many (most?) people are guilty of this... most places I check at random (especially smaller places) have all name-servers for a given zone within the same prefix. When setting up servers start with outside your own network, then on a network with a different backbone provider and offshore for even better redundancy. For larger companies with various automated systems this can be a pain and also a source of anguish for a variety of reasons. Many people are also of the attitude that if one name-server let alone both are down for a given network, then 'who cares' as everything else important such as email and www is also busted. And for many people this is to a large extent true. --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
And for those of you who have smaller networks: http://www.ironclad.net.au/lists/dns-swap/ Nathan Ward At 06:14 PM 8/4/2002, you wrote:
On Sun, Aug 04, 2002 at 12:39:32PM +1200, Andy Linton wrote:
It's a good point Peter makes - there seems little point in having redundant nameservers on the same network. I suspect they're not the only guilty ones here - you'd do well to check your particular provider.
Many (most?) people are guilty of this... most places I check at random (especially smaller places) have all name-servers for a given zone within the same prefix.
When setting up servers start with outside your own network, then on a network with a different backbone provider and offshore for even better redundancy.
For larger companies with various automated systems this can be a pain and also a source of anguish for a variety of reasons.
Many people are also of the attitude that if one name-server let alone both are down for a given network, then 'who cares' as everything else important such as email and www is also busted. And for many people this is to a large extent true.
--cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Or you can try zoneedit.com if you want... <5 zones is free and they will do master and/or slave. --cw On Sun, Aug 04, 2002 at 06:43:22PM +1200, Nathan Ward wrote: And for those of you who have smaller networks: http://www.ironclad.net.au/lists/dns-swap/ - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
http://www.faqs.org/rfcs/rfc2182.html Selection and Operation of Secondary DNS Servers Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. etc. etc. Perhaps this covers most of the issues pertaining to secondary nameservers. Cheers James - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, 4 Aug 2002, James Spooner wrote:
http://www.faqs.org/rfcs/rfc2182.html
Selection and Operation of Secondary DNS Servers
Status of this Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
James, Thanks for reminding us all of this RFC. There's some good advice from very clueful people in there. Presumably that's why the IETF codified as "Best Current Practice". But what would they know. (:-) I note the RFC is more concerned about broken forward than reverse servers which was the topic of the original post. Perhaps in addition to Peter Mott's suggestion on this topic, people could ask their ISPs why they don't implement the provisions of this RFC. andy - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Having had experience with service providers not at all unlike the one being mentioned here ;-) I think it is important to note that business people don't always read RFC's, and the best intentions (and practices) of mice, men and engineers can sometimes be significantly impacted by those they report to. Aaah ... the real world strikes again. Arron Scott *********************************************************************** Arron Scott (CCIE #4099) Phone: +64-9-3551951 Systems Engineer Mobile: +64-27-4883163 Cisco New Zealand mailto:ascott(a)cisco.com http://www.cisco.com *********************************************************************** -----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Andy Linton Sent: Monday, 5 August 2002 9:24 a.m. To: James Spooner Cc: nznog(a)list.waikato.ac.nz Subject: Re: Netgate outage causes chaos! On Sun, 4 Aug 2002, James Spooner wrote:
http://www.faqs.org/rfcs/rfc2182.html
Selection and Operation of Secondary DNS Servers
Status of this Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
James, Thanks for reminding us all of this RFC. There's some good advice from very clueful people in there. Presumably that's why the IETF codified as "Best Current Practice". But what would they know. (:-) I note the RFC is more concerned about broken forward than reverse servers which was the topic of the original post. Perhaps in addition to Peter Mott's suggestion on this topic, people could ask their ISPs why they don't implement the provisions of this RFC. andy - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Mon, 5 Aug 2002, Arron Scott wrote:
Having had experience with service providers not at all unlike the one being mentioned here ;-) I think it is important to note that business people don't always read RFC's, and the best intentions (and practices) of mice, men and engineers can sometimes be significantly impacted by those they report to. Aaah ... the real world strikes again.
Agreed. But I suspect if you complain without using the Best Common Practices (RFC) reference you'll get a response along the lines of: "Our highly skilled engineering staff have assessed the situation and we're following widely accepted NZ practice". Use the RFC reference and you support the engineering staff in their desire to do the right thing. Business people may not read the RFCs but they would respond very strongly to the idea of a beat up in the press that said: "ISP blah disregards well established international standards causing poor service to customers" Business people love to be 'tick box' compliant. Get this 'tick box' onto their list! - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
A bit off topic I know, but does anyone know how to get a packetshaper 4000 that was put into bypass mode by issuing the command "setup shaping bypass", out of bypass mode. Doco is pretty good at showing howt, but not so good on how to get out of it. (Still waiting on a call back from Packetter.) Cheers Steve. - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sat, 3 Aug 2002, Chris Wedgwood wrote:
For larger companies with various automated systems this can be a pain and also a source of anguish for a variety of reasons.
Agreed. But it is doable and you'd have to ask why these larger companies who probably have spent many thousands of dollars on routers overseas and circuits to connect them across the Pacific and the Tasman can't afford to spend the few thousand dollars need to run a remote secondary server. You could run this on a PC based server with a decent amount of memory and no spinning disk for a few thousand dollars.
Many people are also of the attitude that if one name-server let alone both are down for a given network, then 'who cares' as everything else important such as email and www is also busted. And for many people this is to a large extent true.
But if you've arranged to have your web server offsite or you're getting your mail delivered to one of the big ISPs mail server instead of exposing your own, you're toast. And I'd rather have someone resolve my domain name and find the network is down when they try to use the address rather then get no response from the DNS and think "looks like that domain name is bogus". And at least that way mail will get queued in the system for a while until you sort out the network problems. It's interesting to do a 'dig ns xxxx' for most of the large ISPs in NZ. Most have their name servers apparently on the same segment. Perhaps they all have multiple DNS servers located globally and are using ANYCAST to make this transparent to us all but somehow I doubt it. I'm happy to be shot down in flames on this one as long as whoever does it publishes all the details here so that others can learn. (:-) - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, Aug 04, 2002 at 06:59:16PM +1200, Andy Linton wrote: You could run this on a PC based server with a decent amount of memory and no spinning disk for a few thousand dollars. Hardware is cheap, other issues to consider are: (1) what happens if it doesn't work --- who do I contact with a clue to deal with this? (2) what happens if someone gets access to this... could/should leaking DNS data be considering a security problem? But if you've arranged to have your web server off-site or you're getting your mail delivered to one of the big ISPs mail server instead of exposing your own, you're toast. If you do this, why host your own DNS though? And I'd rather have someone resolve my domain name and find the network is down when they try to use the address rather then get no response from the DNS and think "looks like that domain name is bogus". How do you get "looks like that domain name is bogus"? Can you show me an example of such a domain? You should get NS records from the parent zone at the very least (ignoring Network Solution's squatting/bastardisation). And at least that way mail will get queued in the system for a while until you sort out the network problems. Mail will get queued if your can't contact your name-servers. If not, your MTA is badly broken and you will have plenty of problems in the real world. It's interesting to do a 'dig ns xxxx' for most of the large ISPs in NZ. Most have their name servers apparently on the same segment. Yes, I check lionra.gen.nz before I posted my previous reply, but alas, I can't ridicule over that :) Perhaps they all have multiple DNS servers located globally and are using ANYCAST to make this transparent to us all but somehow I doubt it. If they are in the same prefix, this is pointless... consider global routing problems, they usually affect a prefix or not... not partially, so if you have all your DNS eggs in the same basket/prefix, you loose. I'm happy to be shot down in flames on this one as long as whoever does it publishes all the details here so that others can learn. (:-) Oh, I know for a *fact* many sites do indeed have their DNS servers (and email, and http, etc) all in the same network. I even pointed this out to people and was told things like "yes, but we have HSRP" or "it's good enough". Who am I to tell someone else how to ru(i)n their own network? :) --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, 4 Aug 2002, Chris Wedgwood wrote:
On Sun, Aug 04, 2002 at 06:59:16PM +1200, Andy Linton wrote:
You could run this on a PC based server with a decent amount of memory and no spinning disk for a few thousand dollars.
Hardware is cheap, other issues to consider are:
(1) what happens if it doesn't work --- who do I contact with a clue to deal with this?
I guess I'm thinking about the type of *large* organisation we both used to work for who spend many, many thousands of dollars on "carrier class" solutions - you know routers with dual this and that, SDH rings, fibre backup paths on trans Pacific fibres and who install router hardware in Australia and the west coast of the US. Presumably they've already found someone with a clue or could pay someone to get one on this reasonably important issue. Surely the worst scenario is you get that nameserver switched off and plug in a replacement.
(2) what happens if someone gets access to this... could/should leaking DNS data be considering a security problem?
What happens if someone gets to the existing servers...
But if you've arranged to have your web server off-site or you're getting your mail delivered to one of the big ISPs mail server instead of exposing your own, you're toast.
If you do this, why host your own DNS though?
Well, I can see that but we both know that there are many Layer 8 problems out there that need fixed. It's a clue issue.
And I'd rather have someone resolve my domain name and find the network is down when they try to use the address rather then get no response from the DNS and think "looks like that domain name is bogus".
How do you get "looks like that domain name is bogus"? Can you show me an example of such a domain? You should get NS records from the parent zone at the very least (ignoring Network Solution's squatting/bastardisation).
If I'm using a browser and I try www.xxx.net and there are no nameservers responding that know about the zone won't I get a "name not found - check the name and try again" message. If I try to mail fred(a)bloggs.net and no A or MX record gets returned I'll get a bounce from the mail. I might run a "dig ns bloggs.net" but one or two folk out there will just shrug and think that the address is broken.
And at least that way mail will get queued in the system for a while until you sort out the network problems.
Mail will get queued if your can't contact your name-servers. If not, your MTA is badly broken and you will have plenty of problems in the real world.
I'm not talking about my MTA - I'm thinking of the case above.
It's interesting to do a 'dig ns xxxx' for most of the large ISPs in NZ. Most have their name servers apparently on the same segment.
Yes, I check lionra.gen.nz before I posted my previous reply, but alas, I can't ridicule over that :)
Of course you'd be better looking at lionra.net.nz (:-)
Perhaps they all have multiple DNS servers located globally and are using ANYCAST to make this transparent to us all but somehow I doubt it.
If they are in the same prefix, this is pointless... consider global routing problems, they usually affect a prefix or not... not partially, so if you have all your DNS eggs in the same basket/prefix, you loose.
Sorry. I left out the <irony> </irony> tags on the above and the (:-).
I'm happy to be shot down in flames on this one as long as whoever does it publishes all the details here so that others can learn. (:-)
Oh, I know for a *fact* many sites do indeed have their DNS servers (and email, and http, etc) all in the same network. I even pointed this out to people and was told things like "yes, but we have HSRP" or "it's good enough". Who am I to tell someone else how to ru(i)n their own network? :)
That's two of us, Chris! - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Sun, Aug 04, 2002 at 08:48:06PM +1200, Andy Linton wrote: Presumably they've already found someone with a clue or could pay someone to get one on this reasonably important issue. You and I both know this is easier said than done! There is a shortage of clues and people familiar with the network and systems, which can inhibit remote infrastructure if it's not super reliable or able to be fixed by pressing a reboot button. Surely the worst scenario is you get that nameserver switched off and plug in a replacement. Well... ideally for the cost of hardware you run two or three and remotely switch, have cables labelled and tell the people there to plug the A end of the the blue cable into port #5 of box 7 whatever. Make sure they don't cut the green wire though, that's always bad news, especially if the count down timer is close to zero. One nice idea is that USB webcams are like $9 now... and easy to get going remotely so you can use these. What happens if someone gets to the existing servers... Existing/local servers are usually physically close by and more closely watched and better baby-sit by operations people in my experience. They tend to be behind firewalls which IMO is a terrible idea for any moderately sized DNS server... If I'm using a browser and I try www.xxx.net and there are no nameservers responding that know about the zone won't I get a "name not found - check the name and try again" message. Probably. What is wrong with this? If the web-site is down, who cares? It's an error, people just thing "oh well" and try later or give up. Almost nobody actually really thinks what the error says. A better example is email bounces... almost *everyone* I deal with in some kind of email-providing capacity or as some kind of networking authority (ha!) calls me up or forwards me (munged by M$ lookout) messages with comments like "Chris! The email is broken! The End of Nigh!" when the message clearly says something like "The Mailbox you.r.a.moron(a)aol.com does not exist" or "The domain you.have.no.clue.org is not valid". The problem is so bad I actually wrote a thing to pull apart MIME multipart messages so when a DSN is detected I decode it and give them a nice pretty graphical message with nice flashy graphics to make is eally obvious, complete with clickable 'explain this more thingies'. Of course, M$ sExchange boxes really mess this idea up (they don't seem to produce DSN stlye bounces)... (pity, as those are he most often misconfigured from what I can tell). If I try to mail fred(a)bloggs.net and no A or MX record gets returned I'll get a bounce from the mail. Sure... but only if the authoritative servers say this; which requires working DNS. If they can't be reached, they the mail will remain in the queue. I might run a "dig ns bloggs.net" but one or two folk out there will just shrug and think that the address is broken. It is broken if the mail bounces. If the delegations are lame, the name-servers are borked or unreachable, it *should* queue. An example of this is 'coriolis.com'. The name-servers for this domain are unreachable. Send email to it ... it won't bounce until it expires in the queue. If it does, you need to take a clue-by-four to someone and get the MTA and/or DNS fixed. Email should never bounce from what could be temporary errors such as DNS not responding as this happens all the time for many different reasons. I'm not talking about my MTA - I'm thinking of the case above. I just don't get it. Have you an example domain? Don't get my wrong, I think people should have DNS redundancy across multiple prefixes. I've done this myself. However, assuming I didn't have this and the T goes down, what do I loose? Nothing can reach me anyhow to deliver email or see web-sites. --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (9)
-
Andy Linton -
Arron Scott -
Chris Wedgwood -
James Scott -
James Spooner -
Michael Newbery -
Nathan Ward -
Peter Mott -
Steven Schmidt