So at least there's consistency there.
At the moment, there are 3 possible values for the local domain: dododomain which I edited into the file manually; home.tastewar.com which is what the GUI reports; and local, which certainly was in the file and the GUI at some point in the past, but no longer.
Oh, I also rebooted campi and checked again, thinking I may not have rebooted since the last change on pihole, but nothing changed -- still says "local" and I ran dhclient -d -nw eth0 (saw this mentioned in a post somewhere) to confirm that indeed it was 10.10.10.186 (pihole) that was answering my DHCP broadcast, and it was.
I just ran a wireshark capture of an ipconfig /release followed by ipconfig /renew on my windows laptop, and I can see my pi-hole sending a DHCP offer with option 15 being "local"
So it must be getting this from somewhere, but a mystery to me!
are you running any instances of avahi ?
which avahi
Hi RamSet- which avahi displays nothing.
Not familiar with the "which" command, but ps aux does suggest one is running:
avahi 239 0.0 0.3 6384 1484 ? S May14 0:00 avahi-daemon: chroot helper
see if you have an entry in your /etc/avahi/avahi-daemon.conf with domain-name=.local
I think avahi is pushing it ...
You can edit it and then sudo systemctl restart avahi-daemon
So, there is, but it is preceded with # which I want to assume indicates it's commented out. Here's the whole thing:
pi@pihole:~ $ cat /etc/avahi/avahi-daemon.conf
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# See avahi-daemon.conf(5) for more information on this configuration
# file!
[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no
[reflector]
#enable-reflector=no
#reflect-ipv=no
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3
pi@pihole:~ $That is correct. I can't think of another place where it might come from ...
More confusion. I was looking around and came across a page discussing FTLdns, and it showed commands to use to check which dns/dhcp was being actively used, and it appeared as though both were running. So I rebooted, and now it shows only traditional dnsmasq running. So I thought perhaps something was confused between the two earlier, and tried my release/renew of dhcp with wireshark again, and it's still showing "local" for the domain. Web GUI still shows home.tastewar.com as the configured domain, and the config file still shows dododomain, but whatever is acting as DHCP (is it AVAHI or dnsmasq??) is sending "local"
BTW, I did not intentionally "activate" AVAHI or knowingly request it be run. If it shouldn't be running, please tell me how to disable, and I will, if that will help eliminate confusion.
Also, if it's of interest, I can try setting things up to use FTL.
If you don't use it, you can fully remove it.
If you have nmap use this command to see the DHCP servers in your network:
sudo nmap --script broadcast-dhcp-discover
should return something like this:
The wireshark trace clearly showed that all DHCP was going to/from the pi-hole, so I don't have any reason to believe there are rogue DHCP servers on my network. Just a possible question of what software on the pi-hole is actually receiving the broadcasts and responding, and I don't think that can be determined by a network trace, or nmap, at least the output you're showing doesn't appear to infer that.
My pi-hole started life as a pi-zero, with raspbian installed specifically to run the pi-hole software. I did nothing to it before or after other than use the Web GUI and change settings, and occasionally ssh into it to update or run other diagnostics. Point being, if AVAHI is installed/running, I don't believe it was due to anything explicit I did, so I'd expect anyone with a run-of-the-mill install of pi-hole would have the same symptoms, if they were using the DHCP server (probably a small subset...) and they cared about the domain name that was getting handed out (now we're talking a much smaller subset).
That said, I could certainly uninstall if you think that's a useful troubleshooting step. And I would have done so, it's just that the link you provided suggested it was for Ubuntu rather than raspbian/debian, and that's when I take a pause and ask for clarification 
I don't have nmap on a linux box, but do have "Zenmap" on my windows laptop; running the command there yielded nothing, really:
Starting Nmap 7.70 ( https://nmap.org ) at 2018-05-15 19:36 Eastern Daylight Time
Nmap done: 0 IP addresses (0 hosts up) scanned in 13.13 seconds
WARNING: No targets were specified, so 0 hosts scanned.So, instead of removing, I disabled avahi:
systemctl disable avahi-daemon.socket
systemctl disable avahi-daemon.service
Rebooted. Confirmed that no processes with avahi in the name were running. Performed my dhcp test, Confirmed it shows "local" for the domain name. Confirmed that no avahi processes running.
So that doesn't appear to be it.
And then, I had a bit of a nightmare attempting to update to FTL, where the pi-hole hung in the middle of the process ("update local cache of available packages"). Couldn't get the web interface to respond. My SSH session died. It was still pinging, but I left it in that state for 15 minutes. Family getting restless. removed power, then powered it back up. Had a continuous ping going for another 10 minutes. Nothing. So I enabled DHCP on my router to appease the fam, and noticed that pihole picked up an IP address! That's odd, because it's configured with a static IP. Then its DHCP server started also giving out IPs. I eventually shut that off, and ran the second command for switching the FTL (pihole checkout web FTLDNS) but it said it was already up to date. Or words to that effect. Then I ran a pihole -r (repair) for good measure. Seems to be healthy now, and seems to be running the FTL code. And after all that, I'm still getting "local" for the domain. Sigh.........
So... I started investigating how dnsmasq gets its config, the man page says, "At startup, dnsmasq reads /etc/dnsmasq.conf, if it exists." so I look in that file, and lo and behold, there it says domain=local so I remove that, restart dnsmasq, and then aside from an issue where my router's DHCP server was still handing out IP addresses after the service definition had been deleted, it seems to be working!
Confirmed that this is now working at least in the case I care about. I'm not sure how that setting got into that file, but if you were to tell me that no pi-hole software touches that file, and that it must have been me, I wouldn't doubt it. Ah the perils of having multiple config files!
Thanks to everyone for their time, suggestions, and help!
Glad we you eventually found it!
Just as a last comment on this: yes, we don't mess around with this file. We only install a default variant of it on systems where it was never present, but that doesn't affect you (you had dnsmasq before)
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.