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.
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
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:
or use aking1012's great suggestion:
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:
Returns:
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:
returns:
full domain name servers are configured with the address of at least one root server.
returns:
;; AUTHORITY SECTION:
co
returns
and
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.