Acme DNS-NSupdate / RFC 2136 issue
-
@Gertjan Yours is a older version, mines running BIND 9.18.28-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)
-
Ubuntu ? What is that ?
But ok, I take note : when I upgrade to Debian 12, which contains bind 9.18.x, and I do work out the tedious "what will be better, and what will utterly break" list, I'll keep an eye on RFC 2136 support.
-
@Gertjan everything i try and do doesn't work, its either a problem with Acme or BIND9 itself. Strange how Certbot works though.
-
I generally think Acme Package on pfSense is broken.
-
I use the acme.sh nsupdate method to do some RFC2136 manually.
I've created a file called /root/server
server 1.2.3.4 53 update add blabla.bhf.tld. 60 in txt "yahoo" send
Where 1.2.3.4 is your master name server.
Be careful of "blabla.bhf.tld." should be your domain name and has an ending dot .Now, for some action :
Have a look at your /tmp/acme/ folder - it should contain a folder that represent your domain.
In that folder, you will find a file that ends with .net.key.
Look at what in it :
Surprise :key "update." { algorithm HMAC-SHA512; secret "eYQiVAutEExxxxxxxxx/ xxxxxxxxxxxxxxxxxxxxhO9zDCaJwzkuZp0w=="; };
( you wonder where did came from ^^)
Show time :
Type
nsupdate -d -k / /tmp/acme/DOMAIN/DOMAINnsupdate_acme-challenge.DOMAIN.net.key server
I saw :
Creating key... Creating key... namefromtext keycreate Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22473 ;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;blabla.bhf.tld. IN SOA ;; AUTHORITY SECTION: bhf.tld. 0 IN SOA ns1.bhf.tld. postmaster.bhf.tld. 2023020845 14400 3600 1209600 10800 ;; TSIG PSEUDOSECTION: update. 0 ANY TSIG hmac-sha512. 1725292457 300 64 WcOM9s/w29Hken6Bmzg3exxxxxxxxxeaz3+1SheVSw46NJ7E1isSEg== 22473 NOERROR 0 Found zone name: bhf.tld The primary is: ns1.bhf.tld Sending update to 5.196.xx.182#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 54168 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; UPDATE SECTION: blabla.bhf.tld. 60 IN TXT "yahoo" ;; TSIG PSEUDOSECTION: update. 0 ANY TSIG hmac-sha512. 1725292457 300 64 tHWwUToJ6uM4S4OrbNxxxxxx72YPC54EKG0UKSYFwuIg== 54168 NOERROR 0 Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 54168 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;bhf.tld. IN SOA ;; TSIG PSEUDOSECTION: update. 0 ANY TSIG hmac-sha512. 1725292457 300 64 XAyLf3RacccccccccccccccccccccccccccceCunW95a2Dl1oQD+jql0g== 54168 NOERROR 0
So, you also, should be able to do RFC 2136 'by hand'.
As RFC 2136 can't be broken of course. -
@Gertjan The file you mention with .net.key doesn't exist.
-
@Gertjan nsupdate -d -k works on my workstation to the Name Server but Acme doesn't work, certbot work.
I think this package is broken personally.
-
@Gertjan Just an update, the config I have the HMAC key isn't work at all, running nsupdate -k allows me to send the change but HMAC key isn't even working not sure what is wrong though
-
@Gertjan Give up with this, It's either ACME that has the issue or it's just BIND that's the issue,
All I get now is
TSIG error with server: tsig verify failure update failed: NOTIMP
Did a fresh install with Debian, when running nsupdate -k on the physical name server I get the same error,
dns_request_getresponse: expected a TSIG or SIG(0)
-
@VioletDragon said in Acme DNS-NSupdate / RFC 2136 issue:
HMAC key
HMAC**-SHA512**, right ?
The nsupdate tool that acme.sh uses isn't from acme.sh, but from the OS ( ? ).
The acme.sh update method called "DNS-NSupdate" uses the nsupdate binary, that should be able to talk to bind, on the other side.
@VioletDragon said in Acme DNS-NSupdate / RFC 2136 issue:
Did a fresh install with Debian, when running nsupdate -k on the physical name server I get the same error,
You mean you couldn't even run nsupdate on the debian server itself ?
The nsupdate tools that comes with the bind package can't 'talk' to bind ? -
@Gertjan update. The configuration for Acme and Certbot is different. Will report back when I’ve done the configuration.
-
@Gertjan I've made progress nsupdate now works but the problem I keep getting is on pfSense side,
; TSIG error with server: tsig verify failure update failed: NOTIMP
-
@Gertjan It seems that acme on pfSense has a problem, tested acme.sh on a Debian VM and it works, not sure what the deal is with acme on pfSense though very strange.
Regards
-
There is something that you can test :
as it uses the same 'nsupdate' thus exactly the same parameters :
-
@Gertjan how would that work for Acme SSL Certs ?
-
Not at all.
Services > Dynamic DNS > RFC 2136 Clients uses exacly the same DNS server zone update mechanism by using the 'nsupdate' executable.
Exactly like acme.sh, with the DNS dns_nsupdate method.
acme.sh adds TXT records.
"Services > Dynamic DNS > RFC 2136 Clients" adds A and AAAA records.
Both use the same nsupdate executable on pfSense.
Both use the same key, key name, algorithm, server IP (your domain name master DNS server. -
@Gertjan okay sweet I will try that later after doing some work and I will report back.
Do you think that this problem I’m facing is caused by the acme package ? As acme.sh works on Debian, same with Certbot. When running nsupdate that works too just acme package is causing me some problems.
Regards
-
@Gertjan Update, This can be marked as solved.
I tried the method you replied above but no dice.
I ended up going with Nginx Reverse Proxy and Certbot with RFC2136 which seems to work better.
Regards
-
@VioletDragon for what it's worth:
# named -v BIND 9.18.29 (Extended Support Version) <id:> # freebsd-version 14.1-RELEASE-p4
That just happens to be my current nameserver, prior versions were earlier BIND versions running on CentOS. I have not had issues with the Acme package doing RFC 2136 updates on any of the BIND/OS versions that I've run. I also use HMAC-sha512 keys, but have used others without issue. Sorry, no solution to offer you, just confirmation from another user that Acme/RFC-2136/BIND works well. The only issue I did have when initially getting Acme set up was to make sure I was using a long enough DNS-sleep.
--Larry
-
@LarryFahnoe yep. I’ve switched away from Haproxy and acme on pfsense due to needing more power under the hood and security reasons.
BIND9 with 2 Nginx Reverse Proxy and RFC2136 works well.
Regards.