Re: How common is lack of DNS server diversity?
Then it probably doesn't matter if you resolve their DNS, because you won't be getting to any of their services anyway.
Several folks have mentioned that they don't see a problem with dns failure caused by an inability to reach all of the nameservers for a domain - because presumably clients won't be able to reach any of the hosts in that domain. First, as we've seen demonstrated so clearly in the Microsoft case this week, nameserver unreachability does not always imply unreachability of the hosts in the domain. Second (and even if all of the hosts are truly unreachable), there is one somewhat important service that has a markedly different failure mode if the server appears to not exist - email (smtp). Folks sending mail to a domain that doesn't resolve usually get an immediate "delivery failure" response. But those sending to a resolvable domain when the target mail server is simply unreachable get their mail queued. It will typically get retried by the mail system for a few days. Only after such a long outage of the target will a delivery failure occur. (One somewhat ugly side effect of the dns outage is that some mailing lists will remove the user from their list when a delivery failure occurs. Not good to have to explain this to your users.) I lived through both situations (dns plus entire domain unreachable, and the domain unreachable but dns still works); I much prefer the results with a diverse dns setup. Tony Rall
On Sat, Jan 27, 2001 at 11:13:11AM -0800, Tony Rall wrote:
Several folks have mentioned that they don't see a problem with dns failure caused by an inability to reach all of the nameservers for a domain - because presumably clients won't be able to reach any of the hosts in that domain.
Hang on, I was only saying that for the limited case where DNS failure was caused by route flapping of an entire Class A. Don't tar me with the same brush as the folks who say the same about one's DNS servers catching fire.
Second (and even if all of the hosts are truly unreachable), there is one somewhat important service that has a markedly different failure mode if the server appears to not exist - email (smtp). Folks sending mail to a domain that doesn't resolve usually get an immediate "delivery failure" response. But those sending to a resolvable domain when the target mail server is simply unreachable get their mail queued. It will typically get retried by the mail system for a few days.
If "doesn't resolve" means "the target domain itself exists but none of the authoritative name servers for the domain respond", those mail systems doing as mentioned above should most probably be replaced, because they do not properly and reasonably distinguish between "hard" and "soft" errors when using the DNS. If "doesn't resolve" on the other hand means "the target domain does not exist in the DNS, and a reply to that effect is returned (ultimately originating from one of the name servers of the relevant parent domain)", then I agree; the mail should be bounced immediately. Quoting RFC 974 (which was the best quote I could find at the moment): Mailers are expected to do something reasonable in the face of an error. The behaviour for each type of error is not specified here, but implementors should note that different types of errors should probably be treated differently. For example, a response code of "non-existent domain" should probably cause the message to be returned to the sender as invalid, while a response code of "server failure" should probably cause the message to be retried later. Regards, - Håvard
[ On Saturday, January 27, 2001 at 23:53:54 (+0100), Havard Eidnes wrote: ]
Subject: Re: How common is lack of DNS server diversity?
If "doesn't resolve" means "the target domain itself exists but none of the authoritative name servers for the domain respond", those mail systems doing as mentioned above should most probably be replaced, because they do not properly and reasonably distinguish between "hard" and "soft" errors when using the DNS.
Yup, but don't tell me! :-) Unfortunately "it works most of the time", or "it always works for us" keeps such broken stuff in production. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Several folks have mentioned that they don't see a problem with dns failure caused by an inability to reach all of the nameservers for a domain - because presumably clients won't be able to reach any of the hosts in that domain.
lesson: if you are multi-homed, don't let a dns-risky provider hold your data, don't get two dns-risky providers, ... then again, if you have enough clue to multi-home, there is hope that you have enough clue to provide your own dns service and diversely. randy
Then it probably doesn't matter if you resolve their DNS, because you won't be getting to any of their services anyway.
Several folks have mentioned that they don't see a problem with dns failure caused by an inability to reach all of the nameservers for a domain - because presumably clients won't be able to reach any of the hosts in that domain.
That's a wrong justification, not only due to the reasons you go on to cite, but because detecting a failure to look up a name takes a rather long time (your name server or resolver will typically have to rely on a time-out), while reacting to an ICMP Host Unreachable as a response to a TCP connection attempt is pretty quick (if your network is indeed off the net, but your DNS service isn't). This probably makes for easier debugging / better user reports, less of a "world wide wait", faster mailing list deliveries and probably also has other beneficial effects. Regards, - Håvard
participants (5)
-
Havard Eidnes -
Randy Bush -
Shawn McMahon -
Tony Rall -
woods＠weird.com