Querying for CNAME pointing to A kept by remote server doesn't return A

Help
1

Hello,

instead of following regular bug report's template, i have rather question or misunderstanding on how DNS in general work. For better understanding what i am struggling with, let me introduce my homelab network.

On top there's Mikortik serving (amongst other roles) as edge router and DHCP server. There i have dhcp lease script saving each hostname to local DNS cache to solve ultimately problem of giving fancy names to my equipment but having to address them via IP rather than name.

To this mikrotik there's connected virtualized PiHole, for sake of simplicity let's assume that it's being plugged directly into Mikrotik and is receiving IPv4 172.16.32.30 address as every other device :slight_smile:

On the same network i do have nextcloud server on bare metal. Server's identity is being set as cloud, just regular crashed laptop with Debian, Nginx, nothing too fancy.

There's also Fujitsu's thin client, futroS720, acting as reverse proxy on nginx. One of futro720's roles is to add HTTPS layer to the traffic and to be single HTTP centre of my homelabbity. There are locally hosted static websites, reverse-proxied services like nextcloud and tons of other stuff.
So, in context of my case, futro720 has configured VHost nextcloud.tripos.ovh, to be proxy-passed to my http instance of nextcloud on cloud. This of course usually works flawlessly.
For name-based VHost hosting there has to be Host: header set in http request, for this purpose CNAMEs does their job, pointing to single machine under different hostnames, or identities if you like. That's pihole's job, in webui -> Local DNS -> CNAME records i have setup nextcloud.tripos.ovh being CNAME of futros720.tripos.ovh.

Pihole itself is configured with conditional forwarding, so every querfy for something with .tripos.ovh comes, it should be forwarded to my Mikrotik to be resolved there. Using webui -> Settigns -> DNS -> Conditional forwarding. And this works flawlessly all of the time. Pihole also has Unbound installation running on localhosts's 5335/udp as its upstream but i doubt it has to do anything with my case, just stating this out if it could be handy.

And this is where it's starts to get hard.

Pihole's FTL does "host" so to speak CNAME records, but isn't authoritative for A records for .tripos.ovh domain, as it's "origin" is on Mikrotik. Therefore, after restart of FTL or FTL's cache expiration, queries for nextcloud.tripos.ovh returns only CNAME record.

lis6502@e595:~$ dig @172.16.32.30 nextcloud.tripos.ovh

; <<>> DiG 9.19.21-1-Debian <<>> @172.16.32.30 nextcloud.tripos.ovh
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59645
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nextcloud.tripos.ovh.		IN	A

;; ANSWER SECTION:
nextcloud.tripos.ovh.	0	IN	CNAME	futros720.tripos.ovh.

;; Query time: 23 msec
;; SERVER: 172.16.32.30#53(172.16.32.30) (UDP)
;; WHEN: Sat Mar 23 13:27:43 CET 2024
;; MSG SIZE  rcvd: 83

This way, nor Firefox or Chrome, nor even my laptop's ping doesn't bother to "further resolve" futros720, but rather relies on A being empty, so

lis6502@e595:~$ ping nextcloud.tripos.ovh
ping: nextcloud.tripos.ovh: Name or service not known
lis6502@e595:~$ curl https://nextcloud.tripos.ovh
curl: (6) Could not resolve host: nextcloud.tripos.ovh

However, if i "help" FTL and ask for futros720.tripos.ovh first, i believe it's getting cached and subsequent queries returns A+CNAME responses

lis6502@e595:~$ dig @172.16.32.30 futros720.tripos.ovh

; <<>> DiG 9.19.21-1-Debian <<>> @172.16.32.30 futros720.tripos.ovh
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39189
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;futros720.tripos.ovh.		IN	A

;; ANSWER SECTION:
futros720.tripos.ovh.	203	IN	A	172.16.32.7

;; Query time: 3 msec
;; SERVER: 172.16.32.30#53(172.16.32.30) (UDP)
;; WHEN: Sat Mar 23 13:35:43 CET 2024
;; MSG SIZE  rcvd: 65

lis6502@e595:~$ dig @172.16.32.30 nextcloud.tripos.ovh

; <<>> DiG 9.19.21-1-Debian <<>> @172.16.32.30 nextcloud.tripos.ovh
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23919
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nextcloud.tripos.ovh.		IN	A

