Time out for a terminology check--"resolver" vs "server".

Scott Howard scott at doc.net.au
Mon Feb 15 01:48:23 UTC 2010


On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon <LarrySheldon at cox.net> wrote:
>> It is possibly to run both Authoritative and Recursive server on the
>> same IP, but it's generally not recommended for many reasons (the most
>> simple being that of stale data if your server is no longer the
>> correct nameserver for a domain, but it's still configured to be
>> authoritative for that domain).
>
> Seems like TTL management would take care of that but I think the issues
> of recursion are now different from the safe world I thought I lived in
> 20 years ago.

TTL's play no part in how any Authoritative server answers a request.

Consider what happens if your DNS server was authoritative for
example.com, and the .com nameservers pointed to you for that domain.
Your customer who owns the domain then changes the delegation to
another provider (and/or the domain expires, etc) but doesn't tell
you.

At this point, your server is still answering all requests for
example.com - because that's what authoritative servers do.  It won't
check to make sure that the domain is still delegated to it, and doing
so would make no sense in a generic sense (eg, it might be an internal
only domain, or testing a new domain that hasn't yet been delegated to
you, etc).

If one of your clients queries the server - in the context of it being
a recursive server - it will respond with your view of the world for
example.com, which is incorrect.

If the server was configured as authoritative only, and another server
(or a different IP on the same server) was acting as the recursive
server then your authoritative server will still return the incorrect
answers if asked - but nobody will ever ask it for a domain that isn't
correctly delegated to it.

There are (poor) solutions to this, such as regular checks that all
domains you're serving are actually delegated to you - but simply
separating the functions is a far better solution.

  Scott.




More information about the NANOG mailing list