----- Original Message -----
> From: "Kevin" <bind-users...@thesandiegos.com>
> To: "Kevin" <bind-users...@thesandiegos.com>
> Cc: "Warren Kumari" <war...@kumari.net>, "bind-users"
> <bind-users@lists.isc.org>
> Sent: Tuesday, October 31, 2017 12:33:56 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
> ----- Original Message -----
> > From: "Kevin" <bind-users...@thesandiegos.com>
> > To: "Warren Kumari" <war...@kumari.net>
>> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users"
> > <bind-users@lists.isc.org>
> > Sent: Tuesday, October 31, 2017 12:18:41 PM
> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
> > From: "Warren Kumari" <war...@kumari.net>
> > To: "Kevin" <bind-users...@thesandiegos.com>
> > Cc: "bind-users" <bind-users@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@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
> I looked and already had "check-names {master|slave|response} ignore;" set at
> the view level.
> I next tried setting these options at the global level and there is no change
> in
> behavior.
> -Kevin
Even more curiously, if I do an "rndc sync" and view the zone's ".signed" file,
I see the proper DANE TLSA records with underscores in that file. They just
don't seem to be serve-able to remote systems (while test TLSA records that
don't contain underscores are resolved).
-Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
