[Pdns-users] pDNS Recursor and forward-zones-file

[bert.hubert@netherlabs.nl]

Hi,

Do you have --trace output of what you describe? This is not expected behaviour. Trace will show what is going on.

Bert.

Sent from my phone.

----- Reply message -----
From: "Sebastian Laubscher" <Sebastian.Laubscher at 1und1.de>
Date: Wed, Jun 16, 2010 11:04
Subject: [Pdns-users] pDNS Recursor and forward-zones-file
To: "pdns-users at mailman.powerdns.com" <pdns-users at mailman.powerdns.com>

Hi Mates.

We're experiencing some "strange" behavior with pDNS Recursor (3.2 "static") and the forward-zones-file. Our Recursors are configured to forward a few hundred zones to other DNS servers, so our config is something like...:

forward-zones-file=/path/to/file

and the file itself contains multiple lines like...:

+zone.example=1.2.3.4,2.3.4.5
+example.domain=4.3.2.1

The thing is: if the Recursor forwards a query for zone.example to the authorative server 1.2.3.4 which is down or not responding, the query fails. Every query after this one will resolv correctly with 2.3.4.5. 

So, as soon as the first DNS server in line is offline, every Recursor will send at least one "query failed" to the clients before switching to the next server. Wouldn't it be more reliable to change the behavior to the opposite? First ask the other servers and only if no servers could be reached, send an error?

What if there are more than one zones on an offline server?

+zone.example=1.2.3.4,2.3.4.5
+other.example=1.2.3.4,2.3.4.5
+even.more.example=1.2.3.4,6.7.8.9
+last.example=1.2.3.4,4.3.2.1

Will there be one query error per server or per zone, before switching to the next IP?


Or did I get this wrong? 
Anyone with the same problem? 

Thanks,
  Sebastian
_______________________________________________
Pdns-users mailing list
Pdns-users at mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20100616/346f38cc/attachment-0001.html>