Domain "MyDomain.Local" issue - DNS / DHCP / mDNS / Apple
-
I just don't use .local unless I actually want to query mDNS. Never have any problems and it's a lot easier and doesn't get clobbered by the webConfigurator.
If you want to avoid it all and make a zone in unbound, just use .private or .lan something.
No ofence, but you should read the entire post before you squeeze a useless answer in between.
-
I stated quite well, that I'm aware of ".local" not being recommended to use
-
Also I mentioned quite clear, that for this szenario it is out of the question to use something else than ".local"
-
And just in the last post I stated quite clear, that there are no problems at all with ".local" if the network admin sets up a propper localdomain by providing a SOA.
Or this way - if you want SOA, use an authoritative DNS server like bind. Pretty simple.
Why should I use Bind if there is already unbound?! The current webinterface just lacks on the feature of changing this few lines in unbound setup without modifying it manually in "/var/unbound/host_entries.conf"
#local-zone: "MyDomain.Local" transparent #local-data-ptr: "127.0.0.1 localhost" local-zone: "Local." static local-data: "Local. 10800 IN NS Local." local-data: "Local. 10800 IN SOA Local. Hostmaster.Local. 1 3600 1200 604800 10800" local-data: "Local. 10800 IN A 192.168.10.1" local-zone: "10.168.192.in-addr.arpa." static local-data: "10.168.192.in-addr.arpa. 10800 IN NS Local." local-data: "10.168.192.in-addr.arpa. 10800 IN SOA Local. Hostmaster.Local. 2 3600 1200 604800 10800" local-data: "1.10.168.192.in-addr.arpa. 10800 IN PTR Local."
I am a big fan of using as much "base tools" as available before installing third party tools like Bind. I'm currently busy to find a way to keep the change in the "/var/unbound/host_entries.conf" file.
-
-
Why should I use Bind if there is already unbound?! The current webinterface just lacks on the feature of changing this few lines in unbound setup without modifying it manually in "/var/unbound/host_entries.conf"
I already told you why. Because unbound is NOT an authoritative DNS server.
-
I already told you why. Because unbound is NOT an authoritative DNS server.
But it totally doesn't need to be one in order for this to work just mighty fine. Try my example explained above and you'll experience it for yourself. So I don't get your point?!
-
This is a Guide to change unbound for ".local" domain support by adding SOA support
Go to "Diagnostics" ==> "Edit File"
Edit: /etc/inc/unbound.inc
Look for the line and comment it out with #:$unbound_entries = "local-zone: \"{$syscfg['domain']}\" transparent\n";
Change code to look something like this below:
/* ===================== CHANGE BEGIN ===================== */ #$unbound_entries = "local-zone: \"{$config['system']['domain']}\" transparent\n"; $unbound_entries = "local-zone: \"Local.\" static\n"; $unbound_entries .= "local-data: \"Local. 10800 IN NS Local.\"\n"; $unbound_entries .= "local-data: \"Local. 10800 IN SOA Local. Hostmaster.Local. 1 3600 1200 604800 10800\"\n"; $unbound_entries .= "local-data: \"Local. 10800 IN A 192.168.10.1\"\n\n"; $unbound_entries .= "local-zone: \"10.168.192.in-addr.arpa.\" static\n"; $unbound_entries .= "local-data: \"10.168.192.in-addr.arpa. 10800 IN NS Local.\"\n"; $unbound_entries .= "local-data: \"10.168.192.in-addr.arpa. 10800 IN SOA Local. Hostmaster.Local. 2 3600 1200 604800 10800\"\n"; $unbound_entries .= "local-data: \"1.10.168.192.in-addr.arpa. 10800 IN PTR Local.\"\n\n"; /* ====================== CHANGE END ====================== */
Also don't forget to change IP addresses accordingly to match your environment as well as changing the hostmaster email - in my example it is: "Hostmaster.Local"
This way helps to make the change persistent to pfSense. So whenever a reboot or a change in either DHCP or DNS Resolver occours, it won't destroy the SOA entry and instead keep it in "/var/unbound/host_entries.conf".
Also don't forget to put "Dummy" or anything else BUT your "MyDomain.Local" to "search-domain" in "DHCP" settings site!Also I recomment to setup individual hosts up like this in "Advanced" text area instead of using "Hosts Override" fields of the GUI:
server: # Blocking Ad Server domains. Google's AdSense, DoubleClick and Yahoo # account for a 70 percent share of all advertising traffic. Block them. local-zone: "doubleclick.net" redirect local-data: "doubleclick.net A 127.0.0.1" local-zone: "googlesyndication.com" redirect local-data: "googlesyndication.com A 127.0.0.1" local-zone: "googleadservices.com" redirect local-data: "googleadservices.com A 127.0.0.1" local-zone: "google-analytics.com" redirect local-data: "google-analytics.com A 127.0.0.1" local-zone: "ads.youtube.com" redirect local-data: "ads.youtube.com A 127.0.0.1" local-zone: "adserver.yahoo.com" redirect local-data: "adserver.yahoo.com A 127.0.0.1" # Local Hosts local-zone: "Storage-01.MyDomain.Local" redirect local-data: "Storage-01.MyDomain.Local 3600 IN A 192.168.50.200" local-data-ptr: "192.168.50.200 Storage-01.MyDomain.Local" local-zone: "Storage-02.MyDomain.Local" redirect local-data: "Storage-02.MyDomain.Local 3600 IN A 192.168.50.201" local-data-ptr: "192.168.50.201 Storage-01.MyDomain.Local" local-zone: "Storage-03.MyDomain.Local" redirect local-data: "Storage-03.MyDomain.Local 3600 IN A 192.168.50.101" local-data-ptr: "192.168.50.101 Storage-01.MyDomain.Local"
So it would look something like this:
This way allows you to only once declare a host and all subdomains will automatically forwarded. It saves lots of configuration work if your hosts have many subdomains.
-
But it totally doesn't need to be one in order for this to work just mighty fine. Try my example explained above and you'll experience it for yourself. So I don't get your point?!
Yeah, it also works mighty fine without any mDNS altogether. Since - surprisingly - the purpose of mDNS is to provide DNS-like feature for local networks where no unicast DNS server is present to resolve the local hostnames. When you have a DNS server resolving them, you don't need this mDNS thing at all for name resolution. And you should stay damn out of the reserved .local TLD when you plan to use mDNS. (If you do not use and don't ever plan to use mDNS, then use .local as you wish with your unicast DNS. – And if you do, then turn the mDNS thing off altogther.) Other than that, select something else for normal DNS and leave the .local thing for purposes it's intended for.
And please read this rant from the guy who's behind the much "beloved" Avahi mDNS implementation before implementing similar hacks around stupid design decisions.
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393711#5
Sigh...
-
Yeah, it also works mighty fine without any mDNS altogether. Since - surprisingly - the purpose of mDNS is to provide DNS-like feature for local networks where no unicast DNS server is present to resolve the local hostnames. When you have a DNS server resolving them, you don't need this mDNS thing at all for name resolution. And you should stay damn out of the reserved .local TLD when you plan to use mDNS. (If you do not use and don't ever plan to use mDNS, then use .local as you wish with your unicast DNS. – And if you do, then turn the mDNS thing off altogther.) Other than that, select something else for normal DNS and leave the .local thing for purposes it's intended for.
And please read this rant from the guy who's behind the much "beloved" Avahi mDNS implementation before implementing similar hacks around stupid design decisions.
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393711#5
Sigh...
Ok, right - but I told already the change of the internal TLD ".local" is out of question. It would not be economic at all to change this many devices to another TLD and everything dependending on it. Also, I don't plan on using mDNS at all - and I assume most admins in a productive corporate network don't plan to use it. They rather prefer a propper regular DNS instead. The only devices where mDNS is currently running are the Apple devices in the network. So this kind of forces me to deal with the issue. Unfortunately I can't turn this behaviour off on iOS devices - so I kind of have to live with the mDNS noise. Nevertheless, mDNS of iOS and regular DNS seem to cooperate very nicely together in my described environment. Apple TV is still being picked up by all iOS and OSX devices. I also tried the iOS VLC app which uses "Hostname.local" for its WLAN-sharing (via http) and all is reachable and works totally fine. So I really got the network in harmony here with my described solution. I'm more happy I don't have to use avahi - and I never want to, since I dislike mDNS. In the beginning I didn't know whether it may be necesarry as a translator between mDNS and regular DNS requests in order to serve Apple devices mDNS queries through regular DNS. But since it is not required at all - it is also not part of the discussion any longer.
I'm also very happy, that I don't have to use bind, since the solution of this issue can be covered a 100% by already available unbound.
Again, I can just recomment to implement this functionality in pfSense's "DNS Resolver" setup site. There is too many people with ".local" out there who want to make their devices use of regular DNS instead of mDNS - yet don't loose mDNS features for devices like "Apple TV". My workarround is covering this without breaking anything of the sort.
-
The entire problem here is, that – as usual -- the Apple's "solution" is completely retarded. This mDNS/Zeroconf/Bonjour stuff really is about decentralized networks, portable shit with minimum configuration etc. No DNS, no DHCP even, 169.254.0.0/16 for IPv4, fe80::/16 for IPv4 and that's all -- the computers there still can resolve each other in the .local namespace and advertise themselves and the services available on them, blah blah blah...
Now, Apple comes and suggests creating SOA records on DNS servers? All this shit needs to be configurable on the client. You can configure on Linux in which order resolution should be done and which answers should be treated as authoritative. So, really… WTF. Now, your setup works for you "in harmony" -- but that's just because you don't have any conflicting resources apparently. Now, when some mDNS client comes with a hostname that's pointed to something else on your unicast DNS server (this would be prevented with mDNS properly used, since the machines can protect their names), you get different machines resolved depending on what you query, the reverse records do not match either, and you have generic mess.
-
I agree, yet we have to deal with it :-\
-
IMHO, I would have blocked mDNS on the network and forced DNS. That's a heckuva' lot easier to do and manage moving forward.
mDNS and DNS are two very different things used for two very different kinds of implementations.
As others have pointed out, your network is less than optimal and you're trying to accommodate functionality that should normally seamlessly work. You're headed down a rabbit hole by patching and maintaining complex configurations. It is easier to just block the protocol and force everything to go to DNS. I didn't see anywhere in your posts that mDNS is a hard requirement for network functionality. If so, move everything dependent on mDNS over to DNS. Some Apple technologies will stop working, like sharing in iTunes, network discovery, and things like that. However, everything else Apple can use DNS without an issue. You just lose Apple's simple service discovery.
-
IMHO, I would have blocked mDNS on the network and forced DNS
How exactly would you do that on a LAN segment?
-
IMHO, I would have blocked mDNS on the network and forced DNS
How exactly would you do that on a LAN segment?
On the switch.
-
IMHO, I would have blocked mDNS on the network and forced DNS
How exactly would you do that on a LAN segment?
On the switch.
I know, but you're assuming a switch capable of that.
-
IMHO, I would have blocked mDNS on the network and forced DNS
How exactly would you do that on a LAN segment?
On the switch.
I know, but you're assuming a switch capable of that.
I'm assuming a lot of things in this thread, that's just one of them. If the OP is in an environment as a network admin and cannot change the architecture of the network because of policy, then you can assume they have L2/L3 capable switches. Might actually be a combination of assuming and wishful thinking.
Additionally, you can block IPv6 on the network. mDNS, or at least Apple's implementation of it, initially tries to use IPv6 and then eventually fails to IPv4. Apple doesn't tell anyone that, but if you start blocking IPv6 on your LAN, your Apple products will start to get cranky.