Should the domain used for NS also be managed in Technitium? This creates a loop?

[Turab]

This is a little DNS-noob quetion.

TL;DR
How can I move the DNS hosting of the domain I am using for Technitium, in Technitium? Technitium cluster is on ns.example.com and I would like host example.com's DNS in Technitium as well.
/ TL;DR

I newly started managing my domains in Techitium cluster and it has been going well for a couple of months.

Due to the cluster design, nodes have the name location1.ns.example.com and location2.ns.example.com under the primary zone of ns.example.com

While naturally ns.example.com is primarily hosted in Technitium, primary zone for example.com is hosted elsewhere. Now I want to move example.com to Technitium as well. But how is this going to work, as it creates a loop?

At the registrar, if I define location1.ns.example.com and location2.ns.example.com as the nameservers of this domain, then also special glue needs to be defined at the registrar to have these to resolve to the IP addresses of my cluster nodes. But special NS glue doesn't work for nested subdomains; while nested subdomains is a must for clustering.

I mean NS lookup for example.com finds location1.ns.example.com at the registrar, then it needs to resolve location1.ns.example.com and it comes back to registrar creating a circular dependency.

Now I thought I could add ns1.anotherdomain.com and ns2.anotherdomain.com as the nameservers and then create special NS glue for these two in at the registrar level with the cluster IPs. But then these two new nameservers are not defined in the NS list of example.com in Technitium, as naturally Techitium defines itself as the NS of the domains which it is the primary zone of.

Long story short.. Is it a bad idea and a no-go to manage the cluster's main domain in Technitium? Can't a DNS server serve its own domain? And if I can.. How?

As it could be guessed, adding extra NS records in Technitium for ns1.anotherdomain.com and ns2.anotherdomain.com is not an option since Technitium says:

Error! Cannot add NS records for Primary zones that are members of the Cluster Catalog zone. These NS records are automatically managed by the Cluster and only their TTL values can be updated.

An it could anyway create more complexity than doing anything good. So what now?

[ShreyasZare]

Thanks for asking. You can migrate the main domain example.com to the same cluster without making changes to the cluster zone ns.example.com.

At the registrar, if I define location1.ns.example.com and location2.ns.example.com as the nameservers of this domain, then also special glue needs to be defined at the registrar to have these to resolve to the IP addresses of my cluster nodes. But special NS glue doesn't work for nested subdomains; while nested subdomains is a must for clustering.

At the registrar, you just need to have NS glue records added for example.com. The ns.example.com has nothing to do with the registrar for example.com since its a subdomain and not directly registered with the registrar.

So, you just need to host example.com on your cluster as a primary zone, then register ns1.example.com along with the public static IP address of you cluster as glue with your registrar (along with ns2..., ns3..., etc. as required). With this setup, your example.com zone will be reachable from the internet by recursive resolver.

For ns.example.com, you do not need to do anything at all. The zone is on the same name servers as that of the parent zone example.com and thus will resolve without doing anything else.

[Turab]

Thanks for your time but I am sorry I didn't quite get it.

Cluster nodes already have their respective domains like:

loc1.ns.example.com
loc2.ns.example.com

And these are used as NS records for the domains I want to manage their DNS of, at their respective registrars.

At the registrar, like for any other domain, wouldn't I need to add loc1.ns.example.com and loc2.ns.example.com as the nameservers? So what is it with ns1.example.com? Is it just an exception for the main domain?

I have example.com primary zone in Technitium right now. Do I add ns1 an A record in it? Or I just add the glue (for ns1.example.com and ns2) with cluster IPs at the registrar and do nothing on Technitium side?

In this case, I think the setup works but the DNS inspection reports:

Missing nameservers reported by parent FAIL: The following nameservers are listed at your nameservers as nameservers for your
domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are
working. If they are not working ok, you may have problems!
loc1.ns.example.com
loc2.ns.example.com

Missing nameservers reported by your nameservers ERROR: One or more of the nameservers listed at the parent servers are
not listed as NS records at your nameservers. The problem NS records are:
ns1.example.com
ns2.example.com
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at
the root servers and the NS records point to your own domain, for example).

[ShreyasZare]

And these are used as NS records for the domains I want to manage their DNS of, at their respective registrars.

At the registrar, like for any other domain, wouldn't I need to add loc1.ns.example.com and loc2.ns.example.com as the nameservers?

You mean to say that you want to host other domain names too on the cluster and use the loc1.ns.example.com and loc2.ns.example.com as their name servers? If that is correct then yes, if you host xyz.com on your cluster then at the registrar, change the name server entries to loc1.ns.example.com and loc2.ns.example.com so that they are resolved from your cluster name servers.

So what is it with ns1.example.com? Is it just an exception for the main domain?

For example.com you need to have separate glue records for itself. You cannot bypass the parent zone with using name servers from subdomain zone. A recursive resolver will first reach example.com before reaching ns.example.com zone.

I have example.com primary zone in Technitium right now. Do I add ns1 an A record in it? Or I just add the glue (for ns1.example.com and ns2) with cluster IPs at the registrar and do nothing on Technitium side?

Yes, you must add A record for ns1, ns2, etc. that match the glue records you have added at registrar. Glue records are just a reference and without having these A records, those NS domain names will fail to resolve.

[ShreyasZare]

The parent zone for loc2.ns.example.com is example.com and thus that zone has nothing to do with the registrar. You have to update name servers at registrar since you want to have them update the .com parent zone to include those delegation NS records for example.com.

For your example.com zone, you must use ns1.example.com and ns2.example.com as name servers and have only those registered with the registrar.

