BIND issue: nsupdate unable to update reverse zone

Question

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

Can you try : echo "update add 45.2.2.10.in-addr.arpa. 600 IN PTR test.example.com." | nsupdate -d -v ? — Danila Ladner, May 01 '13 at 21:45
To make `nsupdate` tell you what it's doing, issue `debug` as your first command. This will show the SOA query (and "unsuccessful" response) and allow you to troubleshoot better. — voretaq7, May 01 '13 at 21:49
Also 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; }; — Danila Ladner, May 01 '13 at 21:54
@Danila: I'm not having any luck doing this via echo and pipe, probably because I haven't specified the path to the keyfile properly or something. However, I think I'm getting the same thing you're aiming for with **EDIT1** in my original question. Also, I added `127.0.0.1` to allow-update clause for the forward zone, but no change. — sbgoodwin, May 01 '13 at 22:33
RE: EDIT3, your zone for example.com does not define an `A` record for `ns1`. You cannot omit this since you have no upstream nameserver providing the glue for `ns1.example.com`. — Andrew B, May 01 '13 at 23:00
@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) — sbgoodwin, May 02 '13 at 00:26
EDIT3's input command does not match its output. (query for 5, attempts to resolve 10) Please update it. — Andrew B, May 02 '13 at 02:41
From 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... — voretaq7, May 02 '13 at 14:54
@AndrewB: I'm querying for 10.2.2.5, and it's returning the reverse query of 5.2.2.10, so this looks right to me (and this is indeed what is being output to my screen). — sbgoodwin, May 02 '13 at 16:14
@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... — sbgoodwin, May 02 '13 at 16:17
@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. — Andrew B, May 02 '13 at 16:36

score 1 · Answer 1 · answered May 01 '13 at 21:37

1

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.

answered May 01 '13 at 21:37

Andrew B

31,858
12
90
128

See **EDIT2** in my question for output. Still no update, but at lesat this time the `response to SOA query was unsuccessful` error is gone. – sbgoodwin May 01 '13 at 22:30

sbgoodwin · Answer 2 · 2013-05-02T22:31:06.057

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.

That 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. — Andrew B, May 02 '13 at 18:35
Works 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. — sbgoodwin, May 02 '13 at 22:14

BIND issue: nsupdate unable to update reverse zone

2 Answers2