On 2015-12-03 17:20, lee wrote:
Alan McKinnon <alan.mckin...@gmail.com> writes:
Secondly, nothing else on your network can know your auth server is
authoritative without first being informed so by the delegating server.
The name server itself knows this from its configuration, and it's the
only thing that needs to know this because it's the only thing
everything on the network is asking.
Or in other words, if you own example.com and an auth server for
example.com is on your network, you have to first go via .com to know
that. Weird, but that's how it works.
The name server doesn't know what domains it's supposed to give answers
for without asking others first?
If you have a DNS server that is serving DNS info for example.com, it
*does* know that. However,
what Alan is saying is that none of the resolvers (not even the resolver
running on your
example.com DNS server) knows which DNS server serves records for
example.com without
a few more queries.
Assume a resolver (for example, the resolver in glibc) that has no
cached knowledge. To
look up www.example.com, it first queries for '.com' from the root DNS
servers. Next, it
queries for 'example' from the '.com' DNS servers. Finally, from the
'example.com' DNS
server, it can get the IP for www.example.com.
DNS was designed to need a network connection because most of the DNS is
out there somewhere else
Then how do you solve the problem of being unable to even resolve the
names of hosts on the LAN when the connection goes down?
Ideally, your caching name server has cached the record for your domain
by the time
your connection goes down.
Alec