Your example.com zone thus will have 4 NS records: 2 for itself and the other 2 to delegate ns subdomain name. The 2 NS records for itself are the ones you registered with registrar and the name for those NS records must be @. While the other two delegation NS records, the name must be ns and domain names must be loc1/loc2.ns.example.com.

[Turab]

For your example.com zone, you must use ns1.example.com and ns2.example.com as name servers and have only those registered with the registrar.

This is ok.

Your example.com zone thus will have 4 NS records: 2 for itself and the other 2 to delegate ns subdomain name.

It has 3 NS records. loc1 and loc2 for itself (@) and one for ns host as ns.example.com with two glue IPs defined. (So in theory, it makes it 4 yes.

The 2 NS records for itself are the ones you registered with registrar and the name for those NS records must be @

This is one thing I am not understanding here. How can the ones I registered with the registrar be the NS records for itself in Technitium. The 2 records for itself (@) are auto-managed by Technitium, which are to be loc1/loc2.ns.example and thus these can't be the ones I registered with the registrar? What am I missing here? At the registrar it is only ns1/ns2.

If you mean I need to add extra NS records of ns1/ns2 for the zone example.com, this I can't, as I said that's because it is automatically managed by Technitium and it would emit this error if I tried to add it anyway:

Error! Cannot add NS records for Primary zones that are members of the Cluster Catalog zone. These NS records are automatically managed by the Cluster and only their TTL values can be updated.

So at the registrar:
ns1/ns2 are the only nameservers that are saved with the glue of the IPs of my cluster.

On Technitiuım:
loc1/loc2 are the only nameservers for the zone example.com itself (@)
ns is the only nameserver for in the example.com zone, for the host ns, with the glue of IPs of my cluster.
A records for ns1/ns2 in the example.com zone.

So in short;

I can't register loc1/loc2.ns.example.com at the registrar but only ns1/ns2
I can't register NS records of ns1/ns2 on Technitium, but only loc1/loc2

Since the registrar reports ns1/ns2 and Technitium reports loc1/oc2 as the nameservers; that's what I am calling "mismatch". The declared nameservers do not match at domain level and at DNS level.

[ShreyasZare]

It has 3 NS records. loc1 and loc2 for itself (@) and one for ns host as ns.example.com with two glue IPs defined. (So in theory, it makes it 4 yes.

The example.com zone cannot have loc1.ns and loc2.ns as its name servers. You need to fix that to use ns1 and ns2.

How can the ones I registered with the registrar be the NS records for itself in Technitium. The 2 records for itself (@) are auto-managed by Technitium, which are to be loc1/loc2.ns.example and thus these can't be the ones I registered with the registrar? What am I missing here?

I guess the example.com zone is a member of the cluster catalog zone. Which is why the NS records are loc1/2.ns. You need to remove example.com zone from the cluster catalog and create the expected ns1/2 NS records manually. Create the secondary zone for it manually too on the secondary node.

At the registrar it is only ns1/ns2.

This is the reason for the mismatch issue you have. At registrar you have ns1/ns2 and in your zone your have loc1.ns and loc2.ns.

Removing the example.com zone from the catalog and managing it separately is the only way to make this work.

[Turab]

I guess the example.com zone is a member of the cluster catalog zone. Which is why the NS records are loc1/2.ns. You need to remove example.com zone from the cluster catalog and create the expected ns1/2 NS records manually. Create the secondary zone for it manually too on the secondary node.

This is the answer I was looking for. Yes it is a member of the cluster zone, for automatic syncing, for the sake of being a cluster.

Ok. Than this means I will have to manually sync this domain through the cluster each time I (or any other automated service) changes anything? That's not good :(

I think Technitium should consider its own domain a special case; rather than having to remove the domain out of sync.

[ShreyasZare]

Ok. Than this means I will have to manually sync this domain through the cluster each time I (or any other automated service) changes anything? That's not good :(

I think Technitium should consider its own domain a special case; rather than having to remove the domain out of sync.

No, that not what it means. You only have to manually create a secondary zone for example.com on the secondary node. This is a one time task and after that all changes in primary zone will sync with the secondary zone just like how it is working now. Only difference is that you are not using the catalog zone feature and have to provision the secondary zone manually.

[Hemsby]

I think the confusion is that loc1/loc2.ns.example.com and ns1/ns2.example.com look like they should be the same set of nameservers, but they're actually answering two completely separate questions, and that's why there's no loop.

example.com gets found by a resolver through the glue records at your registrar, ns1.example.com and ns2.example.com pointing at your cluster IPs. That's the entry point, it's what lets someone find your domain cold with no prior info.

ns.example.com only comes into play after that. Once a resolver has already resolved example.com and gets referred down into the ns.example.com subdomain, it's now walking a zone you're already authoritative for. It doesn't need to go back to the registrar at that point, so there's nothing circular about it.

So both sets of names are correct, they just don't need to match each other, and they're not supposed to.

On why you can't hand-edit the NS records on ns.example.com: that zone is the cluster's own catalog zone, and those loc1/loc2 records reflect actual cluster membership. If you could edit them manually they'd drift out of sync with the real nodes. example.com is just a normal primary zone though, so you're free to add ns1/ns2 A and NS records there yourself, which is exactly what you should do.

So I wouldn't call this a product gap, it's just standard delegation behavior. Any nameserver software would work the same way here. The mismatch you're seeing reported is coming from a third party checker tool that isn't accounting for the nameservers being a subdomain of the zone itself.

[Hemsby]

Sorry, I misread the mismatch part, I was thinking of it purely in terms of "can a resolver still find the zone" and missed that the NS records still need to actually line up with what's registered. Shreyas is right, that's not something to ignore.