;; ANSWER SECTION:
nextcloud.tripos.ovh.	0	IN	CNAME	futros720.tripos.ovh.
futros720.tripos.ovh.	199	IN	A	172.16.32.7

;; Query time: 3 msec
;; SERVER: 172.16.32.30#53(172.16.32.30) (UDP)
;; WHEN: Sat Mar 23 13:35:47 CET 2024
;; MSG SIZE  rcvd: 99

Then, browsers, ping, whatnot is able to reach nextcloud or any other reverse proxied webapp hosted on futro.
I know, this could be solved in at least three ways:

  • use local cache on my clients (like systemd-resolved),
  • use local /etc/hosts entries on my client devices for futros720( but why to use DNS then)
  • setup ugly cronjob on pihole instance to query every 3 minutes for futros720.tripos.ovh to keep its address always in cache.

Instead i would like to tackle problem at its core and conceive solution on Pihole itself, without grotesque workarounds.

What i've tried so far was to setup forward zone on Unbound (while turning off conditional forwarding on Pihole of course), like

root@dns:~# cat /etc/unbound/unbound.conf.d/local-tripos-forwardzone.conf 
forward-zone: 
	name: "tripos.ovh."
	forward-addr: 172.16.32.1@53

but also without luck.

2

Indeed, this is not a bug, but intended standard DNS behaviour.

Local CNAME Records prominently disclaims

The target of a CNAME must be a domain that the Pi-hole already has in its cache or is authoritative for. This is a universal limitation of CNAME records.

To make CNAMEs work, if you only intend to use it internally, for private range IPs only, you could consider to define the respective local DNS records (A and AAAA) for resolution targets within Pi-hole as well.

But as futros720.tripos.ovh seems to be your own public domain(?), you really should create those CNAME records within your public authoritative DNS Server.

3

Thanks! Especially that my setup isn't as common and original post wasn't that short :stuck_out_tongue:
So two solutions: either

  • "import" my records from Mikrotik to Pihole, making them "local" for Pihole,or
  • abandon idea of comfortably setting CNAMEs from PIhole's webui and stick to editing them on Mikrotik :C

Bummer.
I was really hoping for some "exclusions", given that only thing parting me from success is presence of preresolved A.

Are there any FTL-level workarounds? Like marking cache entry "static" or "trusted"? Or maybe utilize some other DNS features instead of CNAMEs? Or maybe setup "zone transfer" from MT to PH to make PH authoritative? :stuck_out_tongue:

4

Is this strictly internal, private range IP use only?

You could consider defining A records in Pi-hole instead of CNAMEs.

From your description, it would seem you wouldn't need all your router's records, but just for that one CNAME target domain?

5

Is this strictly internal, private range IP use only?

yes. i know it's not valid B-class segment but back then i had to coexist with my employer's network and instead of natting i simply chose to cheat ;p. sidenote: ironing out all these rough edges is a process of untangling my LANs, i plan to switch to actual B-class segment in nearest future.

Domain is valid though, i wanted to avoid browsers to redirect my hostnames to search engine due to not having valid TLD, but "public" side of my tripos.ovh has nothing to do with my lan's internal tripos.ovh. My idea was to seamlessly switch between public/ private instances of webapps. Simply, if anytime my "private" records leaks, internet's resolvers return NX while inside my lan, Pihole being first resolver will lookup name locally. Also, i wanted to have valid TLS certificates instead of forcing my every client device to trust my sketchy forged CA.

you wouldn't need all your router's records, but just for that one CNAME target domain?

At this point in time - yes. I only have one 'hostname-based' revese proxy, but this can change. For now of course i can supersede CNAMEs with As as you've wisely suggested. And this is route i will take - at the end of the day all my DHCP assignments are static (same host gets assigned same IP address) so this will work :slight_smile:

Will let you all know does this did the trick :slight_smile:

6

So indeed, adding my former CNAMEs as A records on Pihole ultimately did the trick( meaning no NX replies). What's worth noting is a fact that Pihole's interface has option to supply comma separated list of domain names to be resolved to single IP, so my "conversion" was as simple as ctrl-select left side of the CNAMEs table, superseding EOL to comma and pasting resulting line into DNS Records section.

Thanks for this idea Bucking_Horn !

7

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