pfSense

server=/local/8.8.8.8

works faster. It's a temporary useful hack, not an answer.

Here's a better idea - do NOT use .local domain if you want to use avahi? Sheesh, it's even written as a hint in the System - General GUI hint: "Do not use 'local' as a domain name. It will cause local hosts running mDNS (avahi, bonjour, etc.) to be unable to resolve local hosts not running mDNS."

Of course the bug in this case applies no matter what the pfsense domain name is. The first line in EVERY pfsense /etc/hosts file is:

127.0.0.1 localhost localhost.<pf general screen domain name>

And that's all it takes for dnsmasq to respond with an SOA record to a .local query.

BTW, there are multiple bug reports against this BS script check, like

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559927
- https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1254357

The workaround for the whole nonsense seems to be changing AVAHI_DAEMON_DETECT_LOCAL=1 to AVAHI_DAEMON_DETECT_LOCAL=0 in /etc/default/avahi-daemon

Oh, and BTW, the proper thing to do would be to check for NXDOMAIN, not doing utter nonsense such as

if echo `LC_ALL=C host -t soa local. 2>&1` | egrep -vq 'has no|not found'; then 
    return 0
fi

(SIGWTF)

Gentlemen:

1. Every single ubuntu, debian, gnome, xfce and other linux distro that packages the "Network Manager" by default demonstrates this problem, every bootup, NO MATTER WHAT is placed as the 'domain' in the pfsense GUI. None of my pf boxes have 'local', they are all <realinternetdomaingoeshere>.com . This is not my first barbecue.

2. Other firewall routers DO NOT exhibit this behavior

3. The choice you are offering is to have every end-user that happens to show up on the private side of a pfsense firewall, any given day, to google to find a workaround, and NOT call for support--- OR think about whether dnsmasq responding as the domain authority for 'local' because 'localhost' is in the hosts file, is or isn't a good thing.

Is the response:

root@server1:~# host -t SOA local.
local has SOA record local. nobody.localhost. 42 86400 43200 604800 10800

when the pfsense domain is a real internet non-local domain correct, or not?

With 127.0.0.1 localhost in the /etc/hosts file, pfsense reports the above.

To Chris's point:

root@server1:~# host -t SOA local. 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

Host local. not found: 3(NXDOMAIN)

But if you ask pfsense:

root@server1:~# host -t SOA local.
local has SOA record local. nobody.localhost. 42 86400 43200 604800 10800

Go ahead, just do it on the lan side of your own pf box. Really. I'm not making this up.

Well, now, let's see, what the braindead script does:

if [ "$AVAHI_DAEMON_DETECT_LOCAL" != "1" ]; then
  exit 0
fi 

There! You can disable the whole braindead thing and move on.

Now, the real check, in fact, it does no such thing as you claim, it does NOT check for SOA. It checks for either "has no" or "not found" in the ouput, already commented on the stupidity above. So, the problem here is not in SOA at all. Also read below on more noted on the brain-dead-ness of the check itself.

As for other BS in the script:

- resolv.conf parsing itself is broken in multiple places: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629509
- the stupid delays: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559927
- last, but not least: the check does not make any sense: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433945 (as noted even by Lennart Poettering himself). Not just because of the reasons stated by myself above, but also because it does not work with some router implementations, and finally because there in fact is absolutely no problem with .local on the reference MacOSX implementation. The only trouble it has with .local is when it is used as a "single-label" TLD. Which is, in fact, what about noone does, as also noted on the linked bug. This misimplementation in Avahi itself apparently has never been fixed by Lennart, most likely since this was just another of his hit'n'run jobs, and - after a short intermezzo with breaking users' sound with pulseaudio - he now opted to screw systems much more fundamentally by a thing called systemd.

Final suggestions:
- either disable the check as sugested above
- or go bug Debain/Ubuntu to either rewrite the brainfart script from scratch, or drop it altogether
- or check what the script really does, run the command on your Ubuntu/Debian, and investigate why you get 0 (success) returned when running (no, it has absolutely NOTHING to do with /etc/hosts on pfSense.)

LC_ALL=C host -t soa local. 2>&1 | egrep -vq 'has no|not found'

Doktor Notor, if it was just my little box I would be pleased to do as you suggest.

However in situations where people bring their devices to work, where guests come and go to use the services of a firewall, where people aren't interested in understanding why they get a pop-up on boot saying their system has a problem they just call for help... your answer isn't practical. I hope you see that. It's the difference between a lab toy and a real-world product.

Look, make it simple and ignore the symptom and focus on the core issue:

Google (and everyone else) does this:

root@server1:~# host -t SOA local. 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

Host local. not found: 3(NXDOMAIN)

But if you ask pfsense, it does this:

root@server1:~# host -t SOA local.
local has SOA record local. nobody.localhost. 42 86400 43200 604800 10800

Who is right?

Afraid we'd have to go back to "fix your domain to NOT use .local", or fix your Debian/Ubuntu boxes. Since:

$ host -t SOA local. 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host local. not found: 3(NXDOMAIN)

$ hostname
gw.testdomain.local

Note, this is even run on pfSense box itself, running dnsmasq, and with hostname that actually DOES include local. Yet, no such BS .local host found.

All pointing to pfSense for DNS (hostnames replaced with OS):

Pointing to my edge router (127.0.0.1 localhost localhost.example.org):
jim@ubuntu:~$ host -t SOA local.
Host local. not found: 3(NXDOMAIN)

Also pointing to my edge router:
jim@freebsd$ host -t SOA local.
Host local. not found: 3(NXDOMAIN)

A test VM pointing to itself (127.0.0.1 localhost localhost.example.org):
root@pfs21-amd64.localdomain#: host -t SOA local.
Host local. not found: 3(NXDOMAIN)

An Lubuntu VM pointed toward a different VM (127.0.0.1 localhost localhost.localdomain):
jim@jim-lubn2:~$ host -t soa local.
Host local. not found: 3(NXDOMAIN)

There must be something else about your config causing it, sorry. We can continue the discussion in the forum.

Jim, Chris and Doktor Notor,

Thanks for all your focus here. It has led to a discovery and a suggested change to pfsense that is a permanent fix.

Here's the key discovery:

Google's DNS servers (8.8.8.8, 8.8.4.4) report
root@server1:~# host -t SOA "local." 8.8.4.4
Using domain server:
Name: 8.8.4.4
Address: 8.8.4.4#53
Aliases:

Host local. not found: 3(NXDOMAIN)

Mediacom's DNS servers report

root@server1:~# host -t SOA "local." 74.84.119.153
Using domain server:
Name: 74.84.119.153
Address: 74.84.119.153#53
Aliases:

local has SOA record local. nobody.localhost. 42 86400 43200 604800 10800

To get uniform behavior, behavior that doesn't make users call for help each boot should they use every ubuntu and gnome variant presently in distribution: consider adding this as an option, or a default, or at least a comment in the dnsmasq gui:

server=/local/

Then all host lookups on the lan side will correctly report there is no SOA entry for local. no matter whether the upstream DNS is google or the one provided to millions by cable ISP's.

Once again, thanks for the focus.

On 2.2 the default DNS Resolver will be Unbound, so you may want to test using that package and if the behavior is still present, refile this as a feature request with the more accurate description of the underlying issue.

Thanks!