Added drill command to get_a[aaa]_record() for local hostname

[vsbs-david]

When the hostname ends with .local, the functions get_a_record and get_aaaa_record expect that command avahi-resolve or dig are available to resolve, but they are not in the docker image. However we have drill available, so we can use it as an alternative as mentioned in #2378 (comment)

[vsbs-david]

For testing in my case I don't have hosts with name .local for multicast DNS, but for standard DNS. For example, dig hostname.local shows a warning like this:

;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS

But the answer section has the IP correctly. With drill there is no warning though, and the IP appears correctly too.
With the commands using the address 224.0.0.251 for mDNS as mentioned in the issue, there are errors like these:

# drill @224.0.0.251 -p 5353 <redacted>.local
Error: error sending query: Could not send or receive, because of network error
# dig @224.0.0.251 -p 5353 +short -t a +notcp <redacted>.local
;; communications error to 224.0.0.251#5353: timed out
;; communications error to 224.0.0.251#5353: timed out
;; communications error to 224.0.0.251#5353: timed out
;; no servers could be reached

Then, when running testssl.sh via docker, with docker run --rm -t vsbs-david/testssl.sh hostname.local, the message Error: error sending query: Could not send or receive, because of network error appears before using standard DNS (as the functions use it when the mDNS query has not returned IP addresses) and then the test run successfully.

So, this would work for our case, but maybe we should handle these errors from dig or drill to not appear directly in testssl.sh. Also it would be needed to test an actual mDNS use case. Any thoughts?
Thanks

[drwetter]

So, this would work for our case, but maybe we should handle these errors from dig or drill to not appear directly in testssl.sh.

Probably it would help to redirect stderr to /dev/null for drill as for dig with the inner round brackets.

As a result of an error $ip6 and $ip4 should be empty, so this is where we could add a message like [[ -z "$ip4" ]] && fatal ".local IP address requested but mDNS resolution failed" -- e.g. after else .. fi.

[drwetter]

PS: neither /n/or probably would sound better

[vsbs-david]

Ok thanks, that works but I'd prefer that the script continues with a standard DNS query, instead of forcefully existing with fatal error. To be honest I was not sure if having .local hosts in our network but without using mDNS is correct from the point of view of standards, I'm having a look and apparently it can be fine to use both multicast and unicast DNS according to this RFC: https://datatracker.ietf.org/doc/html/rfc6762#:~:text=Implementers%20MAY%20choose%20to%20look%20up%20such%20names%20concurrently%20via%20other%0A%20%20%20mechanisms%20(e.g.%2C%20Unicast%20DNS)%20and%20coalesce%20the%20results%20in%20some%0A%20%20%20fashion.

So if you agree I was going to add a line like you mentioned but with warning instead of fatal, how could it be better to do it with the current functions?

[drwetter]

Good point. Seems I remembered that differently, (as your link didn't work for me at least as intended: Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion.

Sigh, sounds unusually a bit wishy-washy to me but so be it.

But then at least lets add a debug statement like "$DEBUG" && echo ".local IP address requested but mDNS resolution failed"

[vsbs-david]

@drwetter I pushed one more commit with the changes we talked about, but the CI check seems to fail because of network error, particularly when connecting to badssl.com (104.154.89.105), could it have been a problem with that service itself? Maybe can we retry the CI action to double check? Thanks

[drwetter]

but the CI check seems to fail because of network error

yes, thanks. Experienced the same yesterday too and re-run the job. If you push the suggested change it'll run again and we'll see whether I have to push the button again

[drwetter]

Thanks a lot, @vsbs-david !