| 1 |
On 2015-12-03 17:20, lee wrote: |
| 2 |
> Alan McKinnon <alan.mckinnon@×××××.com> writes: |
| 3 |
>> Secondly, nothing else on your network can know your auth server is |
| 4 |
>> authoritative without first being informed so by the delegating server. |
| 5 |
> The name server itself knows this from its configuration, and it's the |
| 6 |
> only thing that needs to know this because it's the only thing |
| 7 |
> everything on the network is asking. |
| 8 |
> |
| 9 |
>> Or in other words, if you own example.com and an auth server for |
| 10 |
>> example.com is on your network, you have to first go via .com to know |
| 11 |
>> that. Weird, but that's how it works. |
| 12 |
> The name server doesn't know what domains it's supposed to give answers |
| 13 |
> for without asking others first? |
| 14 |
|
| 15 |
If you have a DNS server that is serving DNS info for example.com, it |
| 16 |
*does* know that. However, |
| 17 |
what Alan is saying is that none of the resolvers (not even the resolver |
| 18 |
running on your |
| 19 |
example.com DNS server) knows which DNS server serves records for |
| 20 |
example.com without |
| 21 |
a few more queries. |
| 22 |
|
| 23 |
Assume a resolver (for example, the resolver in glibc) that has no |
| 24 |
cached knowledge. To |
| 25 |
look up www.example.com, it first queries for '.com' from the root DNS |
| 26 |
servers. Next, it |
| 27 |
queries for 'example' from the '.com' DNS servers. Finally, from the |
| 28 |
'example.com' DNS |
| 29 |
server, it can get the IP for www.example.com. |
| 30 |
|
| 31 |
> |
| 32 |
>> DNS was designed to need a network connection because most of the DNS is |
| 33 |
>> out there somewhere else |
| 34 |
> Then how do you solve the problem of being unable to even resolve the |
| 35 |
> names of hosts on the LAN when the connection goes down? |
| 36 |
|
| 37 |
Ideally, your caching name server has cached the record for your domain |
| 38 |
by the time |
| 39 |
your connection goes down. |
| 40 |
|
| 41 |
Alec |
Archives