SERVFAIL <=> NXDOMAIN

[Irenäus Becker]

Hi again,

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:

############
zone  at      dominic-zones/at.zone


at.     3600    IN      SOA     rns-bind.dss. hostmaster.head.dss. 
2007052100 3600 1800 3600000 600
at.     86400   IN      NS      rns-bind.dss.
at.     86400   IN      NS      rns-nsd.dss.
############

The "dig SOA"- command returns:

[...]
;; AUTHORITY SECTION:
at.                     600     IN      SOA     rns-bind.dss. 
hostmaster.head.dss. 2007052100 3600 1800 3600000 600
[...]

#############################################################################

Furthermore i tried the root-nameserver configuration.
zone .  dominic-zones/root.zone

This root-zone also needs a SOA-Record for correct compilation.

.                       86400   IN      SOA     A.ROOT-SERVERS.NET. 
NSTLD.VERISIGN-GRS.COM. 2007070501 1800 900 604800 86400
.                       459359  IN      NS      F.ROOT-SERVERS.NET.
.                       459359  IN      NS      G.ROOT-SERVERS.NET.
.                       459359  IN      NS      H.ROOT-SERVERS.NET.
.                       459359  IN      NS      I.ROOT-SERVERS.NET.
.                       459359  IN      NS      J.ROOT-SERVERS.NET.
.                       459359  IN      NS      K.ROOT-SERVERS.NET.
.                       459359  IN      NS      L.ROOT-SERVERS.NET.
.                       459359  IN      NS      M.ROOT-SERVERS.NET.
.                       459359  IN      NS      A.ROOT-SERVERS.NET.
.                       459359  IN      NS      B.ROOT-SERVERS.NET.
.                       459359  IN      NS      C.ROOT-SERVERS.NET.
.                       459359  IN      NS      D.ROOT-SERVERS.NET.
.                       459359  IN      NS      E.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.     3600000 IN      A       198.41.0.4
B.ROOT-SERVERS.NET.     3600000 IN      A       192.228.79.201
C.ROOT-SERVERS.NET.     3600000 IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     3600000 IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     3600000 IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     3600000 IN      A       192.5.5.241
G.ROOT-SERVERS.NET.     3600000 IN      A       192.112.36.4
H.ROOT-SERVERS.NET.     3600000 IN      A       128.63.2.53
I.ROOT-SERVERS.NET.     3600000 IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     3600000 IN      A       192.58.128.30
K.ROOT-SERVERS.NET.     3600000 IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     3600000 IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     3600000 IN      A       202.12.27.33

Is this a correct root-zone file for NSD? I did not found any examples 
on the net.


Is it possible to configure the nameserver, that he does not return this 
SOA?


Best regards,
Irenäus



> On Wed, Jun 13, 2007 at 06:26:00PM +0200, Irenäus Becker wrote:
>
>   
>> 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.
>
> -Peter
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20070706/810d23f8/attachment.htm>