All unkown DNS queries resolve to firewall.
-
All unknown queries for ping etc resolve to my firewall. For example:
ping asdfasdfasdfasdf PING home.xxxxxxx.xx (my external firewall IP) 56(84) bytes of data. 64 bytes from xxx.boid.qwest.net (xxx): icmp_seq=1 ttl=64 time=0.247 ms
I can't seem to figure out what option does this, or what I have misconfigured. I use dynamic DNS and use AWS Route 53 to bind the subdomain home.xxxxxxx.xx to my firewall. I also do have *.home.xxxxxxx.xx resolved to my firewall but I still don't understand why all hosts resolve to the firewall. Thank you in advance!
-
So after a little more testing I realized this is only happening on one of my machines. My linux ubuntu 18.04 machine. Maybe I have something configured incorrectly only on this machine?
➜ cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "systemd-resolve --status" to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 search home.xxxxxx.xx
vs my mac:
? cat /etc/resolv.conf # # macOS Notice # # This file is not consulted for DNS hostname resolution, address # resolution, or the DNS query routing mechanism used by most # processes on this system. # # To view the DNS configuration used by this system, use: # scutil --dns # # SEE ALSO # dns-sd(1), scutil(8) # # This file is automatically generated. # domain home.xxxxxxx.xx nameserver 192.168.1.1
-
@jd-schmidt said in All unkown DNS queries resolve to firewall.:
I also do have *.home.xxxxxxx.xx resolved to my firewall
So if you have a wildcard setup like that, and you client does suffix searching and you just ping some gibberish like sljfaslsjdf, that itself can not resolve so you client will add its search suffix to that.. So if you seach suffix is it would do a query for sljfaslsjdf.home.xxxxxxx.xx
So yeah it would return whatever IP you have your wildcard set to return...
-
@johnpoz Thank you for the reply, I am pretty new to networking, is this bad practice? Should I just resolve home.xxxx.xx to the firewall, and then any other home network stuff I want exposed publicly to aws route53 and not use a wildcard? For example:
Say I had website1.home.xxx.xx and service2.home.xxx.xx Should I only be adding those 2 individual mappings and not use a wildcard? -
Its bad practice to be honest to use the same internal domain as external.. While it can be done, it leads to issues like what your seeing where internal resolves the public IP, or external stuff doesn't even resolve at all, etc.
While some like to use a sub like home.domain.tld vs just domain.tld - which sure can work, it can lead to issues with recursive suffix searches returning the wrong things, especially if wildcards are in play.
What I would suggest you do is use a different tld or domain completely... so for example if you own domain.com, use say domain.net internally (if you own and control domain.net) and have no outside records for it. Better yet would be to use a completely non public tld, so you own domain.com use say domain.localdomain or .lan (currently not public).. But don't use .local as your tld, this is a special use case tld and not good idea to try and leverage this locally for your own domain stuff. But to be honest prob the best practice right now would be to use the home.arpa domain, so say domain.home.arpa would be your local domain.
https://tools.ietf.org/html/rfc8375
This is the domain that has been called out for special use for home use..
At some point I will switch all my stuff to it, but currently since I use local.lan and .lan is not a valid public tld.. I doubt it will ever be a public tld.. But never hurts to follow the rfcs ;)
Also yes its considered bad practice to use any rfc1918 in a public domain..
As to a tip also, the default zone type in unbound is transparent... This means if there is no local record for whatever.domain.tld - it will try to resolve that public.. Which unless you have something in this domain that would resolve to something elsewhere say you have www.domain.tld host out on some webspace something. You prob want to set the zone type to static in unbound. This means that if whatever you query for is not a local record.. you will just get back nx..
Specific example I use local.lan, so if I look up something.local.lan and there is local record I get returned the local IP for it. but if I look up whatever.local.lan and there is no local record unbound will try and resolve that, so it will ask the roots for hey who is the NS for .lan - and it will get told, sorry buddy no such thing... But its still a wasted query, since yeah we know there is no ns for .lan tld. So I have the zone set to static.. This prevents unbound from ever trying to resolve anything.local.lan that is not in its local records.
-
Thanks @johnpoz, I really appreciate this complete and thorough answer! Thanks so much I'll work on getting things switched over to home.arpa.