RFC-1035 explanation needed
Kevin Darcy
kcd at chrysler.com
Wed Feb 17 20:47:30 UTC 2010
On 2/17/2010 3:05 AM, Alans wrote:
>
> Hi,
>
> I read below paragraph from RFC 1035 about AXFR:
>
> " - If the server needs to close a dormant connection to reclaim
>
> resources, it should wait until the connection has been idle
>
> for a period on the order of two minutes. In particular, the
>
> server should allow the SOA and AXFR request sequence (which
>
> begins a refresh operation) to be made on a single connection.
>
> Since the server would be unable to answer queries anyway, a
>
> unilateral close or reset may be used instead of a graceful
>
> close."
>
> What does it means by "since the server would be unable to answer
> queries..." ?
>
> And when "reset.." should be used?
>
If I were to speculate, I'd say that the author was imagining a
situation where the nameserver was experiencing such severe resource
starvation that it couldn't even respond to UDP queries until it
reclaimed a dormant TCP connection, its associated buffers, control
blocks, etc.
Remember, this was written back in 1987. Machines struggled with memory
management back then, and networking stacks were pretty primitive.
Also, the apparent hope/expectation of the author was that DNS resolvers
would typically maintain persistent TCP connections to DNS servers, but
this never materialized, since it's a lot harder to manage a bunch of
persistent TCP connections than short-lived UDP transactions, and
there's no real performance benefit to be gained over (what came to be
the _de_facto_ standard of) UDP-with-TCP-fallback-on-truncation, given
the name-lookup usage patterns which evolved over time. I'm not sure
that modern BIND even has any code in it to reclaim dormant TCP
connections, since no resolvers (of which I'm aware) maintain persistent
TCP connections. If there is such code, it's probably only for
compliance with the aforementioned verbiage in the standard, not because
it would actually see much practical use in the real world...
- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100217/6db439af/attachment.html>
More information about the bind-users
mailing list