Re: Mitigating human error in the SP
Otherwise, as Suresh notes, the only way to eliminate human error completely is to eliminate the presence of humans in the activity. and,hence by reference. Automated config deployment / provisioning. That's the funniest thing I've read all day... ;-) A little pessimistic rant ;-) Who writes the scripts that you use, who writes the software that you use ? There will always be at least one human somewhere, and where there's a human writing software tools, there's scope for bugs and unexpected issues. Whether inadvertent or not, they will always be there. If the excrement is going to hit the proverbial fan, try as you might to stop it, it will happen. Nothing in the IT / ISP / Telco world is ever going to be perfect, far too complex with many dependencies. Yes you might play in your perfect little labs until the cows come home . but there always has been and always will be an element of risk when you start making changes in production. Face it, unless you follow the rigorous change control and development practices that they use for avionics or other high-risk environments, you are always going to be left with some element of risk. How much risk your company is prepared to take is something for the men in black (suits) to decide because it correlates directly with how much $$$ they are prepared to throw your way to help you mitigate the risk .;-) That's my 2 insert_currency over .. thanks for listening (or not !) ;-)
RE: I don't need no stinking firewall!
Don't think anyone has mentioned this yet, so I will All this debate over the pros and cons of firewalls brings the words Jericho Forum to mind.and their principles for de-perimeterization (perimeter erosion) http://www.opengroup.org/jericho/ Just my 2insert_currency worth !
RE: Facility wide DR/Continuity
On the subject of DNS GSLB, there's a fairly well known article on the subject that anyone considering implementing it should read at least once :) http://www.tenereillo.com/GSLBPageOfShame.htm and part 2 http://www.tenereillo.com/GSLBPageOfShameII.htm Yes it was written in 2004. But all the food for thought that it provides is still very much applicable today.
Re: Facility wide DR/Continuity
As with all things, there's no right answer . a lot of it depends on three things : - what you are hoping to achieve - what your budget is - what you have at your disposal in terms of numbers of qualified staff available to both implement and support the chosen solution That's the main business level factors. From a technical level, two key factors (although, of course, there are many others to consider) are : - whether you are after an active/active or active/passive solution - what the underlying application(s) are (e.g. you might have other options such as anycast with DNS) Anyway, there's a lot to consider. And despite all the expertise on Nanog, I would still suggest the original poster does their fair share of their own homework. :) - Original Message From: Jim Wise jw...@draga.com To: gb10hkzo-na...@yahoo.co.uk Cc: nanog@nanog.org Sent: Wednesday, 3 June, 2009 15:42:24 Subject: Re: Facility wide DR/Continuity gb10hkzo-na...@yahoo.co.uk writes: On the subject of DNS GSLB, there's a fairly well known article on the subject that anyone considering implementing it should read at least once :) http://www.tenereillo.com/GSLBPageOfShame.htm and part 2 http://www.tenereillo.com/GSLBPageOfShameII.htm Yes it was written in 2004. But all the food for thought that it provides is still very much applicable today. One thing I've noticed about this paper in the past that kind of bugs me is that in arguing that multiple A records are a better solution than a single GSLB-managed A record, the paper assumes that browsers and other common internet clients will actually cache multiple A records, and fail between them if the earlier A records fail. The (first) of the two pages explicitly touts this as a high availability solution. However, I haven't observed this behavior from browsers, media players, and similar programs `in the wild' -- as far as I've been able to tell, most client software picks an A record from those returned (possibly, but not usually skipping those found to be unreachable), and then holds onto that choice of IP address until the record times out of cache, and a new request is made. Have I been unlucky in my observations? Are there client programs which do failover between multiple A records returned for a single name -- presumably sticking with one IP for session-affinity purposes until a failure is detected? If clients do not behave this way, then the paper's observations about GSLB for HA purposes don't seem to hold -- though in my limited experience the paper's other point (that geographic dispatch is Hard) seems much more accurate (making GSLB a better HA solution than it is a load-sharing solution, again, at least in my experience). Or am I missing something? -- Jim Wise jw...@draga.com
Re: Facility wide DR/Continuity
to whoever said ... F5's if you like commercial solutions F5s if you like expensive commercial solutions . Those with a less bulging wallet may wish to speak to the guys at Zeus Technology (http://www.zeus.com/) who have a lot of experience in the area and a more reasonable price tag. Contact me off-list and I can give you some names of senior techies there to speak to. (usual disclaimer that you should research your products it may be that for your particular application/environment/business model/whatever F5 may be your tool of choice)
Re: Facility wide DR/Continuity
(by the way before the accusations start flying of spamming , no I don't work for Zeus or have any incentive to mention their name... just happen to know their product)
Re: Facility wide DR/Continuity
Some things just don't active/active nicely on a budget. Sure, because of inefficient legacy design choices. Roland, I'm not sure I understand your argument here. Budget is very much an issue when choosing between active/active and active/passive. Nothing to do with inefficient legacy design. For example, consider the licensing and hardware costs involved in running something like Oracle Database in active/active mode (in a topology that is supported by Oracle Tech Support).
RE: In a bit of bind...
Hi, I have not been following this thread too closely, but I spotted the last poster talking about a database backend to DNS. There are some interesting thoughts on the matter in a Nominet Blog Post here : http://blog.nominet.org.uk/tech/2008/06/02/nameservers-and-very-large-zones/
Re: MX Record Theories
On Wed, 27 May 2009 09:48:39 -0400, gb10hkzo-na...@yahoo.co.uk wrote: Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long records such as fc00:836b:4917::a180:4179. You do realize DNS queries aren't passing around addresses in ASCII? 3 additional bytes per address isn't going to break the bank. I think you might have missed the point of my post. It was a tounge in cheek reply to the poster who suggested bad things happen if the DNS message size exceeds 512 bytes. He was commenting about AOL's MX records which currently weigh in at 507 bytes. Therefore if we were to hypothesise that the world ends at 512 bytes, then companies doing things the way AOL does, but using IPv6 addresses rather than IPv4 addresses for their MX records could run into problems. Hope that clarifies :)
Re: MX Record Theories
Mark, A EDNS referral from the root servers to the COM servers already exceeded 512 bytes. The world hasn't fallen over. Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long records such as fc00:836b:4917::a180:4179. :)
[no subject]
fc00:836b:4917::a180:4179 And yes, before anyone points out, I just realised I posted an abbreviated example. :)
MX Record Theories
Hello all, First, I hope this is not off-topic for NANOG, please be gentle with me as this is my first post. I would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? Do you have experience in more than one of these methods and which do you favour ? To illustrate my question : (1) If you query the MX records for, Hotmail or AOL you will receive 4 equal weight MX records, each of the MX records having a round-robin set of IPs. e.g. hotmail.com.2706INMX5 mx4.hotmail.com. hotmail.com.2706INMX5 mx1.hotmail.com. hotmail.com.2706INMX5 mx2.hotmail.com. hotmail.com.2706INMX5 mx3.hotmail.com. -and- mx3.hotmail.com.1926INA65.xxx mx3.hotmail.com.1926INA65.xxx mx3.hotmail.com.1926INA65.xxx etc.etc. (2) Alternatively, some people, particularly the ones that use hosted filtering, tend to have one MX record, which as multiple round robin IPs. e.g. microsoft.com.780INMX10 mail.global.frontbridge.com. -and- mail.global.frontbridge.com. 1728 INA65.xxx mail.global.frontbridge.com. 1728 INA207.xxx etc. etc. (3) And others simply have a more traditional setup using multiple MX records and only one IP per MX record with no round robin apple.com.931INMX10 mail-in14.apple.com. apple.com.931INMX20 mail-in3.apple.com. apple.com.931INMX20 eg-mail-in2.apple.com. etc.etc. So what's the big deal ? Please note I'm not asking which is better ... I am just curious and interested to hear your professional opinions and experiences. Personally, I favour the simple option 3, multiple MX records. Thanks y'all.
Re: MX Record Theories
Hi, I thought i'd give you a quick response (and welcome to NANOG) :). Thanks. I can't believe that I've already received three very interesting responses in just over an hour ! I've been quietly lurking on NANOG for a while, just plucked up the courage to post . and might now even find a bit more courage to attempt to contribute to some threads ! Glad to see the community spirit still exists ! Keep the replies coming if there are any still on their way . :) Tim P.S. Valdis Kletnieks . I've got the feeling that this That 507 is critically important if it's true, might potentially explain a few intermittent unexplicable issues we've been seeing at some sites time for some research me thinks :)
