Why does dig not show the authority section and how to make it show the authoritative name servers that hold the DNS query`s answer?

Solution 1:

More exactly, I'd like to see the authoritative name servers (their names or IP addresses) that hold the answers to my DNS queries and I don't know how.

It all depends on which nameserver you query. If you don't specify any with the @ flag it uses the local recursive one to give you the final answer. This answer may have been computed by the recursive nameserver querying many different authoritative nameservers before coming to the answer, so there is not "one" authoritative nameserver in this scenario.

If you can dig with +trace it will behave itself like a recursive nameserver and will show you each step of the resolution, with each authoritative nameserver being queried and its answer.

The one that interests me is the AUTHORITY section which normally should show resource records of type NS (name server) that provide information about the authoritative name servers from which the answer to the initial query is retrieved.

It is more complicated than that. It depends which nameserver you are querying, and what query you do.

Let us use serverfault.com as example (and remember dig does an A record type query by default), and compare between recursive nameserver, authoritative on name, authoritative on parent.

Asking a recursive nameserver

$ dig serverfault.com  @9.9.9.9 +noall +auth +nottlunits
$

No data in AUTHORITY section, as expected. A recursive nameserver is not authoritative on the data, so it just gives you the answer you request.

Asking the zone authoritative nameservers

$ dig serverfault.com NS +short
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com.
ns-1135.awsdns-13.org.
ns-860.awsdns-43.net.
$ dig serverfault.com @ns-cloud-c1.googledomains.com. +noall +auth +nottlunits
$

No AUTHORITY either because you just do not need it, it is an optimization. Note that if you query the AWSDNS nameservers, you will get an AUTHORITY section, but it is not useful.

Asking the parent authoritative nameservers

$ dig com. NS +short
b.gtld-servers.net.
k.gtld-servers.net.
d.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
f.gtld-servers.net.
h.gtld-servers.net.
c.gtld-servers.net.
e.gtld-servers.net.
g.gtld-servers.net.
m.gtld-servers.net.
a.gtld-servers.net.
l.gtld-servers.net.
$ dig serverfault.com @g.gtld-servers.net. +noall +auth +nottlunits
serverfault.com.    172800 IN NS ns-860.awsdns-43.net.
serverfault.com.    172800 IN NS ns-1135.awsdns-13.org.
serverfault.com.    172800 IN NS ns-cloud-c1.googledomains.com.
serverfault.com.    172800 IN NS ns-cloud-c2.googledomains.com.

Here you will always (no matter which of the above nameservers you query) get an AUTHORITY section (and no ANSWER section in fact) because these nameservers do not have the answer to your query as they are not authoritative on the name but they do know a delegation exists so they give you back in AUTHORITY the list of nameservers you should query instead.

This is all normal DNS delegation workflow.

PS:

I would put an image of the terminal but I don`t have yet 10 reputation

No, don't put an image no matter what. A terminal is lines of text. Copy and paste relevant ones, AS TEXT, in any question. Absolutely do not attach a screenshot, this is bad on all aspects.

Solution 2:

I just realized, "dig" uses implicitly the name servers found in /etc/resolv.conf. These are the ones to which "dig" sends by default any DNS query. Thus, if I type for instance "dig google.com" I don't get any authority records in the output, but if I specify a certain name server to query by its IP address, like "dig @byte.byte.byte.byte google.com", it might happen to get an answer that contains a non-zero authority section. So, as far as I can understand till now, the output of "dig" command can vary widely depending on which name server you query and if the database of that server is defined to contain an authoritative record as answer to your query then you get authority records in the reply. Hope I`m not far from truth. If you spot any mistakes or information that might be added please add a comment.