Unbound DNS Resolver - Not caching?
-
did you snip out something.. or is that really xxx.com ?
The AAAA is easy, whatever you were using to go to cnn.com did a AAAA query (ipv6)..
as to the xxx.com I would guess you got something working through a suffix search and adding that to your queries.. And the suffix your using is actually resolvable on the public side
So your suffix is prob int.xxx.com, so it did query for those, and it also did query for the parent of that xxx.com which it attaches to what you really looked for.. Which is why you see
cnn.com.int.xxx.com
cnn.com.xxx.comWith both A and AAAA
I would guess your using int.xxx.com as your internal domain. But is that really xxx or did you snip what it really was?
-
Ah yes, that makes sense.
I'm using int.domain.com as my internal home domain, while domain.com is an actual resolvable domain. That's probably why.
Does this mean that I'm doing a public lookup for my internal domain every time I make a lookup? Won't that double my response time on DNS queries?
I guess this is normal behavior and I shouldn't do anything about it?Unfortunately I just snipped the actual domain, I don't own xxx.com :'( :'( :'( ::) ;D
EDIT: "msg" entries only being added when using "nslookup". So browsing and other services does not seem to create these entries.
-
Well depends on your dns client and how you have your suffix search setup.. Depending on version of nslookup and you don't put the trailing . on your query then sure it might walk up your suffix list.
You could setup debug on it and watch what it does for example.
at your nslookup prompt do a
set debug
or better even for more info
set d2Now you will see what it asks and what it gets back. Browsers normally wont walk your suffix list, other applications might all depends.
If you really want to have some fun.. Do a wireshark so you can actually see the queries and responses. This is fun on the wan of pfsense so you can watch it walk from the roots down as it finds what your looking for.
DNS is one of my favorite things to play with… If you have any questions - I could talk about dns for hours and hours ;) heheheh especially if you get some beer and bourbon in me...
To be honest not a real fan of nslookup and its limited info and features. Dig is better tool, you can install on windows machine as well.. So you don't have to be limited to nslookup.
As to doing external queries.. Since unbound is not an authoritative server, and it has no record for what you did a query for - yes it would try and find it via the roots, and walk down.. Normally those suffix searches would be rare, but guess depending on your client sure if asking unbound for cnn.com.int.domain.com it would go and try and find that. One way to limit how far down the tree that would go would be to use a non public tld, for example i use .lan.. So as if I looked for cnn.com.local.lan unbound would get a NX back right away from roots when it was looking for the NS of .lan
But there should be a way to keep unbound from even asking for that if it does happen. Have to take a look see..
-
Thanks again, set d2 is excellent :)
It does indeed query for my domain 4 times. I'll mess around with this, quite interesting, as you point out
I'll swoosh by the states with a gallon of bourbon, it's merely an 8 hour flight ;D
-
see my edit.. I add some stuff about those queries going outbound.. I am heading back to the hotel, but will take a look tonight on if that really goes out and how to stop your local domain from going outbound.
I know for sure that my .lan tld would get past asking roots for it.. But just from wanting to be efficient and dnsleaking security concerns depending how tight your tinfoil hat is, if you try and search for blablah without a domain you wouldn't want it asking all the outside ns for blahblah.int.domain.com and then blahblah.doman.com
There might be something already preventing that, but will double check it.
-
Thanks a lot for your great replies, really helps me understand whats going on!
It would be nice if it would ignore the queries for the internal domain.
I tried setting```
server:private-domain: "int.domain.com"It might have something to do with this autogenerated line? **local-zone: "int.domain.com" transparent** Maybe it should be "static" in stead?? -
You are correct, static will return NX for a query that in your local domain that does not exist. To be honest this is prob a better default than transparent for the tinfoil hat dns guys that are concerned with leaking queries ;)
If set to the default transparent and you query something in your local domain, ie I did a query for noname.local.lan I got back NX from root with SOA.. You can verify that with simple sniff on your wan.
If you set this to static, you just get back NX from pfsense for stuff you query that is not in your local domain data. So yes this should stop queries outbound when suffix search that includes your local domain. You could also set it up to return your SOA if you wanted for that domain.. Just have to create the local data I believe.
But since you have a local subdomain setup, ie yours is int.domain.com, my take would be this would stop the query for cnn.com.int.domain.com, but I am not 100% sure on your query cnn.com.domain.com as you walk down your suffix search. I would test it to be sure.
Is there some specific reason you went with a subdomin, and use of a public tld? I find it better to use non public tld for local domains. But each their own, maybe you have a specific reason.. Lets say you owned domain.com, for me locally I would use say domain.lan, using of .local is problematic since apple ruined it for everyone ;)
But .locallan wold be fine.. anything really as your tld that is not public.. Which there are more and more of all the time. I find it unlikely that they would ever allow .lan - but you never know now that they let you register your own TLD if you have the $ maybe someone will scoop that one up?
-
I took the plunge and renamed my domain to "domain.lan". There was no particular reason for the "int.domain.com" domain name, so I decided to change it, to avoid further confusion.
It didn't remove the "msg" entries though, they're still there, just with the .lan extension in stead.
I have tried the different "local-zone" types (static, typetransparent), without any change in the way the results are returned. I've been using the unbound.conf(5) man page for reference.
I guess the answer here is that nslookup on Windows will include the DNS suffix search to the upstream NS. Unbound sees this as a legitimate query and forwards it. No harm done really, since it's not affecting a standard DNS->IP lookup using browsers, tablets, phones, etc.
-
If u change to static it will not send upstream. Keep in mind u will have cache so once u change u have to query new host or wait til ttl expires
-
Using "Static":
orange.com. 86398 IN A 185.63.192.20 orange.com. 3598 IN SOA a4.nstld.com. dnssupport.verisign-grs.com. 2284794609 28800 7200 1209600 86400 orange.com. 86398 IN NS j4.nstld.com. orange.com. 86398 IN NS k4.nstld.com. orange.com. 86398 IN NS a4.nstld.com. orange.com. 86398 IN NS l4.nstld.com. orange.com. 86398 IN NS h4.nstld.com. orange.com. 86398 IN NS g4.nstld.com. orange.com. 86398 IN NS f4.nstld.com. msg orange.com. IN A 32896 1 86398 3 1 1 0 orange.com. IN A 0 orange.com. IN NS 0 msg orange.com. IN AAAA 32896 1 3598 3 0 1 0 orange.com. IN SOA 4Using "Transparent":
blue.com. 1794 IN A 104.236.7.74 blue.com. 1794 IN SOA ns1.digitalocean.com. hostmaster.blue.com. 1429203160 10800 3600 604800 1800 blue.com. 172794 IN NS ns1.digitalocean.com. blue.com. 172794 IN NS ns2.digitalocean.com. blue.com. 172794 IN NS ns3.digitalocean.com. msg blue.com.domain.lan. IN AAAA 32899 1 3594 4 0 3 0 msg blue.com.domain.lan. IN A 32899 1 3594 4 0 3 0 msg blue.com. IN A 32896 1 1794 3 1 0 0 blue.com. IN A 0 msg blue.com. IN AAAA 32896 1 1794 3 0 1 0 blue.com. IN SOA 4It still creates the "msg" entries, but omits the domain.lan when using "Static". Do you suggest I keep it at "Static"??
-
Huh?? What does static have to do with looking up domains? on the public internet??
What is your concern with msg? Yes you still did a query for blue.com.domain.com to unbound.. That is your client, that has nothing to do with unound.. What you don't want is unbound sending that query blue.com.domain.com upstream.. Which as static it will not, as transparent it will.
-
I get it. Was just wondering if static would be a better choice for me, rather than transparent.
Thanks for you assistance :)
-
Depends.. If you you have domain.lan, and you have something that adds suffix do you want that searching going out to the roots to try and look up?
So for example if your client asks for cnn.com.domain.lan do you want unbound to try and find that? Or do you want it to respond with NX since it has no record for it?
If you look for nohostyouhave.domain.lan do you want unbound to ask roots trying to find it?
So I run static, with SOA entry.. So when I try and lookup something that is not in my dns but in my domain local.lan I get this.. so if something gets looked up and for whatever reason the app or whatever adds my local suffix it to it, unbound just sends back NX vs sending it on anywhere. 2nd pic example
All comes down to what you want..
-
I would like to have it configured, so I don't send those request out. So I guess "Static" with SOA is the way to go.
How to add SOA for my domain in unbound?
-
Another thing, that I'm hoping you might have the answer to :)
After enabling the DNS resolver, I'm getting hundreds of firewall entries concerning DNS.
The source IP's seem to be DNS servers operated by my ISP, but I don't know why they're trying to return a query to me on a non-established port. I'm not using the ISP DNS servers, I should be querying root servers only.
I have attached a screenshot of the firewall log.
-
You can create a SOA record in the advanced option.. Attached you will see mine.
As to those blocks.. I would sniff on your wan and see what is going on.. Grab those packets and open them up in wireshark, etc.. What is the data in them? If something was actually creating the queries, then they shouldn't be blocked they should be allowed, etc. So yeah its a bit odd.. Maybe your isp is trying to do some sort of intercept on your dns queries and sending them back? So your not actually talking to roots.. But normally in this case queries fail..
As I said before watching dns traffic on your wan with a sniffer can be quite enlightening to what is actually going on.
The include is something you don't need, that is me just loading up domains I redirect to loopback to block ad domains.. pfblocker does such a thing, but it redirects to service running on pfsense that serves up 1x1 image, not something I need/want.. So I just send back loopback if anything tries to lookup a ad domain, etc.
> dig something.zmedia.com ; <<>> DiG 9.10.3-P4 <<>> something.zmedia.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30873 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;something.zmedia.com. IN A ;; ANSWER SECTION: something.zmedia.com. 3600 IN A 127.0.0.1 ;; Query time: 0 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Sun May 22 06:55:20 Central Daylight Time 2016 ;; MSG SIZE rcvd: 65
-
Thanks a million. I actually started a capture and while analysing your reply ticked in :)
I will try the SOA record, do I also need to add the "root.local.lan" you have in the SOA?
EDIT: mine looks like this now local-data: "domain.lan. 10800 IN SOA pfsense.domain.lan. 1 3600 1200 604800 10800"
As to the weird DNS.
I had a firewall alias with a friends DDNS address which I resolved to allow him access to my plex server. According to the packet capture, that DDNS address does not exist. The following ip addresses was hitting my WAN from port 53 with a reply:
195.215.95.7
195.215.95.8
195.215.95.12
195.215.95.11
195.215.95.6I have attached the wireshark screenshot.
Removing the DDNS address from the alias has solved that problem :)
You're the man, might consider dropping by with that bourbon :D :P
-
Well a SOA needs an email address to be valid atleast I believe it does, can be anything you want it to be. I don't think its valid without that? Your saying it loads and gets returned when you look up something that is not a valid record in your domain?
The SOA resource record contains the following information:
Source host - The host where the file was created.
Contact e-mail - The e-mail address of the person responsible for administering the domain's zone file. Note that a "." is used instead of an "@" in the e-mail name.
Serial number - The revision number of this zone file. Increment this number each time the zone file is changed. It is important to increment this value each time a change is made, so that the changes will be distributed to any secondary DNS servers. (since you don't have any secondary servers there will be no need to change your serial number going forward)
Refresh Time - The time, in seconds, a secondary DNS server waits before querying the primary DNS server's SOA record to check for changes. When the refresh time expires, the secondary DNS server requests a copy of the current SOA record from the primary. The primary DNS server complies with this request. The secondary DNS server compares the serial number of the primary DNS server's current SOA record and the serial number in it's own SOA record. If they are different, the secondary DNS server will request a zone transfer from the primary DNS server. The default value is 3,600.
Retry time - The time, in seconds, a secondary server waits before retrying a failed zone transfer. Normally, the retry time is less than the refresh time. The default value is 600.
Expire time - The time, in seconds, that a secondary server will keep trying to complete a zone transfer. If this time expires prior to a successful zone transfer, the secondary server will expire its zone file. This means the secondary will stop answering queries, as it considers its data too old to be reliable. The default value is 86,400.
Minimum TTL - The minimum time-to-live value applies to all resource records in the zone file. This value is supplied in query responses to inform other servers how long they should keep the data in cache. The default value is 3,600.
So those servers were answering that the record you were asking them about is NX? What were they returning exactly, was unbound actually sending them a query? So when your aliases were updating they were asking them about the record? So what do you have pfsense pointing to for dns? Only ns that pfsense can use in my setup is itself (resolver) it has no entries in general, it only has 127.0.0.1 listed as dns. And I don't allow dhcp on the wan to overwrite any dns info.
If you were actually sending them a query, not sure why it would of been listed as blocked in your firewall log? If they were sending you traffic that pfsense did not expect, then sure it should be blocked.
-
Thanks for your reply.
So you are saying that my SOA record local-data: "domain.lan. 10800 IN SOA pfsense.domain.lan. 1 3600 1200 604800 10800" is missing information? Can you guide me through how to add the relevant data to the entry?
As to the weird DNS. I will have to enable that alias once again and check. I also wondered why I was hammered with replies. From what I remember, I had not sent a query out.
On my General page in pfSense I have listed some DNS servers, see screenshot.
EDIT: Added screenshots of the same queries you did in your post above. (https://forum.pfsense.org/index.php?topic=112160.msg625069#msg625069)
-
there is no point to those other servers if your wanting all queries to go through unbound. If pfsense asks those server its not going to be able to resolve your local entries.
Yeah see your not getting a SOA returned when you ask for something that is not in your domain, so yeah that SOA is not loading or is invalid because its missing your email address.
Just add your email address to your record. Whatever email you want, does not have to be valid to be honest, just replace the @ with . So the way mine reads is root@local.lan
ocal-data: "domain.lan. 10800 IN SOA pfsense.domain.lan. root.domain.lan. 1 3600 1200 604800 10800"
So you see when I ask for something that is no in my local.lan I get back a SOA along with the NX.
There is nothing say you need to do this, it just makes it easy to see right away that what you queried was really NX and what the authoritative server was is all.
