srvrco / getssl

obtain free SSL certificates from letsencrypt ACME server Suitable for automating the process on remote servers.
GNU General Public License v3.0
2.07k stars 372 forks source link

DNS verification not working #823

Open jnob1 opened 8 months ago

jnob1 commented 8 months ago

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):

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

sorry, don't know why it formatted like that

tlhackque commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.