Project

General

Profile

Actions

Bug #4716

closed

"DNS Resolver" lacks SOA for ".local" domain setups

Added by Leander Schäfer almost 9 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
DNS Resolver
Target version:
-
Start date:
05/19/2015
Due date:
% Done:

0%

Estimated time:
3.00 h
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

It turns out pfSense does not setup the localdomain set under "General Setup" ==> "domain" as SOA. Instead pfSense currently only sets it up as transparent in "/var/unbound/host_entries.conf":

local-zone: "MyDomain.Local" transparent
local-data-ptr: "127.0.0.1 localhost"
[...]

Due to this fact, in most szenarious localdomain lacks on SOA - which means it is a mostly working - but yet - unfinished setup of a localdomain.

Additionally to this lack, it currently also causes ".local" domains not being resolved by Apple devices - instead they start to look for mDNS via multicast. This is not due to a bad decission of Apple - it rather is the RFC6762 standard (http://en.wikipedia.org/wiki/.local and http://tools.ietf.org/html/rfc6762) which Apple respects and others don't yet. So one can expect more and more devices will follow this standard as well in future. Nevertheless this does not mean ".local" is a bad decission to use as your personal localdomain for your networks. If someone says this - it is simply false information. It will only cause trouble if ".local" is not setup as SOA. So if you want to use the special ".local" domain as your local tld then make sure you set ".local" up as your SOA as well as you have to make sure NOT to use ".local" as your "search-domain" e.g. via DHCP or static IP setups. This article also describes the solution: https://support.apple.com/de-de/HT204684

So for pfSense to close this bug with the RFC6762, "DNS Resolver" needs an option to set the localdomain either as "transparent (default)" or as "static (SOA)". Personally I have "MyDomain.Local" in "General Setup" so it would auto setup something like "pfSense-02.MyDomain.Local". But it did not help to setup "MyDomain.Local" as SOA - instead I needed to setup ONLY the last part: ".local" as SOA for it to completly work. This change in "/var/unbound/host_entries.conf" file solves the current problem of "DNS Resolver":

@#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. AdminMailUser.MailDomain. 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. AdminMailUser.MailDomain. 2 3600 1200 604800 10800"
local-data: "1.10.168.192.in-addr.arpa. 10800 IN PTR Local."

[...] CUT [...]@

From my point of understanding NO authoritative DNS server like bind(8) is required, since unbound(8) does the job perfectly mighty fine with the slight change showed above. For more detailed description, please have a look to the according topic in pfSense forum: https://forum.pfsense.org/index.php?topic=93855.msg522071

My suggested solution would be (estimated max. 3h of work):

Add a HTML bullet choise Transparent localdomain (default) or Create SOA of localdomain on "DNS Resolver" main setup site.
If Transparent localdomain (default), then operate as e.g. pfSense 2.2.2-RELEASE currently already does.
If Create SOA of localdomain has been choosen, then it should offer you a little text box below bullet choise, where there is already the default localdomain written in of previously setup "Gerneral Setup". So this way people can reduce the default localdomain "Mydomain.Local" to e.g. only "local" in the text box. The resulting ooutput should be something like demonstrated by my "/var/unbound/host_entries.conf" example above.

Actions #1

Updated by Kill Bill almost 9 years ago

Uh.

- Nowhere in RFC6762 is suggested than .local should contain SOA. To the contrary, mDNS by definition have no SOA record.
- Unbound is NOT an authoritative DNS server. (Nor mDNS one, for that matter.)

Resume: You simply should not use the reserved .local TLD.

Actions #2

Updated by Leander Schäfer almost 9 years ago

- unbound doesn't need to be an authoritative DNS server for this to work mighty fine. So this should not be up for discussion any further - try my example explained above
- it is wrong to just say "one shouldn't use .local". ".local" works totally fine if setup correctly - again: try my example explained above
- SOA with unbound as in my example above doesn't break mDNS - so this is also not worth going into further detail - again: try my example explained above

pfSense should give people a chance to set up such a SOA record with unbound via "DNS Resolver" setup site. It suits the standards as well as it helps a bunch lot of people, since ".local" de facto still is the most used localdomain.
Therefore it is a very important feature of pfSense to support this scenario.

Actions #3

Updated by Leander Schäfer almost 9 years ago

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!

Actions #4

Updated by Kill Bill almost 9 years ago

Leander Schäfer wrote:

Therefore it is a very important feature of pfSense to support this scenario.

It supports this scenario just fine. You really just totally misunderstand the RFC. "Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server." It's really just absurd to pull Unbound or any other DNS server into this. IOW, unbound is totally out of business here. The single-label .local TLD is reserved for mDNS.

Actions #5

Updated by Chris Buechler over 8 years ago

  • Subject changed from "DNS Resolver" lacks on SOA - Broke RFC6762 support with ".local" domain setups to "DNS Resolver" lacks SOA for ".local" domain setups
  • Status changed from New to Confirmed
  • Priority changed from Very High to Low

What happens here is OS X and iOS do a SOA lookup for .local, and if they get NXDOMAIN in reply, they strictly use mDNS for .local name resolution. I confirmed with packet captures from such devices, and this page explains it as well.
https://support.apple.com/en-us/HT204684

This isn't a recommended setup in any case, as .local shouldn't be used as a DNS TLD because its IANA assignment is for mDNS. Even this workaround may not work reliably now or at some point in the future.

Best off as Apple recommends, "Avoiding use of a .local suffix when planning internal corporate networks is strongly recommended."

Actions #6

Updated by Jim Thompson almost 8 years ago

  • Assignee set to Chris Buechler
Actions #7

Updated by NOYB NOYB almost 8 years ago

"System Domain Local Zone Type" option was added to DNS Resolver in pfSense 2.3. This allows setting "The local-zone type used for the pfSense system domain (System | General Setup | Domain)."

Does selecting the "Static" option here resolve the SOA issue?

(recommendations != specifications)

Actions #8

Updated by Chris Buechler over 7 years ago

  • Assignee deleted (Chris Buechler)
Actions #9

Updated by Marcos M about 2 years ago

  • Status changed from Confirmed to Closed

Currently there exists the option Disable Auto-added Host Entries. With this option, along with the ability to set Custom options for DNS Resolver, the original desired behavior can be achieved. No other changes should be done to the GUI given that we already have the following warning under System / General Setup // Domain:

Do not end the domain name with '.local' as the final part (Top Level Domain, TLD), The 'local' TLD is widely used by mDNS (e.g. Avahi, Bonjour, Rendezvous, Airprint, Airplay) and some Windows systems and networked devices. These will not network correctly if the router uses 'local' as its TLD. Alternative TLDs such as 'local.lan' or 'mylocal' are safe.

Actions #10

Updated by Jim Pingle about 2 years ago

  • Target version deleted (Future)
Actions

Also available in: Atom PDF