Project

General

Profile

Bug #4716

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

Added by Leander Schäfer about 2 years ago. Updated 12 months ago.

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

0%

Estimated time:
3.00 h
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.

History

#1 Updated by Kill Bill about 2 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.

#2 Updated by Leander Schäfer about 2 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.

#3 Updated by Leander Schäfer about 2 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!

#4 Updated by Kill Bill about 2 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.

#5 Updated by Chris Buechler almost 2 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."

#6 Updated by Jim Thompson about 1 year ago

  • Assignee set to Chris Buechler

#7 Updated by NOYB NOYB about 1 year 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)

#8 Updated by Chris Buechler 12 months ago

  • Assignee deleted (Chris Buechler)

Also available in: Atom PDF