[Pdns-users] dns queries timeout on secondary IPs
Hi, I have CentOS 5.5 and powerdns 2.9.21 set up as a slave server. My problem is that pdns does not reply to queries that come from outside on any secondary IP . Here's the full story: nslookup -norecurse domain.com - MAINIP Server: MAINIP Address:MAINIP#53 Name: domain.com Address: 1.1.1.1 nslookup -norecurse domain.com - SECONDARYIP ;; connection timed out; no servers could be reached When I run nmap on both primary and secondary IP for port 53 UDP and TCP it says they are open. I configured pdns for verbose logging and the strange thing is that when I query for a non-existent domain then I can see in the pdns logs: pdns[5282]: Not authoritative for 'asd', sending servfail to SOMEIP (recursion was desired) But when I query for a domain that exists in pdns there's no message, nothing. Just timeout. However querying from the dns server itself on all its IPs works fine. I have no firewalls Please help Thanks -- Server Surgeon Support supp...@serversurgeon.com http://www.serversurgeon.com System Administration Services Toll Free 1-877-E-SURGEON (877-378-7436) International 623-374-6848 Get the system support you need when you need it. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] dns queries timeout on secondary IPs
On Wed, Sep 08, 2010 at 08:31:45PM +0300, George wrote: > I have CentOS 5.5 and powerdns 2.9.21 set up as a slave server. My > problem is that pdns does not reply to queries that come from outside > on any secondary IP . Here's the full story: Can you run: grep local-address /etc/powerdns/pdns.conf (or whereever your configuration is?). Can you also paste the startup messages of PowerDNS? Thanks. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] dns queries timeout on secondary IPs
Hi, Here are the outputs: [r...@webprod02 ~]# grep local-address /etc/pdns/pdns.conf # local-address Local IP addresses to which we bind local-address=0.0.0.0 # query-local-address Source IP address for sending queries # query-local-address= pdns[5109]: Scheduling exit on remote request pdns[5109]: Guardian is killed, taking down children with us pdns[6266]: Listening on controlsocket in '/var/run/pdns.controlsocket' pdns[6269]: Guardian is launching an instance pdns[6269]: This is module gmysqlbackend.so reporting pdns[6269]: This is a guarded instance of pdns pdns[6269]: It is advised to bind to explicit addresses with the --local-address option pdns[6269]: UDP server bound to 0.0.0.0:53 pdns[6269]: TCP server bound to 0.0.0.0:53 pdns[6269]: PowerDNS 2.9.21 (C) 2001-2006 PowerDNS.COM BV (Apr 1 2008, 12:06:01, gcc 4.1.2 20070626 (Red Hat 4.1.2-14)) starting up pdns[6269]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2. pdns[6269]: Creating backend connection for TCP pdns[6269]: Master/slave communicator launching pdns[6269]: gmysql Connection succesful pdns[6269]: About to create 3 backend threads for UDP pdns[6269]: gmysql Connection succesful pdns[6269]: gmysql Connection succesful pdns[6269]: All slave domains are fresh pdns[6269]: gmysql Connection succesful Please advise Thanks On Wed, Sep 8, 2010 at 8:39 PM, bert hubert wrote: > On Wed, Sep 08, 2010 at 08:31:45PM +0300, George wrote: >> I have CentOS 5.5 and powerdns 2.9.21 set up as a slave server. My >> problem is that pdns does not reply to queries that come from outside >> on any secondary IP . Here's the full story: > > Can you run: > grep local-address /etc/powerdns/pdns.conf (or whereever your configuration > is?). > > Can you also paste the startup messages of PowerDNS? > > Thanks. > ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] dns queries timeout on secondary IPs
On Wed, Sep 08, 2010 at 08:44:01PM +0300, George wrote: > Here are the outputs: > [r...@webprod02 ~]# grep local-address /etc/pdns/pdns.conf > # local-address Local IP addresses to which we bind > local-address=0.0.0.0 (...) > pdns[6269]: It is advised to bind to explicit addresses with the > --local-address option > pdns[6269]: UDP server bound to 0.0.0.0:53 > pdns[6269]: TCP server bound to 0.0.0.0:53 (...) > Please advise George - it already gave you advice ;-) Please bind to explicit Ip addresses, and not to 0.0.0. Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] dns queries timeout on secondary IPs
Thanks! I changed local-address and included all the IPs with a , between them and it worked. I thought 0.0.0.0 is supposed to make it work on all IPs. On Wed, Sep 8, 2010 at 8:46 PM, bert hubert wrote: > On Wed, Sep 08, 2010 at 08:44:01PM +0300, George wrote: >> Here are the outputs: >> [r...@webprod02 ~]# grep local-address /etc/pdns/pdns.conf >> # local-address Local IP addresses to which we bind >> local-address=0.0.0.0 > (...) >> pdns[6269]: It is advised to bind to explicit addresses with the >> --local-address option >> pdns[6269]: UDP server bound to 0.0.0.0:53 >> pdns[6269]: TCP server bound to 0.0.0.0:53 > (...) >> Please advise > > George - it already gave you advice ;-) Please bind to explicit Ip > addresses, and not to 0.0.0. > > Good luck! > > Bert > ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] tcp listener issue - hopefully fixed
On Sun, Aug 29, 2010 at 09:17:01PM +, Brad Dameron wrote: > > The release process for 3.3 can now start - only 1 feature request left > > to > > finish. > > Good to hear Bert. I'll run it through the ringer on Monday and see if we can > reproduce the problem. Cross fingers that it is fixed. Brad, Any news? If I get confirmation from you, Simon or Laurent that the problem is gone, we can go for release. Thanks ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Strange time drift in log
No other suggestions?
In the meantime, just in case, I have tried switching from the
2.9.22 rpm which I had found in a repository, to the more
standard 2.9.21-4 rpm included in the 'extras' CentOS
repositories, but the behavior is exactly the same.
I am thinking that this problem could probably be linked to the
LDAP backend. Has anyone else noticed this time shift in pdns
logging when using non-UTC as server time, esp. with LDAP?
Nick
On 5/9/2010 3:36 μμ, Nikolaos Milas wrote:
Thanks Christian,
{I am resending in HTML format, to avoid auto line breaks
which make terminal output illegible.}
This problem happened to me only with pdns server logging.
I've never had a similar problem on this or on any of the
other servers I'm managing (mainly CentOS), all with the same
locale, with various daemons and syslog.
The pdns daemons running are as follows:
# ps -ef | grep
pdns
UID PID PPID C STIME TTY TIME CMD
102 2265 1 0 13:02 ? 00:00:00
/usr/sbin/pdns_recursor --daemon
root 2854 1 0 15:10 ? 00:00:00
/usr/sbin/pdns_server --daemon --guardian=yes
pdns 2856 2854 0 15:10 ? 00:00:00
/usr/sbin/pdns_server-instance --daemon --guardian=yes
Threads:
# ps axjf | grep pdns
PPID PID PGID SID TTY TPGID STAT UID TIME
COMMAND
1 2265 2265 2265 ? -1 Ss 102 0:00
/usr/sbin/pdns_recursor --daemon
1 2854 2854 2854 ? -1 Ssl 0 0:00
/usr/sbin/pdns_server --daemon --guardian=yes
2854 2856 2854 2854 ? -1 Sl 101
0:00 \_/usr/sbin/pdns_server-instance --daemon
--guardian=yes
It might help in troubleshooting to observe that only
the pdns server start- and stop- related messages are logged
with correct time (Europe/Athens, i.e. EEST). All
normal operation messages are logged with UTC time.
It might also help that the time drift happens after the
message: "Creating backend connection for TCP".
See below:
Stop server (messages with correct time):
Sep 5
14:48:34 vdns pdns[2706]: Scheduling exit on remote request
Sep 5 14:48:34 vdns pdns[2706]: Guardian is killed,
taking down children with us
Start server (messages with correct time):
Sep 5
14:48:46 vdns pdns[2764]: Listening on controlsocket in
'/var/run/pdns.controlsocket'
Sep 5 14:48:46 vdns pdns[2766]: Guardian is launching an
instance
Sep 5 14:48:46 vdns pdns[2766]: Reading random entropy
from '/dev/urandom'
Sep 5 14:48:46 vdns pdns[2766]: [LdapBackend] This is
the ldap module version 2.9.22 (Aug 23 2009, 10:47:15)
reporting
Sep 5 14:48:46 vdns pdns[2766]: This is a guarded
instance of pdns
Sep 5 14:48:46 vdns pdns[2766]: UDP server bound to
xxx.xxx.xxx.xxx:53
Sep 5 14:48:46 vdns pdns[2766]: TCP server bound to
xxx.xxx.xxx.xxx:53
Sep 5 14:48:46 vdns pdns[2766]: PowerDNS 2.9.22 (C)
2001-2009 PowerDNS.COM BV (Aug 23 2009, 10:49:35, gcc 4.1.2
20080704 (Red Hat 4.1.2-44)) starting up
Sep 5 14:48:46 vdns pdns[2766]: PowerDNS comes with
ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it according to the terms of the GPL
version 2.
Sep 5 14:48:46 vdns pdns[2766]: Set effective group id
to 103
Sep 5 14:48:46 vdns pdns[2766]: Set effective user id to
101
Sep 5 14:48:46 vdns pdns[2766]: DNS Proxy launched,
local port 20388, remote xxx.xxx.xxx.xxx:53
Sep 5 14:48:46 vdns pdns[2766]: Creating backend
connection for TCP
Entering normal operation (messages with wrong time - pdns has
switched to UTC):
Sep 5
11:48:46 vdns pdns[2766]: [LdapBackend] LDAP servers =
localhost
Sep 5 11:48:46 vdns pdns[2766]: Launched webserver on
xxx.xxx.xxx.xxx:8081
Sep 5 11:48:46 vdns pdns[2766]: [LdapBackend] Ldap
connection succeeded
[Pdns-users] Successful, yet incomplete AXFR to BIND9 slave
In my pdns/ldap (tree) on CentOS 5.5, I am setting up a domain (say: 'example.com') with its single SOA record. This has several virtual subzones (a.example.com, b.example.com etc.) which include their own MX records but are not delegated: the same NS records (as defined in the example.com entry) are used for the whole domain (zone) and its subdomains (subzones). The LDAP server also includes 5 in-addr.arpa zones (which correspond to the 5 available LANs = Class-C subnets) for reverse mapping. Everything seems to be working fine when the pdns server is queried for any records, which obviously means that pdns sees everything correctly in ldap. (One problem however: queries for example.com and its subdomains/hosts indicate AUTHORITY: 0. I would expect it to indicate AUTHORITY: 1 in such queries. Any hint on this?) For testing (preparing a production environment), I have setup a BIND9 slave ( which uses pdns as master. Everything seems to run smoothly, messages in logs indicate successful zone transfers, no errors either in BIND or in pdns logs, BUT a large number of A records in some of the subdomains is not transferred at all (however, some of the A records are transferred). Interestingly, the PTR records in all in-addr.arpa zones seem to be transferred correctly. The slave is also CentOS 5.5 with bind-9.3.6-4.P1.el5_4.2. The BIND9 zone file for example.com (as produced by slaving), includes all subdomains, specifies their MX records, but it misses a large number of A records. I waited for several AXFRs, to check if subsequent zone transfers would correct things, but nothing changed. The transferred records are always the same. In the meantime, just in case, I have tried switching from the 2.9.22 rpm which I had found in a repository, to the more standard 2.9.21-4 rpm included in the 'extras' CentOS repositories, but the behavior is exactly the same. (I am using CentOS 5.5 with a 2.6.18-194.11.3.el5 kernel). I would come to the conclusion that AXFR is not being sent correctly by pdns, because, if a full set of records is being sent, why the slave is not registering the complete set of records? All rpms (and the servers) are x86_64. Any suggestions? How can I troubleshoot this in more detail? Thanks in advance, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Successful, yet incomplete AXFR to BIND9 slave
Indeed, I have confirmed that pdns does not send a complete set of records during AXFR, by executing: # dig example.com AXFR @dns.example.com where dns.example.com is the pdns/ldap server. The output is exactly the content of slave files. So, why aren't all zone records included in the AXFR set? I am waiting for your advice. I like pdns and I am trying to resolve issues so that it can replace (gradually) all BIND9 servers in our organization. Nick On 8/9/2010 11:26 μμ, Nikolaos Milas wrote: In my pdns/ldap (tree) on CentOS 5.5, I am setting up a domain (say: 'example.com') with its single SOA record. This has several virtual subzones (a.example.com, b.example.com etc.) which include their own MX records but are not delegated: the same NS records (as defined in the example.com entry) are used for the whole domain (zone) and its subdomains (subzones). The LDAP server also includes 5 in-addr.arpa zones (which correspond to the 5 available LANs = Class-C subnets) for reverse mapping. Everything seems to be working fine when the pdns server is queried for any records, which obviously means that pdns sees everything correctly in ldap. (One problem however: queries for example.com and its subdomains/hosts indicate AUTHORITY: 0. I would expect it to indicate AUTHORITY: 1 in such queries. Any hint on this?) For testing (preparing a production environment), I have setup a BIND9 slave ( which uses pdns as master. Everything seems to run smoothly, messages in logs indicate successful zone transfers, no errors either in BIND or in pdns logs, BUT *a large number of A records* in some of the subdomains *is not transferred at all* (however, some of the A records are transferred). Interestingly, the PTR records in all in-addr.arpa zones seem to be transferred correctly. The slave is also CentOS 5.5 with bind-9.3.6-4.P1.el5_4.2. The BIND9 zone file for example.com (as produced by slaving), includes all subdomains, specifies their MX records, but it misses a large number of A records. I waited for several AXFRs, to check if subsequent zone transfers would correct things, but nothing changed. The transferred records are always the same. In the meantime, just in case, I have tried switching from the 2.9.22 rpm which I had found in a repository, to the more standard 2.9.21-4 rpm included in the 'extras' CentOS repositories, but the behavior is exactly the same. (I am using CentOS 5.5 with a 2.6.18-194.11.3.el5 kernel). I would come to the conclusion that AXFR is not being sent correctly by pdns, because, if a full set of records is being sent, why the slave is not registering the complete set of records? All rpms (and the servers) are x86_64. Any suggestions? How can I troubleshoot this in more detail? Thanks in advance, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Successful, yet incomplete AXFR to BIND9 slave
On Thu, Sep 09, 2010 at 12:10:53AM +0300, Nikolaos Milas wrote: > Indeed, I have confirmed that pdns does not send a complete set of > records during AXFR, by executing: > ># dig example.com AXFR @dns.example.com > > where dns.example.com is the pdns/ldap server. The output is exactly > the content of slave files. > > So, why aren't all zone records included in the AXFR set? Usually this is because of a badly formatted record in the database, one that cannot be sent out over AXFR. Can you figure out where it stops exactly, and what would've been the "next" record? Bert > > I am waiting for your advice. > > I like pdns and I am trying to resolve issues so that it can replace > (gradually) all BIND9 servers in our organization. > > Nick > > On 8/9/2010 11:26 μμ, Nikolaos Milas wrote: > >In my pdns/ldap (tree) on CentOS 5.5, I am setting up a domain > >(say: 'example.com') with its single SOA record. This has several > >virtual subzones (a.example.com, b.example.com etc.) which include > >their own MX records but are not delegated: the same NS records > >(as defined in the example.com entry) are used for the whole > >domain (zone) and its subdomains (subzones). > > > >The LDAP server also includes 5 in-addr.arpa zones (which > >correspond to the 5 available LANs = Class-C subnets) for reverse > >mapping. > > > >Everything seems to be working fine when the pdns server is > >queried for any records, which obviously means that pdns sees > >everything correctly in ldap. (One problem however: queries for > >example.com and its subdomains/hosts indicate AUTHORITY: 0. I > >would expect it to indicate AUTHORITY: 1 in such queries. Any hint > >on this?) > > > >For testing (preparing a production environment), I have setup a > >BIND9 slave ( which uses pdns as master. Everything seems to run > >smoothly, messages in logs indicate successful zone transfers, no > >errors either in BIND or in pdns logs, BUT *a large number of A > >records* in some of the subdomains *is not transferred at all* > >(however, some of the A records are transferred). Interestingly, > >the PTR records in all in-addr.arpa zones seem to be transferred > >correctly. The slave is also CentOS 5.5 with > >bind-9.3.6-4.P1.el5_4.2. > > > >The BIND9 zone file for example.com (as produced by slaving), > >includes all subdomains, specifies their MX records, but it misses > >a large number of A records. I waited for several AXFRs, to check > >if subsequent zone transfers would correct things, but nothing > >changed. The transferred records are always the same. > > > >In the meantime, just in case, I have tried switching from the > >2.9.22 rpm which I had found in a repository, to the more standard > >2.9.21-4 rpm included in the 'extras' CentOS repositories, but the > >behavior is exactly the same. (I am using CentOS 5.5 with a > >2.6.18-194.11.3.el5 kernel). > > > >I would come to the conclusion that AXFR is not being sent > >correctly by pdns, because, if a full set of records is being > >sent, why the slave is not registering the complete set of > >records? > > > >All rpms (and the servers) are x86_64. > > > >Any suggestions? How can I troubleshoot this in more detail? > > > >Thanks in advance, > >Nick > > > > > ___ > 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] Successful, yet incomplete AXFR to BIND9 slave
Yes, I can see exactly where it stopped, but I can't find a reason why it did so. It seems to me as a typical host A record like all the others - it responds to dig queries as well. I exported it and it looks like that (I left only the hostname as is, i.e. bpsil1): dn: dc=bpsil1,dc=xxx,dc=example,dc=com,ou=dns,dc=example,dc=com objectClass: dNSDomain2 objectClass: domainRelatedObject dc: bpsil1 associatedDomain: bpsil1.xxx.example.com aRecord: 10.10.10.10 After all, all records where automatically converted from BIND8 zone files using zone2ldap. The AXFR stops at a particular record, then includes the SOA record and ends: # dig example.com AXFR @dns.example.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> example.com AXFR @dns.example.com ;; global options: printcmd example.com. 3600 IN SOA dns.example.com. sysadmin.example.com. 2010090804 3600 180 604800 10800 ... example.com. 3600 IN SOA dns.example.com. sysadmin.example.com. 2010090804 3600 180 604800 10800 ;; Query time: 192 msec ;; SERVER: 195.251.204.236#53(195.251.204.236) ;; WHEN: Thu Sep 9 00:01:50 2010 ;; XFR size: 510 records (messages 8) Any ideas? Nick. On 9/9/2010 12:19 πμ, bert hubert wrote: Usually this is because of a badly formatted record in the database, one that cannot be sent out over AXFR. Can you figure out where it stops exactly, and what would've been the "next" record? ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] tcp listener issue - hopefully fixed
Bert, I can’t seem to get this latest version to run right. I build my RPM. I launch it with the following: /usr/sbin/pdns_recursor --local-address=172.26.68.42,127.0.0.1 --allow-from= --max-cache-entries=300 --log-common-errors=no --threads=4 --socket-dir=/var/run/recursor1 --daemon --dont-query= pdns_recursor[32283]: Operating in 64 bits mode pdns_recursor[32283]: Reading random entropy from '/dev/urandom' pdns_recursor[32283]: WARNING: Allowing queries from all IP addresses - this can be a security risk! pdns_recursor[32283]: Inserting rfc 1918 private space zones pdns_recursor[32283]: Listening for UDP queries on 172.26.68.42:53 pdns_recursor[32283]: Listening for UDP queries on 127.0.0.1:53 pdns_recursor[32283]: Enabled TCP data-ready filter for (slight) DoS protection pdns_recursor[32283]: Listening for TCP queries on 172.26.68.42:53 pdns_recursor[32283]: Listening for TCP queries on 127.0.0.1:53 pdns_recursor[32283]: Calling daemonize, going to background pdns_recursor[32284]: Launching 4 threads pdns_recursor[32284]: Done priming cache with root hints kernel: pdns_recursor[32288] general protection rip:4ea75c rsp:42802840 error:0 pdns_recursor[32284]: Done priming cache with root hints pdns_recursor[32298]: PowerDNS recursor 3.3-pre (C) 2001-2010 PowerDNS.COM BV (Sep 8 2010, 22:53:00, gcc 4.1.2 20080704 (Red Hat pdns_recursor[32298]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it ac the GPL version 2. pdns_recursor[32298]: Operating in 64 bits mode pdns_recursor[32298]: Reading random entropy from '/dev/urandom' pdns_recursor[32298]: WARNING: Allowing queries from all IP addresses - this can be a security risk! pdns_recursor[32298]: Inserting rfc 1918 private space zones pdns_recursor[32298]: Listening for UDP queries on 172.26.68.42:53 pdns_recursor[32298]: Listening for UDP queries on 127.0.0.1:53 pdns_recursor[32298]: Enabled TCP data-ready filter for (slight) DoS protection pdns_recursor[32298]: Listening for TCP queries on 172.26.68.42:53 pdns_recursor[32298]: Listening for TCP queries on 127.0.0.1:53 pdns_recursor[32298]: Calling daemonize, going to background pdns_recursor[32299]: Launching 4 threads pdns_recursor[32299]: Done priming cache with root hints kernel: pdns_recursor[32300] general protection rip:4ea75c rsp:409ff840 error:0 pdns_recursor[32307]: PowerDNS recursor 3.3-pre (C) 2001-2010 PowerDNS.COM BV (Sep 8 2010, 22:53:00, gcc 4.1.2 20080704 (Red Hat pdns_recursor[32307]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it ac the GPL version 2. pdns_recursor[32307]: Operating in 64 bits mode pdns_recursor[32307]: Reading random entropy from '/dev/urandom' pdns_recursor[32307]: WARNING: Allowing queries from all IP addresses - this can be a security risk! pdns_recursor[32307]: Inserting rfc 1918 private space zones pdns_recursor[32307]: Listening for UDP queries on 172.26.68.42:53 pdns_recursor[32307]: Listening for UDP queries on 127.0.0.1:53 pdns_recursor[32307]: Enabled TCP data-ready filter for (slight) DoS protection pdns_recursor[32307]: Listening for TCP queries on 172.26.68.42:53 pdns_recursor[32307]: Listening for TCP queries on 127.0.0.1:53 pdns_recursor[32307]: Calling daemonize, going to background pdns_recursor[32308]: Launching 4 threads pdns_recursor[32308]: Done priming cache with root hints pdns_recursor[32308]: Enabled 'epoll' multiplexer kernel: pdns_recursor[32309]: segfault at 00723a41 rip 00723a41 rsp 409ffb18 error 15 Thanks, Brad From: pdns-users-boun...@mailman.powerdns.com [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf Of bert.hub...@netherlabs.nl Sent: Tuesday, September 07, 2010 5:45 AM To: Mike Cc: Brad Dameron; pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] tcp listener issue - hopefully fixed Simon, Brief reply, am on the road. 3.3 will be released the moment you, brad or laurent confirm the issue is truly gone. What I can do is make packages that will be binary identical to the real 3.3 once you 'bless' them as having solved your issue. This would save you an upgrade. Would this work for you? Bert. Sent from my phone. - Reply message - From: "Simon Bedford" Date: Mon, Sep 6, 2010 14:16 Subject: tcp listener issue - hopefully fixed To: "bert hubert" Cc: "Brad Dameron" , "pdns-users@mailman.powerdns.com" Hi Bert, Apologies for the delay in replying I have been assigned to some different work for the moment, I don't think I will get a chance to compile and test this version and was going to wait for the full 3.3 version release. Do you know how far off this is at all? Our production systems are still displaying the tcp listener issue but I have a watchdog script restarting it before it maxs out the number of clients so no customer impact, I would be loathed to look at upgrading until we have the full 3.3 deb package if possible. Sim
