Domain "MyDomain.Local" issue - DNS / DHCP / mDNS / Apple

[LeoLinux]

Hi

out of well known reasons it is not a good suggest to use ".Local" as your local TLD. Unfortunately some environments won't allow an easy change of the TLD due to much more dependencies. This is why I have been fighting for the past days to get ".Local" DNS resolution working with currently the latest pfSense 2.2.2 RELEASE. Many hours of research and reading but unfortunately only with 80% success. iOS still lacks.

First tests resulted that all regular clients such as MS Windows, Apple OSx and any othe nix-alike System resolves everything as expected. I tested the configuration of pfSense by ping and host. So I came to the mobile i devices. It turnes out iOS doesn't accept the pfSense configuration and it doesn't resolve hostnames configured in pfSense. After hours of debugging, tcpdump told me, that iOS tries to query its DNS requests via mDNS brodcast - even though it had a valid DNS server in the wireless settings. But it turnes out DNS server setup via WLAN is completly ignored for ".Local" queries. CRAP! ;(

Ok, so I did some research about tools which may be able to operate as a mDNS server for iOS queries on pfSense, and simply forward the query to the local unbound DNS server. I found avahi. Sounded promising, so I installed it. Btw. it is only possible to install it via commandline with the slow ALIX boards. Have a look at this if this affects you: https://doc.pfsense.org/index.php/2.1_New_Features_and_Changes#SH.2FPHP_Shell_Scripts```
pfSsh.php playback installpkg Avahi

It takes extremly long to extract after it even reports a progress status of 100% .. so just wait round about a 20 minutes …

Once it was installed tried all sorts of options in the configuration (via webinterface and manually) unfortunately it was NOT able to forward iOS DNS requests to unbound or dnsmasq. Mybe I did not understand the entire thought behind avahi but I didn't get it to work.

So I did further research. I found some sites suggesting to configure DHCP, so that it delivers "MyDomain.Local" as the default search domain to the DHCP clients. This should apparently help - but it didn't - not even if setup together with dynamic DHCP.

My relevant DHCP Server settings look like:

Gateway IP of pfSense (192.168.1.1)
Domain name: MyDomain.local
Domain search list: MyDomain.Local;Local
Dynamic DNS: MyDomain.local (the dynamic DNS domain which will be used to register client names in the DNS server.)

So my question is: There must be a way to establish a ".Local" BUT how do I forward iOS mDNS queries to my local unbound and let unbound respond back to iOS?

[jahonix]

mDNS/Bonjour/ZeroConf is Multicast. This means you cannot redirect it somewhere, much like other broadcasts.
Can you segment your network and put wireless devices on a separate interface with different IP/netmask and domain suffix? Assuming most all iOS devices are wireless only (Apple TV isn't but I don't expect you to use just those).
Leaving the rest of your network unchanged and working.

[LeoLinux]

Unfortunately creating different network segments is not going to be a solution.

Sure, my aim isn't to re-direct the mDNS traffic. Instead I want a tool like avahi which listens for mDNS requests and queries the pfSense DNS in order to deliver a correct reply to iOS mDNS requests. Is this possible with avahi? Cause to me it looked like I would have to install avahi on each station individually in order to publish its services. But I would rather have this central than de-central.

iOS <======> avahi <========> unbound

PC <====================> unbound

[doktornotor]

Unbound does NOT do mDNS. Period.

[LeoLinux]

@doktornotor:

Unbound does NOT do mDNS. Period.

This was never part of the question. The core of this discussion is to find a tool which is capeable of mDNS and hands the query further to unbound. The tool should then get unbounds respond to the query and provide it as mDNS reply for iOS.

The question is now: Can avahi do this? Or is there another mDNS tool which is capeable of using a regular DNS server as backend?

[doktornotor]

Uh. Your client is misconfigured. It should query DNS itself. Not relay the queries via some nonsensical client => avahi => DNS => avahi => client chain. Now, if your problem is that you used .local despite being explicitly told to avoid this because it breaks Bitten Fruit (TM) junk, then there's this domain-name configuration option for Avahi to tell it to use something else than .local for mDNS.

[LeoLinux]

So boys … here is the solution to the trouble of ".local" as your local tld. First of all it is no trouble as many try to tell you, that this ".local" is breaking thins. It is simply just wrong information!!! The ".local" is a standard explained as described in this wiki artice ".local" ==> http://en.wikipedia.org/wiki/.local. Apple did right when they made their decission to force mDNS as it is a favoured standard for people who want to have no effort in configuring their local network (and belive me, there is many of them ;D). This standard does not exclude people who want to have a nice configured network with the tld ".local". This article descripbes what you need to do if you want Apple devices (and probably others as well in future) to understand what you want. The problem with pfSense is that it doesn't offer the right configuration options for this szenario yet. But this is why I'm providing this reply.

• Yes it is possible to use ".local" without ANY restrictions

• The app "avahi" is not required for this to work

• It is a simple issue of current unbound setup provided via web GUI in pfSense 2.2.2-RELEASE

• No "search-domain" setup e.g. via DHCP is required for this to work either - as in fact don't deploy ANY "search-domain", since it destroys your ".local" URI resolution with internal FQDN and currently iOS.

The known and well adverticed "search-domain" workaround

First of all - it is not a real workarround, since it doesn't achive the 100% of the wanted requirements. What this workarround offers in general is pure user lazyness. So instead of typing "MyHost.Local" it would accept "MyHost" and simply append the "search-domain" value to the request. So if you would e.g. request "MyHost" it would append the "search-domain" in the background to FQDN "MyHost.Local" if your "search-domain" would be "Local". So if a client would try to query "MyHost" it would try this and if no valid result comes it would try to appended "MyHost.Local" and see if there is a success (again: if your "search-domain" would be "Local"). A valid "search-domain" setup through e.g. DHCP might work for OSx as well as for other clients like MS and *nix but not for iOS. For iOS it ONLY accepts the relative hostname for the "search-domain" but not the FQDN - IF in ".local" environment NOT if in any other. Meaning "MyHost" with "search-domain"=".Local" will be able to be resolved by iOS but "MyHost.Local" won't, since it tries to query through mDNS. So now you may undesrtand why it is not a 100% of a workaround, cause it simply breakse any FQDN in e.g. your local website inside your intranet.

• This could be achived by setting the "domain" in "General Setup" as "MyDomain.Local" and

• setting the "Domain search list" of your LAN interface to the same "MyDomain.Local" - optionally the "Domain name" as well as the "Dynamic DNS" to the very same value of "MyDomain.Local"

This is crap for a production environment - and this is why I personally recommend the following setup …

The perfect workaround for a ".local" environment with pfSense 2.2.2-RELEASE

Here is the inspiration: https://support.apple.com/de-de/HT204684. I use "MyDomain.Local" as an example for this …

• Setup "General Setup" ==> "domain" as "MyDomain.Local"

• If "DNS Forwarder" activated, please deactivate it - aslo known as "dnsmasq"

• Open "DHCP Server" ==> "LAN" and put "Dummy" as "Domain search list"

• Activate "DNS Resolver" known as "unbound" as shown in the screenshot below. Please have a close look at the "Hosts Override" configuration example for your personal internal DNS setup. Save and Apply.

• Then manupulate the file: "/var/unbound/host_entries.conf" via "Diagnostics" ==> "Edit File" as it holds the zone(s) and hosts as shown in the second screenshot below - and save changes shown below. Remember that you should only overwrite the settings on top and NOT your "Hosts Overrides" settings below […] CUT […]

• Re-start unbound as something like this: killall unbound && sleep 2 && /usr/local/sbin/unbound -c /var/unbound/unbound.conf && sleep 1 && ps aux | grep unbound from pfSense shell e.g. via SSH

This is it. Unfortunately the settings in "/var/unbound/host_entries.conf" will be reset to not working default EVERY time you apply something in "DHCP-Server" or "DNS" configuration OR after a reboot of the pfSense. So make sure the SOA and PTR settings on top are always corrected afte a change/apply and re-start unbound manually after applying the correct configuration via "Diagnostics" ==> "Edit File" in "/var/unbound/host_entries.conf".

Basic unbound configuration through pfSense GUI 2.2.2-RELEASE

Manupulate unbound hosts configuration through pfSense GUI 2.2.2-RELEASE

The perfect solution for a ".local" environment

Well first of all: ANY TLD should have a SOA. Anything else is just "botch" … trying to glue things together with min. effort. WRONG! Create a SOA and things run smooth 8)
So for pfSense, this is "future music" - this is why I opened bug report 4716: https://redmine.pfsense.org/issues/4716. It would require the pfSense GUI to implement parametrs where you can set a SOA individualy, instead of assuming it from your general setup. OR to give you a chance to manupulate it accordingy as described in the previous "perfect workaround". Because what pfSense currently does is to set it it to "transparent" instead of setting it to "static" also it takes the full "domain" from "General Setup" instead of letting it individually cut down to "Local" instead " of "MyDomain.Local".

This is it. Have fun 8)

[Derelict]

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.

[doktornotor]

Or this way - if you want SOA, use an authoritative DNS server like bind. Pretty simple.

[LeoLinux]

@Derelict:

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.

@doktornotor:

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.

[doktornotor]

@LeoLinux:

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.

[LeoLinux]

@doktornotor:

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?!

[LeoLinux]

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.

[doktornotor]

@LeoLinux:

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...

[LeoLinux]

@doktornotor:

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.

[doktornotor]

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.

[LeoLinux]

I agree, yet we have to deal with it  :-\

[tim.mcmanus]

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.

[Trel]

@tim.mcmanus:

IMHO, I would have blocked mDNS on the network and forced DNS

How exactly would you do that on a LAN segment?

[tim.mcmanus]

@Trel:

@tim.mcmanus:

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.