https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-05-19T07:51:46ZpfSense bugtrackerpfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=184752015-05-19T07:51:46ZKill Bill
<ul></ul><p>Uh.</p>
<p>- Nowhere in RFC6762 is suggested than .local should contain SOA. To the contrary, mDNS by definition have no SOA record. <br />- Unbound is NOT an authoritative DNS server. (Nor mDNS one, for that matter.)</p>
<p>Resume: You simply should not use the reserved .local TLD.</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=184762015-05-19T08:05:52ZLeander Schäfermr-spott@gmx.de
<ul></ul><p>- unbound <ins>doesn't need</ins> to be an authoritative DNS server for this to work mighty fine. So this should not be up for discussion any further <em>- try my example explained above</em><br />- <ins>it is wrong</ins> to just say "one shouldn't use .local". ".local" works totally fine if setup correctly <em>- again: try my example explained above</em><br />- SOA with unbound as in my example above <ins>doesn't break mDNS</ins> - so this is also not worth going into further detail <em>- again: try my example explained above<br /></em><br />pfSense <ins>should give</ins> 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 <ins>helps a bunch lot of people</ins>, since ".local" <ins>de facto</ins> still is the most used localdomain.<br />Therefore it is a very important feature of pfSense to support this scenario.</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=184772015-05-19T09:35:15ZLeander Schäfermr-spott@gmx.de
<ul></ul><p>This is a Guide to change unbound for ".local" domain support by adding SOA support</p>
<p>Go to "Diagnostics" ==> "Edit File" <br />Edit: /etc/inc/unbound.inc<br />Look for the line and comment it out with #:<br /><code><br />$unbound_entries = "local-zone: \"{$syscfg['domain']}\" transparent\n";<br /></code></p>
<p>Change code to look something like this below:</p>
<pre><code>/* ===================== CHANGE BEGIN ===================== <strong>/<br /> #$unbound_entries = "local-zone: \"{$config['system']['domain']}\" transparent\n";<br /> $unbound_entries = "local-zone: \"Local.\" static\n";<br /> $unbound_entries .= "local-data: \"Local. 10800 IN NS Local.\"\n";<br /> $unbound_entries .= "local-data: \"Local. 10800 IN SOA Local. Hostmaster.Local. 1 3600 1200 604800 10800\"\n";<br /> $unbound_entries .= "local-data: \"Local. 10800 IN A 192.168.10.1\"\n\n";<br /> $unbound_entries .= "local-zone: \"10.168.192.in-addr.arpa.\" static\n";<br /> $unbound_entries .= "local-data: \"10.168.192.in-addr.arpa. 10800 IN NS Local.\"\n";<br /> $unbound_entries .= "local-data: \"10.168.192.in-addr.arpa. 10800 IN SOA Local. Hostmaster.Local. 2 3600 1200 604800 10800\"\n";<br /> $unbound_entries .= "local-data: \"1.10.168.192.in-addr.arpa. 10800 IN PTR Local.\"\n\n";<br /> /</strong> ====================== CHANGE END ====================== */</code></pre>
<p>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"</p>
<p>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".<br />Also don't forget to put "Dummy" or anything else BUT your "MyDomain.Local" to "search-domain" in "DHCP" settings site!</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=184782015-05-19T10:07:43ZKill Bill
<ul></ul><p>Leander Schäfer wrote:</p>
<blockquote>
<p>Therefore it is a very important feature of pfSense to support this scenario.</p>
</blockquote>
<p>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 <strong>in the absence of any conventional Unicast DNS server</strong>." 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.</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=206322015-09-15T00:24:09ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Subject</strong> changed from <i>"DNS Resolver" lacks on SOA - Broke RFC6762 support with ".local" domain setups</i> to <i>"DNS Resolver" lacks SOA for ".local" domain setups</i></li><li><strong>Status</strong> changed from <i>New</i> to <i>Confirmed</i></li><li><strong>Priority</strong> changed from <i>Very High</i> to <i>Low</i></li></ul><p>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. <br /><a class="external" href="https://support.apple.com/en-us/HT204684">https://support.apple.com/en-us/HT204684</a></p>
<p>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.</p>
<p>Best off as Apple recommends, "Avoiding use of a .local suffix when planning internal corporate networks is strongly recommended."</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=258902016-03-28T13:34:33ZJim Thompsonjim@netgate.com
<ul><li><strong>Assignee</strong> set to <i>Chris Buechler</i></li></ul> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=259112016-03-29T01:00:54ZNOYB NOYBJunkYardMail1@Frontier.com
<ul></ul><p>"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)."</p>
<p>Does selecting the "Static" option here resolve the SOA issue?</p>
<p>(recommendations != specifications)</p> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=279232016-07-02T04:11:09ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Assignee</strong> deleted (<del><i>Chris Buechler</i></del>)</li></ul> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=585482022-01-24T18:28:08ZMarcos M
<ul><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Closed</i></li></ul><p>Currently there exists the option <code>Disable Auto-added Host Entries</code>. With this option, along with the ability to set <code>Custom options</code> for <code>DNS Resolver</code>, 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 <code>System / General Setup // Domain</code>:</p>
<blockquote>
<p>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.</p>
</blockquote> pfSense - Bug #4716: "DNS Resolver" lacks SOA for ".local" domain setupshttps://redmine.pfsense.org/issues/4716?journal_id=587632022-02-07T15:02:40ZJim Pingle
<ul><li><strong>Target version</strong> deleted (<del><i>Future</i></del>)</li></ul>