On Thu, Dec 13, 2007 at 11:25:27AM -0500,
John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote
a message of 40 lines which said:
IMO, it would be really helpful if relevant WGs or other
groups concerned with DNS operations and configurations would
take the question up again, review it, and make some sort of
definitive contemporary statement (even if that were only "it
depends" with an explanation of the tradeoffs).
An important reason why we SHOULD have DNS reliability
(including geographical variety) even if service X is down is
because there are several services, not just the Web. OK, if
the Web site is down, it is not *too* important (but it is
important, for the reasons you mention) if I cannot resolve
www.ietf.org but email, jabber, etc, continue to live and need
the DNS.
This is consistent with my instincts (and has been for many
years), but Dave is not the first person to take the other
position.
And it is a essentially very bad position to take.
The DNS was designed to handle many more "connections" per second
than any TCP based server can handle but to achieve that it needs
to get it needs to be able to find a working server for every zone
it is querying. If it doesn't the list of outstand recursive queries
quickly becomes a resource issue on the caching server as the amount
of time connection state needs to be remembered goes from sub second
to multi second.
If everyone took the attitude that if the services pointed to by
the DNS are offline then the DNS can be offline then the DNS just
would not work. Luckily most don't or we would have a "tragesty
of the commons" here.
DNS servers are also often a shared shared resource for thousands
if not hundreds of thousands of clients machines. This means that
lookup failures don't just affect the user making the lookup. They
are cumulative and affect all the users of the shared resource.
We see these effects with spam runs which use host names which point
to lame / non-existant servers so this is not just idle speculation.
If the DNS lookup succeeds then the impact of the failure moves
away from the shared resource and back towards individual resources
(browers) or to shared resources which don't have the volume of
lookups (MTAs) and have different failure recovery strategies (store
to disk rather than in memory of a caching server).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf