On 16/12/2015 05:01, Adam Carter wrote: > There are several problems with your idea. First, the configured > > namservers in resolv.conf are caching servers, not authoritative > servers. You never configure an auth server to act as a cache. Yes, it > can be done. No, it's an awful idea and things break horribly. > > > Hi Alan, > > What breaks if you have caching and auth on the same server? I have been > running my tiny home network this way for years. The local domain is > properly delegated, but if you just wont a local domain that's not > necessary.
Well first off I should explain where I'm coming from. I work at a large ISP and the DNS infrastructure falls in my team's area. There are 1000s of customers and nothing must break[1] so it's a very different POV from having your own small instance serving just you. > > > Secondly, nothing else on your network can know your auth server is > authoritative without first being informed so by the delegating server. > Or in other words, if you own example.com <http://example.com> and > an auth server for > example.com <http://example.com> is on your network, you have to > first go via .com to know > that. Weird, but that's how it works. > > > AFAIK clients simply request service from whatever's configured in their > /etc/resolv.conf (recursive query). They dont need to know whether the > DNS server is authoritative or not, and they dont need to know anything > about delegation status as they are not performing iterative queries. > > As long as all caching servers on your network are also authoritative > for the zone, or have forwarders for that zone to an authoritative > server, it works. Right? Bind doesnt do iteration on zones its > authoritative for - i just tested with a dummy domain. All large DNS providers' auth servers are full of outdated and orphaned zones and RRs. It happens, and it happens a LOT more than one would think. It's almost well-nigh impossible to keep things 100% straight for these lame zones[2] What happens when your auth server is also a recursive cache and a client requests one of those lame zones? Your cache replies. If that zone is something big and important (like a busy co.tLD) that zone just broke for all your customers. Technically, it's a case of domain poisoning and very very difficult to find. You never run into this on your own network so you likely are wondering what I'm on about. You don't have an auth zone for a supermarket chain on your auth server that can be migrated away on a whim :-) [1] Yeah, I know - nothing must break. It can and it does because humans ask for changes and humans implement them. We pretend these things never happen in our advertising materials. [2] It's really an exercise in garbage collection, the same as interpreters have to do. The only reliable way to find all the garbage is to walk the DNS for every zone hosted and see if they are still legit. No-one ever really does this until their DNS management software is migrated, and then eyeballs get very big indeed. I had the pleasure once - it took 16 hours to fully validate 50,000 zones, and it took 6 attempts to write code for all errors. -- Alan McKinnon alan.mckin...@gmail.com
