Please, help me figure out which nameserver I'm actually querying
-
What's the IP address of the nameserver that is actually resolving my requests??
My pfSense box is set up as follows:
System -> General Setup
Services -> DNS Resolver -> General Settings
dig yahoo.com from a shell on pfSense tells me I'm querying 127.0.0.1
My question is: which nameserver is localhost querying??
Thank you.
-
You are using the resolver.
It starts at the root and works hierarchically from there.
dig -4 +trace +nodnssec yahoo.com a ; <<>> DiG 9.11.1-P1 <<>> -4 +trace +nodnssec yahoo.com a ;; global options: +cmd . 123723 IN NS e.root-servers.net. . 123723 IN NS d.root-servers.net. . 123723 IN NS b.root-servers.net. . 123723 IN NS l.root-servers.net. . 123723 IN NS k.root-servers.net. . 123723 IN NS j.root-servers.net. . 123723 IN NS h.root-servers.net. . 123723 IN NS f.root-servers.net. . 123723 IN NS a.root-servers.net. . 123723 IN NS m.root-servers.net. . 123723 IN NS i.root-servers.net. . 123723 IN NS c.root-servers.net. . 123723 IN NS g.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 31 ms com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 834 bytes from 192.5.5.241#53(f.root-servers.net) in 8 ms yahoo.com. 172800 IN NS ns1.yahoo.com. yahoo.com. 172800 IN NS ns5.yahoo.com. yahoo.com. 172800 IN NS ns2.yahoo.com. yahoo.com. 172800 IN NS ns3.yahoo.com. yahoo.com. 172800 IN NS ns4.yahoo.com. ;; Received 292 bytes from 192.52.178.30#53(k.gtld-servers.net) in 203 ms yahoo.com. 1800 IN A 206.190.36.45 yahoo.com. 1800 IN A 98.139.180.149 yahoo.com. 1800 IN A 98.138.253.109 yahoo.com. 172800 IN NS ns5.yahoo.com. yahoo.com. 172800 IN NS ns1.yahoo.com. yahoo.com. 172800 IN NS ns2.yahoo.com. yahoo.com. 172800 IN NS ns4.yahoo.com. yahoo.com. 172800 IN NS ns3.yahoo.com. ;; Received 340 bytes from 98.138.11.157#53(ns4.yahoo.com) in 68 ms
-
"actually resolving my requests??"
As Derelict correctly states you walk down the tree from roots to end up at an authoritative ns for domain your doing the query in.. So in the yahoo example - when you finally to the authoritative it would be one of these.
dig yahoo.com NS
; <<>> DiG 9.11.2 <<>> yahoo.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18101
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 9;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com. IN NS;; ANSWER SECTION:
yahoo.com. 172800 IN NS ns4.yahoo.com.
yahoo.com. 172800 IN NS ns1.yahoo.com.
yahoo.com. 172800 IN NS ns3.yahoo.com.
yahoo.com. 172800 IN NS ns2.yahoo.com.
yahoo.com. 172800 IN NS ns5.yahoo.com.;; ADDITIONAL SECTION:
ns1.yahoo.com. 86400 IN AAAA 2001:4998:130::1001
ns2.yahoo.com. 86400 IN AAAA 2001:4998:140::1002
ns3.yahoo.com. 86400 IN AAAA 2406:8600:b8:fe03::1003
ns1.yahoo.com. 1209600 IN A 68.180.131.16
ns2.yahoo.com. 1209600 IN A 68.142.255.16
ns3.yahoo.com. 1209600 IN A 203.84.221.53
ns4.yahoo.com. 1209600 IN A 98.138.11.157
ns5.yahoo.com. 1209600 IN A 119.160.247.124;; Query time: 337 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Sep 21 07:39:12 Central Daylight Time 2017
;; MSG SIZE rcvd: 292After you walked down the tree to get there - you can see those at the end of Derelicts trace.
-
I see… thanks to both of you!
Please, guide me through this and tell me if my understanding is correct: unbound (dns resolver) is querying the root nameservers because that's how it's configured by default.
If so I have two more questions:-
is it safe to assume that querying my ISP's DNS servers rather than the root nameservers I get responses faster?
-
if true, how would I go about configure unbound to query my ISP's DNS servers instead of the root nameservers?
Thank you!
-
-
"is it safe to assume that querying my ISP's DNS servers rather than the root nameservers I get responses faster?"
Your talking milliseconds of differences here, and only on a first query of something that is not cached. And if your isp does not have it cached you gain really nothing at all anyway. And use of a forwarder means most likely you give up dnssec, which is validation that the info you get back is what the owners of the domain want you to get, etc.
Unless you were on some really high latency network, like sat or something there is no benefit to just using a forwarder. And many disadvantages of doing so..
The reason pfsense defaults to using resolver is it the best choice. But if you insist then set unbound to forwarder mode, or just change over to using the forwarder vs unbound. Turn off resolver (unbound) and enable forwarder (dnsmasq)..
-
Thank you for your reply.
I want to keep using unbound, not switch to dnsmasq, I just want to know how to configure pfSense so that it queries my ISP's nameservers rather than the root nameservers when it doesn't find a cached answer.
Thank you.
-
Check this box. It will use the servers set in System > General
-
Check this box. It will use the servers set in System > General
Thank you!
If I do that, will unbound still serve me cached answers for recent queries?
-
Yes.
Also uncheck DNSSEC.
-
You do understand if your isp doesn't have what your looking for cached - it has to at some point in the chain hit a resolver that actually resolves. Your talking about a few ms, your never going to notice the difference. And now you give up dnssec..
And to be quite honest many a isp dns kind of blow chunks ;) Resolver is really the best solution no matter how you look at it.. Are you on some high latency sort of connection?
-
Are you on some high latency sort of connection?
No, I'm not :-)
I was just asking because I want to understand how it works.
I'm probably going to stick with unbound querying the root nameservers, as everybody here is suggesting.
So, to put it in layman's terms, querying root nameservers is better because it leverages secure DNS, right?
-
Entire books have been written on this subject:
https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=dns+%26+bind
-
^ exactly.. The dns & bind is a great book.. I do believe I have a 2nd edition on one of my shelves at home.. Could let you have it cheap ;)
-
Are you on some high latency sort of connection?
No, I'm not :-)
I was just asking because I want to understand how it works.
I'm probably going to stick with unbound querying the root nameservers, as everybody here is suggesting.
So, to put it in layman's terms, querying root nameservers is better because it leverages secure DNS, right?Exactly, by querying the authoritative servers directly you are getting the answers "straight from the horse's mouth" so to speak. When using forwarders you're trusting the security of your DNS to somebody else.
-
Also with the dns leak being such a buzz word lately.. Your not feeding every query you do to some specific forwarder, be it your isp or google or open, etc. Your spreading out your dns to all the different authoritative servers.
So unless someone was actually sniffing your traffic as it leaves your network, it would be more difficult for them to put together a comprehensive list of what dns you query for..
There really is no draw back to just running your own resolver and cutting out all the middlemen forwarders.. And you also don't have to worry about the forwarders you using going down.. When you forward, if the forwarder is down - your down you can not query anything. With a resolver sure you might have a problem if a specific domains dns is down for that specific domain. But if roots are down the whole internet would be broke anyway..
-
Reading this thread I got confused over the need to set upstream DNS hosts given that unbound queries the root servers directly. Are they there just in case someone configures the forwarder to work instead?
No doubt you guys will want to slap me over the head, but I'll ask the following anyhow:
Web sites and streaming services seem to geo-locate a pfS box running unbound. Are they working the source of its connection requests, or is it just the server IP that gets resolved and thus connected to?
IIRC, specifying upstream DNS servers from a geo-dns-unblocking service will work when streaming services and web-sites try to provide content specific to the browser location. Is unbound using the user-specified forwarders in some instances (?), or is it because it queries root nameservers in the local region?
If so, how can one get it to query non-local ones?
Unless it is unbound's IP address that is being 'sensed'
-
Every single outgoing connection from your pfSense system carries the public IP address bound on the WAN IP in the "source address" field of the IP packets, including DNS queries. This can't be avoided no matter what you try unless you use some form of VPN to hide your real IP address.
What this means with DNS queries is that if you're using forwarders (set in the unbound configuration as "forwarding mode") your public IP address is carried only to the forwarders that you have set and no further. If you're using the resolver mode instead without forwarders your queries are seen first by the root servers, then the TLD name servers and finally by the authoritative servers for the domain you're resolving. That is where the destination server can sense your Geolocation based on the source IP address of your DNS queries.
-
"If so, how can one get it to query non-local ones?"
If your asking how to use different dns servers to circumvent geo restrictions when using resolver, you should really start a different thread since that is outside the scope of what was asked by the OP.
You can use a domain override if you want unbound to ask a specific nameserver for a specific domain.. So that you get a different IP then what doing answer than what your query resolves to when asking the authoritative server from your own IP.
-
Thanks @johnpos, @kpa, that is most helpful. One of the challenges of the forum is all the dynamic dns and (increasingly important) client resolution info (local resolver & forwarder config), not to mention DHCP questions. Thanks for taking the time to answer my question. You really helped me out.
-
You can get info directly from unbound about how it's resolving as well.
Normal resolver mode example (I just looked up google.com):
: unbound-control -c /var/unbound/unbound.conf dump_infra 216.239.34.10 google.com. ttl 894 ping 9 var 71 rtt 293 rto 293 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 2001:500:12::d0d . ttl 894 ping 0 var 94 rtt 376 rto 376 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 2001:503:d414::30 com. ttl 894 ping 0 var 94 rtt 376 rto 376 tA 0 tAAAA 0 tother 0 ednsknown 0 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.58.128.30 . ttl 894 ping 47 var 136 rtt 591 rto 591 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.36.148.17 . ttl 894 ping 5 var 81 rtt 329 rto 329 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 216.239.38.10 google.com. ttl 894 ping 11 var 59 rtt 247 rto 247 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 216.239.32.10 google.com. ttl 894 ping 9 var 71 rtt 293 rto 293 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.12.94.30 com. ttl 894 ping 12 var 94 rtt 388 rto 388 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 192.52.178.30 com. ttl 894 ping 29 var 129 rtt 545 rto 545 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0: unbound-control -c /var/unbound/unbound.conf lookup . The following name servers are used for lookup of . ;rrset 86383 13 1 8 0 . 518383 IN NS a.root-servers.net. . 518383 IN NS b.root-servers.net. . 518383 IN NS c.root-servers.net. . 518383 IN NS d.root-servers.net. . 518383 IN NS e.root-servers.net. . 518383 IN NS f.root-servers.net. . 518383 IN NS g.root-servers.net. . 518383 IN NS h.root-servers.net. . 518383 IN NS i.root-servers.net. . 518383 IN NS j.root-servers.net. . 518383 IN NS k.root-servers.net. . 518383 IN NS l.root-servers.net. . 518383 IN NS m.root-servers.net. . 518383 IN RRSIG NS 8 0 518400 20171031140000 20171018130000 46809 . Ue/V7yyrQirgsXdZIAoYcx2u20SdhJxhhXuCVZt90SQI1GvulljiLeqr/bF+RNnrKrDJQBnc5c3CDwjffAYUz9Bcx0n7+oEoK+yfVoPSbqwTqcTUL9pyYDb9i4ClMKTW/y8+qKvKd8qBJYEJxcfMVxm2BsPIm0dmioPr2cRwN98m5EVNO8HoGXbx7sC5te7VUoxwOnl8r0gdeJo9f8YLUZAlNzwwQzMCwzHtbweechzrDj3JSi0cIKrKLuEXK6Rvsw12w/fiNk5l9drgmpgW65aKNsDgLP8HhmSaV8BH9P9jh7vH7uElDQEN50jZjuM1wqCOG8JMpyhNKV/kyQmQng== ;{id = 46809} ;rrset 86383 1 0 3 0 m.root-servers.net. 518383 IN A 202.12.27.33 ;rrset 86383 1 0 3 0 m.root-servers.net. 518383 IN AAAA 2001:dc3::35 ;rrset 86383 1 0 3 0 l.root-servers.net. 518383 IN A 199.7.83.42 ;rrset 86383 1 0 3 0 l.root-servers.net. 518383 IN AAAA 2001:500:9f::42 ;rrset 86383 1 0 3 0 k.root-servers.net. 518383 IN A 193.0.14.129 ;rrset 86383 1 0 3 0 k.root-servers.net. 518383 IN AAAA 2001:7fd::1 ;rrset 86383 1 0 3 0 j.root-servers.net. 518383 IN A 192.58.128.30 ;rrset 86383 1 0 3 0 j.root-servers.net. 518383 IN AAAA 2001:503:c27::2:30 ;rrset 86383 1 0 3 0 i.root-servers.net. 518383 IN A 192.36.148.17 ;rrset 86383 1 0 3 0 i.root-servers.net. 518383 IN AAAA 2001:7fe::53 ;rrset 86383 1 0 3 0 h.root-servers.net. 518383 IN A 198.97.190.53 ;rrset 86383 1 0 3 0 h.root-servers.net. 518383 IN AAAA 2001:500:1::53 ;rrset 86383 1 0 3 0 g.root-servers.net. 518383 IN A 192.112.36.4 ;rrset 86383 1 0 3 0 g.root-servers.net. 518383 IN AAAA 2001:500:12::d0d ;rrset 86383 1 0 3 0 f.root-servers.net. 518383 IN A 192.5.5.241 ;rrset 86383 1 0 3 0 f.root-servers.net. 518383 IN AAAA 2001:500:2f::f ;rrset 86383 1 0 3 0 e.root-servers.net. 518383 IN A 192.203.230.10 ;rrset 86383 1 0 3 0 e.root-servers.net. 518383 IN AAAA 2001:500:a8::e ;rrset 86383 1 0 3 0 d.root-servers.net. 518383 IN A 199.7.91.13 ;rrset 86383 1 0 3 0 d.root-servers.net. 518383 IN AAAA 2001:500:2d::d ;rrset 86383 1 0 3 0 c.root-servers.net. 518383 IN A 192.33.4.12 ;rrset 86383 1 0 3 0 c.root-servers.net. 518383 IN AAAA 2001:500:2::c ;rrset 86383 1 0 3 0 b.root-servers.net. 518383 IN A 192.228.79.201 ;rrset 86383 1 0 3 0 b.root-servers.net. 518383 IN AAAA 2001:500:200::b ;rrset 86383 1 0 3 0 a.root-servers.net. 518383 IN A 198.41.0.4 ;rrset 86383 1 0 3 0 a.root-servers.net. 518383 IN AAAA 2001:503:ba3e::2:30 Delegation with 13 names, of which 0 can be examined to query further addresses. It provides 26 IP addresses. 2001:503:ba3e::2:30 not in infra cache. 198.41.0.4 not in infra cache. 2001:500:200::b not in infra cache. 192.228.79.201 not in infra cache. 2001:500:2::c not in infra cache. 192.33.4.12 not in infra cache. 2001:500:2d::d not in infra cache. 199.7.91.13 not in infra cache. 2001:500:a8::e not in infra cache. 192.203.230.10 not in infra cache. 2001:500:2f::f not in infra cache. 192.5.5.241 not in infra cache. 2001:500:12::d0d rto 376 msec, ttl 883, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 192.112.36.4 not in infra cache. 2001:500:1::53 not in infra cache. 198.97.190.53 not in infra cache. 2001:7fe::53 not in infra cache. 192.36.148.17 rto 329 msec, ttl 883, ping 5 var 81 rtt 329, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:503:c27::2:30 not in infra cache. 192.58.128.30 rto 591 msec, ttl 883, ping 47 var 136 rtt 591, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:7fd::1 not in infra cache. 193.0.14.129 not in infra cache. 2001:500:9f::42 not in infra cache. 199.7.83.42 not in infra cache. 2001:dc3::35 not in infra cache. 202.12.27.33 not in infra cache.Forwarding mode example:
: unbound-control -c /var/unbound/unbound.conf dump_infra 8.8.4.4 . ttl 274 ping 12 var 32 rtt 140 rto 140 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 8.8.8.8 . ttl 295 ping 29 var 39 rtt 185 rto 185 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 198.51.100.1 . ttl 274 ping 23 var 39 rtt 179 rto 179 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0 203.0.113.1 . ttl 274 ping 17 var 30 rtt 137 rto 137 tA 0 tAAAA 0 tother 0 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0: unbound-control -c /var/unbound/unbound.conf lookup . The following name servers are used for lookup of . forwarding request: Delegation with 0 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 198.51.100.1 rto 179 msec, ttl 270, ping 23 var 39 rtt 179, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 203.0.113.1 rto 137 msec, ttl 270, ping 17 var 30 rtt 137, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 8.8.4.4 rto 140 msec, ttl 270, ping 12 var 32 rtt 140, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 8.8.8.8 rto 185 msec, ttl 291, ping 29 var 39 rtt 185, tA 0, tAAAA 0, tother 0, EDNS 0 probed.
