DNS & NTP best practice (vlans & IoT)
-
Hi,
I just had an interesting chat with chatGPT about pfSense and DNS setup when having IoT devices with hardcoded DNS servers. It insisted that NAT was not needed for this to work, which made me wonder why I once went down that road...
Currently use
DNS Resolver with forwarding enabled&
This is my NAT rules;
- 'local_lans' is an Interface group
- local networks is an alias with all relevant lans
For the interface 'local_lans' I then have these rules
It feels a bit messy, or am I missing something? chatGPT indicated it could be done much simpler, but then again, it is not always correct.
My goal is as stated above to configure DNS to always use pfSense for name resolution, even when a device has hardcoded addresses.
Would what I have be the best way of doing this, or can it be done in a simpler way (as suggested)?
Thanks
-
@furom ok couple of things - ntp doesn't use tcp.
5353 is mdns - redirection of that isn't really going to work. Why would pfsense answer a mdns query? And mdns is going to be a multicast (its in the namd), local devices answer with their own info.
Trying to redirect dot (853) wouldn't work either. The client should for one be validating the cert of the name of the dns talking to.. Is pfsense going to present a cert with that name in it? That the client trusts?
If you don't want clients using some external dot server - block it.. mdns do you want the discovery to work across your vlans - setup avahi
How to redirect dns.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
-
@johnpoz Thanks... as I supposed, things that I can improve on :)
But other than mDNS and 853, does it look reasonable? -
@furom yeah you can always redirect normal dns, see the link.. And sure you can redirect ntp as well but it would never use tcp - so you could alter the rule to only do udp.
Another thing you could do with ntp, if they are looking for a specific ntp server via name - I had some "stupid" light bulbs that were trying to use the uk based ntp pool.. vs just generic pool, so I setup a host override for that to just point it to my local ntp. Why would I want my devices checking ntp servers in the uk, when I am in the us ;)
What a company is supposed to do if they want their product to use the ntp pool, is register a name with ntp pool.. Like pfsense.
https://www.pool.ntp.org/vendors.html
I have another host override for time-ios.apple.com for example.
-
@johnpoz Ok, cleaned up a bit
So essentially, if a device is locked at using 853 DNS, there is nothing one can do to redirect it to use whatever DNS one prefer? There is an option in the DNS Resolver options to respond to 853 requests, or do I misunderstand what that would be used for?
-
@furom said in DNS & NTP best practice (vlans & IoT):
So essentially, if a device is locked at using 853 DNS, there is nothing one can do to redirect it to use whatever DNS one prefer? There is an option in the DNS Resolver options to respond to 853 requests, or do I misunderstand what that would be used for?
Think I got this, almost. Can't say I fully understand this note in the docs... "Activating this option disables automatic interface response routing behavior, thus it works best with specific interface bindings."
Does it mean I should set up some interface where only 853 capable clients go? -
@furom said in DNS & NTP best practice (vlans & IoT):
There is an option in the DNS Resolver options to respond to 853 requests
yeah you could use that for your own clients, internal dns that actually pointed to your fqdn, and you have a cert that has info in it that your client would trust..
The whole point of dot and doh, other than just encryption of the traffic is validation that your talking to who you think your talking to - the client should be validating the cert being used has the name they are talking to in it, and signed by a ca they trust.
If the client is not validating that they are talking to who they are suppose to be talking to - then sure it could work. But that is a pretty shitty dot client to be honest. Normally dot is not used by clients anyway, doh is used by clients. Dot is more meant for a dns server to use to where they forward too.
Clients like doh better anyway because its easier to sneak the traffic through any firewall because it uses just the 443 port, and can look like any normal https traffic. While dot is very easy to stop by just blocking the 853 port.
edit: here is a post I did not that long ago touching on the validation that should be done with a dot client, etc
https://forum.netgate.com/post/1079355
if you don't want to read through that, here is the take away when the name doesn't match
;; DEBUG: TLS, The certificate is NOT trusted. The name in the certificate does not match the expected. ;; WARNING: TLS, handshake failed (Error in the certificate.) -
@johnpoz said in DNS & NTP best practice (vlans & IoT):
https://forum.netgate.com/post/1079355
if you don't want to read through thatThanks! I'll read it, I have a small setup, but want to learn how to do it right... :) Much appriciated!
-
@furom happy to help, but if you ask me the "right" way to do it.. Would not be to use any of that doh/dot crap and just resolve heheh
I don't use any dot/doh and I don't forward.
I play with it, I understand how it works.. I just personally do not agree with what they are trying to do with it. It seems more like a way to circumvent a local networks ability to filter dns. And for companies to glean info from more clients because they send them all their dns with what I believe is false marketing of privacy and security.
I would be all for clients supporting to do it, but what bothers me is these companies defaulting to their applications using some method to circumvent local dns. And not saying it doesn't have some valid use cases.
The big issue I have with it is say browser, unless told not too on its own without an ok from the user pointing to some doh server.
If I want my browser to use something other than what the OS is using for dns, then that should be an explicit setting the user has to opt into, not something the client has to jump through hoops to turn off. Or that the local admin needs to worry about.
Shoot the OS can support using it as well - but it should always be opt in, not opt out.
The browser makers can run a campaign to sell using their doh servers to their clients if they want.. But before they go ahead and send queries to some doh/dot server over an encrypted channel - you should very well bloody directly ask the user of the browser for permission to do so!
And the sneaking of it in normal 443 traffic - well come on.. Why can it not run on some specific port.. Say like dot does on 853. This way its easy enough to block if local admin doesn't want it.
Trying to prevent doh amounts to a wack-a-mole game.. Sure can get a list of ips and fqdn being used on many of the public services. But the client could always use something that is not well known... You can't very well just block port 443 and expect the internet to work..
I just get a gut feeling - some browser maker saying hey send us all your dns, we are doing you a favor and making you more secure.. I just do not believe them that they are doing it out of the goodness of their hearts and the well being of everyone.. They have a agenda for doing it other then the best interests of the end user if you ask me. So no thanks.. I will just resolve thank you very much..
I will send my queries to the roots, the gltd servers and the authoritative ns for the domains I am looking for info from... I don't want or need to send my dns traffic to say google, they already have enough info and data from and about me.. etc..
qname or minimization of what your asking is better at limiting info about what your doing as well..
Send the roots, hey looking for .com or .net who are the ns for those tlds..
Ok ns for .com, what is the name server for domain.com, ok thanks
hey ns for domain.com, what is the record for host.domain.com you are authoritative for.I like this method way better than sending google or quad or whoever hey I am looking for host.domain.com, could you look it up for me.
The strict setting would be best, but have run into stuff that will not resolve when you use that - so it can be problematic. It breaks some major domains if you use it..
sorry this got to be a long winded almost rant.. But dns is one of those things I like talking about, maybe too much.. hehehe
-
@johnpoz Well, I agree on the "all eggs in one basket" kind a thing. If not running the service self-hosted, or as you seem to do, talk directly to the root DNS servers (didn't know that was possible still?), you are potentially volunteering a lot of information. But if limiting it to one actor who at least seems believable it must still be better than just using whatever ones ISP or Google provides as a default solution, at least in terms of privacy. But as with most things, it's a balance act - what is good enough, too much or too little, not to mention the usability aspects...
-
@furom said in DNS & NTP best practice (vlans & IoT):
talk directly to the root DNS servers (didn't know that was possible still?),
huh - this is pfsense (unbound) default setting..
you are potentially volunteering a lot of information
To who - the root servers that I asked for NS for .com ?
To who the owner of domain.com that I want to go to their web server at www.domain.com
-
@johnpoz said in DNS & NTP best practice (vlans & IoT):
To who - the root servers that I asked for NS for .com ?
No, I meant when using default DNS. So how would you do this?
-
@furom how would you do what? That is the default configuration of pfsense/unbound out of the box.. It resolves.. If you want to only send min info to the NS in the path to what your looking up, that is check box in advanced.
edit: btw keep in mind that the NS for say .com are going to be cached, same for NS for of say domain.com.
So if I want to look up somethingelse.domain.com unbound knows already who the name servers are for domain.com so it doesn't have to ask root or the gtld servers anything.
The only time its going to ask roots anything is when asking for some new tld, only time going to talk to any of the gtld servers is when looking for a new domain.tld they are authoritative for.
So when not even using qname min stuff, root only knows first time I ask for .com say, they don't know that asking for .com anything again until the ttl expires on the nsers for .com
Same for the gltd level servers.. while they might know I asked for www.domain.com the first time.. After that when I ask for ftp, www, or host, or service.domain.com they are no involved and have no idea I was asking for those.
-
@johnpoz said in DNS & NTP best practice (vlans & IoT):
@furom how would you do what? That is the default configuration of pfsense/unbound out of the box.. It resolves.. If you want to only send min info to the NS in the path to what your looking up, that is check box in advanced.
Ok, sure. I guess I pictured removing the upstream DNS provider IP's to say Cloud9 or Google etc from the equation and replace with root DNS servers instead... I already have that box ticked
-
@furom huh - why would I ever use my ISP dns? The only scenario were those would be used is by pfsense itself, a client behind would never asks them anything.
Even if you let your dhcp from your isp hand you dns, the only device that would ever use those is pfsense if unbound failed, it could resort to using those to check for say updates to pfsense.
Only if you setup forwarding in unbound would unbound ever use say your isp dns to forward too if they are in your general pfsense settings. But this is not the default.. Default is unbound resolves. Would never talk to your isp dns, unless it was authoritative for some domain..
edit: another thing these dot and doh providers don't tell you.. Until esni, or the new name ech is standard across the board.. Your isp still knows where you going. For one they going to know the IP your going to unless you use a vpn.. They also going to know the domain your going to, because with IP along - that could be almost anything because hosted of some huge CDN, etc.
But the sni, the fqdn your trying to go to is going to be in the clear, that they can see with the start of the https/tls connection.. So while they might not know your going to www.domain.com/something - they can easy still tell your going to www.domain.com, and they would of never known the /something anyway even if you were sending them your dns directly..
So what exactly is sending encrypted dns to some dot/doh server hiding from your isp exactly? While they might not get it served up on silver platter with you sending it to their dns - they for sure can see the fqdn your going to if they so desire..
esni (encrypted server name indication) is dead, long live ech (encrypted client hello).. But to be honest that is years out from becoming an actual viable thing. Because the server owners have to allow for it, set it up to be able for clients to use it, etc..
-
@johnpoz Ok, now I lost myself in this I think, sorry... So I could do without these?
which then wouldn't use these?
If not really needed, why here?
-
@furom do with out what.. You do not need to set that up, your free to do so if you want.. But your just sending all your dns to them on a silver platter.. What do you get in return? Maybe some malware/bad site filtering? You sure are not really hiding anything from your isp, etc.
The only reason to set that up - is you want to, for whatever reasons you might have for doing it. But out of the box pfsense/unbound is a resolver.. It has no need for any sort of dns setup or forwarding too, etc.
-
@johnpoz said in DNS & NTP best practice (vlans & IoT):
Maybe some malware/bad site filtering? You sure are not really hiding anything from your isp, etc.
True, the malware filters are nice, but guess pfBlocker can take on some of that. I don't try to hide anything, just merely keeping data somewhat private when possible
So another woe then... The list of resolver names I now have under
Status / DNS Resolver, I take it that is local to Ubound running on my pfSense and what my queries has asked for, right? But is the resolving between Ubound/pfSense and the root DNS's protected somehow or can it be? -
@furom said in DNS & NTP best practice (vlans & IoT):
But is the resolving between Ubound/pfSense and the root DNS's protected somehow or can it be?
Protected from who, from what? You mean can it be via an encrypted tunnel.. No
If you want to hide that from your isp, then route your dns queries through a vpn.. But no there is no method to talk to the roots or the gtlds via dot or doh, nor would you be able to talk to the authoritative ns for some domain via dot or doh either.
Now by default when you resolve you would be using dnssec, so the info you get from roots would be validated that its correct with that. But that only goes as far as the dnssec has been setup for the tld, the specific domain. Most of the tlds have been setup for dnssec - but pretty sure there are still some that have not setup dnssec..
And the use of dnssec for specific domains is way lower than it should be, so yeah there are many a domain that do not do dnssec, and then their are something that just F it up anyway trying to use it ;)
-
@johnpoz said in DNS & NTP best practice (vlans & IoT):
And the use of dnssec for specific domains is way lower than it should be, so yeah there are many a domain that do not do dnssec, and then their are something that just F it up anyway trying to use it ;)
Ok. Well, yeah. Things move slowly sometimes. Just look at the IPv6 "rollout". It was said IPv4 addresses were almost depleted, yet we still use them in what I believe most places still. I haven't felt the need really to switch to IPv6, and suppose it won't happen until there is a must or real benefit from doing that.
I would have liked it better if there were a tunnel to the root DNS's though, but well, can't have it all... lol
