3

With resolvconf, dig always shows the loopback address. Is there anyway to see which server is actually answering?

jokerdino
  • 41,320
Bryan Agee
  • 3,356
  • That dig shows the loopback address is not really because of resolvconf; it is simply because resolv.conf contains the loopback address. But your question is still a good one and there are good answers below. – jdthood Oct 29 '12 at 10:26

2 Answers2

4

Not that I am aware of.

You could use:
nmcli dev list iface *insert outbound interface name here* | grep IP4 | grep DNS as was suggested here.

It works for me.

A cleaner invocation that doesn't rely on entering the interface name is:
nmcli -f IP4 dev list | grep DNS

Community
  • 1
RobotHumans
  • 29,530
  • It is an old post but google brought me here. Your command didn't work for me (POP_OS 20) maybe it helps someone else:

    I had to do: nmcli -f IP4 dev show | grep DNS

     – markus Mar 21 '21 at 20:08
4

That line of dig simply tells you where dig went for the answer, not its ultimate source.

On your system, assuming it is Ubuntu 12.04 or later Desktop and you haven't disabled the local nameserver, dnsmasq is listening at the loopback address, port 53. Dnsmasq is a lightweight nameserver that uses other nameservers to resolve names.

To see the server it uses enter the following:

 fgrep dnsmasq /var/log/syslog* | fgrep using | fgrep -v 127.0.0.1

or use aking1012's great suggestion:

nmcli -f IP4 dev list | grep DNS

