Project

General

Profile

Actions

Bug #3539

closed

dnsmasq responds to domain 'local', breaks avahi

Added by Harry Coin about 10 years ago. Updated about 10 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
DNS Forwarder
Target version:
-
Start date:
03/20/2014
Due date:
% Done:

0%

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

Description

Ubuntu / debian and related network manager issues this command at startup

host -t soa local.

in /usr/lib/avahi/avahi-daemon-check-dns.sh If it returns with no error and 'has no|not found' then avahi is allowed to load. Anything else, and an annoying pop-up warning every reboot appears and avahi is blocked from running.

All to determine whether there is a .local unicast dns.

Pfsense puts "127.0.0.1 localhost localhost.<domain>" in /etc/hosts. dnsmasq sees that, and returns a valid SOA, breaking avahi.
if in the 'advanced' area the line server=/local/4.4.4.4 , then it works.
Most routers don't reply with false SOAs when local is queried. PF shouldn't, either.

Actions #1

Updated by Harry Coin about 10 years ago

server=/local/8.8.8.8

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

Actions #2

Updated by Doktor Notor about 10 years ago

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

Actions #3

Updated by Harry Coin about 10 years ago

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.

Actions #4

Updated by Chris Buechler about 10 years ago

  • Status changed from New to Rejected

The entire description here isn't true. I suspect as Doktor noted you're using .local as your domain. Otherwise you have something else broken. Pretty much every DNS server includes a SOA in NXDOMAIN responses. If this is "broken", then Google DNS, OpenDNS, Level 3, BIND, and dnsmasq are "broken."

[2.1.1-PRERELEASE][root@cmbhome-testfw1.buechler.lan]/root(2): dig local

; <<>> DiG 9.6.-ESV-R5-P1 <<>> local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6786
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;local.                IN    A

;; AUTHORITY SECTION:
.            1535    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2014032001 1800 900 604800 86400

;; Query time: 44 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 21 06:47:01 2014
;; MSG SIZE  rcvd: 98

[2.1.1-PRERELEASE][root@cmbhome-testfw1.buechler.lan]/root(12): dig local @4.2.2.2

; <<>> DiG 9.6.-ESV-R5-P1 <<>> local @4.2.2.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5371
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;local.                IN    A

;; AUTHORITY SECTION:
.            20391    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2014032001 1800 900 604800 86400

;; Query time: 122 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Mar 21 06:51:51 2014
;; MSG SIZE  rcvd: 98

[2.1.1-PRERELEASE][root@cmbhome-testfw1.buechler.lan]/root(13): dig local @8.8.8.8

; <<>> DiG 9.6.-ESV-R5-P1 <<>> local @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4194
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;local.                IN    A

;; AUTHORITY SECTION:
.            1236    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2014032001 1800 900 604800 86400

;; Query time: 38 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 21 06:52:00 2014
;; MSG SIZE  rcvd: 98

[2.1.1-PRERELEASE][root@cmbhome-testfw1.buechler.lan]/root(14): dig local @208.67.222.222

; <<>> DiG 9.6.-ESV-R5-P1 <<>> local @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;local.                IN    A

;; AUTHORITY SECTION:
.            989    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2014032001 1800 900 604800 86400

;; Query time: 30 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Mar 21 06:52:20 2014
;; MSG SIZE  rcvd: 98

[2.1.1-PRERELEASE][root@cmbhome-testfw1.buechler.lan]/root(8): dig asdfadsfdsfa @8.8.8.8 

; <<>> DiG 9.6.-ESV-R5-P1 <<>> asdfadsfdsfa @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37108
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;asdfadsfdsfa.            IN    A

;; AUTHORITY SECTION:
.            1716    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2014032001 1800 900 604800 86400

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 21 06:50:53 2014
;; MSG SIZE  rcvd: 105

Actions #5

Updated by Doktor Notor about 10 years ago

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

Actions #6

Updated by Doktor Notor about 10 years ago

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)

Actions #7

Updated by Harry Coin about 10 years ago

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.

Actions #8

Updated by Harry Coin about 10 years ago

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.

Actions #9

Updated by Harry Coin about 10 years ago

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.

Actions #10

Updated by Doktor Notor about 10 years ago

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'
Actions #11

Updated by Harry Coin about 10 years ago

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?

Actions #12

Updated by Doktor Notor about 10 years ago

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.

Actions #13

Updated by Jim Pingle about 10 years ago

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):
#: 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.

Actions #14

Updated by Harry Coin about 10 years ago

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.

Actions #15

Updated by Jim Pingle about 10 years ago

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!

Actions

Also available in: Atom PDF