starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

MagicDNS base domain clobbers valid records #54

New Issue
Closed
opened 2025-12-29 01:21:13 +01:00 by adam · 4 comments
adam commented 2025-12-29 01:21:13 +01:00
Owner
Copy Link

Originally created by @nicka101 on GitHub (Oct 14, 2021).

The Domain used for MagicDNS' base domain must not match an actual domain, as any valid records within such domain are completely clobbered by MagicDNS and return NXDOMAIN.

In my own testing I use my domain (anstee.dev) as the base, knowing full well that MagicDNS will include the namespace ("nicka101" for my testing) in the produced records , and thus there should be no conflict with actual records visible to upstream DNS.

However checking DNS responses after making these changes reveals the following:

Relevant section of headscale config:

"dns_config": {
       "nameservers": ["8.8.4.4", "8.8.8.8"],
       "domains": [],
       "magic_dns": true,
       "base_domain": "anstee.dev"
   }

DNS query for the base domain against 8.8.8.8:

❯ dig @8.8.8.8 anstee.dev

; <<>> DiG 9.16.21 <<>> @8.8.8.8 anstee.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11423
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;anstee.dev.                    IN      A

;; ANSWER SECTION:
anstee.dev.             3600    IN      A       51.195.219.36

;; Query time: 116 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 14 01:13:26 CEST 2021
;; MSG SIZE  rcvd: 55

DNS query for base domain against 100.100.100.100:

❯ dig @100.100.100.100 anstee.dev

; <<>> DiG 9.16.21 <<>> @100.100.100.100 anstee.dev
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6569
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;anstee.dev.                    IN      A

;; Query time: 0 msec
;; SERVER: 100.100.100.100#53(100.100.100.100)
;; WHEN: Thu Oct 14 01:14:34 CEST 2021
;; MSG SIZE  rcvd: 28

Note that its not just the base domain that gets clobbered, any valid subdomains are also clobbered:

~ 
❯ dig @8.8.8.8 +noall +answer anstee.dev
anstee.dev.             2876    IN      A       51.195.219.36

~ 
❯ dig @8.8.8.8 +noall +answer git.anstee.dev
git.anstee.dev.         3600    IN      CNAME   anstee.dev.
anstee.dev.             3600    IN      A       51.195.219.36

~ 
❯ dig @100.100.100.100 +noall +answer git.anstee.dev

~ 
❯ dig @8.8.8.8 +noall +answer ldn1.anstee.dev
ldn1.anstee.dev.        3600    IN      A       51.195.219.36

~ 
❯ dig @100.100.100.100 +noall +answer ldn1.anstee.dev

~ 
❯

MagicDNS entries themselves are working as expected however:

❯ dig @100.100.100.100 +noall +answer pi4.nicka101.anstee.dev
pi4.nicka101.anstee.dev. 600    IN      A       100.99.123.231
Originally created by @nicka101 on GitHub (Oct 14, 2021). The Domain used for MagicDNS' base domain must not match an actual domain, as any valid records within such domain are completely clobbered by MagicDNS and return NXDOMAIN. In my own testing I use my domain (anstee.dev) as the base, knowing full well that MagicDNS will include the namespace ("nicka101" for my testing) in the produced records , and thus there should be no conflict with actual records visible to upstream DNS. However checking DNS responses after making these changes reveals the following: Relevant section of headscale config: ``` "dns_config": { "nameservers": ["8.8.4.4", "8.8.8.8"], "domains": [], "magic_dns": true, "base_domain": "anstee.dev" } ``` DNS query for the base domain against 8.8.8.8: ``` ❯ dig @8.8.8.8 anstee.dev ; <<>> DiG 9.16.21 <<>> @8.8.8.8 anstee.dev ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11423 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;anstee.dev. IN A ;; ANSWER SECTION: anstee.dev. 3600 IN A 51.195.219.36 ;; Query time: 116 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Oct 14 01:13:26 CEST 2021 ;; MSG SIZE rcvd: 55 ``` DNS query for base domain against 100.100.100.100: ``` ❯ dig @100.100.100.100 anstee.dev ; <<>> DiG 9.16.21 <<>> @100.100.100.100 anstee.dev ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6569 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;anstee.dev. IN A ;; Query time: 0 msec ;; SERVER: 100.100.100.100#53(100.100.100.100) ;; WHEN: Thu Oct 14 01:14:34 CEST 2021 ;; MSG SIZE rcvd: 28 ``` Note that its not just the base domain that gets clobbered, any valid subdomains are also clobbered: ``` ~ ❯ dig @8.8.8.8 +noall +answer anstee.dev anstee.dev. 2876 IN A 51.195.219.36 ~ ❯ dig @8.8.8.8 +noall +answer git.anstee.dev git.anstee.dev. 3600 IN CNAME anstee.dev. anstee.dev. 3600 IN A 51.195.219.36 ~ ❯ dig @100.100.100.100 +noall +answer git.anstee.dev ~ ❯ dig @8.8.8.8 +noall +answer ldn1.anstee.dev ldn1.anstee.dev. 3600 IN A 51.195.219.36 ~ ❯ dig @100.100.100.100 +noall +answer ldn1.anstee.dev ~ ❯ ``` MagicDNS entries themselves are working as expected however: ``` ❯ dig @100.100.100.100 +noall +answer pi4.nicka101.anstee.dev pi4.nicka101.anstee.dev. 600 IN A 100.99.123.231 ```
adam added the bug label 2025-12-29 01:21:13 +01:00
adam closed this issue 2025-12-29 01:21:13 +01:00
adam commented 2025-12-29 01:21:14 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 14, 2021):

