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?
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
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
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
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.
@ljakob Are you trying to set up an alias? In this case, you need CNAME, not NS.
Stay secure,
Peter
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.