Fedora 40 - Split DNS Resolution(Internal/External) Issue - Favortizing External Resolution

Ask Fedora
, , , , , ,
24

Is it possible that your Fedora DNS resolver config (or your local DNS server) has a typo in the local domain name definition, while your Windows and Mac systems do not (or have the same typo as your local DNS server)?

If that were the case, e.g., exmple.com vs. example.com,

Bare hostnames would be referred to as host.exmple.com rather than host.example.com, and your local DNS server would see it as an external domain, rather than one that it’s authoritative for.

Unfortunately, I can only guess since you’ve obfuscated not just host names, but domain names and IP addresses (I can see obfuscating external IPs and domains, but internal IP addresses – assuming they’re RFC1918 ranges, doesn’t make a lot of sense since they’re not routable). That said, I understand your paranoia (and just because you’re paranoid doesn’t mean “they” aren’t out to get you). I’d suggest reviewing all the DNS/network configs on your DNS and DHCP servers, as well as on your Fedora, Windows and Mac clients and ensure there aren’t any typos.

I don’t claim that will resolve your problem (as it’s impossible to say what that problem might be), but it’s something else to try.

HTHAL.

25

Thank you for this. I had some time today to circle back to this and further troubleshoot. To answer your questions.

HOST=servername.domainname.com; for NS in 127.0.0.53 
$INTERNALIPV4_IP $INTERNALIPV6_IP; do dig -t A @$NS $HOST; host $HOST 
$NS; done`

 Are there any significant differences in their responses among different servers? does response directed at local resolved 127.0.0.53 address match what response it gets on internal DNS addresses? Do IPv4 and IPv6 internal servers respond with the same addresses? Order of addresses might change if multiple records, but the set should be the same.

I performed the above command using servername FQDN against 127.0.0.53 and the internal DNS server IP 10.0.1.1. The dig results were exactly the same. Both pulled back the internal IPv4 IP Address, and then the two IPv6 external IPs addresses coming from cloudflare hosted external DNS. Of interest it ONLY showed the two external IPv6 IP Addresses and not the two external IPv4 which are also associated with the hostname. Could it be it ignores them because it sees a local resolution?

Results against local DNS Server (Same when 127.0.0.53)

HOST=homebridge.schwartzllc.com; for NS in 10.0.1.1 $INTERNALIPV4_IP $INTERNALIPV6_IP; do dig -t A @$NS $HOST; host $HOST $NS; done

; <<>> DiG 9.18.28 <<>> -t A @10.0.1.1 homebridge.schwartzllc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;homebridge.schwartzllc.com. IN A

;; ANSWER SECTION:
homebridge.schwartzllc.com. 0 IN A 10.0.10.124

;; Query time: 2 msec
;; SERVER: 10.0.1.1#53(10.0.1.1) (UDP)
;; WHEN: Sat Aug 10 10:05:02 EDT 2024
;; MSG SIZE rcvd: 71

Using domain server:
Name: 10.0.1.1
Address: 10.0.1.1#53
Aliases:

homebridge.schwartzllc.com has address 10.0.10.124
homebridge.schwartzllc.com has IPv6 address 2606:4700:3036::6815:1e25
homebridge.schwartzllc.com has IPv6 address 2606:4700:3031::ac43:9684

Results against external DNS Server

HOST=homebridge.schwartzllc.com; for NS in 1.1.1.1 $INTERNALIPV4_IP $INTERNALIPV6_IP; do dig -t A @$NS $HOST; host $HOST $NS; done

; <<>> DiG 9.18.28 <<>> -t A @1.1.1.1 homebridge.schwartzllc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40021
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;homebridge.schwartzllc.com.	IN	A

;; ANSWER SECTION:
homebridge.schwartzllc.com. 300	IN	A	104.21.30.37
homebridge.schwartzllc.com. 300	IN	A	172.67.150.132

;; Query time: 32 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Aug 10 10:23:03 EDT 2024
;; MSG SIZE  rcvd: 87

Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

homebridge.schwartzllc.com has address 104.21.30.37
homebridge.schwartzllc.com has address 172.67.150.132
homebridge.schwartzllc.com has IPv6 address 2606:4700:3031::ac43:9684
homebridge.schwartzllc.com has IPv6 address 2606:4700:3036::6815:1e25

It seems as fedora prioritizes those two external IPv6 addresses for connections vs. mac and windows prioritize the internal IPv4 address when available.

My next thought coincides with what you mentioned. Maybe I need to define a local IPv6 AAAA or CNAME record on the internal Unifi DNS so that it ignores the external resolutions? (Of which I cannot do as Unifi is still pending CNAME resolution implementation for their DNS which is supposed to be coming.)

This leads me to my last test which leads to further confusion… Focusing on a host that is not using IPv6 and only IPv4. FQDN IPv4 defined internally, and on external DNS server a CNAME mapping to another host with IPv4 only. All connections in fedora favor the external CNAME ip vs. local.

When run against 127.0.0.53 or my internal DNS server:

HOST=homeassistant.schwartzllc.com; for NS in 10.0.1.1 $INTERNALIPV4_IP $INTERNALIPV6_IP; do dig -t A @$NS $HOST; host $HOST $NS; done

; <<>> DiG 9.18.28 <<>> -t A @10.0.1.1 homeassistant.schwartzllc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63394
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;homeassistant.schwartzllc.com.	IN	A

;; ANSWER SECTION:
homeassistant.schwartzllc.com. 0 IN	A	10.0.10.121

;; Query time: 6 msec
;; SERVER: 10.0.1.1#53(10.0.1.1) (UDP)
;; WHEN: Sat Aug 10 10:35:15 EDT 2024
;; MSG SIZE  rcvd: 74

Using domain server:
Name: 10.0.1.1
Address: 10.0.1.1#53
Aliases:

homeassistant.schwartzllc.com has address 10.0.10.121
homeassistant.schwartzllc.com is an alias for ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa.
homeassistant.schwartzllc.com is an alias for ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa.

When run against external DNS server

HOST=homeassistant.schwartzllc.com; for NS in 1.1.1.1 $INTERNALIPV4_IP $INTERNALIPV6_IP; do dig -t A @$NS $HOST; host $HOST $NS; done

; <<>> DiG 9.18.28 <<>> -t A @1.1.1.1 homeassistant.schwartzllc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34261
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;homeassistant.schwartzllc.com.	IN	A

;; ANSWER SECTION:
homeassistant.schwartzllc.com. 300 IN	CNAME	ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa.
ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa. 60 IN A 52.23.103.22

;; Query time: 39 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Aug 10 10:36:20 EDT 2024
;; MSG SIZE  rcvd: 133

Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

homeassistant.schwartzllc.com is an alias for ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa.
ibkfmtn1dncggu0ulv1xtffymzfsc16f.ui.nabu.casa has address 52.23.103.22

Lastly, all dig results also look the same on windows and mac too, yet they favor the internal IPs for connections.

26

Create an AAAA record on your local DNS server targeting the :: address for each hostname you want to override including the IPv4-only host.

This works for me to prefer local A records over upstream AAAA and CNAME when using dnsmasq.

Another approach is to disable DNS forwarding for queries matching the local domain.

27

This sounds like my same issue. I’m only using IPv4…

did you ever figure it out? I’m also on a Unifi network and it’s only connecting to an external address, not the local one. And why does this work fine on Windows and Android but not on Fedora?