nsupdate not updating Apex record

Question

nsupdate is only working for cnames. It seems the apex (A record for the root domain) is not updating. I have been able to add to the zone file by using "update add . 604800 A 1.1.1.1" but it puts it in the "$ORIGIN ." section of the zone file and I am unable to delete and update it. I have tried "update add . 604800 A 2.2.2.2" but no update happens. I also tried "update add example.com. 604800 A 2.2.2.2". I have placed a place holder record in the "$ORIGIN ." and the "$ORIGIN example.com." section of the zone file thinking it needs to find it to update it. I have tried deleting it and updating it also... nothing seems to work. I read somewhere that bind cant write to /etc/bind/zones so I put the zone file in /var/lib/bind. Bind has written to the file, but only once to put in a record in the "$ORIGIN ." section. Any advice?

My Zone file:

$ORIGIN .
$TTL 604800 ; 1 week
example.com.        IN SOA  ns1.example.com. admin.ns1.example.com. (
                24         ; serial
                604800     ; refresh (1 week)
                86400      ; retry (1 day)
                2419200    ; expire (4 weeks)
                604800     ; minimum (1 week)
                )
            NS  ns1.example.com.
            NS  ns2.example.com.
$ORIGIN example.com
@           A   5.5.5.5
ds1512      A   10.0.0.13
ds1817      A   10.0.0.14
home        CNAME   ds1817
ns1         A   10.0.0.6
ns2         A   10.0.0.3
roma        CNAME   ds1817
www         CNAME   example.com.

My commands with debug output:

brent@dnsdhcpserver:/var/lib/bind$ sudo nsupdate -d
> server 10.0.0.6
> zone example.com
> update delete @ A
> update add @ 604800 A 2.2.2.2
> send
Sending update to 10.0.0.6#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  25996
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 0
;; ZONE SECTION:
;example.com.       IN  SOA

;; UPDATE SECTION:
.           0   ANY A
.           604800  IN  A   172.16.1.10


Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTZONE, id:  25996
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.com.       IN  SOA

That didn't work so I tried:

> server 10.0.0.6
> prereq nxdomain example.com
> update add example.com. 604800 A 2.2.2.2
> send
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47462
;; flags: qr aa ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;example.com.       IN  SOA

;; ANSWER SECTION:
example.com.    604800  IN  SOA ns1.example.com. admin.ns1.example.com. 24 604800 86400 2419200 604800

;; AUTHORITY SECTION:
example.com.    604800  IN  NS  ns2.example.com.
example.com.    604800  IN  NS  ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800  IN  A   10.0.0.6
ns2.example.com.    604800  IN  A   10.0.0.3

Found zone name: example.com
The master is: ns1.example.com
Sending update to 10.0.0.6#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:   8484
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 1, ADDITIONAL: 0
;; PREREQUISITE SECTION:
example.com.    0   NONE    ANY

;; UPDATE SECTION:
example.com.    604800  IN  A   172.16.1.11


Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: YXDOMAIN, id:   8484
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.com.       IN  SOA

Can anyone see what I am missing?

Answer 1

Don't add the trailing dot to the RR name. Use it like this:

server my.dns.server
zone example.com
key example.com some-key-data
update delete example.com 604800 A
update add example.com 604800 A 192.0.2.1
send

I just tested it with A and MX record; it worked for me, the server is PowerDNS, the client is ISC nsupdate from bind-tools, authentication was via TSIG, the key name equals the zone name for simplicity.

---

I've got an impression you don't fully understand how $ORIGIN and @ work, so here is a little explanation. For the complete explanation see RFC1035.

On the wire these never appear. It's just a convience "syntax sugar" shortening your typing and reading of zone files. The following three examples define identical zones (I am lazy to complete SOA records, their exact values don't matter for our subject):

$ORIGIN example.com.
@ 604800 IN SOA ns1 ....
  604800 IN NS  ns1
ns1 3600 IN A 192.0.2.1
@ 3600 IN A 192.0.2.5 

$ORIGIN .
example.com 604800 IN SOA ns1.example.com ....
$ORIGIN com.
example 604800 IN NS ns1.example
$ORIGIN ns1.example.com.
@ 3600 IN A 192.0.2.1
example.com. 3600 IN A 192.0.2.5 

example.com. 604800 IN SOA ns1.example.com. ....
example.com. 604800 IN NS  ns1.example.com.
ns1.example.com. 3600 IN A 192.0.2.1
example.com. 3600 IN A 192.0.2.5 

In the first example I didn't specify any RR name in the third line (NS RR after SOA RR), so parser will take it from the previous line. This behaviour is the precise reason for @ syntax existence: you can't leave the RR name field empty, as it will take the previous record name. If I skipped the @ at the last record, I'd define a second A record for ns1. So to define a record with the name equals to currently set origin (it'll be "apex" if the origin set to zone name) you can't use "empty name", because it will invoke this "take previous" behaviour. You either have to spell the full record name explicitly with the trailing dot so it won't append an origin (like it is written in other examples), change the origin, or use a special symbol @ which tells the parser: "don't repeat the previous name, here comes the origin naked", so the last line in the first example defines example.com..

The second example is just fancy demonstration how $ORIGIN and @ work together.

The third example doesn't use any sugar. This is real absolute data the zone holds in each of those three examples.

---

So, your record could be represented in the zone file as example.com after $ORIGIN ., or example.com. anywhere, or @ after $ORIGIN example.com., or even example after $ORIGIN com., it doesn't matter. These cases are all equal. Probably you are expecting to see "@" variant, but BIND may decide to spell it as any of those variants, so be prepared to recognize them all. And you can't force it to use any particular variant, sorry.

Another caveat could be you reading the zone file after update without first freezing it. Notice the "jnl" file next to the zone file; it is the journal where your updated data first stored. Only when you do the rndc freeze example.com the data is written into the zone file (but the zone is then locked for updates, to unlock you need to do the thaw operation or reload the server). The proper way to check if zone is updated or not is to do the actual DNS query, with dig or host or nslookup, whichever you like:

host -v example.com