| 1 |
On 16/12/2015 05:01, Adam Carter wrote: |
| 2 |
> There are several problems with your idea. First, the configured |
| 3 |
> |
| 4 |
> namservers in resolv.conf are caching servers, not authoritative |
| 5 |
> servers. You never configure an auth server to act as a cache. Yes, it |
| 6 |
> can be done. No, it's an awful idea and things break horribly. |
| 7 |
> |
| 8 |
> |
| 9 |
> Hi Alan, |
| 10 |
> |
| 11 |
> What breaks if you have caching and auth on the same server? I have been |
| 12 |
> running my tiny home network this way for years. The local domain is |
| 13 |
> properly delegated, but if you just wont a local domain that's not |
| 14 |
> necessary. |
| 15 |
|
| 16 |
Well first off I should explain where I'm coming from. I work at a large |
| 17 |
ISP and the DNS infrastructure falls in my team's area. There are 1000s |
| 18 |
of customers and nothing must break[1] so it's a very different POV from |
| 19 |
having your own small instance serving just you. |
| 20 |
|
| 21 |
> |
| 22 |
> |
| 23 |
> Secondly, nothing else on your network can know your auth server is |
| 24 |
> authoritative without first being informed so by the delegating server. |
| 25 |
> Or in other words, if you own example.com <http://example.com> and |
| 26 |
> an auth server for |
| 27 |
> example.com <http://example.com> is on your network, you have to |
| 28 |
> first go via .com to know |
| 29 |
> that. Weird, but that's how it works. |
| 30 |
> |
| 31 |
> |
| 32 |
> AFAIK clients simply request service from whatever's configured in their |
| 33 |
> /etc/resolv.conf (recursive query). They dont need to know whether the |
| 34 |
> DNS server is authoritative or not, and they dont need to know anything |
| 35 |
> about delegation status as they are not performing iterative queries. |
| 36 |
> |
| 37 |
> As long as all caching servers on your network are also authoritative |
| 38 |
> for the zone, or have forwarders for that zone to an authoritative |
| 39 |
> server, it works. Right? Bind doesnt do iteration on zones its |
| 40 |
> authoritative for - i just tested with a dummy domain. |
| 41 |
|
| 42 |
All large DNS providers' auth servers are full of outdated and orphaned |
| 43 |
zones and RRs. It happens, and it happens a LOT more than one would |
| 44 |
think. It's almost well-nigh impossible to keep things 100% straight for |
| 45 |
these lame zones[2] |
| 46 |
|
| 47 |
What happens when your auth server is also a recursive cache and a |
| 48 |
client requests one of those lame zones? Your cache replies. If that |
| 49 |
zone is something big and important (like a busy co.tLD) that zone just |
| 50 |
broke for all your customers. |
| 51 |
|
| 52 |
Technically, it's a case of domain poisoning and very very difficult to |
| 53 |
find. You never run into this on your own network so you likely are |
| 54 |
wondering what I'm on about. You don't have an auth zone for a |
| 55 |
supermarket chain on your auth server that can be migrated away on a |
| 56 |
whim :-) |
| 57 |
|
| 58 |
|
| 59 |
|
| 60 |
[1] Yeah, I know - nothing must break. It can and it does because humans |
| 61 |
ask for changes and humans implement them. We pretend these things never |
| 62 |
happen in our advertising materials. |
| 63 |
|
| 64 |
[2] It's really an exercise in garbage collection, the same as |
| 65 |
interpreters have to do. The only reliable way to find all the garbage |
| 66 |
is to walk the DNS for every zone hosted and see if they are still |
| 67 |
legit. No-one ever really does this until their DNS management software |
| 68 |
is migrated, and then eyeballs get very big indeed. I had the pleasure |
| 69 |
once - it took 16 hours to fully validate 50,000 zones, and it took 6 |
| 70 |
attempts to write code for all errors. |
| 71 |
|
| 72 |
-- |
| 73 |
Alan McKinnon |
| 74 |
alan.mckinnon@×××××.com |
Archives