On 8/4/23 13:23, Shadrock Uhuru wrote:
hi everyone
i have unbound setup on port 53
and nsd listening on localhost port 53530
i have set up another dns server as a secondary
am i correct to assume that i can't zone transfer because
as the nsd's are listening on localhost
the primary can't reach the secondary ?
i have these errors on the primary
error: xfrd: zone 1.10.10.in-addr.arpa: max notify send count reached,
10.10.1.5 unreachable
error: xfrd: zone forwardzone: max notify send count reached, 10.10.1.5
unreachable
shadrock
yes, they have to have some way to talk.
Lots of ways around this, including alternate ports,
redirection in PF, etc.
For example...you could redirect from ONE IP address (your
"other" server) to NSD, the rest goes to unbound. Or have
unbound listen on another port that is filtered to only
listen to your other server.
But my recommended way: don't do zone transfers. Manage your
DNS in another way.
I consider the whole zone transfer thing a bad idea.
What's the reason for having multiple DNS servers? Redundancy.
What do you get when one of your "redundant" systems controls
the other? A: A system that isn't very redundant. If that
controlling system goes down, you have issues.
LONG TIME AGO...in a job far, far away, I set up a pair of
DNS servers, and a little script. I (or my teammates) could
make changes to either DNS server, test them, then run the script.
The script would:
1) run a diff between the zone file on THIS system and the OTHER system.
2) Put that diff into a file, named with the date and time.
3) Put me in vi to edit that file, so I could put a comment in it
explaining what the change was for. This gives me a chance to verify
the change is JUST what I want, and make sure there weren't other
changes made that didn't get replicated.
4) IFF I saved that file with changes, it would:
a) copy and install the file to the "other" system
b) save the diff file to a history directory on BOTH systems
5) Compare the replication script to make sure I didn't update one
and forget to update the other.
Now you have two DNS servers that hold the same data when you want
them to, can be managed separately for testing, and brought back
into sync. Either machine can run indefinitely without the other,
either machine can be used as a source for rebuilding the other.
You also have near zero-effort "change control". Same concept works
for PF and other redundant systems.
Today, lots of people will recommend a central management system,
and that's not all bad, but I have found often with DNS, you want
to be able to test a change on one machine before breaking
everything...and then waiting for the next refresh cycle to fix it.
Nick.
