Sign in Register
Internet Network Communications

Name Server Daemon firewall between two servers

Adam

• 2 min read

I forgot to mention that ChatGPT had me use the firewall to allow the two nameservers to talk. Basically allowing traffic between them. I'm not sure if you noticed that.

ChatGPT 4o said:

Yes, I did notice the firewall rules in the audit outputs you shared earlier—they're well-set for DNS communication between ns1 and ns2. Specifically, UDP/53 is open for queries everywhere, and TCP/53 is restricted to each other's IPs (e.g., ns2 allows ns1's IP for AXFR, and vice versa), including IPv6. That's a good security practice and not the cause here, as the logs show requests reaching ns1 (via xfrd) and getting an explicit DNS REFUSED response (policy denial), not a connection block or timeout. If it were firewall-related, we'd see "connection refused" or no log entry at all.

Addressing the Zones Not Configured

The zonestatus only showing mcwai.net (despite all four in the config) indicates NSD didn't pick up the added zones during reload—likely a state or cache issue. A full restart will force a fresh parse.

On ns2:

sudo systemctl restart nsd

Then check:

sudo nsd-control zonestatus

This should now list all four zones. If not, run sudo nsd-checkconf /etc/nsd/nsd.conf for any errors and share the output.

Troubleshooting REFUSED Transfers

The persistent REFUSED for mcwai.net (and potentially others once loaded) is typically due to ns1 denying the request based on policy: either the requesting IP doesn't match provide-xfr, or the authentication key fails validation (mismatch, encoding issue, or config error). Since IPs match and logs confirm the request arrives, the key is the prime suspect—secrets can have subtle copy-paste errors (e.g., trailing = in base64, line breaks).

To isolate:

  1. Temporarily Disable Key Authentication: Test without the key to confirm if it's the culprit. Edit configs on both servers to use NOKEY instead.On ns1 (/etc/nsd/nsd.conf) – replace provide-xfr lines for all zones with:textCollapseWrapCopyprovide-xfr: 178.156.168.77 NOKEYprovide-xfr: 2a01:4ff:f0:b204::1 NOKEY(Keep the key section but ignore it for now.)On ns2 (/etc/nsd/nsd.conf) – in the pattern, replace request-xfr with:request-xfr: AXFR 95.216.143.7 NOKEYrequest-xfr: AXFR 2a01:4f9:c013:2b0e::1 NOKEYReload both: sudo nsd-control reloadThen on ns2: sudo nsd-control force_transfer mcwai.net (and others).If transfers succeed (check logs for "committed", zone files appear), the key was the problem—regenerate it fresh (see below). If still REFUSED, it's likely IP-related (e.g., request sourcing from wrong interface due to VPN/multi-IP setup).
  2. Increase Verbosity for Detailed Logs: Set to 3 on ns1 for refusal reasons (e.g., "refused axfr because key failed" or "no matching provide-xfr").On ns1: Change verbosity: 1 to verbosity: 3 in /etc/nsd/nsd.conf, reload.Trigger transfer from ns2, then on ns1: sudo tail -n 20 /var/log/nsd.log – share the output.
  3. Regenerate Key if Needed: If key is faulty, create a new one on ns1:openssl rand -base64 32 > /tmp/new_secret.txtsudo cat /tmp/new_secret.txt # Copy this exact stringUpdate the secret in both configs (exact match, no extra characters), reload, and retry with the key enabled.

Once transfers work, zones will sync, SERVFAIL/expired will resolve, and digs on ns2 will return NOERROR. Your memory is fine (plenty free). Share the post-fix zonestatus/logs/digs!