Local CNAME resolution is inconsistent

Expected Behaviour:

The response to queries for local hosts with CNAME entries should always also include the proper A record.

Actual Behaviour:

Sometimes, only the CNAME record is returned and it is left to the querying client to do issue a second query.

It is debatable if the expected behavior is the norm. Some clients can deal with CNAME-only responses and they issue another query but it does no harm if the initial response always also includes the A record.

I do not know why the behavior works for some entries and doesn't for others.

Please provide some examples that show the behavior you see.

Relevant CNAME entries:
firefox_sggWwEJjCz

Querying for harry.lan:
kitty_1ZTOqKrPqH

Querying for grafana.lan:
kitty_v008N3AQEh

Querying for broker.lan:
kitty_bZJIVlLFhJ

The target of a CNAME must be a domain that the Pi-hole knows the A value for, or is authoritative for that domain.

Pi-hole will not do additional queries if you set the target to a domain that isn't already known. It will return the information it knows at the time of the query, without having to send additional queries to an upstream for resolution.

Thanks, @DanSchaper for your comments. The alias grafana.lan points to harry.lan (see my first screenshot). Pi-hole knows harry.lan (see my second screenshot). Yet, I only get the CNAME record when querying for grafana.lan. When querying for broker.lan I get the expected result (fourth screenshot).

How is harry.lan's IP address set?

Edit: And is it set in a different method than berry.lan?

That's a good point, thanks. berry.lan has an explicit DNS entry (via the web gui) while harry.lan uses a reserved DHCP lease. I think we found the reason. I gave harry its own DNS entry and now it works.

This solves the case for me but I don't know if this a bug or a case of works-as-intended.

It's in the middle. It's a works as intended per RFC and dnsmasq but it's not the best user experience.

1 Like

To spare others from my experience I suggest the following addition or something similar to the web interface documentation: "Canonical names to which alias entries (in the CNAME section) point must have an explicit DNS entry (DNS section). Alias entries pointing to names that exist as DHCP leases only will not be fully resolved."

https://github.com/pi-hole/AdminLTE/pull/1663

Thanks for suggesting the documentation change.

                  <p>The target of a CNAME must be a domain that the Pi-hole knows the A value for, or is authoritative for that domain.</p>
                  <p>Pi-hole will not do additional queries if you set the target to a domain that isn't already known. It will return the information it knows at the time of the query,
                    without having to send additional queries to an upstream for resolution.</p>

Sorry for nitpicking, but IMHO this is too cryptic for the average user (such as me). It does not address the fact that even though the Pi-hole assigned an IP to a client via DHCP it does not 'know' it. Perhaps adding this makes it clearer: "Pi-hole does not resolve alias names if the canonical name is just used through a DHCP lease."

I updated the PR to make it even clearer.

I think you are referring to hostname and local FQDN, e.g. harry and harry.lan -being two different domains- would both require DNS records, one handled by DHCP and one by a Local DNS record.

That may not be true for configurations where Pi-hole is acting as DHCP servers and Never forward non-FQDNs is ticked, as that would prompt an expand-hosts option to be set (see also Clients unable to resolve Pi-Hole hostname - #9 by Bucking_Horn).

CNAMEs themselves have always to be defined explicitly for both variants (if required) with dnsmasq.

Thanks for the remarks. I looked over my situation and now recognized an error on my side. I apologize for the confusion. There was no active lease for harry.lan, just a reservation and the IP was fixed on the client. I now understand that the alias would have been resolved if it matched an active lease.

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