[GH-ISSUE #109] use a separate nameserver for subdomain #219

New issue

Open

opened 2026-03-01 17:24:38 +03:00 by kerem · 1 comment

kerem commented

2026-03-01 17:24:38 +03:00

Owner

Originally created by @nclr on GitHub (Apr 29, 2018).
Original GitHub issue: https://github.com/abh/geodns/issues/109

This is probably obvious but I have trouble in setting a nameserver for subdomain (geo.< mydomain >.com).
My setup is this:

filename: < mydomain >.com

{
	"serial": 1,
	"ttl": 30,
	"max_hosts": 10,
	"data": {
		"": {
			"ns": {
				"ns1.<mydomain>.": "<ip>",
				"ns2.<mydomain>": "<ip>"
			}
		},
		"geo": {
			"ns": [ "ns-876.awsdns-45.net", "ns-1767.awsdns-29.co.uk" ]
		}
	}
}

Originally created by @nclr on GitHub (Apr 29, 2018). Original GitHub issue: https://github.com/abh/geodns/issues/109 This is probably obvious but I have trouble in setting a nameserver for subdomain (geo.< mydomain >.com). My setup is this: filename: < mydomain >.com ``` { "serial": 1, "ttl": 30, "max_hosts": 10, "data": { "": { "ns": { "ns1.<mydomain>.": "<ip>", "ns2.<mydomain>": "<ip>" } }, "geo": { "ns": [ "ns-876.awsdns-45.net", "ns-1767.awsdns-29.co.uk" ] } } } ```

kerem commented

2026-03-01 17:24:39 +03:00

Author

Owner

@abh commented on GitHub (Apr 29, 2018):

Yeah, that’s totally broken / not implemented! Thank you for noticing and reporting this.

It works if you do a NS lookup (explicitly) on “geo.com” (right?), but the code is completely missing the bits that recognizes the delegation.

Some notes, mostly from memory:

In zones/reader.go the code needs to notice the delegation (search for dns.TypeNS). Given an NS record on “sub” then when looking up “something.foo.sub” it has to figure out that “sub” is a delegation and serve the NS records.

The obviously place to do this would be in server/serve.go somewhere just before we give up and serve NXDOMAIN, but that doesn’t catch lookups (other than NS) on “sub” itself. There’s a check for len(m.Answer) == 0 where this would go, but obviously duplicating this is a sign the code isn’t structured right for putting this in.

I wanted to take out the _country and _status special cases. Taking them out might make the solution more obvious (basically have “no labelMatches” and “we ended up with no answers” branch into “is this a delegation?” before figuring out if it’s an NXDOMAIN or just a NOERROR with a SOA record).

If you work on it, the ‘dev’ branch is much ahead of master at the moment (and will soon get merged in as version 3.0).

@abh commented on GitHub (Apr 29, 2018): Yeah, that’s totally broken / not implemented! Thank you for noticing and reporting this. It works if you do a NS lookup (explicitly) on “geo.com” (right?), but the code is completely missing the bits that recognizes the delegation. Some notes, mostly from memory: In `zones/reader.go` the code needs to notice the delegation (search for `dns.TypeNS`). Given an NS record on “sub” then when looking up “something.foo.sub” it has to figure out that “sub” is a delegation and serve the NS records. The obviously place to do this would be in `server/serve.go` somewhere just before we give up and serve NXDOMAIN, but that doesn’t catch lookups (other than NS) on “sub” itself. There’s a check for `len(m.Answer) == 0` where this would go, but obviously duplicating this is a sign the code isn’t structured right for putting this in. I wanted to take out the _country and _status special cases. Taking them out might make the solution more obvious (basically have “no labelMatches” and “we ended up with no answers” branch into “is this a delegation?” before figuring out if it’s an NXDOMAIN or just a NOERROR with a SOA record). If you work on it, the ‘dev’ branch is much ahead of master at the moment (and will soon get merged in as version 3.0).