DNS & NTP best practice (vlans & IoT)
-
@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 -
@furom said in DNS & NTP best practice (vlans & IoT):
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 am with you.. I see it as the future sure - but I don't believe it is on the curve to adoption that they thought it would be. I have yet to find a resource - not one that would require me to have IPv6..
I have zero use for it myself, and it is pretty much off.. My current isp doesn't even provide it native hehe.. and have not even seen any mention of it even being on their radar.. I have used a tunnel from HE for years and years for my access to Ipv6, but its only for learning and playing.. I do not use it on any of my devices in any sort of production.. I turn it on a device when I want to play/test something. I use to provide my ntp server to the pool over both ipv4 and ipv6, but have turned that off.. It was more of learning curve thing anyway.. I have no real desire to provide services to the public internet ;)
Part of the problem to be honest, is the adoption of IPv6 for stuff like phones that require a vast amount of IPs to use - how many billions of phones are on the planet.. My phone does not get an IPv4 address, it gets IPv6 only for cell data - when it wants to go to an IPv4 address the cell providers network handles that connection via their 464xlat setup..
So them moving away from IPv4 freed up a bunch of IPs to use for other stuff. There is pretty active market in selling your IPv4 space to those that need it.. And you can make some good money, I was directly involved in the sale of some of the /16 in my old company.. They really have actual need of small fraction of that space, were not using most of it. To be honest if they would be doing what arin suggests they would of returned most of that space to arin years and years ago. It was quite lucrative deal.. I got screwed out of my bonus that I should of gotten for coming up with it.. Suppose to get like 10% when you came up with any sort of out of the box thing that made the company money.. Should of gotten like 50k in that deal, they threw me a bone of 5k.. Bastards! ;)
There is just the cost for companies moving to it as well - at least internally.. And what driving force do they have - the migration sure isn't going to save them money, not even in the long run.. They have plenty of rfc1918 space to use on the company internal network.. They will not run out of that ever.. So where is the advantage of them moving to ipv6.. Sure you can play nice and throw up some public IPv6 access to your public facing servers.. That is pretty simple and easy to do, and really easy to get a /32 from Arin for your own IPv6 space.. Was involved in that whole process - has the company really done anything with it - no they have used some of it in a future project that not sure will ever go anywhere.. So some infrastructure is using IPv6 on the public internet - but there is no driving force for its use elsewhere in the company or other projects..
My new company, on the fortune 100 list, it is not a tiny network that is for sure.. While I am new and sure do not have a handle on everything going on in the company - Can tell you from study of all the network diagrams and info. IPv6 is no where that I see... And even the public site for website has no AAAA.. I might have to ask around if any IPv6 work planned anytime in the near future..
I more than for sure will retire before any real traction with IPv6 in the corporate landscape to be honest - I got 10 years.. So we will see I guess.. But if I could place a bet, I would and a very large sum that not much happens with it.. I use to see new customer networks all the time old company was a MSP.. Never once did get a customer that had used any IPv6 in their networks, nor any customers that had any real plans or drive to do so..
-
@johnpoz Oh well, as for coming up with cost savings, heck, even tech that introduced possibilities not there before - and not getting even the credit for it - been there done that, it sucks.
I also doubt I'll ever come to use IPv6 in any commercial way, and though it seems rather straightforward, it is many new things to remember and cope with. Maybe something for a really boring rainy summer, who knows... lol
I think you hit the nail there - cost of implementing. Why fix something that isn't broken? It's always hard to motivate. What I think of for myself is perhaps along the lines of future-proofing, preparing just enough to not having to do a complete overhaul if the rainy day comes... :)
-
@furom said in DNS & NTP best practice (vlans & IoT):
and though it seems rather straightforward
There is way more too it than just a longer address ;)
-
@johnpoz said in DNS & NTP best practice (vlans & IoT):
There is way more too it than just a longer address ;)
Yes, I'm aware of that, but not necessarily hard - pending on scope, just a different way of thinking (trying to stay positive about it)
