On 17/05/2018 06:34, Mohamad F. Barham wrote:
> dig -t ANY ps @172.21.2.153
> ps. 60 IN NS rip.psg.com.
> ps. 60 IN NS ote.pnina.ps.
> ps. 60 IN NS fork.sth.dnsnode.net.
> ps. 60 IN NS ps-ns.anycast.pch.net.
> ps. 60 IN NS dns1.gov.ps.
> ps. 60 IN SOA ns1.pnina.ps. sys.pnina.ps. 2018050308 86400 7200 3600000 172800
> ps. 60 IN TXT "Generation Time: 1525341615"
> ps. 60 IN NS ns1.pnina.ps.
> ps. 60 IN NS ps.cctld.authdns.ripe.net.
> dig -t ANY ramallah-gis.ps @dns1.gov.ps
> ramallah-gis.ps. 86400 IN NS nscp1.intertech-pal.com.
> ramallah-gis.ps. 86400 IN NS nscp2.intertech-pal.com.
> dig -t ANY ramallah-gis.ps @nscp1.intertech-pal.com
> ramallah-gis.ps. 14400 IN MX 0 ramallah-gis.ps.
> ramallah-gis.ps. 86400 IN SOA ns2.cmeac.net. sys.mada.ps. 2015101905 86400
> ramallah-gis.ps. 86400 IN NS ns2.cmeac.net.
> ramallah-gis.ps. 14400 IN A 126.96.36.199
> as shown here there is an A record , but my recursor does not take this A record, it go
> further to get it from ns2.cmeac.net , while this server is down.
You have inconsistency in your delegation.
- In the parent zone (ps), ramallah-gis.ps is delegated to
nscp1.intertech-pal.com and nscp2.intertech-pal.com
- In the zone itself, ramallah-gis.ps is delegated to ns2.cmeac.net only
- ns2.cmeac.net is not responding to queries.
Suppose a client wants to resolve the A record for ramallah-gis.ps. 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/2.intertech-pal.com. 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 ns2.cmeac.net 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 @nscp1.intertech-pal.com. ramallah-gis.ps. a
$ dig +short @nscp2.intertech-pal.com. ramallah-gis.ps. a
$ dig +short @ns2.cmeac.net. ramallah-gis.ps. 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 ns2.cmeac.net 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 nscp1.intertech-pal.com and
nscp2.intertech-pal.com? Or do you want three
nameservers:nscp1.intertech-pal.com, nscp2.intertech-pal.com and
ns2.cmeac.net ? 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 ns2.cmeac.net and add two NS
records pointing to nscp1.intertech-pal.com and
nscp2.intertech-pal.com. Job done.
Queries for <any>.ramallah-gis.ps 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* ns2.cmeac.net to be
authoritative nameservers for this domain. You need to configure
replication so that ns2.cmeac.net 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 ns2.cmeac.net 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, 188.8.131.52. Hence in reality there is only a single
nameserver and there is no resilience whatsoever! Please, please,
please read RFC 2182...
Pdns-users mailing list