Add a --verbose or --debug flag to resolvectl

[olivier-godart]

Resolvectl is a very useful tool for testing the dns resolution of systemd-resolved.

When investigating name resolution issues (if it resolves fine with dig @server domain.to.test but not with systemd-resolved), you can use resolvectl status to view the active configuration with the link related parameters, OR use resolvectl query domain.to.test to test the resolution (but you have no details, just either a result, or a simple "not found" message).

It would really help a lot to have either a --verbose or a --debug flag, to see which server is queried, why, which domains are actually sent in the query (based on the search domains), was the cache used,...

Thanks!

[yuwata]

resolvectl just show the result of the query done by systemd-resolved. So, how about to enable debugging log of resolved, then call resolvectl query and see the logs by journalctl.

[olivier-godart]

That is indeed a way to do it, as a workaround. It involves changing a config file, restarting a service, isolating the query in the log, then reverting the changes to the system.
A simple --verbose flag, would be much more convenient, and is something rather common on unix tools.

[xnox]

for example, it would be nice if resolvctl enable-debugging was a thing, that would change the verbosity of resolved, and then dump logs with a query.

Similarish to how systemct status prints logs for the unit from journal too.

[keszybz]

It involves changing a config file, restarting a service, isolating the query in the log, then reverting the changes to the system.

Log level can already be dynamically tweaked with the LogControl1 API.

Dunno, maybe resolved could add a journal metadata field that would tag the queries it performs with some "source" identifier, similarly to how postfix or exim4 tag all messages related to a specific message using the identifier of that message. So resolvectl could specify a UUID when performing the query, and then resolved would include REQUESTED_BY=uuid in messages, and the logs could be queried with this metadata. This could be useful, but it not a trivial project.

A simple --verbose flag, would be much more convenient, and is something rather common on unix tools.

Well, it's one thing to support that for a tool that does stuff locally, and completely another thing to make that work in something that tells a server to do stuff. SYSTEMD_LOG_LEVEL=debug resolvectl will describe in detail what resolvectl is doing, but that it's not very interesting.

[pemensik]

Every DNS query has 16-bit id (id: in dig ->>HEADER<<-). It is not proved to be unique, but should be sufficient to pair each request to its reply. Should work to pair with dependent queries, like DNSKEY or DS records.

[pemensik]

I think resolvectl could just allow increasing and decreasing verbosity level without sending d-bus messages.

[piotr-dobrogost]

So resolvectl could specify a UUID when performing the query, and then resolved would include REQUESTED_BY=uuid in messages, and the logs could be queried with this metadata. This could be useful, but it not a trivial project.

This would be so nice!
Could this idea be taken further?
Could we write SYSTEMD_LOG_ID=xxx any_systemd_utility and have journald pick up and log id?

[davispuh]

So how can we currently debug DNS issues?

Completely useless

$ resolvectl query some.domain
some.domain: resolve call failed: 'some.domain' not found

In journalctl -u systemd-resolved there's nothing either.

I want to find out at which level/where it failed.

[pemensik]

Why do you think it failed? It may be just vague terminology. But I assume this message is result of status: NXDOMAIN dns query, which just means that name does not exist. It is not error, it is just negative response.

There is relatively new extension EDE, which can provide reasons for SERVFAIL status in response. Which would be good to be provided by UI if specified. But in this case just error message should be corrected. It is not error or failure. It just tells you 'some.domain' name does not exist. It should be presented as such, not as a failure.

[pemensik]

I think not found is just wrong. It may make difference between name does not exist (NXDOMAIN status) and record type does not exist (NOERROR status but no answer). But it should not say not found, at least not for DNS. Because it was found no such name exist and that is definitive answer. It may be different on multicast protocols, where it does mean nobody answered for such name. But unicast DNS makes clear difference between failure (SERVFAIL, REFUSED or just timeout) and negative answer.

[dreua]

I think this is going off topic / should be discussed in it's own issue.

Edit: I see you just created a new issue for this sub-problem, thanks! 👍

I'd like to second the need for a --verbose / --debug flag, that's why I upvoted and subscribed here some time ago. In my case there are spurious resolve issues every few weeks which are gone after a reload, i.e. restarting resolved in debug mode doesn't help as the issue is not reproducible any more. Getting some more information through resolvectl would certainly help in these cases.

[pemensik]

I admit it would be great if resolvectl --debug could just temporary change log level. Something like this command:
LOGLEVEL=$(resolvectl log-level) && resolvectl log-level debug && resolvectl query example.org && resolvectl log-level ${LOGLEVEL}

It may increase log level or verbosity level and return it back when the command is finished. Somehow more difficult would be to include messages done by systemd-resolved daemon in the command output. But maybe that part is not so important.

[davispuh]

Why do you think it failed? It may be just vague terminology. But I assume this message is result of status: NXDOMAIN dns query, which just means that name does not exist. It is not error, it is just negative response.

Because issue is with something related with systemd-resolved. If I query DNS server directly bypassing resolved then it works fine.

Didn't realize there's resolvectl log-level debug and then after enabling it shows more info in journal.

[waynegemmell]

+1. Just being able to see what server the query went to and the response from that server with a --verbose flag would be useful.

[afras-kc]

+1