[GH-ISSUE #1825] Windows client only uses resolved CNAME IP in answers, not in additionals #784

New issue

Open

opened 2026-03-16 00:13:55 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 00:13:55 +03:00

Owner

Originally created by @moschroe on GitHub (Nov 8, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1825

I want to use trust-dns named for a VPN and internal services. It will be defined as a domain-specific DNS server and only serve internal addresses.

I want to use CNAMEs to be flexible later on when I may want to point to servers outside of this internal network. Example:

# zone .v.domain.tld
some-alias CNAME server00
server00 A 10.55.55.42

When I did a compatibility check with a windows system, I could not resolve some-alias.v.domain.tld to an address and neither the browser nor ping would reach the server for lack of an IP.
When I used server00.v.domain.tld, everything worked fine.

When I deactivated the VPN on my test VM and forgot about it, the system used the uplink for DNS and that happened to be the host (also in the VPN), running systemd-resolved. The test succeeded.

Wireshark showed me that the answer to the A query for some-alias.v.domain.tld from systemd-resolved contained the CNAME for some-alias and an A record for server00 in the answers section.

The failing test with trust-dns showed the CNAME record being returned in the answers section but the A record in additionals.

I looked at #513 and it put me on the right track. I patched trust-dns (in-memory authority) to put A (and AAAA) records in answers instead of additionals and now the windows host was able to use the returned answer.

For the time being, I'm using my patched build. It seems systemd-resolved queries the internal named and aggregates all answers.

Questions:

Is everything according to spec and I just misunderstood something?
Is windows doing weird things by not properly using the additional record?
Is trust-dns doing something weird?
Would it be desirable to change trust-dns behaviour (or make it at least configurable?)

Originally created by @moschroe on GitHub (Nov 8, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1825 I want to use trust-dns `named` for a VPN and internal services. It will be defined as a domain-specific DNS server and only serve internal addresses. I want to use CNAMEs to be flexible later on when I may want to point to servers outside of this internal network. Example: ``` # zone .v.domain.tld some-alias CNAME server00 server00 A 10.55.55.42 ``` When I did a compatibility check with a windows system, I could not resolve `some-alias.v.domain.tld` to an address and neither the browser nor ping would reach the server for lack of an IP. When I used `server00.v.domain.tld`, everything worked fine. When I deactivated the VPN on my test VM and forgot about it, the system used the uplink for DNS and that happened to be the host (also in the VPN), running systemd-resolved. The test succeeded. Wireshark showed me that the answer to the A query for `some-alias.v.domain.tld` from `systemd-resolved` contained the CNAME for `some-alias` _and_ an A record for `server00` in the answers section. The failing test with trust-dns showed the CNAME record being returned in the answers section but the A record in _additionals._ I looked at #513 and it put me on the right track. I patched trust-dns (in-memory authority) to put A (and AAAA) records in answers instead of additionals and now the windows host was able to use the returned answer. For the time being, I'm using my patched build. It seems `systemd-resolved` queries the internal `named` and aggregates all answers. Questions: 1. Is everything according to spec and I just misunderstood something? 1. Is windows doing weird things by not properly using the additional record? 1. Is trust-dns doing something weird? 1. Would it be desirable to change trust-dns behaviour (or make it at least configurable?)