Re: Changes to named between 7.0 and 9.2?

[steve%prd.co.uk@localhost (Steve Blinkhorn)]

So I ran nsupdate on two of my colo servers, one has been upgraded to 9.2, the other is
awaiting upgrade and is currently on 8.0_RC1.  I used a non-root account and attempted
to add the same TXT record to my primary DNS server, using copies of the same key as in
my acme.sh setup.  On 9.2 it failed with a 'bad TSIG' message, on 8.0_RC1 it succeeded.

I was badly bitten a while back with an unremaked md5 change when I bumped my Tcl/Tk
scripts (of which I have many) from 8.4 to 8.6 and eventually discovered that the
default output from md5 was now binary, upper-case hex was an option, when previously
lower-case hex was the default.  Lots of editing and testing needed at no notice.

Has somethng similar happened here?  The problem appears to be compatibility between 9.2
and previous releases, and acme.sh seems to be exonerated.

--
Steve Blinkhorn <steve%prd.co.uk@localhost>

You wrote:
> 
> steve%prd.co.uk@localhost (Steve Blinkhorn) writes:
> 
> > One of the things that went awry after upgrading from 7.0 to 9.2 was
> > that the automatic renewal of my Letsencrypt certificate stopped
> > working.  For one thing I lost my crontab, which I hadn't realised was
> > ketp in /var, but that's fixable with a bit of editing.
> >
> > More importantly the DNS update challenge no longer works.  named -g
> > -d 9 reports:
> >
> > request has invalid signature: TSIG update: tsig verify failure (BADSIG)
> >
> > Nothing is different in my acme.sh setup, and I can manually update
> > the zone with a TXT record using nsupdate with the same key
> > on the nameserver.
> >
> > Is it possible that 9.2 generates a signature differently from 7.0,
> > despite the relevant key files being identical?
> 
> 
> Hello...
> 
> I can't exactly speak to the specific question of whether or not 7.x and
> 9.x used different key formats.  I can only speculate that perhaps the
> default HMAC changed and you may need to set it in an specific manor
> somewhere or the way that the policy is set is different in
> /etc/named.conf.
> 
> I use Letsencrypt as well but with certbot and a more manual set up.
> 
> The very first thing I would try is to use nsupdate.  Something like
> this:
> 
> GONDOLIN% nsupdate
> > server <put your BIND server ip or hostname here>
> > zone <put the exact zone name here, in my example it is pptp.eldar.org>
> > key hmac-md5:pptpeldarorgtxt. <put your secret here>
> > update add testing.pptp.eldar.org 300 IN TXT "abc123"
> > send
> update failed: REFUSED
> > show
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; ZONE SECTION:
> ;pptp.eldar.org.			IN	SOA
> 
> > answer
> Answer:
> ;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:  55595
> ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;pptp.eldar.org.			IN	SOA
> 
> ;; TSIG PSEUDOSECTION:
> pptpeldarorgtxt.	0	ANY	TSIG	hmac-md5.sig-alg.reg.int. 1651922302 300 16 <hidden> 55595 NOERROR 0 
> 
> ----- the above REFUSED was to be expected as the only entry that is
>       allowed to be updated is _acme-challenge.pptp.eldar.org.  In my
>       /etc/named.conf file I have this:
> 
> zone "pptp.eldar.org" {
>         type master;
>         file "db.pptp.eldar";
>         allow-transfer {
>                 is-valinor;
>         };
>         update-policy {
>                 grant pptpeldarorgtxt. name _acme-challenge.pptp.eldar.org. txt;
>         };
> };
> 
> ----- This may be a place of difference between the bind in 7.x and
>       9.x.  In particular the manor in which the policy is set and what
>       the default allows.  You will see a complaint in /var/log/messages
>       or whatever you have your BIND error and warning logs going to.
> 
> ----- Now on to one that will work:
> 
> > update add _acme-challenge.pptp.eldar.org 300 TXT "abc123"
> > send
> > answer
> Answer:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  15464
> ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;pptp.eldar.org.			IN	SOA
> 
> ;; TSIG PSEUDOSECTION:
> pptpeldarorgtxt.	0	ANY	TSIG	hmac-md5.sig-alg.reg.int. 1651922400 300 16 <hidden> 15464 NOERROR 0 
> 
> > update delete _acme-challenge.pptp.eldar.org
> > send
> > quit
> 
> 
> Be aware that this is all using dynamic DNS updates and as such the zone
> text files may not reflect the reality after an update.  You may need to
> do a "rndc sync -clean" to sync the zone journal files (the .jnl files)
> with the actual zone record base files (your typical zone files).
> Normal queries will work as expected.  That is "host -t txt
> _acme-challenge.pptp.eldar.org." would return the right thing or nothing
> if the entry wasn't there.
> 
> If nsupdate works as expected, but your acme.sh script does not then I
> would be looking to make sure that the proper HMAC is set and that it
> has the proper secret key.  If that all appears to be fine, then a
> reinstall of some pkgsrc may be needed.  There were a number of changes
> between 7.x and 9.x in the OpenSSL library world.
> 
> 
> 
> 
> 
> -- 
> Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org
> 


-- 
Steve Blinkhorn <steve%prd.co.uk@localhost>

****************************************************************************
This email is for the addressee only.   If you are not the addressee
you should immediately delete this email from your system(s) and
inform us.   It may contain information that is confidential or
otherwise privileged, and should not be copied or redistributed to
recipients not originally specified as addressees without permission.

S F Blinkhorn MA PhD CPsychol FBPsS, Managing Director,
Psychometric Research & Development Ltd.
PO Box 1143, St Albans, Herts, AL1 9UT, UK
Registered in England No. 1909571
Registered Office: Verulam Point, Station Way, St Albans, Herts, AL1 5HE
Phone: +44 (0)1727 841455
http://www.prd.co.uk
****************************************************************************