[BUG / possible BUG] DNS resolution fails in a container

[mythi]

I'm checking my Kubernetes webhook TLS services using testssl.sh deployed. Things used to work with drwetter/testssl.sh:3.0 but now fails with drwetter/testssl.sh:3.2 (and :latest):

Fatal error: No IPv4/IPv6 address(es) for "<my service>" available

Before you open an issue please check which version you are running and whether it is the latest in stable / dev branch
I am running version ( git log | head -1 / testssl.sh -v | grep from): drwetter/testssl.sh:3.2

Before you open an issue please whether this is a known problem by searching the issues
couldn't find anything

Command line / docker command to reproduce
testssl.sh --openssl=/usr/bin/openssl --mapping iana -s -f -p -P -U <my service>

Expected behavior
testssl.sh to succeed the same way it does with drwetter/testssl.sh:3.0.

Your system (please complete the following information):

• OS: drwetter/testssl.sh:3.2

Additional context

[drwetter]

Hi @mythi ,

not sure whether you scan from within the k8s cluster or outside? From the inside: it's hard to tell what's going wrong as it depends on your DNS service and how you set it up. testssl.sh depends on a proper working resolver.

As a litmus test: Does (ping|host|dig|netcat) return the correct IP address?

There was one bigger DNS related change I recall btw 3.0 and 3.2 (d001bba) but as you don't use a proxy that shouldn't affect you.

[mythi]

From the inside: it's hard to tell what's going wrong as it depends on your DNS service and how you set it up. testssl.sh depends on a proper working resolver.

From inside. I'm assuming the resolver works properly since it's the exact same cluster that works with 3.0 image but not when I move to 3.2. I'll take a closer look on d001bba and try out the utils you suggested.

[drwetter]

if you have DNS query logs that would be also a useful source to look at

[mythi]

The (coreDNS) logs do not return any errors. nslookup returns an address and at least I can get testssl.sh with --nodns=none --ip <IP from nslookup> to work. Still debugging...

[drwetter]

Don't know about coreDNS but I just meant queries, so that you'd be aware that testssl.sh at least does a query and not only see a failed query.

[mythi]

so that you'd be aware that testssl.sh at least does a query and not only see a failed query.

OK, I see. How do I get the logs from the DNS query. I can't see anything with --debug 0...6 levels

[drwetter]

no clue for CoreDNS.

But if your scan target is outside the cluster coreDNS is the forwarding server and the next hop might be a different DNS server (bind: https://www.thegeekdiary.com/how-to-enable-bind-query-logging-to-find-out-whos-querying-a-name-server/)

[mythi]

no clue for CoreDNS.

I meant to ask how to debug what testssl.sh runs to do the query.

[drwetter]

Read the fine manual please ;-) hidden :-) here: https://github.com/drwetter/testssl.sh/wiki/Findings-and-HowTo-Fix-them . best is 2a or 2b

[drwetter]

if you want to narrow it down: the functions is get_a_record(), assuming there's no IPv6 in your cluster

[mythi]

if you want to narrow it down: the functions is get_a_record(), assuming there's no IPv6 in your cluster

I'm still working on figuring out why this worked with 3.0 image and fails with 3.2 but the problem seems to be that drill a <my service> fails (ANSWER SECTION is empty) with the URI I provided. Thanks for the wiki pointer, it helped a lot and fortunately 3.2 has script installed too! I'll keep you updated on what I find out.

[mythi]

3.2 image does not have nslookup installed so there is no working fallback since drill does not return an address. 3.0 ends up using nslookup after drill so I get an IP and this works.

[drwetter]

ok, thanks. Did you get why drill doesn't return an IP address?

[drwetter]

PS: other docker containers work -- I am pretty sure.