| 1 |
There are several problems with your idea. First, the configured |
| 2 |
|
| 3 |
> namservers in resolv.conf are caching servers, not authoritative |
| 4 |
> servers. You never configure an auth server to act as a cache. Yes, it |
| 5 |
> can be done. No, it's an awful idea and things break horribly. |
| 6 |
> |
| 7 |
> |
| 8 |
Hi Alan, |
| 9 |
|
| 10 |
What breaks if you have caching and auth on the same server? I have been |
| 11 |
running my tiny home network this way for years. The local domain is |
| 12 |
properly delegated, but if you just wont a local domain that's not |
| 13 |
necessary. |
| 14 |
|
| 15 |
|
| 16 |
> Secondly, nothing else on your network can know your auth server is |
| 17 |
> authoritative without first being informed so by the delegating server. |
| 18 |
> Or in other words, if you own example.com and an auth server for |
| 19 |
> example.com is on your network, you have to first go via .com to know |
| 20 |
> that. Weird, but that's how it works. |
| 21 |
> |
| 22 |
|
| 23 |
AFAIK clients simply request service from whatever's configured in their |
| 24 |
/etc/resolv.conf (recursive query). They dont need to know whether the DNS |
| 25 |
server is authoritative or not, and they dont need to know anything about |
| 26 |
delegation status as they are not performing iterative queries. |
| 27 |
|
| 28 |
As long as all caching servers on your network are also authoritative for |
| 29 |
the zone, or have forwarders for that zone to an authoritative server, it |
| 30 |
works. Right? Bind doesnt do iteration on zones its authoritative for - i |
| 31 |
just tested with a dummy domain. |
Archives