In my case that's my router/modem, also running a lightweight server, obtained from my router/modem's DHCP server. I would have to sign on to the router and use a router-specific method to find out which dns server it uses. (It's configured by my ISP to forward to their domain name server).

You can certainly override the domain name server your system uses with NetworkManager, or, if you use ifup instead of NetworkManager, in ifup's configuratino file /etc/network/interfaces.

Assuming the request is forwarded to your ISP, the ISP's name server may do a recursive lookup to determine the answers, or, less probably, forward a recursive request even further. This chain of recursive requests continues until a domain name server is reached which is willing and able to do the full recursive look-up. It ends, perhaps prematurely, if there is no full domain name server before you reach one willing to respond to recursive requests. Most domain name servers won't do them for you, but an ISP will do them for its customers and business domain name servers will do them for their domains. You could install one yourself under Ubuntu. Google's 8.8.8.8 open domain name service will, as well.

For any particular address I enter I might get the answer from dnsmasq if it has the answer in its cache, from my router/modem, if it has the answer in its cache, or from the ISP or beyond.

Like aking1012, I don't think you can trace back the answers dig returns.

If you want to know where such information might ultimately come from you may want to know where the source of authority information is kept for a domain.

As an example:

dig @8.8.8.8 -t soa bing.com

Returns:

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t soa bing.com    
; (1 server found)    
;; global options: +cmd    
;; Got answer:    
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59757    
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0    

;; QUESTION SECTION:
;bing.com.          IN  SOA    

;; ANSWER SECTION:    
bing.com.       43199   IN  SOA ns1.msft.net. msnhst.microsoft.com. 2012081301 1800 900 2419200 3600    

;; Query time: 155 msec    
;; SERVER: 8.8.8.8#53(8.8.8.8)    
;; WHEN: Sat Aug 25 01:10:26 2012    
;; MSG SIZE  rcvd: 91

So the authoritative source of information about the domain bing.com can come from either ns1.msft.net or msnhst.microsoft.com.

You can also track down information using the recursive algorithm a full domain name server does:

dig @8.8.8.8 -t ns "."

returns:

; ANSWER SECTION:    
.           20616   IN  NS  h.root-servers.net.    
.           20616   IN  NS  m.root-servers.net.    
.           20616   IN  NS  j.root-servers.net.    
.           20616   IN  NS  f.root-servers.net.    
.           20616   IN  NS  a.root-servers.net.    
.           20616   IN  NS  k.root-servers.net.    
.           20616   IN  NS  l.root-servers.net.    
.           20616   IN  NS  i.root-servers.net.    
.           20616   IN  NS  b.root-servers.net.    
.           20616   IN  NS  d.root-servers.net.    
.           20616   IN  NS  g.root-servers.net.    
.           20616   IN  NS  e.root-servers.net.    
.           20616   IN  NS  c.root-servers.net.

full domain name servers are configured with the address of at least one root server.

 dig @c.root-servers.net. -t ns "com"

returns:

;; AUTHORITY SECTION:
co

m.          172800  IN  NS  a.gtld-servers.net.    
com.            172800  IN  NS  b.gtld-servers.net.    
com.            172800  IN  NS  k.gtld-servers.net.    
com.            172800  IN  NS  d.gtld-servers.net.    
com.            172800  IN  NS  j.gtld-servers.net.    
com.            172800  IN  NS  h.gtld-servers.net.    
com.            172800  IN  NS  f.gtld-servers.net.    
com.            172800  IN  NS  c.gtld-servers.net.    
com.            172800  IN  NS  m.gtld-servers.net.    
com.            172800  IN  NS  l.gtld-servers.net.    
com.            172800  IN  NS  g.gtld-servers.net.    
com.            172800  IN  NS  e.gtld-servers.net.    
com.            172800  IN  NS  i.gtld-servers.net.    

;; ADDITIONAL SECTION:    
a.gtld-servers.net. 172800  IN  A   192.5.6.30    
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30    
b.gtld-servers.net. 172800  IN  A   192.33.14.30    
b.gtld-servers.net. 172800  IN  AAAA    2001:503:231d::2:30    
c.gtld-servers.net. 172800  IN  A   192.26.92.30    
d.gtld-servers.net. 172800  IN  A   192.31.80.30    
e.gtld-servers.net. 172800  IN  A   192.12.94.30    
f.gtld-servers.net. 172800  IN  A   192.35.51.30    
g.gtld-servers.net. 172800  IN  A   192.42.93.30    
h.gtld-servers.net. 172800  IN  A   192.54.112.30    
i.gtld-servers.net. 172800  IN  A   192.43.172.30    
j.gtld-servers.net. 172800  IN  A   192.48.79.30    
k.gtld-servers.net. 172800  IN  A   192.52.178.30    
l.gtld-servers.net. 172800  IN  A   192.41.162.30    
m.gtld-servers.net. 172800  IN  A   192.55.83.30    


dig @k.gtld-servers.net -t ns "google.com"

returns

;; AUTHORITY SECTION:
google.com.     172800  IN  NS  ns2.google.com.    
google.com.     172800  IN  NS  ns1.google.com.    
google.com.     172800  IN  NS  ns3.google.com.    
google.com.     172800  IN  NS  ns4.google.com.    

;; ADDITIONAL SECTION:    
ns2.google.com.     172800  IN  A   216.239.34.10    
ns1.google.com.     172800  IN  A   216.239.32.10    
ns3.google.com.     172800  IN  A   216.239.36.10    
ns4.google.com.     172800  IN  A   216.239.38.10

and

    dig @ns1.google.com -t a www.google.com

;; ANSWER SECTION:    
www.google.com.     604800  IN  CNAME   www.l.google.com.    
www.l.google.com.   300 IN  A   74.125.225.209    
www.l.google.com.   300 IN  A   74.125.225.208    
www.l.google.com.   300 IN  A   74.125.225.210    
www.l.google.com.   300 IN  A   74.125.225.212    
www.l.google.com.   300 IN  A   74.125.225.211

The Additional information section gives the domain name service address hints so it can easily find name servers.

the CNAME record says that the canonical name for the alias www.google.com is www.l.google.com.

Of course sites like google.com and msft.com do all kinds of things to distribute queries to various computers.

nanofarad
  • 20,717
John S Gruber
  • 13,336