BIND issue: nsupdate unable to update reverse zone
Solution 1
SOLUTION:
I have no idea why, but it is now working. The only things I did were rndc querylog
, which clearly can't have fixed anything by itself, and the following:
# chown -R named:named /var/named
# find . -type d -exec chmod 770 {} \;
# find . -type f -exec chmod 660 {} \;
Now, the funny thing is, I am 99.999% sure that the permissions were already set correctly (owner/group named, with 660 permissions). I mean, I checked the dang permissions at least a dozen times. Oh, the other thing I did was to delete the zero-length db.2.2.10.in-addr.arpa.jnl, and restart named, to allow it to recreate it. It recreated it properly (though with 644 permissions), and it worked from there on out. I'm baffled for the exact reason it's working, but I'll take it! Thanks everyone for your effort.
EDIT:
It looks as if my reverse zone file got updated somehow (I'm assuming via nsupdate). I'm posting it here in case it helps. Note the difference from my originally posted 2.2.10.in-addr.arpa zone in my original question. I feel like the differences are trivial enough to not make a difference in functionality, but of course, I'm far from an expert.
$ORIGIN .
$TTL 600 ; 10 minutes
2.2.10.in-addr.arpa IN SOA ns1.example.com. root.example.com. (
4 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS ns1.example.com.
$ORIGIN 2.2.10.in-addr.arpa.
10 PTR a.example.com.
11 PTR b.example.com.
15 PTR c.example.com.
96 PTR d.example.com.
55 PTR 3.example.com.
5 PTR server.example.com.
Solution 2
I have a hunch that this might be the absence of an explicit zone
statement in your update.
nsupdate
has to guess what zone the update applies to when you omit that ("based on the rest of the input" according to the manpage), and I see lots of room for that assumption to be wrong given how many quads deep this zone is.
Failing that, give -v
a spin to see if you have better luck with TCP.
sbgoodwin
Updated on September 18, 2022Comments
-
sbgoodwin almost 2 years
I'm testing my ddns update config (for ISC DHCP hosted on same server) with
nsupdate
, and while the forward zone updates correctly:# nsupdate > server 127.0.0.1 > key dhcpupdate MYSECRETKEY > update add test.example.com. 600 IN A 10.2.2.45 > send # tail -n1 /var/log/named.conf client 127.0.0.1#12584: view internal: updating zone 'example.com/IN': adding an RR at 'test.example.com' A
the reverse zone does not:
# nsupdate > server 127.0.0.1 > key dhcpupdate MYSECRETKEY > update add 45.2.2.10.in-addr.arpa. 600 IN PTR test.example.com. > send response to SOA query was unsuccessful
nsupdate then spits me back to the shell, and there are no errors (or messages of any kind) in the logs. I've tried the reverse zone update with and without trailing periods. I have the feeling I'm missing something basic, but I can't figure out what it is.
Thanks for any pointers. Here are my config files, and other info:
# cat /etc/named.conf
acl internals { 127.0.0.0/8; 10.2.2.0/24; }; logging { channel named.log { file "/var/log/named/named.log"; severity dynamic; }; category default { named.log; }; }; options { listen-on port 53 { any; }; // listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; recursion no; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; }; key dhcpupdate { algorithm hmac-md5; secret "MYSECRETKEY"; }; include "/etc/named.root.key"; view "internal" { match-clients { internals; }; recursion yes; zone "localhost" IN { type master; file "/var/named/db.localhost"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "/var/named/db.0.0.127.in-addr.arpa"; allow-update { none; }; }; zone "." IN { type hint; file "named.ca"; }; zone "example.com" { type master; file "/var/named/db.example.com"; allow-update { key dhcpupdate; }; }; zone "2.2.10.in-addr.arpa" IN { type master; file "/var/named/db.2.2.10.in-addr.arpa"; allow-update { key dhcpupdate; }; }; }; view "external" { match-clients { any; }; recursion no; forwarders { 1.2.3.4; 1.2.3.5; }; // ISP DNS servers forward first; };
# cat /var/named/db.example.com
$ORIGIN . $TTL 600 ; 10 minutes example.com IN SOA ns1.example.com. root.example.com. ( 5 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) NS ns1.example.com. A 10.2.2.44 $TTL 3600 ; 1 hour MX 1 ASPMX.L.GOOGLE.COM. MX 5 ALT1.ASPMX.L.GOOGLE.COM. MX 5 ALT2.ASPMX.L.GOOGLE.COM. MX 10 ASPMX2.GOOGLEMAIL.COM. MX 10 ASPMX3.GOOGLEMAIL.COM. $ORIGIN example.com. $TTL 600 ; 10 minutes myserver A 10.2.2.5 ns1 A 10.2.2.5 test A 10.2.2.45 www A 123.12.34.32 // externally hosted www server
# cat /var/named/db.2.2.10.in-addr.arpa
; ; BIND data file for example.com ; $TTL 10m @ IN SOA ns1.example.com. root.example.com. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; 2.2.10.in-addr.arpa. IN NS ns1.example.com. 5 IN PTR myserver.example.com.
EDIT:
Using debug command in nsupdate gives the following:
Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28411 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;96.2.2.10.in-addr.arpa. IN SOA ;; TSIG PSEUDOSECTION: dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367446210 300 16 XXXXXXXXX 28411 NOERROR 0 response to SOA query was unsuccessful
EDIT2:
When specifying zone, I get the following:
> debug > server 127.0.0.1 > zone 2.2.10.in-addr.arpa > key dhcpupdate XXXXXXXXXXX > update add 96.2.2.10.in-addr.arpa. 600 IN PTR scott-lap.example.com. > send Sending update to 127.0.0.1#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 11170 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;2.2.10.in-addr.arpa. IN SOA ;; UPDATE SECTION: 96.2.2.10.in-addr.arpa. 600 IN PTR scott-lap.example.com. ;; TSIG PSEUDOSECTION: dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367447008 300 16 XXXXXXXXXXXXXX 11170 NOERROR 0 Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: SERVFAIL, id: 11170 ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;2.2.10.in-addr.arpa. IN SOA ;; TSIG PSEUDOSECTION: dhcpupdate. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1367447008 300 16 XXXXXXXXXXXXXXXXX 11170 NOERROR 0
EDIT3:
Huh. I'm trying to use
host
to see if it resolves my DNS server's ip address (which is listed in the reverse zone file above), and this is what I get. No log entries again.# host -v 10.2.2.5 Trying "10.2.2.10.in-addr.arpa" Host 10.2.2.10.in-addr.arpa not found: 2(SERVFAIL) Received 40 bytes from 10.2.2.5#53 in 0 ms
-
Danila Ladner about 11 yearsCan you try : echo "update add 45.2.2.10.in-addr.arpa. 600 IN PTR test.example.com." | nsupdate -d -v ?
-
voretaq7 about 11 yearsTo make
nsupdate
tell you what it's doing, issuedebug
as your first command. This will show the SOA query (and "unsuccessful" response) and allow you to troubleshoot better. -
Danila Ladner about 11 yearsAlso try "sudo nsupdate -l" >update add 45.2.2.10.in-addr.arpa. 600 IN PTR test.example.com. >show See what it is doing. Sometimes also helps allow-update { localhost, key dhcpupdate; };
-
sbgoodwin about 11 years@voretaq7: see edited question above for debug output
-
Andrew B about 11 yearsRE: EDIT3, your zone for example.com does not define an
A
record forns1
. You cannot omit this since you have no upstream nameserver providing the glue forns1.example.com
. -
sbgoodwin about 11 years@AndrewB: Sorry, my config up there is outdated. I'll update it now. (I have this record in my example.com zone file: ns1 A 10.2.2.5)
-
Andrew B about 11 yearsEDIT3's input command does not match its output. (query for 5, attempts to resolve 10) Please update it.
-
voretaq7 about 11 yearsFrom your debugging output the NS you're talking to is returning
SERVFAIL
-- there should be something in your BIND logs indicating why. Usual culprits are permissions problems (on the zone or the journal file) or the NS not being authoritative for the zone... -
sbgoodwin about 11 years@voretaq7: Strange, but no log entries at all! I've checked messages and named.log. I'll see if I can enable more verbose logging for bind...
-
Andrew B about 11 years@sbgoodwin Trying "10.2.2.10.in-addr.arpa" suggests that the command input was 10.2.2.10. It should still return a SERVFAIL though, so I'm not expecting it to succeed.
-
sbgoodwin about 11 years@AndrewB: ah, good point, sorry I misread the octet above.
-
-
sbgoodwin about 11 yearsSee EDIT2 in my question for output. Still no update, but at lesat this time the
response to SOA query was unsuccessful
error is gone. -
Andrew B about 11 yearsThat clears the SERVFAIL that crept in, but what happens when you remove the
zone
line? Just curious whether or not that was in fact the solution to the original problem. -
sbgoodwin about 11 yearsWorks even without the zone line. I'm looking at my reverse zone file and it's different now... I am posting this in the solution above in case it sheds any further light.