Queries for local hosts hanging while ipv6 query forwarded upstream?

Help
1

i've gotten pihole running pretty solidly as my network resolver host as well as dhcp provider, but recently i noticed that i've got a strange behaviour from/on one of my linux hosts on my network that is using pihole as its resolver..

when i try to ssh into the linux host, it first hangs for over half a minute before completing the login.. this is a classic sign of DNS resolution issues. But when on i do finally log in, it has resolved the client hostname properly, so i turned to tcpdump:

12:23:36.909013 IP 192.168.0.52.40037 > 192.168.0.254.domain: 49171+ A? macbookpro.home.my-domain. (41)
12:23:36.909032 IP 192.168.0.52.40037 > 192.168.0.254.domain: 49171+ A? macbookpro.home.my-domain. (41)
12:23:36.910145 IP 192.168.0.52.49598 > 192.168.0.254.domain: 43045+ AAAA? macbookpro.home.my-domain. (41)
12:23:36.910155 IP 192.168.0.52.49598 > 192.168.0.254.domain: 43045+ AAAA? macbookpro.home.my-domain. (41)

and looking at the logs of pihole:

Apr 27 11:23:36 dnsmasq[1341]: query[A] macbookpro.home.my-domain from 192.168.0.52
Apr 27 11:23:36 dnsmasq[1341]: DHCP macbookpro.home.my-domain is 192.168.0.22
Apr 27 11:23:36 dnsmasq[1341]: query[AAAA] macbookpro.home.my-domain from 192.168.0.52
Apr 27 11:23:36 dnsmasq[1341]: forwarded macbookpro.home.my-domain to 208.67.222.222
Apr 27 11:23:36 dnsmasq[1341]: forwarded macbookpro.home.my-domain to 127.0.0.1
Apr 27 11:23:36 dnsmasq[1341]: forwarded macbookpro.home.my-domain to 208.67.222.222

So from the looks of it, it looks like after pi-hole properly resolves the IPV4 A query, it ALSO is forwarding the AAAA query for an IPV6 version of the address UPSTREAM..

what options need to be set with pihole to prevent this? I have the following two settings turned ON:

Never forward non-FQDNs
Never forward reverse lookups for private IP ranges

but they don't seem to affect the issue, as what it's looking up IS a fqdn :-/ i also tried to enable ipv6 in dhcpd section

still my logins to this host take upwards of 40 seconds (when they should be taking milliseconds), it also happens when logging OUT from the linux host also.. I don't think there's something misconfigured on the linux host, it's just using plain dhcp..

so basically, how do i fix this situation so pi-ihole isn't contributing to stalling of ssh login connections to/from my linux hosts on forwarding ipv6 queries upstream??

2

I think this is a missing Feature/ Bug - Try raising this in the Features thread as well

3

What command are you using to initiate the ssh session? Are you addressing the linux host by name or by IP? Are you initiating the session from the MacBook?

4

Welcome to the Pi-hole community, aleks-mariusz. :slight_smile:

You could always get around those delays by using an IP address with ssh. Similarly, ssh -4 could force IPv4 usage only.

That doesn't do away with your problem for IPv6 hostname resolution, though.

You are trying to resove a FQDN name, so Pi-hole forwarding that request if it doesn't know the immediate answer is to be expected.
You may mitigate this by actually providing an AAAA record for Pi-hole.

But why are you using localhost 127.0.0.1 as upstream DNS?

Depending on who is listening on your Pi-hole machine, this might configure a DNS loop, which may explain long resolution times while waiting for time-outs.

5

The scenario happens BOTH when A.) i try to log into the macbook from the linux host B.) i try to log into the linux host from the macbook... the common theme is the linux host looking up the macbook IP both as an A record (handled by pi-hole directly) as well as an AAAA record (forwarded "incorrectly" by pi-hole upstream).

While i know i can bypass DNS being involved in scenario A by specifying the IP instead of the hostname; i would need to modify my linux host's sshd config to not look up the client connecting's hostname for scenario B. Neither option is desireable however

Thanks for the idea but i'm not looking for work-arounds, what i'd like is for pi-hole DNS dns to work properly as expected and pi-hole to not forwarded queries my local FQND queries for my local network upstream.

6

It already does that, see my previous answer and suggested solution.
We could help detailing how to configure should you need assistance with that.

