Secondary DNS with local_unbound?

C

cross

For decades, I'd run a primary name server in my network, and had the FreeBSD router in the middle of the networks act as a caching secondary for my local zones. Years ago, this was all with isc-bind, but since that's gone away from active use in the world, I switched my router to using local_unbound for my local networks a couple years ago when I upgraded it. My primary server is using nsd.

I had configured stub-zones on my router, but that wasn't doing what I wanted it to. I found that the primary was just getting rejects when it sent notifies for updates, and while trying to figure out how to reconfigure to get what I wanted and used to have, tried setting up the local domains as auth-zones. But, I can't quite get that working.

I was able to get the notify messages to not be rejected. Able to figure out where the zonefile needed to live. But, I am not able to figure out what magic is needed to:
1) If there is no local zonefile for the auth-zone, accept and write it when getting the notify from the primary.
2) If I manually put a zonefile in place from the primary into the local_unbound zonefile on the router for an auth-zone, it seems to serve that without knowing it is out of date.

The error I'm getting from local_unbound when it gets the notify seems to be able the SOA being wrong?
Code: 
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. probe: notify addrs updated
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. soa probe sent to 2600:XX:xx:XX:ab:cd:ef:99
[...]
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com.: bad reply to soa probe
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: close fd 58
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. probe: notify addrs updated
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. soa probe sent to AA.BB.CC.DD
[...]
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com.: bad reply to soa probe
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: close fd 58
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. probe: notify addrs updated
Mar  1 00:21:47 grouter local-unbound[3841]: [3841:0] debug: auth zone distal.com. soa probe failed, wait to retry

(Both addresses above are the same primary server, IPv4 and IPv6 addresses)

I'm not able to figure out what it means with "bad reply to soa probe". The zone is clearly working for nsd, and if I load an older copy of that zonefile into place on the router, local_unbound serves the old data from it.

Anyone have any ideas, or guidance to where to look for more detailed diagnostics?
 
Not a direct answer to your question, maybe not helpful at all, but perhaps an alternative direction...

Install unbound from ports. local_unbound is a stripped down version. You can use it as a local caching resolver or a full recursive server (if you are hosting email services you want to do this as black lists etc throttle queries from the big dns servers 1.1.1.1 etc and you won't get the value of them - can also run a recursive resolver just for you email set up as well).

using config settings something like

Code: 
local-zone: "example.com" typetransparent
local-zone: "1.168.192.in-addr.arpa" typetransparent

Will allow you to serve records for the domain with local records overriding remote records - same for reverse dns.

The following will allow you to set your records

Code: 
local-data: "test.example.com. IN A 192.168.1.123"
local-data-ptr "192.168.1.123 test.example.com"

If you have something like public.example.com defined in a public dns it will resolve to those values unless you have a local record for it.

As an added bonus you can use unbound views to serve data based on the origin of a request, so you can have different returns if you are on, say, a dmz device.
 
Well, I did know I could install unbound, or nsd for that matter, to get something more fully functional. However, it _looks_ like local-unbound would be capable of what I want. At least, it sounds like auth-zone should do what I was describing.

I know I experimented with views a decade or two ago (ISC bind), and I ended up just keeping my own local copy of everything because it was easier. The idea of "transparent", union mounting a DNS zone, is appealing though. I'll look into that if I end up trying unbound port.

The primary question I need to answer first, though, is why local-unbound is telling me "bad reply to soa probe". If that's caused by misconfiguration, or something else I can fix, I'll try that first.
 
As tedious as it can be I would probably take a look with wireshark and see what is actually happening at the packet level to make sure that looks sane and compare it to the working zone.
 
You must log in or register to reply here.
Back
Top