Tools for troubleshooting in one place #

Let me reiterate and consolidate all the tools that can be used to troubleshoot applications and systems when the stub resolver is under suspicion.

• `getent` #

When you need to query hostname via all NSS modules:

$ getent host microsoft.com
$ getent ahost microsoft.com

To dump in a user friendly format all requests to 53 port:

$ sudo tcpdump -i any -s0 -A -n port 53

Query DNS recursor:

$ dig @1.1.1.1 microsoft.com AAAA

If you need to debug or check DNSSEC:

$ delv  @1.1.1.1 dnssec-failed.org

With local systemd-resolved, query it for a hostname:

$ resolvectl query facebook.com

Get cache content:

$ resolvectl show-cache

Monitor current queries:

$ resolvectl monitor

Understand which files were opened to guess the resolver by the read config files:

$ sudo strace -f -s0 -e openat app

Check the network activity of an app:

$ sudo strace -f -s0  -e trace=network app

It’s possible to set a breakpoint to libc stub resolver function getaddinfo() and/or other functions:

$ gdb ./resolver
(gdb) set args microsoft.com   # ①
(gdb) break getaddrinfo        # ②
Breakpoint 1 at 0x11aa90
(gdb) run                      # ③

① – setting cli args if need;

② – set a breakpoint for getaddinfo();

③ – run binary.

You can also attach to a running process with gdb by:

$ sudo gdb -p PID

But be careful, it will suspend the execution of a process.

The one note here is to check whether you need debug info for the binary or not.