Hi Mike. You're welcome. I know what it's like when you just don't get why something isn't doing what you thought it should. What are 10.0.2.10 and 10.0.2.11? You don't show them in your config, but then you say "In summary: I'm trying to get 10.0.2.10 and 10.0.2.11 to serve internal.exmaple.com ...".
According to the config shown (changing "example.net" to "example.com" and assuming you meant "example" instead of "exmaple") I think there are four actions that could happen, depending on the QNAME. Firstly I'm going to re-state the config, with the corrections I *think* you meant. zone "example. <http://example.net/>com" { type forward; forwarders { 10.0.1.10; 10.0.1.11; }; }; zone "internal.example.com <http://internal.exmaple.com/>" { type primary; file "/etc/bind/db.internal.example.com <http://db.internal.exmaple.com/>"; }; 1) If this server receives queries for any name ending "internal.example.com" (including "internal.example.com" itself), for any QTYPE, this server will try to answer it from the primary zone you have declared. If there is no anwer - name and/or type does not exist in that zone file - you will get either the response NXDOMAIN or NOERROR/NOANSWER. I leave you to figure out which applies when. Nothing else happens. This server has responded authoritatively. 2) If this server receives queries for any name ending "example.com" - but excluding names ending "internal.example.com", which are covered by point 1) - this server will answer from its cache, if it has anything in cache to use, or it will forward to 10.0.1.10 or 10.0.1.11, depending on which has the best SRTT at the moment. If either of those forwarders provides a positive response, even if it doesn't contain an answer (responses don't always contain answers) this server will cache that and then respond to the client. 2a) If neither of those forwarders provides a response, forwarding has failed and, because you don't have "forward only;", this server will then recurse to the internet. 3) If this server receives queries for any other name *not* ending " example.com" it will respond from cache, if it can, or recurse to the internet. I would suggest a few things: - Try "dig @10.0.1.10 example.com SOA" and "dig @10.0.1.10 junk.example.com" : repeat for 10.0.1.11 - In a separate terminal window, run tcpdump for all interfaces (including loopback) for port 53. Personally I would capture this to a file using "-w <filename>" in the command line so that you can download the pcap and analyse it in Wireshark afterwards. Make some test queries, then study the results in WS to understand why the box did what it did, given the config it has. - Add "forward only;" to the "example.com" forward zone, as I said before. Lastly, if you are on 9.18, DNSSEC validation will be enabled in auto mode by default. This means that the server will attempt to validate every response it receives. This is too much to go into now, but just be aware that it is happening. To help your understanding it may be useful to disable it for now. Cheers, Greg On Mon, 9 Dec 2024 at 00:34, Mike <m...@csits.net> wrote: > Hi Greg, > > Thanks for taking the time to reply. > > The version of BIND is BIND 9.18.28. It's a config that I wrote many > years ago and so it's been through many cycles of apt-get update with a > config that's grandfathered in. Thanks for the tip about root hints, > that's something to look at. > > Sorry about the confusion. I meant example.com and not .net. I was > trying to construction a mininal config to illustrate my point cleary. > Seems that I achived the opposite. > > That's what I thought about the forward-first, from what I have read. > That said, once went the ADSL line failed, 10.0.2.10 and 10.0.2.11 would > only resolve addresses in internal.example.com and nothing else. I > didn't do a great deal of troubleshooting at the time, as the priority > was digging out a new PSU and getting my ADSL router working again. > > Upon further inspection, when I do dig +trace @10.0.2.10 > server.dmz.example.com, I can see a trace starting at the root and > working down, when I would expect it to go straight to one of the > servers listed as forwarders. > > Kind regards, > Mike. > > > On Mon, Dec 09, 2024 at 12:06:50AM +0000, Greg Choules wrote: > > Hi Mike. > > What version of BIND are you running? > > > > Firstly, please clarify your question and example configuration. > > You talk about "example.com" and subdomains of "exmaple.com", but your > > config shows "example.net". It's not easy to understand exactly what > you're > > trying to achieve a) when your problem statement is confused and b) when > > you give made up names rather than the real names you actually want to > use. > > > > Secondly, "forward first" (the default) will forward if it can (i.e. try > > that first). If it works, all good, no recursion. If it tries to forward > > and fails, then it will recurse. I would recommend you add "forward only" > > for consistent behaviour. Then it either works, or it doesn't and you can > > fix that. > > > > Lastly, root hints haven't been necessary for a very long time as they > are > > now built in (unless you are running a VERY old version). > > > > I hope that helps. > > Greg > > > > On Sun, 8 Dec 2024 at 23:31, Mike via bind-users < > bind-users@lists.isc.org> > > wrote: > > > > > Folks, > > > > > > I have a domain "exmaple.com" and two subdomains, tied to two subnets > > > behind an ADSL line. Let's say dmz.exmaple.com and > > > internal.exmaple.com. Let's say the DMZ is 10.0.1.0/24 and for a > laugh, > > > let's imagine it's routable via the Interwebs. Let's say the internal > > > zone is 10 > > > .0.2.0/24 and it not Internet routable. > > > > > > Let's say that .com has NS recording point example.com to 10.0.1.10 > and > > > 10.0.1.11. Those are bind servers hosting zones for example.com and > > > dmz.exmaple.com. > > > > > > There are two BIND servers in the internal zone, 10.0.1.10 and > > > 10.0.1.11, which have a root hint zone, a master/slave zone for > > > internal.exmaple.com and a forward zone for example.com, forwarding to > > > 10.0.1.10 and 10.0.1.11. > > > > > > zone "." { > > > type hint; > > > file "/etc/bind/db.root"; > > > }; > > > > > > zone "example.net" { > > > type forward; > > > forwarders { > > > 10.0.1.10; > > > 10.0.1.11; > > > }; > > > }; > > > > > > zone "internal.exmaple.com" { > > > type master; > > > file "/etc/bind/db.internal.exmaple.com"; > > > }; > > > > > > This works fine, except that it turns out that when looking up names in > > > dmz.exmaple.com or exmaple.com from 10.0.2.0/24 via 10.0.2.10 or > > > 10.0.2.11, it's not forwarding to 10.0.1.10/11 but insteading going > via > > > the root and working down. Generally this isn't an issue, except m > > > aybe being a trifle inefficient but it does cause the annyoing > > > side-effect that if the ADSL line goes down and the root and .com DNS > > > servers cannot be reached, then exmaple.com and dmz.example.com become > > > unreachable from 10.0.2.0/24. > > > > > > I've read some posts that suggest adding forward-only to force the zone > > > to only forward and not use root hints. I also understand that the > > > default behaviour is the same as forward-first, which will contact the > > > forwarers first and then contact the root servers if the forward > > > fails. That doesn't appear to be what is happening and I'm trying to > > > understand why. > > > > > > I think I've also seen it suggested that zone exmaple.com should be a > > > master zone with two NS servers defined, 10.0.1.10 and 10.0.1.11. That > > > seems to suggest type forward serves no purpous? > > > > > > In summary: I'm trying to get 10.0.2.10 and 10.0.2.11 to serve > > > internal.exmaple.com from their own database (which they are), > > > example.com records from 10.0.1.10 and 10.0.1.11 (which they are not) > > > and everything else from the interwebs (which they are). > > > > > > Most significantly though, I'm not just trying to resolve the issue but > > > actually fix my understanding of BIND and learn where I am going wrong > > > here. > > > > > > Kind regards, > > > Mike. > > > -- > > > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > > > from this list > > > > > > ISC funds the development of this software with paid support > > > subscriptions. Contact us at https://www.isc.org/contact/ for more > > > information. > > > > > > > > > bind-users mailing list > > > bind-users@lists.isc.org > > > https://lists.isc.org/mailman/listinfo/bind-users > > > >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
