Re: [Pdns-users] (no subject)

2023-03-14 Thread Brian Candler via Pdns-users

On 14/03/2023 06:45, Raghvendra Choudhary via Pdns-users wrote:
I want to put the DNS of google in the *forwarder* in the 
recursor.conf but i am unable to resolve the DNS form the *forwarder. 
*Please help me to get this configuration in the right way.


The setting you need is forward-zones-recurse 
, 
and the zone to forward for "everything" is a dot by itself.


If this doesn't work, please show what configuration you tried, and what 
error message you get when using it.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2018-05-17 Thread Brian Candler

On 17/05/2018 12:01, Mohamad F. Barham wrote:
Im the one who managing a recursor server not the one who manage an 
authoritative server for ramallah-gis.ps.


but I noticed the previous case in ramallah-gis.ps 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 dns.google do ) 


If an authoritative domain is broken for you, then it's most likely 
broken for much of the Internet.


You can force all queries for ramallah-gis.ps to be sent to 
nscp1/2.intertech-pal.com by means of a "forwarders" entry. To do this, 
in your recursor.conf put:


forward-zones-file=/etc/powerdns/forward-zones

And in that file put:

ramallah-gis.ps=46.43.66.107

But if you need this domain to work, I think effort would be better 
spent talking to the domain owner.  Over time your forwarders entry may 
become stale (e.g. if the domain owner moves their nameservice), so you 
are storing up problems for the future.


As for whether pdns recursor merges NS records from the zone with the 
delegation, or replaces them - I defer to the pdns experts.  I pretty 
sure that BIND has implemented both behaviours in different versions.


https://stackoverflow.com/questions/636084/dns-do-the-ns-names-set-for-a-zone-have-to-match-the-ns-names-reported-by-the-u

Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2018-05-17 Thread Mohamad F. Barham
Thanks Mr Brian Candler,,,

Im the one who managing a recursor server not the one who manage an 
authoritative server for ramallah-gis.ps.

but I noticed the previous case in ramallah-gis.ps 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 dns.google do )





[cid:image002.png@01D327F4.25E9A910]


Mohamad Barham

System administrator | Information Technology Department

Birzeit University

P.O.Box. 14, Birzeit, Palestine

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

mbar...@birzeit.edu | www.birzeit.edu<http://www.birzeit.edu/>







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

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 360 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 
> 7200 360
> 86400
> ramallah-gis.ps. 86400 IN NS ns2.cmeac.net.
> ramallah-gis.ps. 14400 IN A 213.6.7.147
>
> 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
213.6.7.147
$ dig +short @nscp2.intertech-pal.com. ramallah-gis.ps. a
213.6.7.147
$ 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 .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 

Re: [Pdns-users] (no subject)

2018-05-17 Thread Brian Candler

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 360 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 
7200 360
> 86400
> ramallah-gis.ps. 86400 IN NS ns2.cmeac.net.
> ramallah-gis.ps. 14400 IN A 213.6.7.147
> 
> 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
213.6.7.147
$ dig +short @nscp2.intertech-pal.com. ramallah-gis.ps. a
213.6.7.147
$ 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 .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 

Re: [Pdns-users] (no subject)

2018-05-17 Thread bert hubert
On Thu, May 17, 2018 at 05:34:42AM +, Mohamad F. Barham wrote:
> > I have installed pdns-recursor on a centos machine, I'm trying to resolve
> > ramallah-gis.ps , some times it can get the  A record and most of the time 
> > returns
> > ServFAIL .

Hi - I can't reproduce this problem here. Which version of PowerDNS are you
on?

while true; do rec_control wipe-cache ramallah-gis.ps ; dig -t any 
ramallah-gis.ps @127.0.0.1 -p 5300; done

This is always able to resolve ramallah-gis.ps for me.

Can you show your trace log if you are on a supported version (4.1), then we
can take a far better look.

Thanks!

Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2016-01-05 Thread bert hubert
On Tue, Jan 05, 2016 at 10:17:43AM +0100, Sebastian Broekhoven wrote:
> Our PowerDNS server is crashing lately.
> When looking into te log, I get this messages:

Please run pdnssec check-all-zones and tell us what it says. Or pdnsutil
check-all-zones if on 4.x.

> Jan  5 10:01:42 ns1 pdns[22577]: TCP Connection Thread died because of
> STL error: DNSPacketWriter::xfrLabel() found empty label in the middle
> of name

You probably have a record like this somewhere in your database:
'www..powerdns.com'. We should not crash on that of course, so that is a
bug.

If pdnssec doesn't find anything, try:
select * from records where content like '%..%'
and
select * from records where name like '%..%'

Bert

> 
> I can't realy find where to look for, to solve this problem.
> 
> pdns_control version
> 3.4.7
> MySQL back-end
> Debian GNU/Linux OS
> 
> Kind regards,
> Sebastian
> 



> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2016-01-05 Thread Sebastian Broekhoven
Hello Bert,

Tank you for the response.
Later on I was searching the database for records.

SELECT id, name, type, content FROM records WHERE name LIKE '.%';
SELECT id, name, type, content FROM records WHERE name LIKE '%..%';
SELECT id, name, type, content FROM records WHERE name LIKE '% %';
SELECT id, name, type, content FROM records WHERE name LIKE '%@%';

The results were to cry for...
I think I'm going to kick some developers!

The error log is almost clean now!

-- 
Kind Regards,
Sebastian Broekhoven


On 05-01-16 10:22, bert hubert wrote:
> On Tue, Jan 05, 2016 at 10:17:43AM +0100, Sebastian Broekhoven wrote:
>> Our PowerDNS server is crashing lately.
>> When looking into te log, I get this messages:
> 
> Please run pdnssec check-all-zones and tell us what it says. Or pdnsutil
> check-all-zones if on 4.x.
> 
>> Jan  5 10:01:42 ns1 pdns[22577]: TCP Connection Thread died because of
>> STL error: DNSPacketWriter::xfrLabel() found empty label in the middle
>> of name
> 
> You probably have a record like this somewhere in your database:
> 'www..powerdns.com'. We should not crash on that of course, so that is a
> bug.
> 
> If pdnssec doesn't find anything, try:
> select * from records where content like '%..%'
> and
> select * from records where name like '%..%'
> 
>   Bert
> 
>>
>> I can't realy find where to look for, to solve this problem.
>>
>> pdns_control version
>> 3.4.7
>> MySQL back-end
>> Debian GNU/Linux OS
>>
>> Kind regards,
>> Sebastian
>>
> 
> 
> 
>> ___
>> Pdns-users mailing list
>> Pdns-users@mailman.powerdns.com
>> http://mailman.powerdns.com/mailman/listinfo/pdns-users
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2016-01-05 Thread Sebastian Broekhoven
Hello,

After doing some cleaning up (a few thousand records) the log is clean.
No strange errors.

Also, the pdns_server isn't crashing anymore!

The only thing I have to clean op are record duplicates which I found
with: pdnssec check-all-zones.

Thanks for the help.

-- 
Kind Regards,
Sebastian Broekhoven

On 05-01-16 13:12, Sebastian Broekhoven wrote:
> Hello Bert,
> 
> Tank you for the response.
> Later on I was searching the database for records.
> 
> SELECT id, name, type, content FROM records WHERE name LIKE '.%';
> SELECT id, name, type, content FROM records WHERE name LIKE '%..%';
> SELECT id, name, type, content FROM records WHERE name LIKE '% %';
> SELECT id, name, type, content FROM records WHERE name LIKE '%@%';
> 
> The results were to cry for...
> I think I'm going to kick some developers!
> 
> The error log is almost clean now!
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users