default local DNS caching name server
paul at nohats.ca
Fri Apr 11 20:59:05 UTC 2014
On Fri, 11 Apr 2014, Bruno Wolff III wrote:
>> Unless you have a specific reason not to, you should use the DNS server
>> from DHCP. That may be the only DNS server that will work, there may be
>> private DNS info not available anywhere else, etc.
> Split horizon should still work with a caching recursive resolver (since that
> is based on the IP address of where the request is coming from). It won't
> work if network dnsserver provides alternative data out side of its
> bailiwick. But if these outside of bailiwick domains are known to you, you
> can tell your resolver where to look for them.
If you don't know there is an exception for a domain (eg at the other
end of a VPN) than you will get the public answers and might not get
where you need to go. Additionally, with DNSSEC there is the problem
that the public view cryptographically proves the internal view does not
exist (eg internal.fedoraproject.org)
> If the network operator is just outright breaking things so that you can only
> connect to their dns server, well then you're going to need to do something
> about that. But even if it is switch to their server, you might want to know
> that that kind of thing is going on.
We support that with the VPN software by using the received DOMAIN and
DNS servers from IPsec XAUTH and reconfigure unbound on the fly to use
the internal servers for that domain (and flush the cache)
> The advantage of using your dns server is that you know what you're getting.
> Some large ISPs are known to do interesting things with dns information (such
> as rewrite ttl information) that can cause problems that are avoided by using
> your own server.
Indeed, with DNSSEC we can use them as cache, because we can validate
the answers. But those servers should never be "trusted".
More information about the devel