NS-record for subdomain not showing in zone

Hi,
I’ve setup a NS-record via API and Web-UI for a existing running domain served on desec.io but the NS-record for the subdomain does not show up if I query the name with UNIX tools like

host -t NS xyz.domain.com

Any idea?

The NS records in the zone at deSEC are fairly irrelevant. You need to get your domain registrar to set the NS delegation records in the parent zone.

E.g. if your domain is example.com Then the NS records need to be set in the .com zone for the subdomain example. This is something only the domain registrar can initiate.

While you’re at it you can also get your domain registrar to set the DS records in the parent zone to make DNSSEC work. But do this in 2 steps: NS delegation first, then DS records.

Note: deSEC e.V. is not a domain registrar.

HTH
fiwswe

1 Like

The question is about a subdomain, not the zone apex at the desec-io servers. Technically it should be possible to delegate subdomains to other servers, and this does work if you’re delegating your own domain to Desec. As a matter of policy though, domains under dedyn.io cannot delegate subdomains. The web interface won’t let you create the records.

If you’re trying to delegate a subdomain of your own domain, make sure that the server that you’re delegating to is configured to answer for that zone and can be reached by your (recursive) resolver. If you’re using a public resolver, your server for that subdomain has to be publicly reachable (at least by that resolver) for that host lookup to work. You can see how far the delegation works with dig +trace ns sub.example.com

1 Like

Another common mistake is to put the full name in the subname field. If you want child.example.com, the subname is only child.

Stay secure,
Peter

1 Like

Hi,
thanks for your responses, but IMHO there is a bug:

host -t SOA weite-welt.com ns1.desec.io => ... 2025034387 ...

→ domain is correctly hosted a desec.io and I use it on a daily basis, I would know if the domain would have problems with DNS delegation

host -t SOA weite-welt.com ns2.desec.org => same

→ so both main servers are in sync

host -t NS dt.weite-welt.com ns1.desec.io => dt.weite-welt.com has no NS record

The NS-record is correctly setup

and points to an A record

host -t ANY balder.weite-welt.com ns1.desec.io. => balder.weite-welt.com has address 85.215.238.111

Any ideas?

The Desec nameservers return the NS record that you set, but then the resolver can’t contact your nameserver balder…, so the host command never finishes resolving your query. The recursive resolver tries to contact the authoritative server for your ds subdomain to get the NS records, so your server, to which you successfully delegated the subdomain, has to be reachable by the recursive resolver, and it isn’t. Do try that dig +trace command that I recommended.

1 Like

@ljakob Are you trying to set up an alias? In this case, you need CNAME, not NS.

Stay secure,
Peter

1 Like

hi, funny - I found the problem (it was “local”):

host -t NS dt.weite-welt.com ns1.desec.io still returns “has no NS record”

but the dig +trace www.dt.weite-welt.com prints

dt.weite-welt.com. 86400 IN NS balder.weite-welt.com.

I’ve assumed that host -t NS would print the result from the queried nameserver, but they do something different… all is fine. It also shows with host -v

What’s happening is that you delegated the subdomain to your own server, “balder…”. So when asked for the NS record, the Desec servers tell your resolver to ask the NS for that subdomain, “balder…”. That’s the line you see in the dig trace. The host command (and dig as well) doesn’t treat that as the response because the domain is delegated to a different server.

The Desec nameservers refuse to resolve recursive queries, because they’re authoritative nameservers, not resolvers. So even if they could reach your server, they wouldn’t try to get the answer for you. You get a response that doesn’t have the answer bit set, and host tells you that it didn’t get a NS record for the subdomain. It did, but just as a referral, not as the answer.

Your resolver still has to ask the server that’s authoritative for that subdomain, your server, and it can’t because that isn’t reachable.

1 Like