DNS verification not working

[jnob1]

Describe the bug
getssl was not obtaining the TXT record with dig even though running dig manually showed the correct value for the record.

To Reproduce
Steps to reproduce the behavior:
getssl.cfg with
VALIDATE_VIA_DNS=true
DNS_ADD_COMMAND=/usr/share/getssl/dns_scripts/dns_add_manual
DNS_DEL_COMMAND=/usr/share/getssl/dns_scripts/dns_del_manual

Expected behavior
script retrieves and extracts TXT record from DNS

Operating system (please complete the following information):

• OS: Debian 12
• Bash Version: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
• dig version: DiG 9.18.19-1~deb12u1-Debian

Additional context
Problem identified as there being an @ prefixing the root server name in the script.
Manually running dig with @ prefixing root server in fact does not return an Answer.
Code was modified to remove the @ and script then properly completed.

[timkimber]

Hi @jnob1

Can you tell me which '@' you removed? I'd like to reproduce this and fix

Thanks

Note: I currently have very little time to work on getssl due to work commitments

[jnob1]

Hi,
here are the diffs with v2.28:

590c590
< debug "$DNS_CHECK_FUNC" $DNS_CHECK_OPTIONS TXT "${rr}" "${ns}"

    debug "$DNS_CHECK_FUNC" $DNS_CHECK_OPTIONS TXT "${rr}" "@${ns}"

592c592
< check_output=$($DNS_CHECK_FUNC $DNS_CHECK_OPTIONS TXT "${rr}" "${ns}")

    check_output=$($DNS_CHECK_FUNC $DNS_CHECK_OPTIONS TXT "${rr}" "@${ns}")

607c607
< debug "$DNS_CHECK_FUNC" $DNS_CHECK_OPTIONS ANY "${rr}" "${ns}"

      debug "$DNS_CHECK_FUNC" $DNS_CHECK_OPTIONS ANY "${rr}" "@${ns}"

609c609
< check_result=$($DNS_CHECK_FUNC $DNS_CHECK_OPTIONS ANY "${rr}" "${ns}" \

      check_result=$($DNS_CHECK_FUNC $DNS_CHECK_OPTIONS ANY "${rr}" "@${ns}" \

[jnob1]

sorry, don't know why it formatted like that

[tlhackque]

Removing the @ isn't a solution. The @ tells dig which server to use when resolving a query. So either the ns variable is null or has junk (not a reachable name server).

In the latter case, it would be interpreted by dig as a second query - e.g. for an A record for whatever it is.

In both case,s without the @ the default (/etc/resolv.conf) servers would be used for the query.

No one will work on this without an actual reproducer. Show the debug output that includes the commands issued and the responses from dig.

Use getssl -d for that.

There is nothing secret about domain names or nameservers on the public internet. Or this part of the debug output. (You do have to be careful about passwords & private keys, however.) This is like telling a mechanic "the car doesn't go, please fix it", without indicating where it is, what lights show on the dashboard, or what/whether you crashed into first...

[jnob1]

getssl debug output does not provide much insight other than seeing that dig returns an empty answer section 100 times. You are probably right, removing the @ simply had dig use my default resolv.
More instructive is a simple example of dig output. Below we can see an empty answer section for the TXT query when a root server is specified, and instead the TXT record is returned without it (when it queries my local server.)

$dig sun.com TXT @a.root-servers.net

; <<>> DiG 9.18.24-1-Debian <<>> sun.com TXT @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33367
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sun.com. IN TXT

;; AUTHORITY SECTION:
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.

;; ADDITIONAL SECTION:
e.gtld-servers.net. 172800 IN A 192.12.94.30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
j.gtld-servers.net. 172800 IN A 192.48.79.30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
m.gtld-servers.net. 172800 IN A 192.55.83.30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
i.gtld-servers.net. 172800 IN A 192.43.172.30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
f.gtld-servers.net. 172800 IN A 192.35.51.30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
g.gtld-servers.net. 172800 IN A 192.42.93.30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN A 192.54.112.30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
l.gtld-servers.net. 172800 IN A 192.41.162.30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
k.gtld-servers.net. 172800 IN A 192.52.178.30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
c.gtld-servers.net. 172800 IN A 192.26.92.30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN A 192.31.80.30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30

;; Query time: 20 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net) (UDP)
;; WHEN: Mon Mar 18 17:07:13 CET 2024
;; MSG SIZE rcvd: 832

$dig sun.com TXT

; <<>> DiG 9.18.24-1-Debian <<>> sun.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47317
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sun.com. IN TXT

;; ANSWER SECTION:
sun.com. 10432 IN TXT "v=spf1 ip4:141.146.126.64/27 ip4:156.151.31.64/27 -all"

;; Query time: 4 msec
;; SERVER: 192.168.88.1#53(192.168.88.1) (UDP)
;; WHEN: Mon Mar 18 17:12:51 CET 2024
;; MSG SIZE rcvd: 92

[tlhackque]

What are you actually trying to do? What is (and isn't) happening?

This is option 3 - the nameserver is valid, but does not provide recursion.

The root servers will not return TXT records for this domain. Or any other. There are no TXT records in '.'.

Note the

;; WARNING: recursion requested but not available

from dig in your example.

To resolve sun.com, a nameserver has to trace from the root to .com to sun.com, then look for txt.
Your local resolvers are recursive and will do that. Authoritative servers do not recurse (because it leads to abuse.)

Without actually knowing what getssl has been asked to do - meaning what zone is a certificate being processed, what nameservers are configured in getssl.conf, the complete trace output - there's nothing to fix.

This is telling the above mechanic "I'm not telling you that, just fix the spark plugs. They don't spark when I put them on the kitchen table"... (How far can I stretch an analogy?)

Seriously, if you want anyone to spend any time on this, you'll have to provide a lot more information. I'm not going to ask for it one drop at a time...

I will tell you that the weird formatting in .3 is because this is Markdown, not a raw text box. To quote, use lines with 3 back-quotes (grave) above and below. Click the "Markdown is supported" below the comment text box for more info.

@timkimber - there's no evidence of a bug here - yet. Tagging this information required and removing the Bug tag would be appropriate.