Interestingly, it seems to work from other machines on the network
C:\Users\REDACTED>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
C:\Users\REDACTED>ping osmc
Pinging osmc.lan [192.168.1.22] with 32 bytes of data:
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Reply from 192.168.1.22: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.1.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Hmm, okay, next question: Have you, by any chance, made any changes to any file inside /etc/dnsmasq.d so FTL maybe runs on a different different port?
I guess the answer is "No", especially because
worked before as well.
Please update and test another time, I made a small mistake, causing FTL to be added as the second, instead of the first, resolver for you. Let's see if this makes any difference...
I still have hostnames on the web page, but that seems to have broken it according to the log file.
Its seems to now just be trying 8.8.8.8 for resolution
[2020-04-09 11:22:00.282 16905] 0: 8.8.8.8
[2020-04-09 11:22:00.283 16905] 1: 0.0.0.0
[2020-04-09 11:22:00.283 16905] 2: 0.0.0.0
[2020-04-09 11:22:00.283 16905] ---> "" (N/A)
[2020-04-09 11:22:00.285 16905] Trying to resolve 192.168.1.22
[2020-04-09 11:22:00.309 16905] No host name known to FTL, trying other servers as mandated by resolv.co nf:
I pushed another small change considering that network and host byte order are not always the same so deriving and setting the port the resolver is listening on might have failed. Please try again
For reference (for those interested):
Ports and addresses are always specified in calls to the socket functions using the network byte order convention. This convention is a method of sorting bytes that is independent of specific machine architectures. Host byte order, on the other hand, sorts bytes in the manner which is most natural to the host software and hardware. There are two common host byte order methods:
Little-endian byte ordering places the least significant byte first. This method is used in Intel microprocessors, for example.
Big-endian byte ordering places the most significant byte first. This method is used in IBM® z/Architecture® and S/390® mainframes and Motorola microprocessors, for example.
The network byte order is defined to always be big-endian, which may differ from the host byte order on a particular machine. Using network byte ordering for data exchanged between hosts allows hosts using different architectures to exchange address information without confusion because of byte ordering. Source: IBM Knowledgecenter
When manually changing /etc/resolv.conf to (reverse order of nameservers)
nameserver 127.0.0.1
nameserver 1.0.0.1
and flushing and restarting pihole the hostnames do get resolved. "arp" command now also shows local hostnames
Seems that listing 127.0.0.1 (localhost) as first nameserver in /etc/resolv.conf is critical. However after every reboot /etc/resolv.conf gets overwritten...
Yeah, this is a bad thing. The problem is when 1.0.0.1 responds with "does not exist" (in contrast to "I don't know"), then the second server isn't even tried. This means the server at 1.0.0.1 is incorrectly configured resp. it thinks it is the only DNS server on the planet.
Please also try
with the originalresolv.conf (how it would look like after a reboot). Even if this removes the names from arp, FTL tries to be more clever and still get the names.
Question remains why does Pihole configures 1.0.0.1 as nameserver and does not respect my system configured DNS? Would it not be more wise or elegant if pihole leaves /etc/resolv.conf in tact in stead of overwriting?
Other question IPv6 addresses aren't resolved , is that not supported ?
When this change has been reviewed, approved and merged. I will write here so you will get notified. So far, this branch is identical with release/v5.0 so there is nothing you are currently missing.