Independent from this (but potentially contributing to long resolution times, so I mentioned it also in my previous answer), you still might have configured a DNS loop, unless you are using 127.0.0.1 as upstream by intention (e.g. can't tell from my side if you are using unbound). Even then, it would be unusual, as Pi-hole may choose any one server among its configured upstream DNS servers.

This doesn't necessarily mean it is wrong, but you should verify your Pi-hole's upstream DNS configuration.

7

Please send us the token generated by

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

8

3gqr8bsd55

9

the way my pihole is deployed:

  • linux host has a kvm guest running ubuntu
  • on this ubuntu VM i have pihole running (has its own IP)
  • the vm has a docker container (via podman) running docker.io/pihole/pihole:v4.4-amd64
  • the linux host gets its ip and dns configuration (contents of /etc/resolv.conf on linux host) via dhcp (provided by pihole)

if i have created a DNS loop (i see the container does have 127.0.0.1, but i also have a dns-over-https proxy container also on the pi-hole hosts that i specify via the DNS1 environment variable).. loops could be fixed if it's suspected that's the cause, but i thought it only reverts to using the resolvers in resolv.conf (inside the container) when the pi-hole dns service itself doesn't have the query-answer..

it has the answer for the A query but not the AAAA query, so it forwards that on.. i don't want to blame pihole if i misconfigured it (or the linux host), but i've spent some time looking over this config and it looks (looked) ok to me thus far (other than maybe the loop)

10

The DNS loop -if it is indeed a loop- will only account for long response times.
Likely, upstream public DNS wouldn't take 40 seconds to determine it doesn't know your macbook, so pihole-FTL would wait for 127.0.0.1 to reply, which loops until time-out.

With regard to an actual solution on how to prevent public forwarding, maybe you did overlook that part in my answer?

11

sorry i might have, are you referring to the advice:

I didn't understand how to do this exactly.. apologies, i was under the impression that pi-hole would take care of adding AAAA records for hosts on the local network since it is doing DHCP as well

12

Is IPv6 needed on your network? If not, it greatly simplifies network management if you disable IPv6 and just use IPv4.

13

i haven't found a use case for IPv6 (one where IPv4 is not sufficient) in my applications.. i'm happy to disable IPv6 (i even tried disabling it in the kernel on the host running pi-hole), but i saw this weird issue and while trying to fix it i started enabling it everywehre (figuring if it's enabled in enough places the issue should go away).. My reasoning was that the linux host's queries are asking for an IPv6 address and if it's disabled it is forwarding it upstream, but enabling it didn't seem to solve it so i'm happy to disable it.

14

I support jfb's suggestion - disabling IPv6 will spare you from a lot of potential headaches. If you do not absolutely need it, just switch it off on your router.

One of these headaches is DNS, which was totally absent in early IPv6 and only added later as an afterthought. (click for more)

IPv6 clients will only try to register their names when they use Stateful DHCPv6 for network integration. Most clients don't, preferring SLAAC or sometimes Stateless DHCPv6 - and note that the client (or rather, its OS) decides on the procedure, not a DHCP server.

Some DHCP servers provide heuristics to populate AAAA records if they happen to know the client's MAC address through their IPv4 leases, but IPv6 may use a DUID instead of a MAC address for network integration, so this may not work reliably.

To overcome this, you can manually add an IPv6 to hostname relation in /etc/hosts on your Pi-hole machine, or create a separate configuration for dnsmasq holding the necessary host record definitions.

15

useful approach but is this something pi-hole supports? it sounds like it would be a preferable solution to:

which is manual and not preferable since this has to be done for every host on the network..

16

Yes, pihole-FTL -which embeds dnsmasq- does this already.

However, as this is a heuristic approach, this may or may not work, so the only reliable way is to define the records yourself - or switch off IPv6 altogether.

That's correct.
If you are not interested in receiving a proper hostname reply at all, there may be options to configure dnsmasq to just never answer such a query.
ATM, that's just an assumption, though - that thought occured to me only now.

EDIT: Yes, that seems possible, even with local name resolution from hosts and DHCP still intact:

-S, --local, --server=[/[<domain>]/[domain/]][<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
(..)
Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. --local is a synonym for --server to make configuration files clearer in this case

You could try to create an additional file /etc/dnsmasq.d/50-suppress-local-fqdn.conf containing:

local=/home.my-domain/

Of course, you'll have to adopt home.my-domain to match your actual domain name.

1 Like
17

thanks, that local=/domain-regex/ line seems to have done the trick, i now see:

Apr 27 14:49:08 dnsmasq[541]: config macbook-pro.home.alek.cx is NODATA-IPv6

which is what i was hoping for as it means no delay forwarding the AAAA query to upstream.

while i'm no stranger to command-line, for other folks benefit, should this be configurable via the web interface or done automatically by pihole?

1 Like
21

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.