head scratcher: nsupdate, Bind views, and TLSA record updates

[Warren Kumari]

On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users
<bind-users at lists.isc.org> wrote:
> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a
> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash
> script that executes the following nsupdate batch commands which are
> directed to a Bind "view" that is accessible from the wider internet:
>
> server 1.2.3.4
> zone example.com
> key updatekey xyz123...
> update delete _25._tcp.mail.example.com. TLSA
> local 127.0.0.1
> show
> send
>
> And then:
> server 1.2.3.4
> zone example.com
> key updatekey xyz123...
> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123...
> local 127.0.0.1
> show
> send
>
> I get the following output, all looks good:
>
>  + Updating DNS 1.2.3.4:  for ... ok.
>  + Updating DNS 1.2.3.4:  for ... ok.
>
> I see the following in /var/log/messages, all looks good (updating the view
> named "remote", responsible for answering queries from off-network sources):
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view
> remote: signer "updatekey" approved
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view
> remote: updating zone 'example.com/IN': deleting rrset at
> '_25._tcp.mail.example.com' TLSA
> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending
> notifies (serial 165)
> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal:
> received notify for zone 'example.com'
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view
> remote: signer "updatekey" approved
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view
> remote: updating zone 'example.com/IN': adding an RR at
> '_25._tcp.mail.example.com' TLSA
>
> But then when I try to do a query from remote, no TLSA record exists.
>
> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA
> _25._tcp.mail.example.com +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;_25._tcp.mail.example.com.    IN    TLSA
>
> ;; Query time: 74 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Tue Oct 31 10:37:02 PDT 2017
> ;; MSG SIZE  rcvd: 59
>
> Oct 31 10:33:12 test named[106]: query logging is now on
> Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732
> (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com
> IN TLSA -ED (1.2.3.4)
> Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184
> (74.165.37.177.in-addr.arpa): view internal: query:
> 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4)
> Oct 31 10:33:39 test named[106]: received control channel command 'querylog'
>
> I'm at a loss as to what's going on, any ideas?

You've elided enough stuff that debugging/helping you is really hard,
but at least one of the issues is that you are getting back SERVFAIL.
This is almost defeintely a DNSSEC issue -- I'd suggest looking at
DNSVIZ to fogure out why...

W
>
> -Kevin
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf