No Hostnames - PI is DHCP Sever

DL6ER · April 9, 2020, 11:09am

The log output has changed, the following example belongs together:

[2020-04-09 12:30:00.457 1509] Trying to resolve 127.0.0.2
[2020-04-09 12:30:00.472 1509] No host name known to FTL, trying other servers as mandated by resolv.conf:
[2020-04-09 12:30:00.472 1509]  0: 127.0.0.53
[2020-04-09 12:30:00.472 1509]  1: 0.0.0.0
[2020-04-09 12:30:00.472 1509]  2: 0.0.0.0
[2020-04-09 12:30:00.473 1509]  ---> "thinkpad-x1-carbon-3rd" (found externally)

Something found internally would look like:

[2020-04-09 12:35:00.346 2092] Trying to resolve 127.0.0.1
[2020-04-09 12:35:00.346 2092] Setting nameserver to 127.0.0.1:4711
[2020-04-09 12:35:00.347 2092]  ---> "localhost" (found internally)

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

Maarten · April 9, 2020, 11:24am

Same problem here:

/etc/resolv.conf
nameserver 1.0.0.1
nameserver 127.0.0.1

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

DL6ER · April 9, 2020, 11:28am

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 original resolv.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.

Maarten · April 9, 2020, 11:35am

Thanks, it works!

DL6ER · April 9, 2020, 11:46am

github.com/pi-hole/FTL

Improve internal resolver algorithm

pi-hole:release/v5.0 ← pi-hole:tweak/resolver_try_FTL_first_then_others

opened 11:45AM - 09 Apr 20 UTC

DL6ER

+136 -30

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- This PR modifies FTL's internal resolver to work in two phases: - First, try to obtain a host name by using the internal resolver (i.e., FTL). - In a second step, only executed when FTL didn't know the answer, we ask the resolvers as configured by `resolvconf`. We've seen that the latter is necessary to get proper name resolution in docker environments. This change turns out to be necessary for some upstream servers such as 1.0.0.1 and ensures that FTL is always the first server that gets asked for host names. This PR also considers if FTL runs on a non-default (!= 53) port, e.g., in testing environments.

tris203 · April 9, 2020, 11:49am

Latest output

pi@raspberrypi:~ $ tail -n 250 /var/log/pihole-FTL.log
[2020-04-09 12:44:00.231 23042] Setting nameservers back to default:
[2020-04-09 12:44:00.231 23042]  0: 8.8.8.8:53
[2020-04-09 12:44:00.231 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.231 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.231 23042] Trying to resolve 192.168.1.48
[2020-04-09 12:44:00.232 23042] Setting nameservers to:
[2020-04-09 12:44:00.232 23042]  0: 127.0.0.1:53
[2020-04-09 12:44:00.232 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.232 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.233 23042]  ---> "amazon-abf5cc92e.lan" (found internally)
[2020-04-09 12:44:00.233 23042] Setting nameservers back to default:
[2020-04-09 12:44:00.233 23042]  0: 8.8.8.8:53
[2020-04-09 12:44:00.233 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.233 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.233 23042] Trying to resolve 192.168.1.165
[2020-04-09 12:44:00.233 23042] Setting nameservers to:
[2020-04-09 12:44:00.233 23042]  0: 127.0.0.1:53
[2020-04-09 12:44:00.233 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.233 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.235 23042]  ---> "ringelite-68.lan" (found internally)
[2020-04-09 12:44:00.235 23042] Setting nameservers back to default:
[2020-04-09 12:44:00.235 23042]  0: 8.8.8.8:53
[2020-04-09 12:44:00.235 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.235 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.235 23042] Trying to resolve 192.168.1.105
[2020-04-09 12:44:00.236 23042] Setting nameservers to:
[2020-04-09 12:44:00.236 23042]  0: 127.0.0.1:53
[2020-04-09 12:44:00.236 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.236 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.237 23042]  ---> "ringelite-5c.lan" (found internally)
[2020-04-09 12:44:00.237 23042] Setting nameservers back to default:
[2020-04-09 12:44:00.237 23042]  0: 8.8.8.8:53
[2020-04-09 12:44:00.237 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.238 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.238 23042] Trying to resolve 192.168.1.78
[2020-04-09 12:44:00.238 23042] Setting nameservers to:
[2020-04-09 12:44:00.238 23042]  0: 127.0.0.1:53
[2020-04-09 12:44:00.238 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.238 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.239 23042]  ---> "amazon-a2a406aae.lan" (found internally)
[2020-04-09 12:44:00.240 23042] Setting nameservers back to default:
[2020-04-09 12:44:00.240 23042]  0: 8.8.8.8:53
[2020-04-09 12:44:00.240 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.240 23042]  2: 0.0.0.0:0
[2020-04-09 12:44:00.240 23042] Trying to resolve 192.168.1.157
[2020-04-09 12:44:00.240 23042] Setting nameservers to:
[2020-04-09 12:44:00.240 23042]  0: 127.0.0.1:53
[2020-04-09 12:44:00.240 23042]  1: 0.0.0.0:0
[2020-04-09 12:44:00.240 23042]  2: 0.0.0.0:0

Maarten · April 9, 2020, 11:56am

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 ?

DL6ER · April 9, 2020, 12:13pm

We don't overwrite /etc/resolv.conf. We used to do this previously but v5.0 stops this. Whatever is in this file is written there by your system.

It is supported, for instance

dig -x ::1 @127.0.0.1 +short
ip6-localhost.

Who "knows" about the hostnames and do they get resolved with a similar dig request?

Maarten · April 9, 2020, 12:27pm

Hi, my apologies. I judged too fast. IPv6 are resolving now ! Thanks.
When can I revert FTL to release/v5.0 branch?

DL6ER · April 9, 2020, 12:37pm

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.

Maarten · April 9, 2020, 2:18pm

Was something wrong with resolvconf, I re-installed it on my NanoPi NEO2 running DietPi (buster image):

rm /etc/resolv.conf
apt-mark auto resolvconf
G_AGA
G_AGI resolvconf
reboot

Now resolv.conf contains the static DNS servers I configured through dietpi-config menu.

DL6ER · April 10, 2020, 8:34am

The PR has been reviewed and merged. Please go back to the main branch using

pihole checkout ftl release/v5.0

tris203 · April 10, 2020, 12:39pm

Done

I assume I can drop these lines from the config

DEBUG_API=true
FORCE_FIRST_RESOLVER=true

Thank for your help

DL6ER · April 10, 2020, 6:38pm

Yeah, go ahead and remove them. Thanks for your assistance with this bug!