RFC2136 Validation issue

[loxK]

Here is my script:

Set-PAServer LE_STAGE
#Set-PAServer LE_PROD
$keyVal = Read-Host 'TSIG Key' -AsSecureString
$params = @{
    DDNSNameserver = 'ns.server.com'
    DDNSKeyName = 'mydomain.com'
    DDNSKeyType = 'HMAC-SHA512'
    DDNSKeyValue = $keyVal
    DDNSExePath = 'C:\Program Files\BIND9.11.26.x64\nsupdate.exe'
}
New-PACertificate mydomain.com -Plugin RFC2136 -PluginArgs $params -AcceptTOS -Contact 'maintenance@mydomain.com' -Verbose

Here is what I get:

PS C:\users\user\Documents\WindowsPowerShell\Scripts> .\acme.ps1
COMMENTAIRES : Using ACME Server https://acme-staging-v02.api.letsencrypt.org/directory
COMMENTAIRES : Using account [redacted]
COMMENTAIRES : Using existing order for mydomain.com with status pending
COMMENTAIRES : Updating plugin args for plugin(s) RFC2136
COMMENTAIRES : Publishing challenge for Domain mydomain.com with Token [redacted] using Plugin RFC2136 and DnsAlias 'acme.mydomain.com'.
COMMENTAIRES : Adding acme.mydomain.com with value [redacted]
Submit-ChallengeValidation : Unexpected output from nsupdate command. Use -Verbose for details.
Au caractère C:\Program Files\WindowsPowerShell\Modules\Posh-ACME\4.0.0\Public\New-PACertificate.ps1:216 : 9
+         Submit-ChallengeValidation
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Unexpected outp...se for details.:String) [Submit-ChallengeValidation], RuntimeException
    + FullyQualifiedErrorId : Unexpected output from nsupdate command. Use -Verbose for details.,Submit-ChallengeValidation

I tried nsupdate from both Bind 9.16.10 and Bind 9.11.26. I am sure about my settings because I use RFC2136 Validation on multiple Linux VMs using certbot for the same domain. Running Win2k19 server.

[rmbolger]

Hi @loxK, thanks for the report. I have a theory this is due to the nsupdate output being in French and the plugin expecting English (one of the downsides of relying on an external executable for this functionality). But I can't verify without seeing the actual output of the command. What is weird is that the nsupdate output should be in that verbose output write before the exception and I'm not seing it.

Can you try running the following to test just the DNS record creation and posting the output as well?

# use the same $params variable from your original command
Publish-Challenge mydomain.com (Get-PAAccount) faketoken RFC2136 $params -Verbose

[rmbolger]

I'm still really curious what the nsupdate output looks like on your system. But I also decided to try and work around that potential problem by changing the plugin to use nsupdate's exit code as a success indicator rather than parsing the output. It's in the fix-rfc2136 branch. If you want to test it, you can either just replace your copy of the plugin with the one from the branch or use instdev.ps1 to install the whole branch like this:

$remoteBranch = 'fix-rfc2136'
iex (irm https://raw.githubusercontent.com/rmbolger/Posh-ACME/main/instdev.ps1)

[loxK]

The first command did return the same error with no additional output.

With the fix-rfc2136 branch:

Submit-ChallengeValidation : nsupdate returned non-zero exit code which indicates failure. Check -Verbose output for details.
Au caractère C:\Users\gecka-tech\Documents\WindowsPowerShell\Modules\Posh-ACME\Public\New-PACertificate.ps1:216 : 9
+         Submit-ChallengeValidation
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (nsupdate return...ut for details.:String) [Submit-ChallengeValidation], RuntimeException
    + FullyQualifiedErrorId : nsupdate returned non-zero exit code which indicates failure. Check -Verbose output for details.,Submit-ChallengeValidation

[loxK]

Nsupdate wasn't returning any output so I went to the good old CMD an tried. There I got an error message that I didn't have in PowerShell: vcruntime140.dll was missing. So I went ahead and installed "Visual C ++ Redistributable for Visual Studio 2015"

Now I have nsupdate working:

> & "C:\Program Files\BIND9.16.10.x64\nsupdate.exe" -h -V
nsupdate.exe : C:\Program Files\BIND9.16.10.x64\nsupdate.exe: invalid argument -h
Au caractère Ligne:1 : 1
+ & "C:\Program Files\BIND9.16.10.x64\nsupdate.exe" -h -V
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (C:\Program File...lid argument -h:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
usage: nsupdate [-dDi] [-L level] [-l][-g | -o | -y keyname:secret | -k keyfile] [-v] [-V] [-P] [-T] [-4 | -6] [filename]

Going ahead it still fails but that time with an error message:

nsupdate output: dns_request_getresponse: expected a TSIG or SIG(0)

[loxK]

"C:\Program Files\BIND9.16.10.x64\nsupdate.exe"  -v -y hmac-sha512:mydomain.com:[redacted TSIG key]
> server ns.server.com
> update add test.mydomain.com 86400 A 10.10.10.10
> send
dns_request_getresponse: expected a TSIG or SIG(0)

The exact same commands do work in Linux... It isn't a Posh-ACME issue but it drives me crazy.

For what it is worth I submitted a bug report, but I am still stuck.

[rmbolger]

That's totally weird. When I was testing, I never needed to install any VC dependencies. But I suppose it's possible they had already been installed by something else. I may go back and re-try on a fresh VM with the latest BIND package. It's also possible the dependencies changed between the last time I tested and now.

Not sure if it matters, but when the plugin runs nsupdate, it includes the TSIG key as part of the input data rather than on the command line like this:

$input = @(
    "server $Nameserver $Port"
    "key $($TsigKeyType):$TsigKeyName $TsigKeyValue"
    "update $Action $RecordName 60 TXT `"$TxtValue`""
    'send'
    'answer'
)

# send the input to nsupdate and capture the output
$answerLines = $input | & $NSUpdatePath 2>&1

[loxK]

@rmbolger I am coming back to you after the upstream help. I have no idea why but in the specific environment the Windows VM runs, I need to specify the zone with the nsupdate command zone domain.com

Something that doesn't understand TSIG answered the SOA query. You could try specifying the zone to be updated so that the SOA query is skipped. Perhaps whatever answered the SOA query will leave the UPDATE request alone.

It is probably caused by the ISP's provided and managed router. Would you please mind implementing something to workaround such a situation by specifying the zone ?

[loxK]

That would imply adding a DDNSZoneName parameter, and something like:

$input = @(
    "server $Nameserver $Port"
    "key $($TsigKeyType):$TsigKeyName $TsigKeyValue"
    "zone $Zone"
    "update $Action $RecordName 60 TXT `"$TxtValue`""
    'send'
    'answer'
)

# send the input to nsupdate and capture the output
$answerLines = $input | & $NSUpdatePath 2>&1

With "zone $Zone" being conditionally set if DDNSZoneName is.

[rmbolger]

I don't have any problem with adding a parameter like that particularly in 4.x now that plugin parameters are saved per-order. However, since the parameters apply to the whole order, the parameter will have to accept an array of zones because it's not uncommon that orders contain identifiers from different zones. That also necessitates some logic that needs to determine which zone goes with which identifier via string matching.

I may also revisit trying to do the SOA lookup within the plugin in advance so you don't need to specify the zone. An earlier version of the plugin tried to do this but there were some edge cases I hadn't accounted for that screwed things up and I removed it after realizing it didn't seem to be necessary.

[rmbolger]

Ok, initial implementation for the DDNSZone parameter is now in the the fix-rfc2136 branch if you want to test it.

[loxK]

Hi, awesome, it works well, thanks heaps.