Good observation, from what i understand, this is on the tailscale side and we can't really do anything else than warning/recommending people.

Would you be able to pr a doc change to inform the users?

Let me know if I misunderstood.

@kradalby commented on GitHub (Oct 14, 2021): Good observation, from what i understand, this is on the tailscale side and we can't really do anything else than warning/recommending people. Would you be able to pr a doc change to inform the users? Let me know if I misunderstood.
adam commented 2025-12-29 01:21:15 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Oct 14, 2021):

I think this is a valid issue. Need to investigate a bit. I reckon we should only capture $NAMESPACE.$BASE_DOMAIN not the whole base domain.

@juanfont commented on GitHub (Oct 14, 2021): I think this is a valid issue. Need to investigate a bit. I reckon we should only capture $NAMESPACE.$BASE_DOMAIN not the whole base domain.
adam commented 2025-12-29 01:21:15 +01:00
Author
Owner
Copy Link

@nicka101 commented on GitHub (Oct 15, 2021):

I would tend to agree with Juan that the expected behavior would be for headscale/tailscale to only capture $NAMESPACE.$BASE_DOMAIN (along with any additional namespaces visible to the current user), rather than clobbering the entire base domain.

I understand that the actual DNS responses are controlled by the tailscale client, which is running the DNS server, however it seems like modification of generateMagicDNSRootDomains within dns.go could resolve the issue if it were to actually specify the individual relevant subdomains, instead of the base domain itself like it currently does on dns.go#40

@nicka101 commented on GitHub (Oct 15, 2021): I would tend to agree with Juan that the expected behavior would be for headscale/tailscale to only capture $NAMESPACE.$BASE_DOMAIN (along with any additional namespaces visible to the current user), rather than clobbering the entire base domain. I understand that the actual DNS responses are controlled by the tailscale client, which is running the DNS server, however it seems like modification of `generateMagicDNSRootDomains` within dns.go could resolve the issue if it were to actually specify the individual relevant subdomains, instead of the base domain itself like it currently does on [dns.go#40](https://github.com/juanfont/headscale/blob/main/dns.go#L40)
adam commented 2025-12-29 01:21:15 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Oct 15, 2021):

Yep, I am working on a patch that fixes that already. Will probably launch
a PR today.

On Fri, Oct 15, 2021, 13:48 Nick Anstee @.***> wrote:

I would tend to agree with Juan that the expected behavior would be for
headscale/tailscale to only capture $NAMESPACE.$BASE_DOMAIN (along with any
additional namespaces visible to the current user), rather than clobbering
the entire base domain.

I understand that the actual DNS responses are controlled by the tailscale
client, which is running the DNS server, however it seems like modification
of generateMagicDNSRootDomains within dns.go could resolve the issue if
it were to actually specify the individual relevant subdomains, instead of
the base domain itself like it currently does on dns.go#40
https://github.com/juanfont/headscale/blob/main/dns.go#L40

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/juanfont/headscale/issues/160#issuecomment-944234123,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABMGQ6VJEHPUOHVHAHZ3DTUHAIKDANCNFSM5F6KPQKQ
.

@juanfont commented on GitHub (Oct 15, 2021): Yep, I am working on a patch that fixes that already. Will probably launch a PR today. On Fri, Oct 15, 2021, 13:48 Nick Anstee ***@***.***> wrote: > I would tend to agree with Juan that the expected behavior would be for > headscale/tailscale to only capture $NAMESPACE.$BASE_DOMAIN (along with any > additional namespaces visible to the current user), rather than clobbering > the entire base domain. > > I understand that the actual DNS responses are controlled by the tailscale > client, which is running the DNS server, however it seems like modification > of generateMagicDNSRootDomains within dns.go could resolve the issue if > it were to actually specify the individual relevant subdomains, instead of > the base domain itself like it currently does on dns.go#40 > <https://github.com/juanfont/headscale/blob/main/dns.go#L40> > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/juanfont/headscale/issues/160#issuecomment-944234123>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABMGQ6VJEHPUOHVHAHZ3DTUHAIKDANCNFSM5F6KPQKQ> > . >
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#54
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?