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