we encountered a problem with registry nic.at for tld .at and their transaction "BillWithDraw". This transaction allows an registrar to delegate authority back to registry.
For a successful use of this transaction all nameserver-entries for the zone will be deleted by our application before nic-order will be sent to nic.at.
Nic.at now checks all nameserver for existing entries for affected zone. If all nameservers return a NXDOMAIN (Bind) everything is fine.
Our NSD nameservers return the status SERVFAIL. Nic.at interprets this return-code as an error and does not finish this transaction completely.
Is it possible to return a NXDOMAIN instead of a SERVFAIL? Are there different possibilities how this point can be resolved?
Nic.at will not change their behaviour before Q4!
Nic.at now checks all nameserver for existing entries for affected zone.
If all nameservers return a NXDOMAIN (Bind) everything is fine.
Our NSD nameservers return the status SERVFAIL. Nic.at interprets this
return-code as an error and does not finish this transaction completely.
I haven't checked your view of nic.at's policies and/or procedures and would
appreciate a comment from AT. That said, ...
Is it possible to return a NXDOMAIN instead of a SERVFAIL? Are there
... SERVFAIL is probably the more protocolly correct response but not the only
possible one.
Some scenarios are listed in <draft-koch-dns-unsolicited-queries-01.txt>
different possibilities how this point can be resolved?
If you really need to respond NXDOMAIN (and again, I'm not saying you do),
one approach is to define an empty (lest the served delegations) parent TLD
(here: AT) zone on your server(s). But careful: there may be side effects
and you should make sure not to leak false information. The bottom line is:
if the problem exists, it can be solved by configuration, not by teaching
nsd to violate the protocol.
Is it possible to return a NXDOMAIN instead of a SERVFAIL? Are there
... SERVFAIL is probably the more protocolly correct response but not the only
possible one.
Some scenarios are listed in <draft-koch-dns-unsolicited-queries-01.txt>
different possibilities how this point can be resolved?
If you really need to respond NXDOMAIN (and again, I'm not saying you do),
one approach is to define an empty (lest the served delegations) parent TLD
(here: AT) zone on your server(s). But careful: there may be side effects
and you should make sure not to leak false information. The bottom line is:
if the problem exists, it can be solved by configuration, not by teaching
nsd to violate the protocol.
I agree with Peter here.
NSD returns SERVFAIL as it has no zone RR information. At the very least
NSD needs a SOA RR for the zone; it will then return NXDOMAIN for
everything else in the zone. I do not know if nic.at accepts that.
In query.c, line 1084, change
q->zone = domain_find_zone(closest_encloser);
if (!q->zone) {
if(q->cname_count == 0)
- - RCODE_SET(q->packet, RCODE_SERVFAIL);
to
q->zone = domain_find_zone(closest_encloser);
if (!q->zone) {
if(q->cname_count == 0)
+ RCODE_SET(q->packet, RCODE_NXDOMAIN);
to teach NSD to violate the protocol.
This change should never get into the NSD source as it violates the
protocol (and could cause nasty effects for some misconfigurations;
zones becoming unresolvable 'help my website disappeared').
As Peter says, configure the parent zone .at to get the same effect
without recompile.
our nameservers now return the NXDOMAIN - Status, but now we have further problems with nic.at because our .at - zone returns a SOA-Record for queried zone.
The configuration for zone-file “at.zone” looks like:
further problems with nic.at because our .at - zone returns a SOA-Record
for queried zone.
The "dig SOA"- command returns:
what are the other parameters of this commend, i.e. which domain were you
querying for?
[...]
;; AUTHORITY SECTION:
at. 600 IN SOA rns-bind.dss.
hostmaster.head.dss. 2007052100 3600 1800 3600000 600
[...]
I guess I wrote ...
>(here: AT) zone on your server(s). But careful: there may be side effects
>and you should make sure not to leak false information. The bottom line
for a reason. If at all, you should have copied the correct AT values.
Again, this is an ugly hack, the problem definitely lies elsewhere.
Is this a correct root-zone file for NSD? I did not found any examples
on the net.
There is no such thing as a "root-zone file for NSD", because the root zone
file is server independent. Your example didn't contain any TLD delegation,
which is also probably not what you want. You might have seen "root hints"
for, say, BIND, but since NSD is not offering recursive service, it doesn't
need such a beast.
Is it possible to configure the nameserver, that he does not return this
SOA?
The SOA RR in the authority section is there to make negative caching work
per RFC 2308. Configuring or patching it away would make the responses
non-standards-compliant.
The underlying assumption that a server should return an NXDOMAIN for a
domain it doesn't serve, is wrong.