Thanks Mr Brian Candler,,,

Im the one who managing a recursor server not the one who manage an 
authoritative server for

but I noticed the previous case in domain, SO , is there away 
to avoid such a problem in the recursor , (force to get from nscp1/2 and not to 
go further just like what do )


Mohamad Barham

System administrator | Information Technology Department

Birzeit University

P.O.Box. 14, Birzeit, Palestine

Tel: + 970 22982012 | Mob: +970 597 861929 | Ext: 5616 |<>

From: Brian Candler <>
Sent: Thursday, May 17, 2018 10:52:10 AM
To: Mohamad F. Barham;
Subject: Re: [Pdns-users] (no subject)

On 17/05/2018 06:34, Mohamad F. Barham wrote:
> dig -t ANY ps @
> ps. 60 IN NS
> ps. 60 IN NS
> ps. 60 IN NS
> ps. 60 IN NS
> ps. 60 IN NS
> ps. 60 IN SOA 2018050308 86400 7200 3600000 172800
> ps. 60 IN TXT "Generation Time: 1525341615"
> ps. 60 IN NS
> ps. 60 IN NS
> dig -t ANY
> 86400 IN NS
> 86400 IN NS
> dig -t ANY
> 14400 IN MX 0
> 86400 IN SOA 2015101905 86400 
> 7200 3600000
> 86400
> 86400 IN NS
> 14400 IN A
> as shown here there is an A record , but my recursor does not take this A 
> record, it go
> further to get it from , while this server is down.

You have inconsistency in your delegation.

- In the parent zone (ps), is delegated to and

- In the zone itself, is delegated to only

- is not responding to queries.

Suppose a client wants to resolve the A record for  It will 
ask its nearby cache for the answer.

If this is the first time the cache has done a query for this domain, then the 
query will go to nscp1/ However if it has previously done a 
query, it will have cached the NS record from within the zone.  Depending on 
the software they're running, some caches will *merge* the NS records from the 
delegation and within the zone; other caches will *replace* the NS records with 
those within the zone, and only send queries to from then onwards 
(until the NS records expire).  And of course, with only one nameserver within 
the zone, there is no resilience (see RFC 2182); if that nameserver is down, 
clients will get only SERVFAIL.

Now let's check how those three nameservers answer:

$ dig +short a
$ dig +short a
$ dig +short a
;; connection timed out; no servers could be reached
<< that means SERVFAIL >>

So that's your problem: the problem is in how the zone itself is set up, not 
the recursor, which is behaving correctly.  Once a cache has learned that is the sole nameserver for the zone (learned from the 
authoritative information within the zone), it may only send queries to this 
bad nameserver.

To fix this, you need to decide which nameservers are going to be authoritative 
for the domain.  Is it only and  Or do you want three nameservers:, and ?  Or some 
other combination of nameservers?

* If you only want two nameservers nscp1/2, which are working and which the 
domain is already delegated to, then the fix is simple. Inside the zone file, 
remove the NS record pointing to and add two NS records pointing 
to and  Job done.

Queries for <any> will then only ever hit those two 
nameservers, and if one is down, clients will use the other [^1]

* If you want a different set of nameservers than that, then you have to:

1. configure all the nameservers so they have identical zone contents. Normally 
this is done by configuring replication. You can use DNS zone transfers, so one 
nameserver is master and the others slave from it; or perhaps you build all the 
nameservers with a database backend, and you configure SQL replication between 
the backends.

2. configure NS records inside the zone listing those nameservers

3. change the delegation to point to those nameservers.  This means asking your 
registrar to change the set of NS records for your domain; this will cause a 
change in the zone file for the "ps" domain.

So for example, suppose you want nscp1/2 *and* to be 
authoritative nameservers for this domain.  You need to configure replication 
so that is authoritative for the domain *and* has identical zone 
contents to the other two nameservers.  Then you have to create three NS 
records inside the zone.  Then you have to change the delegation in your 
registrar to point to these three nameservers.

Note that if you do want to use as a nameserver then you need at 
least one other nameserver as well; and it needs to be on a different network 
backbone (again, details in RFC 2182).  Otherwise you can certainly expect 
random failures to occur intermittently.

This is clearly not a pdns-recursor issue, because you want your zone to be 
resolvable by anyone on the Internet regardless of which recursor softwarwe 
they're using; but I hope this helps anyway.



[^1] Except that I just checked, and nscp1 and nscp2 both resolve to the same 
IP address, Hence in reality there is only a single nameserver 
and there is no resilience whatsoever!  Please, please, please read RFC 2182...

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system. The University is neither liable for 
the proper and complete transmission of the information contained in this 
communication nor for any delay in its receipt.
Pdns-users mailing list

Reply via email to