NLnetLabs
IN NS with priority
Given a master and a list of slaves, it would be useful to limit the master to zone transfers and to those who really want to query it, for example by specifying a weight similar to MX:
@ IN NS 10 ns0.example.com. @ IN NS 20 ns1.example.com. @ IN NS 20 ns2.example.com. @ IN NS 20 ns3.example.com.
However, I see no such option from the RFCs.
Do you think it is legal to make the master a hidden master? That is, omit the master form the NS records in the zone, keep the glue at the registrar, publish only the slaves in the NS records, let the slaves perform zone transfers from the hidden master, so that authoritative queries from the public go to the slaves only?
Ref. https://nsd.docs.nlnetlabs.nl/en/latest/reference/rfc-compliance.html
No the RFCs do not have a weight similar to MX for the type NS. Yes, the hidden master set up that is described is allowed as configuration. For that, set it as the primary that the secondary servers transfer from, for NSD this is configured in the config file for the secondary zones.
NSD attempts to fetch the transfer from the primary that sent it a notify at first. Then it falls back to trying all the configured primaries if that does not work. There is also an option, on the primary server, to send notifies out when the zone is updated.
This is what I have in mind.
zones/example.org.zone
ns0 IN A [IP of master name server]; # glue for master @ IN NS ns1.registrar.org; @ IN NS ns2.registrar.org;
etc/nsd.conf
zone: name: "example.org" zonefile: "example.org.zone.signed" provide-xfr: [CIDR by registrar] NOKEY notify: [CIDR by registrar] NOKEY
registrar
ns0 IN A [IP of master name server]; # glue for the master ns1.registrar.org ns2.registrar.org
The master does not advertise ns0 in its NS RRs. The registrar knows that ns0 is the master, because we provided the glue. The registrar can query ns0, because the master zone has a glue for it. The slaves are provided by the registrar, and can transfer the zone because we allowed for it.
What could go wrong?
That looks like it would have issues. The secondaries need to be configured, to pick up the zone from the hidden primary. That needs to be configured for the registrar since that is the one providing the secondaries. If there is no option to set where to transfer the zone from, in separation from the glue to publish in DNS records, then it would not work very well. You end up publishing the hidden primary.
Putting different information as glue in the registrar interface from the glue in the zone file is not good. That would make the glue from the parent zone delegation different from the glue in the zone file, and is considered wrong. It is best to have them the same, the list of publicly available servers. The hidden primary should then not be listed in the glue. For the secondaries to find the hidden primary they then need configuration that tells them to do that, request-xfr: <ip addr> <NOKEY or tsig-key-name>.
The secondaries need to be configured, to pick up the zone from the hidden primary.
Yes, the registrar does it.
That needs to be configured for the registrar since that is the one providing the secondaries.
Done, and known to work reliably.
If there is no option to set where to transfer the zone from, in separation from the glue to publish in DNS records, then it would not work very well.
The registrar is given the glue to the master.
You end up publishing the hidden primary.
The A RR (glue) for ns0 is a must.
The NS RR for ns0 is the gory point we are discussing.
Putting different information as glue in the registrar interface from the glue in the zone file is not good.
In fact, the glue for ns0 is identical.
That would make the glue from the parent zone delegation different from the glue in the zone file, and is considered wrong.
I never stated the opposite.
It is best to have them the same, the list of publicly available servers.
Did you read the example?
The hidden primary should then not be listed in the glue.
If you remove it, the registrar will not accept the configuration. It demands a FQDN and its IP as A RR for the master server.
For the secondaries to find the hidden primary they then need configuration that tells them to do that,
request-xfr: <ip addr> <NOKEY or tsig-key-name>.
That's what I wrote.
Okay, so that is what the registrar set up wants. I guess it works, that is nice! The ns0 as the domain name, and if it uses that for transfers. (NSD itself does not use the domain name for that, it uses the IP address for the configuration. Otherwise it would lead to recursion in needing working DNS to bring up the DNS authoritative server).
I tried it in a live system. It works technically, but fails bureaucratically. The registry demands correspondence between the nameservers listed in the registration request or in the hosts change request with those inserted in the NS records of the zone file. Once removed ns0 from the NS RRs in the master zone, the registry complained about the mismatch.