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

Kevin bind-users-ml at thesandiegos.com
Tue Oct 31 19:18:41 UTC 2017


From: "Warren Kumari" <warren at kumari.net> 
To: "Kevin" <bind-users-ml at thesandiegos.com> 
Cc: "bind-users" <bind-users at lists.isc.org> 
Sent: Tuesday, October 31, 2017 11:28:58 AM 
Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates 

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 

okay...done.

After further debugging, it looks like nsupdate (or Bind) doesn't like underscores (that arrive via nsupdate). If I create a TLSA record using the same mechanism that doesn't contain underscore characters, all is right with the world and remote queries work as expected.

However, given that TLSA records use a common record structure that requires underscores, this is a problem.

Am I missing some obscure named.conf setting that needs to be relaxed to allow underscores in dynamically updated records?

-Kevin
> 
> -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

----- Original Message -----
> From: "Warren Kumari" <warren at kumari.net>
> To: "Kevin" <bind-users-ml at thesandiegos.com>
> Cc: "bind-users" <bind-users at lists.isc.org>
> Sent: Tuesday, October 31, 2017 11:28:58 AM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates

> 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


More information about the bind-users mailing list