Re: [Pdns-users] Acheiving 40,000 QPS
On Mon, May 17, 2010 at 03:23:21PM +0800, Lee Standen wrote: Thanks for that information, Bert. I had seen the documentation before... perhaps I should provide some more information. Here are the options I'm using at the moment (I've tried several values): --- disable-packetcache=no local-address=0.0.0.0 It might be wise to set this to the actual address you are using, but this will not impact performance. local-port=53 max-cache-entries=400 max-packetcache-entries=400 single-socket=off I'd remove this one. threads=8 4 might be better given your hardware. At 8, some scheduling infelicities might pop up. Percentage completed: 99.94% Percentage lost:0.06% Queries per second: 12244.776377 qps This is decidedly disappointing. Can you retry with threads=2 and threads=4? Can you try a 'second run' with the same data? This can rule out certain scnarios. I just double-checked the hardware and I've actually got 4 cores available, not 8 as I initially thought: Is this real hardware or virtualized? Lastly, I'm using the amd64 deb from the powerdns web site on Ubuntu 10.04 rather than building a new binary. It was assumed that those binaries would be optimized, but if they're not, I'm happy to try building it myself. They are pretty ok - the numbers I posted earlier are also from those debs. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [recursor] Segmentation fault at startup
On Wed, May 26, 2010 at 09:29:57AM +0200, Stephane Bortzmeyer wrote: % pdns_recursor % uname -a NetBSD golgoth 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Oct 1 15:46:16 CEST 2009 steph...@golgoth:/usr/obj/sys/arch/i386/compile/GENERIC i386 Hi Stephane, Thanks for checking out the PowerDNS Recursor! I'm afraid you have discovered that not a lot of testing is done on NetBSD, although I personally like this BSD the best. Sadly we do not currently have access to a NetBSD installation to test against. Very little difference when compiling with -O0 -g: (gdb) run Starting program: /usr/sbin/pdns_recursor (no debugging symbols found) In fact, this is so little difference that I wonder if it really was compiled with -g, can you double check? OPTFLAGS=-g is probably the best way to go. May 26 09:29:04 Operating in 32 bits mode May 26 09:29:04 Reading random entropy from '/dev/urandom' Can you strace during startup? Or the local equivalent? Thanks! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [recursor] Segmentation fault at startup
On Wed, May 26, 2010 at 10:18:43AM +0200, Stephane Bortzmeyer wrote: It was properly compiled but the Makefile contains a 'strip $(DESTDIR)/$(SBINDIR)/pdns_recursor' :-( Debugging the non-installed For installed binaries, this is common. OK, the ACL parsing is not robust enough. What is strange is that, even without a configuration file (and therefore without ACL), it crashes at the same place): This probably indicates that your version of NetBSD, compiler linker have problems with Thread Local Storage, which is used by variables that start with 't_' in PowerDNS. Program received signal SIGSEGV, Segmentation fault. parseACLs () at pdns_recursor.cc:1508 1508 NetmaskGroup* oldAllowFrom = t_allowFrom, *allowFrom=new NetmaskGroup; Could you split line 1508 as follows: NetmaskGroup* oldAllowFrom = t_allowFrom; NetmaskGroup* allowFrom = new NetmaskGroup; ? If it still crashes on 1508 (and not on 1509), this is definitely a __thread problem. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [recursor] Segmentation fault at startup
On Wed, May 26, 2010 at 11:01:38AM +0200, Stephane Bortzmeyer wrote:
[BTW, it would be better to do so on a ticketing system but I cannot
find a way to create a new ticket in the PowerDNS Trac.]
There is some anti-spam trickery:
TO FILE BUGS, OR CHANGE THE WIKI, CLICK 'LOGIN' ABOVE, USERNAME anon
PASSWORD No Spam without quotes or the space in between '
So the password is NoSpam
Could you split line 1508 as follows:
NetmaskGroup* oldAllowFrom = t_allowFrom;
NetmaskGroup* allowFrom = new NetmaskGroup;
(gdb) run
Starting program:
/home/stephane/Programmation/DNS/pdns-recursor-3.2/pdns_recursor
May 26 10:59:56 PowerDNS recursor 3.2 (C) 2001-2010 PowerDNS.COM BV (May 26
2010, 10:58:27, gcc 4.1.3 20080704 prerelease (NetBSD nb2 20081120)) starting
up
May 26 10:59:56 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.
May 26 10:59:56 Operating in 32 bits mode
May 26 10:59:56 Reading random entropy from '/dev/urandom'
Program received signal SIGSEGV, Segmentation fault.
parseACLs () at pdns_recursor.cc:1508
1508 NetmaskGroup* oldAllowFrom = t_allowFrom;
We could probably boil this issue down to a tiny testcase that would crash
on NetBSD. This could then lead to a bugreport to NetBSD.
Can you try to compile this (g++ t.cc -o t):
#include stdio.h
class Bogo
{
public:
explicit Bogo(char a)
{
d_a = a;
}
char d_a;
};
__thread Bogo* t_a;
int main()
{
t_a = new Bogo('a');
Bogo* b = t_a;
printf(%c\n, b-d_a);
}
It is unlikely that PowerDNS will remove the __thread variables since they
work very well on all other relevant platforms ;-(
Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [recursor] configure could be more user-friendly
Derek, Dave, Stephane, (a rare top-post!), your points are well understood, and will be addressed. The immediate reason that the pdns-recursor did not have full auto*, and is unlikely to get it, was the deep dissatisfaction we felt with this suite of programs. It turned out to be difficult to have the kind of fine-grained control over building the recursor in static and semi-static modes using auto*. We still have the deep dissatisfaction with auto*, which is exhibited for example by the 'boost' macros which you reference, that are now part of the powerdns trunk, not in fact detecting boost on many of our platforms.. David, one of the best ways to motivate us is by opening a ticket on http://wiki.powerdns.com/ - could you do that? Thanks! On Wed, May 26, 2010 at 09:48:30AM -0700, David Hawthorne wrote: Just to weigh in on this, I'm compiling it on mac right now to see if I can find a missing header I already fixed in a local branch. I had to twiddle CPPFLAGS and LDFLAGS on the configure line to get it to know where macports installed boost: $ CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure There are established macros for requiring boost, and for specifying the location and specific versions for autoconf: http://www.nongnu.org/autoconf-archive/ax_boost_base.html the m4 file goes into the m4 subdirectory and configure.ac gets: AX_BOOST_BASE([1.34.1]) On May 26, 2010, at 9:16 AM, Derrik Pates wrote: On 05/26/2010 12:45 AM, Stephane Bortzmeyer wrote: ./configure is not very helpful when it cannot find a library. For instance, if Boost is not found (because it is in /usr/pkg): % ./configure Testing dependencies and compiler. Using gmake to build [trimming compiler output] Instead of something like, more common among free Unix programs: Cannot find the Boost library http://boost.org/. If it is installed, use --with-boost I cannot even use --help to find documentation, it yields the same error message. PowerDNS recursor, version 3.2 I actually had similar troubles trying to build the v3.2 recursor, but with Boost installed. However, I made the mistake of using the Boost packages included with CentOS; it seems that the 1.33.x version of Boost included in CentOS doesn't have some features that are needed for the new recursor code, but nowhere did I see this new dependency noted, nor did the configure script bitch me out about your boost is too old, please upgrade. I had to grab sources from Fedora 10 (since Fedora 11 and up's RPM format change, backbuilding SRPMs is much more difficult, grr) for Boost 1.39.0 and use that, but something should really be done to make people aware of this, and not have to go scour Google to figure out why the recursor won't build. -- Derrik Pates de...@devrandom.net ___ 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 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [recursor] configure could be more user-friendly
On Wed, May 26, 2010 at 10:15:34PM +0200, Stephane Bortzmeyer wrote: On Wed, May 26, 2010 at 07:57:13PM +0200, bert hubert bert.hub...@netherlabs.nl wrote a message of 85 lines which said: The immediate reason that the pdns-recursor did not have full auto*, and is unlikely to get it, was the deep dissatisfaction we felt with this suite of programs. Do note that I was not asking specifically for a autotools system. I was asking for a more user-friendly configure script, whether built with autotools or in another way. I agree fully - this is the historical explanation, not a reason why we should not improve! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
On Thu, May 20, 2010 at 11:12:29AM +0100, Simon Bedford wrote: This has happened a further twice in the last week, output sent off list, please let me know if you need any further information. Simon, Could you apply this patch: http://wiki.powerdns.com/trac/changeset/1623 And periodically run 'rec_control get tcp-clients' ? If you see that number increase very slowly, this is a powerful hint where we need to look for the problem. If you do not see it increase very slowly, it means we have to look somewhere else.. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] multithreaded epoll_wait in PDNS
On Sun, Jun 06, 2010 at 06:40:18PM +0200, Christof Meerwald wrote: On Tue, 1 Jun 2010 16:12:45 -0500, Naked Short-Selling wrote: I read your post regarding multithreaded epoll_wait behavior on lkml a couple of months ago: http://lkml.org/lkml/2010/3/3/441 My understanding is that using EPOLLET would be the right approach - and particularly for UDP sockets it should be quite easy to implement it that way (it might be a bit more tricky to get the locking right for TCP sockets). Christof, Naked, This issue has been studied and turns out not to be much of a problem under operational load - the number of spurious wakeups is actually minimal. We are probably saved by the fact that under high load, a new packet is probably available anyhow in most cases - perhaps not the one we were originally awoken for. One day, we'll address the epoll_wait optimization, but there are more pressing things on the horizon. Like DNSSEC. Thanks for your attention though! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Slave zone just won't refresh....
Garry, 2.6.1 WKS WKS records are deprecated in [RFC 1123]. They serve no known useful function, except internally among LISP machines Normally we'd whip up an implementation just to have the issue go away, but it is a pretty weird record type too, containing a bitmap of protocols. Unknown record type support might save us, but it is not quite there yet it appears. I struggle to find some WKS zone file examples btw, do you have any? Bert On Wed, Jun 09, 2010 at 02:31:22PM -0700, Gary Shaver wrote: Hi Ken, I just found your ticket from abut 4 years ago... Seems strange that it's still a bug. We just ran a few tests and yep.. you were completely correct, WKS records just piss off pdns something fierce. I'll consolidate the test case down to something reasonable and submit a bug report. Gary On 6/9/10 12:54 PM, Kenneth Marshall wrote: Ah, I hit the same problem. WKS records are not supported by PDNS. On top of that, they are not really useful and have not been for quite a while. Try nuking them and your zone should transfer fine. Regards, Ken On Wed, Jun 09, 2010 at 11:43:27AM -0700, Gary Shaver wrote: On 6/9/10 5:49 AM, Kenneth Marshall wrote: another issue that I've run into was another slave zone. This had pdns cycling every 2-3 seconds Jun 7 00:48:44 ns1 pdns[10216]: Initiating transfer of 'axxxa.us' from remote '216.117.186.93' Jun 7 00:48:45 ns1 pdns[10216]: AXFR started for 'axxxa.us', transaction started Jun 7 00:48:45 ns1 pdns[10216]: Communicator thread died because of error: Failed to execute mysql_query, perhaps connection died? Err=1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''\\# 1007 ad10090a060240002080 004000' at line 1 Jun 7 00:48:46 ns1 pdns[16017]: Our pdns instance exited with code 0 Jun 7 00:48:46 ns1 pdns[16017]: Respawning Jun 7 00:48:47 ns1 pdns[10258]: Guardian is launching an instance Simply removing the zone puts everything back in a happy state, so It's not a timeout issue. Are there any debugging options that can be turned on for the mysql backend? I didn't find any referenced in the documentation and increasing the loglevel doesn't give me any additional information. I've pulled down the zone and besides the laundry list of different record types, it looks fine. I can sanitize it an post it if that would help. The pdns version is the static .deb package from the main download page. Any help is appreciated. Thanks, Gary Hi Gary, Try enabling the MySQL query logging to see what command is being received by the backend. You can also bump the logging level on the PDNS system to see if it gives you more information. Have you changed any of the default queries? What is your PDNS configuration, including the backend chosen? At 27 entries, you could post the entire zone but if the problem is a weird character, sanitizing it will make the information useless. I would try bumping the debugging levels first. I cannot help much on the MySQL side since we use PostgreSQL as the backend database. I already tried both of those. Increasing the loglevel didn't yield any additional information and query log didn't include the query, I suspect due to it's failure. I've attached the zone. I've changed the hostnames and ip's. The remainder of the zone is untouched. Gary Regards, Ken -- Gary Shaver | Voice 510.580.4100, Fax 510.580.4151 Hurricane Electric | AS6939 Network Operations | http://www.he.net ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users -- Gary Shaver | Voice 510.580.4100, Fax 510.580.4151 Hurricane Electric | AS6939 Network Operations | http://www.he.net ; DiG 9.4.2-P2.1 a.us @10.117.186.93 AXFR ;; global options: printcmd a.us. 7200IN SOA DD1.a.us. AtlDNS.Fxl.Com. 2010060736 1200 600 2419200 10800 a.us. 7200IN NS DD1.a.us. a.us. 7200IN NS NS1.SxP.US. a.us. 604800 IN 2fff:470:e056:: a.us. 604800 IN 2fff:ad10:90a:: a.us. 604800 IN A 192.168.9.10 a.us. 604800 IN WKS 192.168.9.10 6 22 25 42 80 113 443 6667 8008 a.us. 604800 IN WKS 192.168.9.10 17 22 25 42 80 443 8008 a.us. 604800 IN MX 10 Mail.a.us. a.us. 604800 IN MX 30 Mail.Rxxxt.US. a.us. 604800 IN MX 30 Mail2.Rxxxt.US. a.us.
Re: [Pdns-users] Can't start powerdns web on port 80 when running pdns not as root
On Thu, Jun 10, 2010 at 08:32:00AM +0200, Thomas Mieslinger wrote: when I set the Webseverport to 80 and run powerdns as user a non root user then the powerdns fails to start with the message permisson denied. Powerdns seems to drop the root priviledges too early. Is someone willing to fix this? http://wiki.powerdns.com/trac/changeset/1629 To apply, see the instructions on http://wiki.powerdns.com/trac/wiki/HACKING Good luck! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
On Mon, Jun 07, 2010 at 04:08:17PM +0100, Simon Bedford wrote: Simon, Could you apply this patch: http://wiki.powerdns.com/trac/changeset/1623 And periodically run 'rec_control get tcp-clients' ? Hi Bert, I have just returned from annual leave and began to look into this earlier but when I download the latest source from your website and put the files from the changeset into place (following the same procedure as worked previously) I get the following error when trying to create the debian package:- Simon, There is now a 3.3 prerelease that contains all the stuff you'd need for further trouble shooting. Please find it on http://svn.powerdns.com/snapshots/pdns-recursor-3.3-pre.tar.bz2 It contains some other exciting stuff too, and it appears to be stable for production use. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
On Tue, Jun 15, 2010 at 02:23:04PM +0100, Simon Bedford wrote: It contains some other exciting stuff too, and it appears to be stable for production use. I have now built a static package and installed to 2 of the 8 servers after testing in isolation, they appear to be running fine and I can use the rec_control get tcp-clients now to see the number reported. We will monitor the new package for a week before rolling out to the rest of the servers and let you know how that goes. Ok - please check the 'get tcp-clients' every once in a while. I personally expect that this version will still see tcp support die after a while under your conditions. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] IPv4/IPv6 nameserver preference by recursor?
On Tue, Jun 15, 2010 at 05:10:11PM -0600, Darren Gamble wrote: We just wanted to get some information on how the recursor behaves when presented with a NS record set containing both IPv6 and IPv4 addresses, and/or if a NS record name has both A and records. If there a preference by the recursor to prefer one protocol over the other? It depends - by default, the PowerDNS Recursor is setup for maximum performance and minimum worries. In this case, that means that you need to manually enable the use of IPv6 for resolution. From the manual: query-local-address6 Send out local IPv6 queries from this address or addresses Disabled by default, which also disables outgoing IPv6 support. Since version 3.2, multiple addresses can be specified, separated by a comma. Since 3.1 or so, when query-local-address6 contains an address (:: works fine), 'ANY' queries are used to get both the A and addresses for nameservers in one go. IPv4 and IPv6 are treated absolutely equally, which means that the IP4/6 address that answers fastest gets most of the queries. In many cases this means that IPv4 will win. The Recursor does not actively seek out IPv6 addresses for a host if it alread knows an IPv4 address for it and vice versa. How does the recursor handle a nameserver name with both A and record types? Is it capable of using both if one is unreachable? Is there a preference? So, yes it can and will use both, and it will use the fastest address. The PowerDNS Recursor can even resolve quite some domains when operating with *only* IPv6. From the log of a recursor with only IPv6: [1] www.sidn.nl.: Resolved '.' NS c.root-servers.net. to: 192.33.4.12 [1] www.sidn.nl.: Trying IP 192.33.4.12:53, asking 'www.sidn.nl.|A' [1] www.sidn.nl.: error resolving, possible error: Operation not permitted [1] www.sidn.nl.: Resolved '.' NS f.root-servers.net. to: 2001:500:2f::f, 192.5.5.241 [1] www.sidn.nl.: Trying IP [2001:500:2f::f]:53, asking 'www.sidn.nl.|A' [1] www.sidn.nl.: Got 19 answers from f.root-servers.net. (2001:500:2f::f), rcode=0, in 149ms [1] www.sidn.nl.: Resolved 'nl.' NS ns3.nic.nl. to: 2001:610:0:800d::2, 194.171.17.2 [1] www.sidn.nl.: Trying IP [2001:610:0:800d::2]:53, asking 'www.sidn.nl.|A' [1] www.sidn.nl.: Got 9 answers from ns3.nic.nl. (2001:610:0:800d::2), rcode=0, in 6ms [1] www.sidn.nl.: Resolved 'sidn.nl.' NS open.nlnetlabs.nl. to: 213.154.224.1, 2001:7b8:206:1::53 [1] www.sidn.nl.: Trying IP 213.154.224.1:53, asking 'www.sidn.nl.|A' [1] www.sidn.nl.: error resolving, possible error: Operation not permitted [1] www.sidn.nl.: Trying IP [2001:7b8:206:1::53]:53, asking 'www.sidn.nl.|A' [1] www.sidn.nl.: Got 11 answers from open.nlnetlabs.nl. (2001:7b8:206:1::53), rcode=0, in 5ms [1] www.sidn.nl.: accept answer 'www.sidn.nl.|A|213.136.31.216' from 'sidn.nl.' nameservers? YES! Interestingly, when we added the IPv6 %link selection code to the development tree (by your suggestion), the IPv6 outgoing support got broken in the progress! Your message led me to verify the 'IPv6 only' claim, which uncovered this. Fix in http://wiki.powerdns.com/trac/changeset/1638 - so please keep asking the questions ;-) This bug was never in any released version. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PDNS Recursor and reverse lookup
On Wed, Jun 16, 2010 at 10:34:30AM +0200, Uroš Gruber wrote: Hi, here is result from one of IP Try adding -x to the command line. From the 'dig' manpage: 'The default query type is A, unless the -x option is supplied to indicate a reverse lookup.' [r...@host1 ~]#dig @91.185.194.202 118.167.130.182 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 7121 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 This answer is correct. One thing I didn't quite understand is that bind have root.hint file but powerdns does not. Could this be a problem? PowerDNS Recursor has a built-in root.hint file (and can also load one from disk), so this is not the problem. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
On Wed, Jun 16, 2010 at 11:10:29AM +0100, Simon Bedford wrote: I have been running the 'get tcp-clients' every 5 mins in cron on both servers, one is very low 10 and fluctuates, the other is just growing and growing and is currently at 55, hope this info is of value for debug. Is there any difference between these two servers in terms of: * Operating system * Number of processors * Network configuration (load balancer?) * Use (mail servers versus residential internet connections?) * Anything else that comes to mind Thanks! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
To everybody seeing this issue (all two of you :)), can you grep the logfile on: startDoResolve problem: DNS parser error: STL error: Any other exception in a resolver context Without the quotes. If you see any of these lines, it might explain the problem. Thanks! On Thu, Jun 17, 2010 at 04:16:50PM +0200, bert hubert wrote: On Thu, Jun 17, 2010 at 03:14:39PM +0100, Simon Bedford wrote: Bert, its now climbing and not seeming to close any clients on both servers now, although one is much worse than the other, one is at 11 and the other is at 108 tcp-clients at the moment. Could you run: # tcpdump -s 0 -w tcpdns port 53 and tcp For a while (few hours) And then send me the output of: # tcpdump -n -r tcpdns You can obfuscate IP addresses, as long as I can see patterns that would be great. Thanks! Simon Simon Bedford wrote: Please see answers below :- bert hubert wrote: On Wed, Jun 16, 2010 at 11:10:29AM +0100, Simon Bedford wrote: I have been running the 'get tcp-clients' every 5 mins in cron on both servers, one is very low 10 and fluctuates, the other is just growing and growing and is currently at 55, hope this info is of value for debug. Is there any difference between these two servers in terms of: * Operating system No, both Debian Etch * Number of processors No, slightly faster processors in the one with the most clients * Network configuration (load balancer?) Different data centre but same network architecture, both loadbalanced. * Use (mail servers versus residential internet connections?) No, config is identical and use is only as a cachingDNS and NTP server * Anything else that comes to mind Nothing appears to be different, they are from a build that should be identical across the platform, although we will be looking to upgrade to Lenny in the near future. Thanks! Thanks Simon ___ 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 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNSSEC, PowerDNS @ ICANN38
Hi everybody, I'll be part of the 'DNSSEC Workgroup' over at ICANN in Brussels this coming week. There, I will present 'PowerDNSSEC' plus our vision of DNSSEC on the resolver side of large ISPs. More details can be found on http://brussels38.icann.org/node/12491 and you can even join in virtually, http://brussels38.icann.org/chat/silverhall Exact agenda is on http://brussels38.icann.org/meetings/brussels2010/agenda-dnssec-workshop-23jun10-en.pdf I'll be around on Tuesday evening and Wednesday. As always, I enjoy meeting PowerDNS users enthousiasts, so I hope to meet you there! Drop me a note if you want to coordinate. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
Simon, the solution to your issue is almost certainly in http://wiki.powerdns.com/trac/changeset/1640 Even though you do not see the log messages, I'm pretty sure this is it. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
Simon, Can you grep your logfiles for 'epoll' or 'unlisted' or 'exception'? Bert On Wed, Jun 23, 2010 at 11:00:12AM +0100, Simon Bedford wrote: Thanks Bert, Appreciate you looking into this, would be nice to nail it once and for all. Simon From: bert.hub...@netherlabs.nl [bert.hub...@netherlabs.nl] Sent: 22 June 2010 15:50 To: Simon Bedford Cc: pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] Possible tcp listener issue So much for my beliefs then :) Will take another good look at how else this could happen. The patch we made at least solves A bug just not your bug. Sent from my phone. - Reply message - From: Simon Bedford sbedf...@plus.net Date: Tue, Jun 22, 2010 09:44 Subject: [Pdns-users] Possible tcp listener issue To: bert hubert bert.hub...@netherlabs.nl Cc: pdns-users@mailman.powerdns.com pdns-users@mailman.powerdns.com bert hubert wrote: Simon, the solution to your issue is almost certainly in http://wiki.powerdns.com/trac/changeset/1640 Even though you do not see the log messages, I'm pretty sure this is it. Bert Morning, I created and installed the package yesterday (with the following option STATIC=full) and the tcp clients still appears to be growing, less than 24 hours later and the count is at 54 already although if I monitor it more frequently I do see the number fluctuate a little put the pattern is still growth as though not cleaning up all client connections The following stats are entered in every 5 mins :- 51 51 51 51 51 51 51 51 51 51 51 51 51 52 52 52 52 52 52 53 53 53 53 53 53 54 54 54 54 54 Simon ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible tcp listener issue
On Wed, Jun 23, 2010 at 01:21:03PM +0100, Josh Berry wrote: Simon is away this afternoon, but to keep things moving... On the server that he is monitoring on there is only one thing in the logs for those, and its when pDNS is starting up (this is the only restart in the logs): /var/log/syslog.1.gz:Jun 21 11:22:18 pcl-cachedns01 pdns_recursor[31939]: Enabled 'epoll' multiplexer Ok - anything along the lines of EOF writing TCP answer to Error writing TCP answer to Oops, partial answer sent to ? Bert Ta, Josh From: pdns-users-boun...@mailman.powerdns.com [pdns-users-boun...@mailman.powerdns.com] On Behalf Of bert hubert [bert.hub...@netherlabs.nl] Sent: 23 June 2010 12:47 To: Simon Bedford Cc: pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] Possible tcp listener issue Simon, Can you grep your logfiles for 'epoll' or 'unlisted' or 'exception'? Bert On Wed, Jun 23, 2010 at 11:00:12AM +0100, Simon Bedford wrote: Thanks Bert, Appreciate you looking into this, would be nice to nail it once and for all. Simon From: bert.hub...@netherlabs.nl [bert.hub...@netherlabs.nl] Sent: 22 June 2010 15:50 To: Simon Bedford Cc: pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] Possible tcp listener issue So much for my beliefs then :) Will take another good look at how else this could happen. The patch we made at least solves A bug just not your bug. Sent from my phone. - Reply message - From: Simon Bedford sbedf...@plus.net Date: Tue, Jun 22, 2010 09:44 Subject: [Pdns-users] Possible tcp listener issue To: bert hubert bert.hub...@netherlabs.nl Cc: pdns-users@mailman.powerdns.com pdns-users@mailman.powerdns.com bert hubert wrote: Simon, the solution to your issue is almost certainly in http://wiki.powerdns.com/trac/changeset/1640 Even though you do not see the log messages, I'm pretty sure this is it. Bert Morning, I created and installed the package yesterday (with the following option STATIC=full) and the tcp clients still appears to be growing, less than 24 hours later and the count is at 54 already although if I monitor it more frequently I do see the number fluctuate a little put the pattern is still growth as though not cleaning up all client connections The following stats are entered in every 5 mins :- 51 51 51 51 51 51 51 51 51 51 51 51 51 52 52 52 52 52 52 53 53 53 53 53 53 54 54 54 54 54 Simon ___ 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] strange resolution problem
On Tue, Jun 22, 2010 at 02:31:44PM +0200, Mario Caruso wrote: Here is an except from the daemon log files, can someone explain me what is happening ? Hi Mario, It is good to hear that you switched to PowerDNS. I hope it will work well for you. Regarding the case below: Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: Trying IP 213.92.11.34:53, asking 'www.cafsials.it.|A' Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: Got 2 answers from ns2.register.it. (213.92.11.34), rcode=3, in 41ms Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: accept answer 'www.cafsials.it.|CNAME|web.dataufficio.com.' from 'cafsials.it.' nameservers? YES! Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: accept answer 'dataufficio.com.|SOA|ns1.register.it. hostmaster.register.it. 2004061701 10800 3600 604800 86400' from 'cafsials.it.' nameservers? NO! Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: determining status after receiving this packet Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: status=NXDOMAIN, we are done The problem here is that 'ns2.register.it' returns an authoritative NXDOMAIN RCode. In this case, the NXDOMAIN is a lie, since you could actually decide to 'trust' that data. However, it is generally not a good idea to make a nameserver program around a bug of someone else. In this case, it is nice that it works in BIND. If you measure, you find that BIND and PowerDNS resolve about the same amount of domains correctly. There will be some domains that work well in PowerDNS and not in BIND and the other way around. So please ask 'register.it' to solve their nameserver. Kind regards, Bert Hubert PS: in powerdns recursor 3.3, this domain will start working anyhow after the first query. So the practical problem is limited there. Jun 22 14:16:43 elan pdns_recursor[26638]: [2048] www.cafsials.it.: failed (res=3) Jun 22 14:16:43 elan pdns_recursor[26638]: 0 [2048] answer to question 'www.cafsials.it.|A': 1 answers, 0 additional, took 2 packets, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3 ___ 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] PDNS Timing Out
On Tue, Jul 27, 2010 at 04:49:19PM -0700, Brandon Lee wrote: Therefore, we turned on logging by setting the log level to 6 in the pdns.conf file and only on the master server we saw hundreds of queries like below being logged whereas on the slave server this was not happening. Not sure if this is related, but the master DNS server is in high load. Can you run tcpdump a bit to determine what kind of queries you are getting? One thing we have done was changed all our domains SOA record TTL from 3600 to 86400 to see if that would bring the load down and no cigar. Also, is it recommended to run PowerDNS in daemon mode? Daemon or not does not matter from a performance perspective. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Possible bug observed in PowerDNS Recursor 3.2.1
Briefly diving into this: On Thu, Aug 05, 2010 at 10:12:54AM -0400, Dave Sparro wrote: I see this all the time on BIND resolvers. The keys to the situation are: * Domain's old NS records have a relatively long TTL (from old auth. servers) * Domain owner changes auth. servers with registrar * Domain owner does NOT update data on old auth. servers. (they're now serving stale data, but authoritatively) Since the domain owner is your ISP customer, you get get queries for the domain relatively often, so your recursive servers rely on the cached NS records for the domain (the ones that point to the auth. server serving stale data). I think that BIND resets the TTL when the recursive server sees NS records in the authority section of a response. Maybe PowerDNS is doing this as well? PowerDNS 3.2 has a bug in this respect where it keeps believing the old data. The 3.3 snapshot, in full production in some places, has this issue resolved. I'll trawl through the entire thread to see if this is indeed the issue we are talking about. Bert I generally advise the domian owner to have the domain removed from the old auth. server. -- Dave ___ 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
[Pdns-users] tcp listener issue - hopefully fixed
Hi everybody, After an *exhaustive* search, no definitive cause of the TCP/IP issue has been found, even though we were eventually able to reproduce it (with the help of Brad). To make headway in solving this, we've now removed most of the old TCP/IP connection accounting code, and replaced it by something a lot cleaner. Details can be seen on http://wiki.powerdns.com/trac/changeset/1685 If anything, this has made PowerDNS a bit smaller ;-) A PowerDNS Recursor 3.3 pre-release is available on http://svn.powerdns.com/snapshots/pdns-recursor-3.3-pre.tar.bz2 and this contains the improvements. This is not the preferred way to solve bugs, nor can we be sure that the problem has in fact been solved. Brad, can you see if you can reproduce the issue using this version? It usually takes us around 2 hours to even see the problem, but for you it usually hit within a few minuts I understand. We hope to hear from you! If this issue is resolved, 3.3 is around the corner. Kind regards, Bert On Wed, Aug 04, 2010 at 09:30:03PM +, Brad Dameron wrote: Bert, Any update on this? Thanks, Brad -Original Message- From: pdns-users-boun...@mailman.powerdns.com [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf Of bert hubert Sent: Tuesday, July 06, 2010 9:01 AM To: Mike Cc: Brad Dameron; pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] Possible tcp listener issue The issue has now been reproduced on one of the PowerDNS servers, thanks to Brad and Christian. However, it is quite some work to make it happen and we've not yet been able to make sense of *why* it is happening. We'll keep you posted. Once this is solved, 3.3 will be released. Bert On Tue, Jul 06, 2010 at 04:11:35PM +0100, Simon Bedford wrote: Hi Christian, Have we had any joy in replicating this issue or highlighting the root cause of the issue? Thanks Simon Christian Hofstädtler wrote: Brad, Josh, I'm trying to reproduce the behaviour you see here, but fail to do so at this time. Maybe you can give me more details about your environment, at least OS version, architecture, and any compile options you've used to build the binary (say, STATIC or LUA). Also of interest would be the last SVN revision you've tried out. If there is anything else you can think of which is special in your environment, please let me know of that, too. Thanks, Christian ___ 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 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. ___ 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] crashes in bind backend on rediscover
On Wed, Aug 11, 2010 at 02:24:04PM +0100, Richard Poole wrote: We're seeing crashes in powerdns 2.9.22 when calling pdns_control rediscover. We have a cron job that does this, currently twice an hour, and on average about once a day it results in a crash, looking like this in /var/log/messages: This is a known issue, but it is usually very rare to hit it. We have about 64 domains in total, with typically up to about 50 That is pretty good! This probably explains why you do see the problem. problems an average of twice a day with a non-negligible chance of losing both nameservers simultaneously and my boss is going to tell me to go This is not good. We'll take a look to see if something can be done that at least works around the problem. I'll keep you posted. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] MySQL backend and notify
On Thu, Aug 12, 2010 at 08:55:17AM +0200, Yves Goergen wrote: On 12.08.2010 08:28 CE(S)T, bert hubert wrote: If configured with 'master' in the configuration, it will periodically retrieve a list of all SOA serial numbers, and determine which ones changed. Does anybody know what time interval this is? Seconds, minutes, hours? 1 minute. This is in fact the 'slave-cycle-interval' setting - the name is a bit confusing. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] recursor resolv ERROR
On Thu, Aug 26, 2010 at 01:20:52PM +0400, Dmitry Rybin wrote: $ dig +short my.smsfeedback.ru @78.108.89.252 click.smsbliss.ru. $ dig +short click.smsbliss.ru @ns1.nameself.com 79.125.121.14 All fine, bind resolves this domain, unbound too, but pdns-recursor - not. It is broken. There are other domains that powerdns resolves just fine, and BIND and unbound can't. Such is life. If we go work around every bug in the world, the DNS will not be better in the end. Tell the majordomo.ru people not to send out NXDOMAINS. Also tell them to stop sending out an authoritative ROOT SOA record. 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 Mon, Aug 23, 2010 at 11:37:42AM +0100, Simon Bedford wrote: Just returned from annual leave to this welcome news, has anyone had a chance to try it as yet and investigate whether the bug still manifests? And does it no longer happen when running Brad's test script? Simon, Sadly we found that the previous code drop, while stable, still exhibited the same problem. We've fixed yet another bug that might be causing the issue, and we are currently testing that. This drop can be found on http://svn.powerdns.com/snapshots/pdns-recursor-3.3-pre.tar.bz2 If you compile the program below, and run it on your pdns server, you'll probably see it print '0' and then a very large number. If you could share that output with us, it could tell us if we are on the right track. http://pastie.org/1124088 http://pastie.org/1124088.txt To compile, save as .cpp file and compile with 'g++ -O2 testing.cpp -o testing', and run with './testing'. 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 04:56:14PM +0200, bert hubert wrote: We've fixed yet another bug that might be causing the issue, and we are currently testing that. This drop can be found on http://svn.powerdns.com/snapshots/pdns-recursor-3.3-pre.tar.bz2 Our testing shows that the problem disappeared! Many thanks to Christian Hofstaedtler. If this was the final problem, this also explains why only some people are seeing it. There are hardware platforms that are highly immune to this bug (Michel Stol measured this), but we've seen an Openvirtuozo hosted Linux being very vulnerable to it. On my own testing hardware, the problem was relatively rare. For the people who care, the root cause appeared to be doing non-atomic updates to the TCP client count. The release process for 3.3 can now start - only 1 feature request left to finish. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] Some notes for Solaris 10 on x86 users of the PowerDNS Recursor
Hi,
This message is for everyone using the PowerDNS Recursor with Solaris 10 on
x86 (non-UltraSPARC) hardware.
It turns out that Solaris 10 on x86 has some issues standing in the way of
high performance for the PowerDNS Recursor. With some care, good results can
be achieved however.
If you need help, please do not hesitate to contact us.
All details can be found on:
http://bert-hubert.blogspot.com/2010/08/some-notes-on-solaris-10-x86-64-bit.html
I've also pasted parts of this post below:
Some notes on Solaris 10 x86, 64 bit compilation, bugs and memory
allocators
(...)
The first thing we noticed was that , the 'Ports' event multiplexer failed
to work on x86 applications, as described in long standing Solaris bug 'CR
6268715 library/libc port_getn(3C) and port_sendn(3C) not working on
Solaris x86'. Apache, libevent and PowerDNS all contain workarounds for
this bug, but that workaround does come with performance implications. At
the very least it is worrying.
Secondly, it turns out that Solaris 10 on x86 can't link 64 bits binaries as
generated by system gcc compiler, at least, not those binaries using Thread
Local Storage for objects at global scope. This is Solaris bug 'CR 6354160',
aka 'Solaris linker includes more than one copy of code in binary when
linking gnu object code', which we worked around by changing PowerDNS so it
could be compiled as one big C++ file.
Using the native Sun Studio compiler failed, because it is not compliant
enough with the C++ standard to compile PowerDNS, and the changes required
were non-trivial.
Although both issues (ports_getn() and 64 bits linking) were known, and
fixes were available in OpenSolaris, these had not made it into Solaris 10
production releases.
Eventually, PowerDNS was able to work around both bugs, but in the case of
6268715 at a runtime performance cost (note: Sun has now shipped
'IDR145429-01' which fixes this).
Which brings us to performance. For some reason, even though the PowerDNS
Recursor uses 'share nothing' threads, there was no scalability when using
multiple threads on Solaris. In fact performance was rather dismal anyhow,
even with only one thread.
Firstly, we discovered that having multiple threads try to wait on a single
socket does not scale beyond a single thread. This was fixed by having only
a single thread wait on the socket, and manually distributing queries over
threads in a round-robin fashion.
This turned out to help slightly, but not decisively. We then discovered
that the default Solaris x86 memory allocator ('malloc()') is effectively
single-threaded (unlike the UltraSPARC variant, which is completely
different!). Solaris ships with no less than two alternative mallocs, called
-lmtmalloc and -lumem respectively. Using libumem helped for benchmarking.
Finally, for Solaris, we had to bring back an old favorite, the 'fork-trick'
which makes the whole PowerDNS Recursor fork itself into multiple processes,
which helped bring Solaris performance up to par with our other major
platform, Linux. We don't yet know why our 'share nothing' threads end up
interfering with each other.
The resulting work was taken into production.. and crashed within 5 minutes
of heavy load, indicating an out of memory error. With a 64 bit binary on an
8 gigabyte machine, this seemed doubtful.
After some further investigations, it was found that while libumem certainly
was faster for multithreaded code, but that it also wastes memory on a
prodigious scale. To be honest, this may be due to the fact that the g++ c++
runtime libraries are not making optimal use of the allocator, or our use of
get/set/swap/makecontext(), but the amount of memory used was staggering.
Think 450MB for storing 10MB of content.
We studied some of the articles available online, among which was 'A
Comparison of Memory Allocators' on the 'Oracle Sun Development Network'.
This one indeed showed graphs of libumem using large amounts of memory, and
a thing called ptmalloc using very little. Oddly enough, ptmalloc is (more
or less) the default allocator for Linux too.
We then built a PowerDNS with all the workarounds, plus ptmalloc linked in,
and now finally have something that survives production use!
Rounding this off:
Solaris x86 is remarkably different from Solaris UltraSPARC (different bugs,
different allocators)
Do not have n1 threads wait on a single datagram socket filedescriptor, it
does not scale
There now IS an IDR to get ports_getn() working, IDR145429-01, which should
also speed up Apache and several other high-performance applications for
Solaris
To build 64 bits binaries with thread local storage (__thread) at global
scope, concatenate all your C++ into one big file, and compile that one
Be aware that the default allocator on Solaris 10 x86 is single-threaded
Be aware that both mtmalloc and libumem may use prohibitive amounts of
memory for some programs
Consider ptmalloc3
We still have to investigate why fork() scales better than pthread_create()
Make sure
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
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] 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] tcp listener issue - hopefully fixed
On Wed, Sep 08, 2010 at 11:16:41PM +, Brad Dameron wrote: Bert, I can’t seem to get this latest version to run right. I build my RPM. I launch it with the following: This is not good! Does it crash immediately, even without accepting any traffic? So if you bind it to port 54 (for example), does it crash too? Bert /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 sbedf...@plus.net Date: Mon, Sep 6, 2010 14:16 Subject: tcp listener issue - hopefully fixed To: bert hubert bert.hub...@netherlabs.nl Cc: Brad Dameron brad.dame...@clearwire.com, pdns-users@mailman.powerdns.com 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
Re: [Pdns-users] PDNS-recursor-3.2 crashed under Solaris 10 (x86)
On Fri, Sep 10, 2010 at 10:20:07AM +0200, Christian Kuehn wrote: Hi, today I installed the Recursor 3.2 in a new Solaris 10 x86 and the process crashed immediately: Hi Christian, Sadly this is well known - see http://mailman.powerdns.com/pipermail/pdns-users/2010-August/006956.html PowerDNS Recursor 3.3-rc1, which is ready for release in wide production, fixes these and other important Solaris issues. Can you try http://svn.powerdns.com/snapshots/pdns-recursor-3.3-rc1.tar.bz2 ? You might also want to install the 'IDR' referenced in the email linked above. To compile for 64 bits use, try: cat portsmplexer.cc syncres.cc misc.cc unix_utility.cc qtype.cc logger.cc arguments.cc lwres.cc pdns_recursor.cc recursor_cache.cc dnsparser.cc dnswriter.cc \ dnsrecords.cc rcpgenerator.cc base64.cc zoneparser-tng.cc rec_channel.cc rec_channel_rec.cc selectmplexer.cc sillyrecords.cc dns_random.cc \ lua-pdns-recursor.cc randomhelper.cc recpacketcache.cc dns.cc reczones.cc base32.cc nsecrecords.cchugefile.cc gcc -g -funit-at-a-time -O3 -m64 -I/export/home/ahu/boost_1_39_0 hugefile.cc aes*c -o pdns_recursor -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -static-libgcc -lm -lc -lresolv -lsocket -lnsl -ldl To get decent performance, try linking in -lptmalloc3 (which you will have to compile first). Bert r...@dns-resolv-1:~# file /opt/pdns-recursor/sbin/pdns_recursor /opt/pdns-recursor/sbin/pdns_recursor: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available Compiled with: CXXFLAGS=-I/opt/src/build/boost_1_34_0 CXX=g++ -m64 CC=gcc -m64 ./configure Any ideas?? Cheers Christian -- Christian Kühn (Technical Consultant) == MCS MOORBEK COMPUTER SYSTEME GmbH Essener Bogen 17 - 22419 Hamburg - Germany Tel +49 (0)40 53773 0 - Fax: +49 (0)40 53773 200 E-Mail: christian.ku...@mcs.de Web: http://www.mcs.de Eingetragen im Handelsregister Hamburg B62933 Geschäftsführer: Kai Brandes Eckard Kabel GPG 8B52 41A1 4B8F 4DE7 9064 2073 6168 137A 3DDA 0F36 == ___ 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
[Pdns-users] PowerDNS Recursor 3.3-RC1 released!
Dear PowerDNS community, PowerDNS Recursor 3.3 Release Candidate 1 is now available! It is in wide production use already, but we'd like everyone to take a good look at it before we release it as 3.3-final. If nothing crops up, RC1 will be the exact same as the 3.3 release. Tar, RPM Deb for 32 bit and 64 bit platforms can be found on http://svn.powerdns.com/release-candidates/ The release notes are also available as HTML with clickable links on http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-3 Release notes: Version 3.3 fixes a number of small but persistent issues, rounds off our IPv6 support and adds an important feature for many users of the Lua scripts. In addition, scalability on Solaris 10 is improved. Bug fixes: * 'dist-recursor' script was not compatible with pure POSIX /bin/sh, discovered by Simon Kirby. Fix in commit 1545. * Simon Bedford, Brad Dameron and Laurient Papier discovered relatively high TCP/IP loads could cause TCP/IP service to shut down over time. Addressed in commits 1546, 1640, 1652, 1685, 1698. Additional information provided by Zwane Mwaikambo, Dr. Nicholas Miell and Jeff Roberson. Testing by Christian Hofstaedtler and Michael Renner. * The PowerDNS Recursor could not read the 'root zone' (this is something else than the root hints) because of an unquoted TXT record. This has now been addressed, allowing operators to hardcode the root zone. This can improve security if the root zone used is kept up to date. Change in commit 1547. * A return of an old bug, when a domain gets new nameservers, but the old nameservers continue to contain a copy of the domain, PowerDNS could get 'stuck' with the old servers. Fixed in commit 1548. * Discovered reported by Alexander Gall of SWITCH, the Recursor used to try to resolve 'AXFR' records over UDP. Fix in commit 1619. * The Recursor embedded authoritative server messed up parsing a record like '@ IN MX 15 @'. Spotted by Aki Tuomi, fix in commit 1621. * The Recursor embedded authoritative server messed up parsing really really long lines. Spotted by Marco Davids, fix in commit 1624, commit 1625. * Packet cache was not DNS class correct. Spotted by Robin, fix in commit 1688. * The packet cache would cache some NXDOMAINS for too long. Solving this bug exposed an underlying oddity where the initial NXDOMAIN response had an overly long (untruncated) TTL, whereas all the next ones would be ok. Solved in commit 1679, closing ticket 281. Especially important for RBL operators. Fixed after some nagging by Alex Broens (thanks). Improvements: * The priming of the root now uses more IPv6 addresses. Change in commit 1550, closes ticket 287. Also, the IPv6 address of I.ROOT-SERVERS.NET was added in commit 1650. * PowerDNS Recursor can now bind to fe80 IPv6 space with '%eth0' link selection. Suggested by Darren Gamble, implemented with help from Niels Bakker. Change in commit 1620. * Solaris on x86 has a long standing bug in port_getn(), which we now work around. Spotted by 'Dirk' and 'AS'. Solution suggested by the Apache runtime library, update in commit 1622. * New runtime statistic: 'tcp-clients' which lists the number of currently active TCP/IP clients. Code in commit 1623. * Deal better with UltraDNS style CNAME redirects containing SOA records. Spotted by Andy Fletcher from UKDedicated in ticket 303, fix in commit 1628. * The packet cache, which has 'ready to use' packets containing answers, now artificially ages the ready to use packets. Code in commit 1630. * Lua scripts can now indicate that certain queries will have 'variable' answers, which means that the packet cache will not touch these answers. This is great for overriding some domains for some users, but not all of them. Use setvariable() in Lua to indicate such domains. Code in commit 1636. * Add query statistic called 'dont-outqueries', plus add IPv6 address :: and IPv4 address 0.0.0.0 to the default dont-query set, preventing the Recursor from talking to itself. Code in commit 1637. * Work around a gcc 4.1 bug, still in wide use on common platforms. Code in commit 1653. * Add 'ARCHFLAGS' to PowerDNS Recursor Makefile, easing 64 bit compilation on mainly 32 bit platforms (and vice versa). * Under rare circumstances, querying the Recursor for statistics under very high load could lead to a crash (although this has never been observed). Bad code removed good code unified in commit 1675. * Spotted by Jeff Sipek, the rec_control manpage did not list the new get-all command. commit 1677. * On some platforms, it may be better to have PowerDNS itself distribute queries over threads (instead of leaving it up to the kernel). This experimental feature can be enabled with the 'pdns-distributes-queries'
Re: [Pdns-users] PowerDNS (2.9.22) crash with signal 8 (floating point exception)
On Sat, Sep 11, 2010 at 06:43:08PM +0700, Dmitriy Lyfar wrote: Hi, I'm using pdns with my own backend. Previous version I've used was 2.9.21 (from centos repo) and my backend works fine. But we decided to move to last version (pdns-static, 2.9.22, x86_64) and it can't even run with my backend. I've got a stack trace from debugging version, which looks like: Dmitry, Do you have a copy of your configuration? do you run with a chroot? Bert Sep 11 13:28:35 dnsfencetest pdns[15527]: Reading random entropy from '/dev/urandom' Sep 11 13:28:35 dnsfencetest pdns[15527]: Got a signal 11, attempting to print trace: Sep 11 13:28:35 dnsfencetest pdns[15527]: /usr/sbin/pdns_server-instance [0x816501e] Sep 11 13:28:35 dnsfencetest pdns[15527]: [0xe500] Sep 11 13:28:35 dnsfencetest pdns[15527]: /usr/sbin/pdns_server-instance(aes_encrypt_key128+0) [0x81fa510] Sep 11 13:28:35 dnsfencetest pdns[15527]: /usr/sbin/pdns_server-instance(_Z10seedRandomRKSs+0x893) [0x81fec05] Sep 11 13:28:35 dnsfencetest pdns[15527]: /usr/sbin/pdns_server-instance(main+0x1b1c) [0x8166ed4] Sep 11 13:28:35 dnsfencetest pdns[15527]: /lib/libc.so.6(__libc_start_main+0xdc) [0x1a8e9c] Sep 11 13:28:35 dnsfencetest pdns[15527]: /usr/sbin/pdns_server-instance [0x80f2971] Sep 11 13:28:36 dnsfencetest pdns[13550]: Our pdns instance (15527) exited after signal 6 So crash something inside of seedRandom function. I'm confused with this trace, is there any problems with /dev/urandom? Thank you. -- Regards, Lyfar Dmitriy ___ 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
[Pdns-users] PowerDNS Recursor 3.3-RC2 released!
Dear PowerDNS community, PowerDNS Recursor 3.3 Release Candidate 2 is now available! It is in wide production use already, but we'd like everyone to take a good look at it before we release it as 3.3-final. If nothing crops up, RC2 will be the exact same as the 3.3 release. RC1 had some compilation problems on popular platforms like CentOS5/RHEL5, which forced a quick RC2. Tar, RPM Deb for 32 bit and 64 bit platforms can be found on http://svn.powerdns.com/release-candidates/ The release notes are also available as HTML with clickable links on http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-3 Version 3.3 fixes a number of small but persistent issues, rounds off our IPv6 support and adds an important feature for many users of the Lua scripts. In addition, scalability on Solaris 10 is improved. Changes between RC1 and RC2: * Fixed linking on RHEL5/CENTOS5, which both ship with a gcc compiler that claims to support atomic operations, but doesn't. Code in commit 1714. Spotted by 'Bas' and Imre Gergely. * Negative query cache was configured to grow too large, and was not cleaned efficiently. Code in commit 1712, spotted by Imre Gergely. 3.3 release notes follow. Bug fixes: * 'dist-recursor' script was not compatible with pure POSIX /bin/sh, discovered by Simon Kirby. Fix in commit 1545. * Simon Bedford, Brad Dameron and Laurient Papier discovered relatively high TCP/IP loads could cause TCP/IP service to shut down over time. Addressed in commits 1546, 1640, 1652, 1685, 1698. Additional information provided by Zwane Mwaikambo, Nicholas Miell and Jeff Roberson. Testing by Christian Hofstaedtler and Michael Renner. * The PowerDNS Recursor could not read the 'root zone' (this is something else than the root hints) because of an unquoted TXT record. This has now been addressed, allowing operators to hardcode the root zone. This can improve security if the root zone used is kept up to date. Change in commit 1547. * A return of an old bug, when a domain gets new nameservers, but the old nameservers continue to contain a copy of the domain, PowerDNS could get 'stuck' with the old servers. Fixed in commit 1548. * Discovered reported by Alexander Gall of SWITCH, the Recursor used to try to resolve 'AXFR' records over UDP. Fix in commit 1619. * The Recursor embedded authoritative server messed up parsing a record like '@ IN MX 15 @'. Spotted by Aki Tuomi, fix in commit 1621. * The Recursor embedded authoritative server messed up parsing really really long lines. Spotted by Marco Davids, fix in commit 1624, commit 1625. * Packet cache was not DNS class correct. Spotted by Robin, fix in commit 1688. * The packet cache would cache some NXDOMAINS for too long. Solving this bug exposed an underlying oddity where the initial NXDOMAIN response had an overly long (untruncated) TTL, whereas all the next ones would be ok. Solved in commit 1679, closing ticket 281. Especially important for RBL operators. Fixed after some nagging by Alex Broens (thanks). Improvements: * The priming of the root now uses more IPv6 addresses. Change in commit 1550, closes ticket 287. Also, the IPv6 address of I.ROOT-SERVERS.NET was added in commit 1650. * The rec_control dump-cache command now also dumps the 'negative query' cache. Code in commit 1713. * PowerDNS Recursor can now bind to fe80 IPv6 space with '%eth0' link selection. Suggested by Darren Gamble, implemented with help from Niels Bakker. Change in commit 1620. * Solaris on x86 has a long standing bug in port_getn(), which we now work around. Spotted by 'Dirk' and 'AS'. Solution suggested by the Apache runtime library, update in commit 1622. * New runtime statistic: 'tcp-clients' which lists the number of currently active TCP/IP clients. Code in commit 1623. * Deal better with UltraDNS style CNAME redirects containing SOA records. Spotted by Andy Fletcher from UKDedicated in ticket 303, fix in commit 1628. * The packet cache, which has 'ready to use' packets containing answers, now artificially ages the ready to use packets. Code in commit 1630. * Lua scripts can now indicate that certain queries will have 'variable' answers, which means that the packet cache will not touch these answers. This is great for overriding some domains for some users, but not all of them. Use setvariable() in Lua to indicate such domains. Code in commit 1636. * Add query statistic called 'dont-outqueries', plus add IPv6 address :: and IPv4 address 0.0.0.0 to the default dont-query set, preventing the Recursor from talking to itself. Code in commit 1637. * Work around a gcc 4.1 bug, still in wide use on common platforms. Code in commit 1653. * Add 'ARCHFLAGS' to PowerDNS Recursor Makefile, easing 64 bit compilation on mainly
Re: [Pdns-users] pdns-recursor-3.3rc2 our root expired messages
On Wed, Sep 15, 2010 at 01:37:30PM +0200, Detlef Peeters wrote: pdns_recursor[32068]: objects-test.deviantart.com.edgesuite.net.: our root expired, repriming from hints and retrying pdns_recursor[32068]: s.de.net.: our root expired, repriming from hints and retrying Hi Detlef, Can you list the relevant parts of your configuration file? (ie, not allow-from, local-address etc). Does this happen immediately? Or after a day? Bert Installed is pdns-recursor-3.3rc2-1.x86_64.rpm on CentOS 5.5 Is there a problem, or what does this messages means. regards, Detlef ___ 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] pdns-recursor-3.3rc2 our root expired messages
Found it solved in http://wiki.powerdns.com/trac/changeset/1716 This issue is harmless, but it is good to have it solved for the 'real' release. Thanks for the vigilance! Bert On Wed, Sep 15, 2010 at 01:39:11PM +0200, bert hubert wrote: On Wed, Sep 15, 2010 at 01:37:30PM +0200, Detlef Peeters wrote: pdns_recursor[32068]: objects-test.deviantart.com.edgesuite.net.: our root expired, repriming from hints and retrying pdns_recursor[32068]: s.de.net.: our root expired, repriming from hints and retrying Hi Detlef, Can you list the relevant parts of your configuration file? (ie, not allow-from, local-address etc). Does this happen immediately? Or after a day? Bert Installed is pdns-recursor-3.3rc2-1.x86_64.rpm on CentOS 5.5 Is there a problem, or what does this messages means. regards, Detlef ___ 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 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns recursor 3.2 cname resolution phenomenon
On Mon, Sep 20, 2010 at 07:32:51AM +0200, Thomas Mieslinger wrote: we're using pdns recursor for out company internal name resolution. We have some strange setups to support that can't easily be removed. In some of our offical Zones are CNAMEs. The A records to these Names are in our internal Zones configured in forward.zones. Getting the A records works fine. But when looking up a CNAME, the answer only contains the CNAME. The recursor seems not to try to resolve the CNAME answer again. Maybe this is because the CNAME containing answer has the NXDOMAIN Bit set. Can you elaborate a bit more? I think this issue is fixed in 3.3, which contains a change that makes PowerDNS be a bit more lenient in understanding CNAME chains containing SOA records that indicate a 'NO ERROR' response. 3.3-rc2 can be found on http://svn.powerdns.com/release-candidates/ The relevant item is: Deal better with UltraDNS style CNAME redirects containing SOA records. Spotted by Andy Fletcher from UKDedicated in ticket 303, fix in commit 1628. http://wiki.powerdns.com/projects/trac/ticket/303 http://wiki.powerdns.com/projects/trac/changeset/1628 Let me know if this solves your problem. Kind regards, Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns-recursor-3.3rc2 cache is growing slow
Odd - can you paste some 'stats:' lines from the log files? stats: 4331362754 questions, 1003788 cache entries, 100987 negative entries, 27% cache hits stats: throttle map: 2752, ns speeds: 76672 stats: outpacket/query ratio 3205%, 2% throttled, 0 no-delegation drops stats: 263614 outgoing tcp connections, 146 queries running, 45761180 outgoing timeouts stats: 504910 packet cache entries, 8798% packet cache hits stats: 6286 qps (average over 1801 seconds) This is from our testing of rc1. Bert On Mon, Sep 20, 2010 at 11:00:58AM +0200, Detlef Peeters wrote: Hello, I've noticed on the machine I am testing pdns-recursor-3.3rc2 the cache is growing really slow. After 6 days there are only 80.000 entries. With pdns-recursor-3.2 the cache is filled up to 1.000.000 entries after 5 days. Has there something changed with the cache handling in pdns-recursor-3.3rc2? regards, Detlef ___ 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
[Pdns-users] PowerDNS Recursor 3.3-RC3 released
Dear PowerDNS community, PowerDNS Recursor 3.3 Release Candidate 3 is now available! It is in wide production use already, but we'd like everyone to take a good look at it before we release it as 3.3-final. If nothing crops up, RC3 will be the exact same as the 3.3 release. RC1 had some compilation problems on popular platforms like CentOS5/RHEL5, which forced a quick RC2. RC2 emitted harmless warnings about the root expiring, but such warnings don't look too harmless, so they had to be fixed. Tar, RPM Deb for 32 bit and 64 bit platforms can be found on http://svn.powerdns.com/release-candidates/ The release notes are also available as HTML with clickable links on http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-3 Version 3.3 fixes a number of small but persistent issues, rounds off our IPv6 support and adds an important feature for many users of the Lua scripts. In addition, scalability on Solaris 10 is improved. Changes between RC1, RC2 and RC3. * RC2: Fixed linking on RHEL5/CENTOS5, which both ship with a gcc compiler that claims to support atomic operations, but doesn't. Code in commit 1714. Spotted by 'Bas' and Imre Gergely. * RC2: Negative query cache was configured to grow too large, and was not cleaned efficiently. Code in commit 1712, spotted by Imre Gergely. * RC3: Root failed to be renewed automatically, relied on fallback to make this happen. Code in commit 1716, spotted by Detlef Peeters. 3.3 release notes follow. Bug fixes: * 'dist-recursor' script was not compatible with pure POSIX /bin/sh, discovered by Simon Kirby. Fix in commit 1545. * Simon Bedford, Brad Dameron and Laurient Papier discovered relatively high TCP/IP loads could cause TCP/IP service to shut down over time. Addressed in commits 1546, 1640, 1652, 1685, 1698. Additional information provided by Zwane Mwaikambo, Nicholas Miell and Jeff Roberson. Testing by Christian Hofstaedtler and Michael Renner. * The PowerDNS Recursor could not read the 'root zone' (this is something else than the root hints) because of an unquoted TXT record. This has now been addressed, allowing operators to hardcode the root zone. This can improve security if the root zone used is kept up to date. Change in commit 1547. * A return of an old bug, when a domain gets new nameservers, but the old nameservers continue to contain a copy of the domain, PowerDNS could get 'stuck' with the old servers. Fixed in commit 1548. * Discovered reported by Alexander Gall of SWITCH, the Recursor used to try to resolve 'AXFR' records over UDP. Fix in commit 1619. * The Recursor embedded authoritative server messed up parsing a record like '@ IN MX 15 @'. Spotted by Aki Tuomi, fix in commit 1621. * The Recursor embedded authoritative server messed up parsing really really long lines. Spotted by Marco Davids, fix in commit 1624, commit 1625. * Packet cache was not DNS class correct. Spotted by Robin, fix in commit 1688. * The packet cache would cache some NXDOMAINS for too long. Solving this bug exposed an underlying oddity where the initial NXDOMAIN response had an overly long (untruncated) TTL, whereas all the next ones would be ok. Solved in commit 1679, closing ticket 281. Especially important for RBL operators. Fixed after some nagging by Alex Broens (thanks). Improvements: * The priming of the root now uses more IPv6 addresses. Change in commit 1550, closes ticket 287. Also, the IPv6 address of I.ROOT-SERVERS.NET was added in commit 1650. * The rec_control dump-cache command now also dumps the 'negative query' cache. Code in commit 1713. * PowerDNS Recursor can now bind to fe80 IPv6 space with '%eth0' link selection. Suggested by Darren Gamble, implemented with help from Niels Bakker. Change in commit 1620. * Solaris on x86 has a long standing bug in port_getn(), which we now work around. Spotted by 'Dirk' and 'AS'. Solution suggested by the Apache runtime library, update in commit 1622. * New runtime statistic: 'tcp-clients' which lists the number of currently active TCP/IP clients. Code in commit 1623. * Deal better with UltraDNS style CNAME redirects containing SOA records. Spotted by Andy Fletcher from UKDedicated in ticket 303, fix in commit 1628. * The packet cache, which has 'ready to use' packets containing answers, now artificially ages the ready to use packets. Code in commit 1630. * Lua scripts can now indicate that certain queries will have 'variable' answers, which means that the packet cache will not touch these answers. This is great for overriding some domains for some users, but not all of them. Use setvariable() in Lua to indicate such domains. Code in commit 1636. * Add query statistic called 'dont-outqueries', plus add IPv6 address :: and IPv4 address 0.0.0.0 to the
Re: [Pdns-users] PowerDNS Recursor 3.3-RC3 released
On Tue, Sep 21, 2010 at 11:08:33AM +0200, Detlef Peeters wrote: On Mon, 20 Sep 2010 20:22:40 +0200, bert hubert bert.hub...@netherlabs.nl wrote: PowerDNS Recursor 3.3 Release Candidate 3 is now available! It is in wide production use already, but we'd like everyone to take a good look at it before we release it as 3.3-final. If nothing crops up, RC3 will be the exact same as the 3.3 release. I've installed it today and I noticed the following message I've never seen before: Unable to parse packet from remote server 216.38.220.31: Error parsing packet of 123 bytes (rd=0), out of bounds: vector::_M_range_check Detlef, these messages are not new, but perhaps you should configure 'log-dns-details=off'. The message means that the remote authoritative server 216.38.220.30 is sending you malformed packets. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns recursor 3.2 cname resolution phenomenon
Thomas, Please provide real domain names, otherwise I can't test. Kind regards, Bert Hubert On Wed, Sep 22, 2010 at 04:53:22PM +0200, Thomas Mieslinger wrote: On 09/20/10 07:53 AM, bert hubert wrote: On Mon, Sep 20, 2010 at 07:32:51AM +0200, Thomas Mieslinger wrote: we're using pdns recursor for out company internal name resolution. [..] containing answer has the NXDOMAIN Bit set. Can you elaborate a bit more? I think this issue is fixed in 3.3, which [..] Let me know if this solves your problem. Hi Bert, I installed pdns_recursor 3.3-rc3 from svn.powerdns.com. Sorry, my Problem isn't gone... I did some packet dumping ... dig db686.XXX.de @recursor tcpdump on the recursor: IP recursor.38240 authdns.53: 19990 A? db686.XXX.de. (38) IP authdns.53 recursor.38240: 19990 NXDomain*- 1/1/0 CNAME[|domain] The answer packet contains db686.XXX.de IN CNAME db686.YYY.de And has the AUTHORITY bit set. At this point I would like the recursor to try another resolution with db686.YYY.de but that would probably break the code and the idea behind DNS. So now, that I understood my problem, I don't think the code needs to be fixed :-( Regards Thomas -- Thomas Mieslinger 11 Internet AG - IT Operations Data Services Infrastructure Brauerstraße 48 · DE-76135 Karlsruhe Telefon: +49 721 91374 4404 thomas.mieslin...@1und1.de Amtsgericht Montabaur / HRB 6484 Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael Scheeren ___ 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] pdns recursor 3.2 cname resolution phenomenon
Thomas,
As discussed before, sending out an NXDOMAIN means just that, an NXDOMAIN.
Please don't do it.
I don't think it would be a good idea to make PowerDNS broken.
If you want to do it personally, apply this patch and recompile:
--- ../syncres.cc 2010-09-16 17:17:38.496153009 +0200
+++ syncres.cc 2010-09-22 17:30:37.506153002 +0200
@@ -1083,7 +1083,7 @@
LOGprefixqname: status=got results, this level of recursion
doneendl;
return 0;
}
- if(lwr.d_rcode==RCode::NXDomain) {
+ if(lwr.d_rcode==RCode::NXDomain newtarget.empty()) {
LOGprefixqname: status=NXDOMAIN, we are done (negindic ?
(have negative SOA) : )endl;
return RCode::NXDomain;
}
It fixes your problem
Good luck!
On Wed, Sep 22, 2010 at 05:08:23PM +0200, Thomas Mieslinger wrote:
Hi Bert,
an example is db686.XXX.de. From the authorative Nameserver
you will get NXDomain and AUTHORTIY = 1, but internally
db686.YYY.de is known.
Would you add an option to try recursing cnames even if an answer
has the authority bit set?
Regards Thomas
On 09/22/10 04:54 PM, bert hubert wrote:
Thomas,
Please provide real domain names, otherwise I can't test.
Kind regards,
Bert Hubert
On Wed, Sep 22, 2010 at 04:53:22PM +0200, Thomas Mieslinger wrote:
On 09/20/10 07:53 AM, bert hubert wrote:
On Mon, Sep 20, 2010 at 07:32:51AM +0200, Thomas Mieslinger wrote:
we're using pdns recursor for out company internal name resolution.
[..]
containing answer has the NXDOMAIN Bit set.
Can you elaborate a bit more? I think this issue is fixed in 3.3, which
[..]
Let me know if this solves your problem.
Hi Bert,
I installed pdns_recursor 3.3-rc3 from svn.powerdns.com. Sorry, my
Problem isn't gone...
I did some packet dumping ...
dig db686.XXX.de @recursor
tcpdump on the recursor:
IP recursor.38240 authdns.53: 19990 A? db686.XXX.de. (38)
IP authdns.53 recursor.38240: 19990 NXDomain*- 1/1/0 CNAME[|domain]
The answer packet contains
db686.XXX.de IN CNAME db686.YYY.de
And has the AUTHORITY bit set.
At this point I would like the recursor to try another resolution
with db686.YYY.de but that would probably break the code and the
idea behind DNS.
So now, that I understood my problem, I don't think the code needs
to be fixed :-(
Regards Thomas
--
Thomas Mieslinger
11 Internet AG - IT Operations Data Services Infrastructure
Brauerstraße 48 · DE-76135 Karlsruhe
Telefon: +49 721 91374 4404
thomas.mieslin...@1und1.de
Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning
Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
--
Thomas Mieslinger
11 Internet AG - IT Operations Data Services Infrastructure
Brauerstraße 48 · DE-76135 Karlsruhe
Telefon: +49 721 91374 4404
thomas.mieslin...@1und1.de
Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning
Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNS Recursor 3.3 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, We're proud to announce the release of the PowerDNS Recursor 3.3! It can be downloaded from http://www.powerdns.com/ or via the following direct links: http://downloads.powerdns.com/releases/pdns-recursor-3.3.tar.bz2 http://downloads.powerdns.com/releases/deb/pdns-recursor_3.3-1_i386.deb http://downloads.powerdns.com/releases/deb/pdns-recursor_3.3-1_amd64.deb http://downloads.powerdns.com/releases/rpm/pdns-recursor-3.3-1.i386.rpm http://downloads.powerdns.com/releases/rpm/pdns-recursor-3.3-1.x86_64.rpm There you will also find PGP signatures of this release (add .sig), based on the same key that has signed this message. A version of the release notes with clickable links to changes, can also be found on http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-3 Version 3.3 fixes a number of small but persistent issues, rounds off our IPv6 %link-level support and adds an important feature for many users of the Lua scripts. In addition, scalability on Solaris 10 is improved. Bug fixes: * 'dist-recursor' script was not compatible with pure POSIX /bin/sh, discovered by Simon Kirby. Fix in commit 1545. * Simon Bedford, Brad Dameron and Laurient Papier discovered relatively high TCP/IP loads could cause TCP/IP service to shut down over time. Addressed in commits 1546, 1640, 1652, 1685, 1698. Additional information provided by Zwane Mwaikambo, Nicholas Miell and Jeff Roberson. Testing by Christian Hofstaedtler and Michael Renner. * The PowerDNS Recursor could not read the 'root zone' (this is something else than the root hints) because of an unquoted TXT record. This has now been addressed, allowing operators to hardcode the root zone. This can improve security if the root zone used is kept up to date. Change in commit 1547. * A return of an old bug, when a domain gets new nameservers, but the old nameservers continue to contain a copy of the domain, PowerDNS could get 'stuck' with the old servers. Fixed in commit 1548. * Discovered reported by Alexander Gall of SWITCH, the Recursor used to try to resolve 'AXFR' records over UDP. Fix in commit 1619. * The Recursor embedded authoritative server messed up parsing a record like '@ IN MX 15 @'. Spotted by Aki Tuomi, fix in commit 1621. * The Recursor embedded authoritative server messed up parsing really really long lines. Spotted by Marco Davids, fix in commit 1624, commit 1625. * Packet cache was not DNS class correct. Spotted by Robin, fix in commit 1688. * The packet cache would cache some NXDOMAINS for too long. Solving this bug exposed an underlying oddity where the initial NXDOMAIN response had an overly long (untruncated) TTL, whereas all the next ones would be ok. Solved in commit 1679, closing ticket 281. Especially important for RBL operators. Fixed after some nagging by Alex Broens (thanks). Improvements: * The priming of the root now uses more IPv6 addresses. Change in commit 1550, closes ticket 287. Also, the IPv6 address of I.ROOT-SERVERS.NET was added in commit 1650. * The rec_control dump-cache command now also dumps the 'negative query' cache. Code in commit 1713. * PowerDNS Recursor can now bind to fe80 IPv6 space with '%eth0' link selection. Suggested by Darren Gamble, implemented with help from Niels Bakker. Change in commit 1620. * Solaris on x86 has a long standing bug in port_getn(), which we now work around. Spotted by 'Dirk' and 'AS'. Solution suggested by the Apache runtime library, update in commit 1622. * New runtime statistic: 'tcp-clients' which lists the number of currently active TCP/IP clients. Code in commit 1623. * Deal better with UltraDNS style CNAME redirects containing SOA records. Spotted by Andy Fletcher from UKDedicated in ticket 303, fix in commit 1628. * The packet cache, which has 'ready to use' packets containing answers, now artificially ages the ready to use packets. Code in commit 1630. * Lua scripts can now indicate that certain queries will have 'variable' answers, which means that the packet cache will not touch these answers. This is great for overriding some domains for some users, but not all of them. Use setvariable() in Lua to indicate such domains. Code in commit 1636. * Add query statistic called 'dont-outqueries', plus add IPv6 address :: and IPv4 address 0.0.0.0 to the default dont-query set, preventing the Recursor from talking to itself. Code in commit 1637. * Work around a gcc 4.1 bug, still in wide use on common platforms. Code in commit 1653. * Add 'ARCHFLAGS' to PowerDNS Recursor Makefile, easing 64 bit compilation on mainly 32 bit platforms (and vice versa). * Under rare circumstances, querying the Recursor for statistics under very high load could lead to a crash
Re: [Pdns-users] PowerDNS recursor rrd change ?
Indeed. And for this purpose we have: http://doc.powerdns.com/recursor-stats.html ;-) This states: It should be noted that answers0-1 + answers1-10 + answers10-100 + answers100-1000 + packetcache-hits + over-capacity-drops = questions. You are currently missing the 'packetcache-hits'. The updated rrdtool graphs know about this already. Good luck! On Tue, Sep 28, 2010 at 12:09:55PM +0200, Jeroen Wunnink wrote: Did something change in the way the RRD/graphs are generated for the recursor ? I just upgraded from 3.1.x to 3.3.1 and it's suddenly showing a big blank space where my 1ms queries used to be: http://noc.easycolocate.nl/dns/ -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeh...@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl ___ 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] Pdns 2.9.22 stopped treating NOTIFY or manual retrieves when acting as slave
On Mon, Oct 04, 2010 at 02:09:16PM +0200, Florent Lerat wrote: We slave about 20 domains for most of which one of our 5 servers is the master. We are slave for 90 different masters. Some of those masters are indeed generating timeout or different types of error such as : - Query to '1.2.3.4' for SOA of 'domain' produced a NS record - Remote nameserver reported error: RCODE=5 - Remote nameserver reported error: RCODE=2 Florent, In 2.9.22 slaving this many domains might actually take *ages*. We've built 2.9.22.x for the people that slave lots of domains, and it has resolved all these issues in huge deployments. It can be downloaded from http://svn.powerdns.com/snapshots/pdns-2.9.22.x-2.tar.gz It runs in setups with 350k slave domains. Please let me know if this solves your issue! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Announcing JPower Admin
Hi Jivko, This looks really interesting! Many thanks for contributing this to the PowerDNS community! I've added JPower Admin to our Open Source Community page on http://www.powerdns.com/content/open-source-community.aspx Other projects will be added too, but this is a great example. Thanks! Bert Hubert PowerDNS On Mon, Oct 11, 2010 at 03:36:35PM -0600, Jivko Sabev wrote: Greetings, I have released yet another control panel for Power DNS. Some of the key features include: - support for all Power DNS features - support for fancy records - built on an enterprise platform - forgotten password function - internationalized and localized interface - easy to extend - API for full control over zones The interface is released under GPL v3. Demo link: http://www.nicmus.com/JPowerAdmin/home.html Download link: http://www.nicmus.com/community.html at the bottom of the page. Regards, Jivko ___ 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] is it nessary to add soa record? I don't use axfr.
On Thu, Nov 11, 2010 at 12:05:26PM +0800, Xscape wrote: hi, I will manage one dns zone(or one domain) with pdns authoritative server (mysql backend). Is there any problems without soa record. SOA means 'start of authority'. Without SOA, there is no authority and no zone. So yes, it is mandatory for DNS, not just for PowerDNS. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNS Recursor additional Lua hooks for IPv6 DNS64 and Renumbering
On Sun, Nov 14, 2010 at 10:32:31PM +0100, bert hubert wrote: The PowerDNS Recursor is currently being extended with additional Lua hooks and extra infrastructure to support flexible DNS64 operations, plus perform on-the-fly IPv4 or IPv6 renumbering. (...) Known defects are: postresolve() can't yet access the original dns rcode there is no way for nodata() to set the TTL to the SOA minimum value as specified by draft-ietf-behave-dns64 Both of these issues have been addressed in the latest source code drop on: http://svn.powerdns.com/snapshots/pdns-recursor-3.3-hooks.tar.bz2 Kind regards, Bert Hubert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Cache Problems with upgrade to Recursor 3.3
On Wed, Dec 01, 2010 at 12:40:40PM -0600, Jeremy Utley wrote: load balancer which handles sharing the load between them. This implementation has been in place for about a year with no issues. We also use Cacti graphs for collecting performance data, by extending SNMP with output from the rec_control command. Jeremy, before delving into this further, can you check if your Cacti calculations are compliant with the following tidbit from http://doc.powerdns.com/recursor-stats.html : It should be noted that answers0-1 + answers1-10 + answers10-100 + answers100-1000 + packetcache-hits + over-capacity-drops = questions. In addition, you might want to look at the rrd metrics. In short, if packetcache-hits are not counted as cache hits, the total cache hitrate will be wrong. Thanks. /usr/bin/rec_control get questions cache-entries cache-hits cache-misses concurrent-queries resource-limits unauthorized-tcp unauthorized-udp spoof-prevents answers-slow client-parse-errors answers0-1 answers1-10 answers10-100 answers100-1000 qa-latency Am I mis-interpreting this, or is there something definately going on? Thanks for your time, Jeremy ___ 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] tcp listener issue - hopefully fixed
Wonderful news! This truly closes this truly longstanding bug ;-) Bert On Tue, Nov 30, 2010 at 09:43:24AM +, Simon Bedford wrote: Bert, I have now rolled out the new 3.3 version to our entire estate of servers and have seen no further bugs, the process has been stable for a number of weeks now and all looks good, many thanks for all of your help. Simon From: pdns-users-boun...@mailman.powerdns.com [pdns-users-boun...@mailman.powerdns.com] On Behalf Of Brad Dameron [brad.dame...@clearwire.com] Sent: 09 September 2010 20:04 To: bert hubert Cc: Mike; pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] tcp listener issue - hopefully fixed Bert, I re-downloaded the src and rebuilt my RPM. It appears to be up and running now. Unknown why the first compiles had this issue. I have been testing the last 2 hours and so far so good. I'll let you know tomorrow the final outcome. Thanks, Brad -Original Message- From: bert hubert [mailto:bert.hub...@netherlabs.nl] Sent: Thursday, September 09, 2010 5:06 AM To: Brad Dameron Cc: Mike; pdns-users@mailman.powerdns.com Subject: Re: [Pdns-users] tcp listener issue - hopefully fixed On Wed, Sep 08, 2010 at 11:16:41PM +, Brad Dameron wrote: Bert, I can't seem to get this latest version to run right. I build my RPM. I launch it with the following: This is not good! Does it crash immediately, even without accepting any traffic? So if you bind it to port 54 (for example), does it crash too? Bert /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
[Pdns-users] PowerDNS Recursor: McAfee-related errors in your log files
Dear PowerDNS Recursor users, If you have McAfee users among your client base, you may currently be seeing errors like these in your log file: pdns_recursor[4024]: DNS parser error: 0.xx-x.xx.1xxx...xxx.x.xx.avqs.mcafee.com., Parsing record content: expected digits at position 9 in '\# 45 093a800258' These errors are harmless to your general Recursor operations, but the McAfee program generating these queries will be reporting timeouts to your end-users. The root cause of this error is a protocol violation by the McAfee nameserver software. We are attempting to contact McAfee so that they can become aware of this error. In short, they are emitting answers in 'CLASS0' instead of in 'CLASS IN'. This causes PowerDNS to log the scary errors reported above. Additionally, it crashes many versions of 'dig'. We are attempting to contact McAfee. If you know anyone in a DNS position there, please let me know. In the meantime, if you want to get rid of this error and you can recompile your PowerDNS Recursor, you can use: Index: dnsparser.cc === --- dnsparser.cc(revision 1745) +++ dnsparser.cc(working copy) @@ -246,6 +246,8 @@ dr.d_ttl=ah.d_ttl; dr.d_type=ah.d_type; dr.d_class=ah.d_class; + if(dr.d_class == 0) +dr.d_class = 1; dr.d_label=label; dr.d_clen=ah.d_clen; Kind regards, Bert Hubert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNS Recursor: McAfee-related errors in your log files
McAfee responded within minutes, and they are on the case. Thanks for the hint! Bert On Wed, Dec 08, 2010 at 09:05:24AM -0500, Curtis Maurand wrote: You might try posting a message to the nanog list. --Curtis On 12/8/2010 7:43 AM, bert hubert wrote: Dear PowerDNS Recursor users, If you have McAfee users among your client base, you may currently be seeing errors like these in your log file: pdns_recursor[4024]: DNS parser error: 0.xx-x.xx.1xxx...xxx.x.xx.avqs.mcafee.com., Parsing record content: expected digits at position 9 in '\# 45 093a800258' These errors are harmless to your general Recursor operations, but the McAfee program generating these queries will be reporting timeouts to your end-users. The root cause of this error is a protocol violation by the McAfee nameserver software. We are attempting to contact McAfee so that they can become aware of this error. In short, they are emitting answers in 'CLASS0' instead of in 'CLASS IN'. This causes PowerDNS to log the scary errors reported above. Additionally, it crashes many versions of 'dig'. We are attempting to contact McAfee. If you know anyone in a DNS position there, please let me know. In the meantime, if you want to get rid of this error and you can recompile your PowerDNS Recursor, you can use: Index: dnsparser.cc === --- dnsparser.cc(revision 1745) +++ dnsparser.cc(working copy) @@ -246,6 +246,8 @@ dr.d_ttl=ah.d_ttl; dr.d_type=ah.d_type; dr.d_class=ah.d_class; + if(dr.d_class == 0) +dr.d_class = 1; dr.d_label=label; dr.d_clen=ah.d_clen; Kind regards, Bert Hubert ___ 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 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [Recursor] Resolving large RRsets
On Mon, Dec 13, 2010 at 09:35:47AM +0100, Stephane Bortzmeyer wrote: On Mon, Dec 13, 2010 at 09:30:18AM +0100, bert hubert bert.hub...@netherlabs.nl wrote a message of 286 lines which said: Dec 13 09:23:54 [1] all-wikileaks.bortzmeyer.fr.: truncated bit set, retrying via TCP This is not perfect: with BIND and Unbound, there is no fallback to TCP since they use EDNS0 (with a default buffer size of 4096 bytes, which is enough for this RRset). Why does PowerDNS do not use EDNS0? We actually have that code, and it turns out it leads to a lot of fallback to non-EDNS0 after timeouts. The net effect of EDNS0 usage is heavily negative, especially when truncated answers are rare. Since almost no TCP overhead is saved, each timeout caused by EDNS0-probing is very expensive. Let alone the EDNS0 path MTU probing etc. In short, for non-DNSSEC workloads, it is not worth it. A nice middleground is what Nominum does, only try EDNS0 in case a tc=1 answer is seen, that might be worth it. But, the logic is there in the PowerDNS Recursor, and it will be hooked up again once we do DNSSEC for validation. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns-recursor doesnt connect to dns root servers
On Tue, Dec 21, 2010 at 06:24:56PM +0100, Florian Krolikowski wrote: Hi Bert! Here the requested tcpdump. I hope it is meaningful for you. Thanks a lot for your help. Hi Florian, It appears that there is no PowerDNS issue - PowerDNS is sending correct root priming queries, but getting no responses. Can you try: dig +bufsize=1280 +norecurs -t ns . @198.41.0.4 And see if you get an answer? It may be that you are behind a firewall that drops answers 512 bytes. If this 'dig' line gets an answer, can you tcpdump it too? Bert Flo On 12/20/2010 08:37 PM, bert.hub...@netherlabs.nl wrote: Can you tcpdump -s 1500 port 53 -w for-bert while it starts? Sent from my phone. - Reply message - From: florian flor...@admin-box.com Date: Mon, Dec 20, 2010 19:39 Subject: [Pdns-users] pdns-recursor doesnt connect to dns root servers To: pdns-users@mailman.powerdns.com Hi everyone! I want to update dns records from root dns servers using pdns-recursor. I already looked around, but I didn't find an solution for my problem: Failed to update . records, RCODE=2 I use a squeeze package: server:~# aptitude show pdns-recursor Package: pdns-recursor State: installed Automatically installed: no Version: 3.2-4 [..] server:~# grep -v ^# /etc/powerdns/recursor.conf | grep -v ^$ allow-from=127.0.0.0/8, 172.16.1.0/24, ::1/128 dont-query= forward-zones=mydomain.org=127.1.2.3 local-address=127.0.0.1,172.16.1.200 local-port=53 log-common-errors=yes quiet=yes setgid=pdns setuid=pdns server:~# tail /var/syslog Dec 20 19:08:29 server pdns_recursor[18538]: PowerDNS recursor 3.2 (C) 2001-2010 PowerDNS.COM BV (Jul 20 2010, 13:06:28, gcc 4.4.4) starting up Dec 20 19:08:29 server pdns_recursor[18538]: 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. Dec 20 19:08:29 server pdns_recursor[18538]: Operating in 64 bits mode Dec 20 19:08:29 server pdns_recursor[18538]: Reading random entropy from '/dev/urandom' Dec 20 19:08:29 server pdns_recursor[18538]: Only allowing queries from: 127.0.0.0/8, 172.16.1.0/24, ::1/128, fe80::/10 Dec 20 19:08:29 server pdns_recursor[18538]: Redirecting queries for zone 'mydomain.org' to: 127.1.2.3:53 Dec 20 19:08:29 server pdns_recursor[18538]: Inserting rfc 1918 private space zones Dec 20 19:08:29 server pdns_recursor[18538]: Listening for UDP queries on 127.0.0.1:53 Dec 20 19:08:29 server pdns_recursor[18538]: Listening for UDP queries on 172.16.1.200:53 Dec 20 19:08:29 server pdns_recursor[18538]: Enabled TCP data-ready filter for (slight) DoS protection Dec 20 19:08:29 server pdns_recursor[18538]: Listening for TCP queries on 127.0.0.1:53 Dec 20 19:08:29 server pdns_recursor[18538]: Listening for TCP queries on 172.16.1.200:53 Dec 20 19:08:29 server pdns_recursor[18538]: Calling daemonize, going to background Dec 20 19:08:29 server pdns_recursor[18539]: Set effective group id to 108 Dec 20 19:08:29 server pdns_recursor[18539]: Set effective user id to 104 Dec 20 19:08:29 server pdns_recursor[18539]: Launching 2 threads Dec 20 19:08:29 server pdns_recursor[18539]: Done priming cache with root hints Dec 20 19:08:29 server pdns_recursor[18539]: Done priming cache with root hints Dec 20 19:08:29 server pdns_recursor[18539]: Enabled 'epoll' multiplexer Dec 20 19:08:54 server pdns_recursor[18539]: Failed to update . records, RCODE=2 Dec 20 19:08:54 server pdns_recursor[18539]: Failed to update . records, RCODE=2 I see it trying to connect to root dns (watch -n 1 lsof -i -n -P|grep pdns) but it only seems to run through a list and never succeeds. server:~# nmap -p53 -sU 202.12.27.33 Starting Nmap 5.00 ( http://nmap.org ) at 2010-12-20 19:23 CET Interesting ports on M.ROOT-SERVERS.NET (202.12.27.33): PORT STATE SERVICE 53/udp open|filtered domain Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds server:~# telnet 202.12.27.33 53 connects So it's not a firewall issue? I think I switched them off. If I change the root domain to an other dns forewarder pdns-recursor runs without errors. But it doesn't use root dns so it's not a fix. forward-zones=mydomain.org=127.1.2.3,.=172.16.1.1 To set .=IP works for all public dns Any help welcome :) ___ 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] Pramod Bodla wants to stay in touch on LinkedIn
Please everybody do not respond ;-) On Wed, Dec 22, 2010 at 04:49:11AM +, Pramod Bodla wrote: LinkedIn I'd like to add you to my professional network on LinkedIn. - Pramod Bodla Pramod Bodla Senior Soft ware Engineer at Kodiak Networks Bengaluru Area, India Confirm that you know Pramod Bodla ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] redirect a search for one site to another site
On Sat, Dec 25, 2010 at 05:13:47PM -0500, Morgan Osborne wrote: The first is 'red.com' with a record type of 'CNAME' and content of 'blue.com' , then the second record is 'blue.com' with a record type of 'A' and the correct IP address of '150.145.15.1' So now when I do a http search for 'red.com' I get to the error site of '150.145.15.1' and not all the way to the site of 'blue.com' Morgan, This is indeed how DNS works. A CNAME works 'behind the scenes'. What you are looking for is a HTTP-level redirect such as a 301 or 302 directive. This will instruct the browser to go 'all the way' to blue.com. For Apache, this is documented on http://httpd.apache.org/docs/current/mod/mod_alias.html 1. I am not inserting the records correctly, or using the wrong record types 2. The CNAME does not send back to the http search the 'blue.com' name so when it gets to site '150.145.15.1' it does not know what to look for (and is probably looking for 'red.com' instead of 'blue.com' and thats why I get the error page) 3. I should not be using CNAME for a redirect, but some other record type 4. or, the Aliases in the record is interrupting the search somehow on '150.145.15.1' '2' is the one you are looking for. Good luck! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns recursor do not always use records in /etc/hosts
On Wed, Dec 29, 2010 at 03:20:13PM +0800, Conan wrote: We know the option export-etc-hosts=on will export records from /etc/hosts to pdns recursor. But I found the records are not always available. Hi Conan, The export-etc-hosts feature is not meant to override the internet, but to supplement it. Hmm, I got the option forward-zones just now. It's much better than export-etc-hosts. But forward-zones is ;-) Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNS Requirements - Packet Type Allowance/Responses/Settings
On Mon, Jan 03, 2011 at 02:27:22PM -0500, Morgan Osborne wrote: Does anyone have a specific list of the required packet types (and response settings) needed for DNS servers to fully operate on the net? I know UDP is a must, but more to the point, are ICMP (ping, tracert) responses required for people/internet browsers to use your DNS? Morgan, This question is not very PowerDNS specific, but the answer is rarely written out anywhere. You will need UDP/53, TCP/53. In addition, you will need to allow UDP fragments, since these are needed in the brave new world of DNSSEC. Also make sure that you can pass UDP answers of 512 bytes. Some firewalls are setup to block these as a security hazard. In order for the fragments to work as intended, you should also have a clear path for ICMP 'need fragment' messages, as these allow for so called Path MTU Probing. And while we are at it, please also add IPv6! With the impending 'ipv4ocalypse', the time to act is now. IPv6 needs some ICMP messages to basically function, so make sure you don't block ICMPv6. So, while you can get away with only allowing 'UDP/53', you'll need all the rest of it to be fully ready for DNSSEC IPv6! Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNSSEC Progress: ready for a first look
Dear PowerDNS Community, With the help of many of you, we've now brought 'PowerDNSSEC' to the point where it might make sense for you to trial it on test domains. We expect to make move some of our own important domains over to PowerDNSSEC early next week. PowerDNS.COM underlies the commercial DNS hosting service 'Express', and may have to wait a bit longer. To test, head over to http://www.powerdnssec.org (which of course is powered by PowerDNSSEC). More information is on http://wiki.powerdns.com/trac/wiki/PDNSSEC - including how to get started, and how to get help. In brief, PowerDNSSEC will allow you to continue operating as normal in many cases, with only slight changes to your installation. There is no need to run signing tools, nor is there a need to rotate keys or run scripts. Particularly, if you run with Generic MySQL, Generic PostgreSQL or Generic SQLite3, you should have an easy time. A small schema update is required, plus an invocation of 'pdnssec secure-zone domain-name pdnssec rectify-zone domain-name' per domain you want to secure. And that should be it. Supported are: * NSEC * NSEC3 in ordered mode (pre-hashed records) * NSEC3 in narrow mode (unmodified records) * Zone transfers (for NSEC) * Import of 'standard' private keys from BIND/NSD * Export of 'standard' private keys * RSASHA1 * Pure PostgreSQL, SQLite3 MySQL operations * Hybrid BIND/PostgreSQL/SQLite3/MySQL operation To join the fun, download the tarball which can be found on the sites above, and let us know how it works for you! To clarify, we do not recommend taking the current code snapshot into production, but we are getting close. Kind regards, Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Changing replies from PowerDNS
Hi 'abcdef ghijkl' with your newsubdomain.domain.com on dns.comain.com, I'm afraid I can't help you this way. Please provide real domain names and IP addresses. You might want to consider upgrading to 2.9.22. Bert On Mon, Jan 10, 2011 at 01:00:46PM +0100, abcdef ghijkl wrote: Hello everyone, I use PowerDNS with mysql backend (from debian package version 2.9.21). Sometimes I have problem with recently added subdomains. As you can see below, my DNS server in one request replies with 2 opposite information (resolved correct IP and domain non exists). In effect, subdomain looks for application like it's not exists. r...@domain:~# host newsubdomain.domain.com dns.domain.com Using domain server: Name: dns.domain.com Address: 1.1.1.1#53 Aliases: newsubdomain.domain.com has address 1.1.1.1 Host newsubdomain.domain.com not found: 3(NXDOMAIN) r...@domain:~# After ~1 hour (nothing has been changed): r...@prymus:~# host newsubdomain.domain.com dns.domain.com Using domain server: Name: dns.domain.com Address: 1.1.1.1#53 Aliases: newsubdomain.domain.com has address 1.1.1.1 r...@domain:~# Now, everything is ok. This happens quite random a few times in 2 weeks after creating subdomain and later everything is ok (probably). Where I should start my research to resolve this quite strange problem? Best Regards. ___ 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] problem with one specific dns name
On Tue, Jan 18, 2011 at 11:12:19AM -0800, dialsc wrote: www.vggr.ch has been registered as a cname record pointing to vggr.ch which is an A type record. randomly one or more powerdns servers are unable to resolve www.vggr.ch. once i restart the recursor of the server having this problem, www.vggr.ch can be resolved as it should be. At the CH servers, things are configured correctly: vggr.ch.3600IN NS ns2.serverdns.ch. vggr.ch.3600IN NS ns1.serverdns.ch. ;; Received 107 bytes from 194.146.106.10#53(f.nic.ch) in 53 ms However, over at ns1.serverdns.ch, these four new nameservers are added, and they all don't work. www.vggr.ch.14400 IN CNAME vggr.ch. vggr.ch.14400 IN A 193.27.218.57 vggr.ch.86400 IN NS ns.ch-datacenter.com. vggr.ch.86400 IN NS ns.us-datacenter.com. vggr.ch.86400 IN NS ns2.ch-datacenter.com. vggr.ch.86400 IN NS ns2.us-datacenter.com. ;; Received 224 bytes from 193.27.218.150#53(ns1.serverdns.ch) in 88 ms anybody got an idea what the problem could be? I suggest fixing the nameserver records over at ns1.serverdns.ch ;-) good luck! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Recursor: Different answers for the same query
On Wed, Jan 26, 2011 at 10:32:19AM +0100, Christian Kuehn wrote: any idea why the pdns-recursor 3.3 gives different answers to the same query?? Hello!! ;-) You probably run with threads=2, and one of the threads has had problems resolving cecilmen.se, and the other hasn't. 3.3.1 which will be released soon tries a bit harder to resolve domains when timeouts happen, which should reduce this from happening. But at the root, there is no bug needed to explain what you are seeing. Bert tks@tks:~$ dig ns cecilmen.se ; DiG 9.7.0-P1 ns cecilmen.se ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 24828 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;cecilmen.se. IN NS ;; ANSWER SECTION: cecilmen.se. 86126 IN NS pns.dtag.de. cecilmen.se. 86126 IN NS secondary000.dtag.net. ;; ADDITIONAL SECTION: pns.dtag.de. 86373 IN A 194.25.0.125 secondary000.dtag.net.84792 IN A 195.244.245.7 ;; Query time: 0 msec ;; SERVER: 212.1.60.5#53(212.1.60.5) ;; WHEN: Wed Jan 26 10:28:49 2011 ;; MSG SIZE rcvd: 121 tks@tks:~$ dig ns cecilmen.se ; DiG 9.7.0-P1 ns cecilmen.se ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 30008 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;cecilmen.se. IN NS ;; Query time: 0 msec ;; SERVER: 212.1.60.5#53(212.1.60.5) ;; WHEN: Wed Jan 26 10:28:49 2011 ;; MSG SIZE rcvd: 29 Looks like a bug?? Cheers Christian -- Christian Kühn (Technical Consultant) == MCS MOORBEK COMPUTER SYSTEME GmbH Essener Bogen 17 - 22419 Hamburg - Germany Tel +49 (0)40 53773 0 - Fax: +49 (0)40 53773 200 E-Mail: christian.ku...@mcs.de Web: http://www.mcs.de Eingetragen im Handelsregister Hamburg B62933 Geschäftsführer: Kai Brandes Eckard Kabel GPG 8B52 41A1 4B8F 4DE7 9064 2073 6168 137A 3DDA 0F36 == ___ 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] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Fri, Jan 28, 2011 at 12:27:13AM +0100, Detlef Peeters wrote: On 27.01.2011 23:37, bert hubert wrote: (the short version, there is a snapshot worth looking at, packages on http://powerdnssec.org/downloads - documentation on http://powerdnssec.org ) I have upgraded to the snapshot on a CentOS5 i386 machine from 2.9.22 and have a problem to resolve external domains via PowerDNS-Recursor. I'm using the same configuration with PDNS 2.9.22 without problems. I can confirm this issue, apologies. The new DNSSEC code does not do Recursor handoff yet. This area has typically been problematic in case of mixed answers (question for a zone in PowerDNS, but it contains a CNAME to a zone not in PowerDNS, for example). DNSSEC is unlikely to ease this situation, but let's see what can be done. Have I to change something in the configuration? You can always wonder if it is advantageous to run in mixed recursor/auth mode. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, Jan 29, 2011 at 10:30:47AM +0100, Christof Meerwald wrote: On Sat, 29 Jan 2011 00:38:12 +0100, Christof Meerwald wrote: That's really excellent news - I have just migrated my 2 nameservers to SVN revision 1928 and signed one of the zones (btw, the setup is: master using bind backend for the zone data and gsqlite3 for the key data - slave is using gsqlite3 and AXFR from master). Let's see what happens... Hmm, I still don't understand DNSSEC well enough to really make some sense of it all, but there are certainly some strange things here: Indeed. The zone I am testing with is cmeerw.priv.at, master dns is ns.cmeerw.net and slave is ns2.cmeerw.net (and trying to use nsec3). Ok, so the setup is that both ns and ns2 have all the keying materials, and ns serves a pre-signed zone over AXFR. ns2 receives this AXFR, should rectify it and serve it using its knowledge of the private keying material. Note: what HAS been tested is where the slave has no keying material, and serves the zone in 'pre-signed' mode. This is not what you are doing, but it should still work! Requesting the SOA record appears to work fine on both servers: dig +dnssec -t SOA cmeerw.priv.at @ns.cmeerw.net dig +dnssec -t SOA cmeerw.priv.at @ns2.cmeerw.net Looks good. But if I try to query for NS, I get some RRSIG records in the additional section, but only from ns.cmeerw.net: ;; ADDITIONAL SECTION: ns2.cmeerw.net. 28800 IN A 80.190.133.60 ns2.cmeerw.net. 28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. mKFWS0sPy8sFs4kWGgs0dvniiDAGzpgxPw/LgsCZ88r/k9Lc/+6pHK8k nkh9QzshTFkHKfIsM5NBr8ABRMPSligLc+t6Qb2B3P+Sfz3kVoW1baoS VTJAjkbMzTa5uD/HD6C0qX3KdMy4wxOq8YZAHislWkuNydCcM+/vGmBt fvo= ns.cmeerw.net.28800 IN A 84.200.12.152 ns.cmeerw.net.28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. kfoB3v8GYzdKJ6afJR81msJ2AKGNQ/7HIsS50ISphbWqUK5UrLDe5kno s1L8JoshcXxUyxcMl2s4SaJX3h+ImFsact8Xunl8fl+AwSJJrbHd4Dsb M1OhxfpTaEHzvBgX/nR0Xam52xBm5ruqOL26mRZjjhbUqlSI21IbP9O6 UEY= This is a bug, which will be fixed in the next commit. PowerDNS does not realize it should not be signing stuff added to a record from an insecure zone. not from ns2.cmeerw.net: ;; ADDITIONAL SECTION: ns.cmeerw.net.28800 IN A 84.200.12.152 ns2.cmeerw.net. 28800 IN A 80.190.133.60 Note that both servers are authoritative for cmeerw.net, but the zone is not signed. I bet ns.cmeerw.net has not been rectified on ns2.cmeerw.net. Even unsigned zones should be rectified! This should be automated in some way perhaps. And finally, if I try to query a non-existing record, the response seems reasonable from ns.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB SO== RRSIG No, this means that you have an NSEC3 configuration, but the 'order' field from the database has not been filled out. This is very weird since you tell me that ns.cmeerw.net runs with the BIND backend, which should do all that automatically. This smells like a separate bug. Can you confirm that ns.cmeerw.net has the cmeerw.priv.at zone in BIND, and can you show the output of 'pdnssec show-zone cmeerw.priv.at'? but very strange from ns2.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN NSEC3 1 0 1 AB RRSIG=== NSEC3 This looks about as strange. This might be a follow-up bug fom what you see on ns.cmeerw.at, let's focus on that first. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNSSEC and Master/Slave setup
On Thu, Feb 03, 2011 at 08:44:08AM +0100, Christof Meerwald wrote:
I kind of expected this to happen today - the master (ns.cmeerw.net)
with the keying material has now updated the RRSIG records, but the
slave (ns2.cmeerw.net, no keying material) still returns the old RRSIG
records:
Indeed, this is an issue we've been pondering for a while now. OpenDNSSEC,
and dnssec-signzone all deal with it in some way.
; DiG 9.7.1-P2 +dnssec -t soa cmeerw.priv.at @ns2.cmeerw.net
;; ANSWER SECTION:
cmeerw.priv.at. 28800 IN RRSIG SOA 8 3 28800
2011021000 2011012700 9895 cmeerw.priv.at.
b6IVcHFLnJvuL1T+OVXDDiuPOPbooVgpNHw8SI21cXoo2Q2v89+UQd7+
H/SVjFYPL5RLjyCIcGWIJOrx5Wssg8vqbVqvkaG/AGmyZqhu5S5dVo1b
ipK32UrcYrsknkYmzYaHD3ew2ka9hwZYND5MK+g3FNAJxnj3fJEiHEvG Lzo=
cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net.
domain.cmeerw.net. 2010080601 3600 900 1814400 3600
Is there any better solution than having to run a script each week on
the master server to update the SOA serial number and reload the zone
(so the slave gets notified of the change and does an AXFR)?
This will obviously have to be automated, but we're not sure how. The more
general case is where PowerDNS operates like OpenDNSSEC, as a 'signing
proxy'. In this case there is an 'original serial' from the unsigned master,
which tells us when the original changed.
Secondly, there is the 'signed serial' which will have to change once a week
at least, but also whenever the 'original serial' changes.
In your case, where PowerDNS merely does the signing, things are a bit
simpler, but stil not trivial.
We obviously need to come up with something smart! Thinking out loud a bit.
A problem is that the SOA serial is 32 bits, and often filled out like this:
4294967296
2011020300 .. 2011020301 .. 2011020302 etc
This means that if we do the 'obvious' and leave the first six digits alone,
we can only do 99 increments, which is not enough by a long shot.
However, '20110203' only encodes a day number, and there have been 15008
days since the beginning of the epoch. What we could do is convert a
'date-formed SERIAL' to a more compact form, and leave loads of room for
autincrementing the serial.
So 2011020312 ('the 12th increment on the 3rd of February 2011') could be
converted to:
3AA00Cnn
This still only gives us 256 increments before things turn nasty.
Ideas?
I prefer a solution where we don't actually increment the serial in the
database but overlay it with something that autoincrements ('weeks since
january first 2011').
Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] signingpipe.hh not in snapshot 1964
On Thu, Feb 03, 2011 at 09:25:04PM +0100, M Techter wrote: being interested in DNSSEC support of pdns, I tried to build from the pdns-3.0-pre.20110202.1964 Good catch - we fixed the issue in SVN already. Meanwhile, http://powerdnssec.org/downloads/pdns-3.0-pre.20110203.1972.tar.gz is available with this other fixes. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PDNS Recursor on Debian / Low performance !!!URGENT!!!!
On Mon, Feb 07, 2011 at 09:17:29AM +, Maroon Ibrahim wrote: As for the file descriptors, I already added the following: - in sysctl.conf : fs.file-max = 65535 - in /etc/init.d/pdns-recursor #!/bin/sh # chkconfig: - 80 75 # description: pdns_recursor is a versatile high performance recursing nameserver ulimit -HSn 65536 How can I know that the above settings are working? with squid for example, I can know by doing squidclient -p port mgr:info Before a test-run, and then afterward, can you run: rec_control get-all And mail the output? So run it twice, once before, once after. This will let us know what is limiting your performance. My best guess is something in your network. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] AXFR problem with pdns snapshots
On Mon, Feb 07, 2011 at 10:24:53PM +0100, Christof Meerwald wrote: Ok, think I have found it - Microsoft DNS doesn't seem to like the EDNS options in the AXFR packets. Guess that's why it says WRONG in tcpreceiver.cc, line 410... Our EDNS-in-AXFR has been brought in line with RFC 5936 now. I hope this solves your problem! See http://wiki.powerdns.com/trac/changeset/1994 - new packages are building now for http://powerdnssec.org/downloads. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] query on --out-of-zone-additional-processing
On Fri, Feb 11, 2011 at 10:32:45AM +, Tom Boland wrote:
Do out of zone additional processing. This means that if a malicious
user adds a '.com' zone to your server, it is not used for other
domains and will not contaminate answers. Do not enable this setting
if you run a public DNS service with untrusted users. Off by default.
My question is this. The description indicates that setting this to
yes would prevent malicious use of your public authoritative DNS
server with untrusted users (such as in our hosting company), but
then goes on to say that you shouldn't enable this setting if you
run a public DNS service with untrusted users? Could someone please
clarify this?
Hi Tom!
The description is indeed off. It should say:
If enabled, data from other zones may be included in the additional
section of answers. If disabled and a malicious user adds a '.com' zone
to your server, it is not used to look IP addresses for MX records and
NS records. Do not enable this setting if you run a public DNS
service with untrusted users. Off by default.
However, it turns out that even this is not actually enough, since
'additional-processing' does not include CNAME resolution, and I bet this is
what you are referring to ;-)
So CNAMEs to 'other customer generated records' will still involve 'public
supplied data'. And as we saw yesterday, this can confuse the internet.
Reading the source, it appears that this is not trivial to fix, and may be
post-3.0 ('PowerDNSSEC').
So, thanks for pointing out the error in the documentation, and apologies
that we don't in fact do what you need (right now).
Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNS Tickets are being processed, please check the status of yours
Dear PowerDNS users, As of yesterday, 103 tickets were open in the PowerDNS bugtracker, available on http://wiki.powerdns.com/trac/report/1 Today, 87 are left. As most tickets have been filed anonymously, if you ever created one, please check our timeline on http://wiki.powerdns.com/trac/timeline?from=02/14/11daysback=3ticket=onupdate=Update to see what happened to yours. In addition, if nothing happened to your ticket, feel free to check if your problem has been resolved in the latest 3.0 prereleases, available on http://powerdnssec.org/downloads . Please update the status of your ticket if this is the case! Finally, we also welcome reports of 'fixed' issued that turn out not to have fixed your problem. For your convenience, here is a list from the 'trac' URL above with everything that got modified today. Thanks! 17:22 Ticket #300 (packetcache does not decrease TTLs) closed by ahu fixed: It does! 17:20 Ticket #277 (packetcache-ttl default values) closed by ahu invalid: The packetcache is TTL aware, so it will not cache shorter TTLd answers … 16:34 Ticket #327 (signed/unsigned bug in StatBag leads to wrap-around issues with counters) closed by ahu fixed: Fixed slightly differently in commit 2019, thanks! 16:21 Ticket #257 (pdns-static deb + gmysql = fail?) closed by ahu fixed: This indeed happens on some architectures, the static deb is rather old. … 16:19 Ticket #314 (Pipe backend doesn't allow a priority specification for SRV records) closed by ahu fixed: Fixed, thanks. 16:18 Ticket #208 (Patch to add new configure functionality) closed by ahu fixed: Fixed differently. 16:17 Ticket #230 (bind backend axfr possible scope race condition for MX) closed by ahu fixed: Fixed - this was a zoneparser bug. 16:16 Ticket #266 (dnsscope compilation problem) closed by ahu fixed: Fixed in svn. 16:15 Ticket #166 (BIND backend support for 'allow-query' ACL to restrict zone lookups by ...) closed by ahu wontfix: While I'm grateful for the effort, this would mess up our code too badly … 16:09 Ticket #216 (Proposed also-notify support) closed by ahu fixed: This has been fixed differently in 3.0 via the domainmetadata table, which … 16:08 Ticket #177 (Auth. server has poor TCP performance.) closed by ahu fixed: Something similar has been merged, thanks! 16:07 Ticket #202 (pdns 2.9.21.1 compile failure on HP-UX 11.11) closed by ahu wontfix: See 201. 16:07 Ticket #201 (several compilation errors on HP-UX) closed by ahu wontfix: Thanks - I'm afraid these patches no longer apply to 2.9.22+ and we have … 16:06 Ticket #334 (Auto-splitting long TXT records doesn't work) closed by ahu fixed: Has been fixed in 3.0 because of the 'jp_mens zone from hell'. 16:03 Ticket #280 (Typo in anti-spam anon credentials) closed by ahu invalid: The wording is rather precise, I have to admit, but it is correct on the … 16:01 Ticket #144 (Feature-Request also-notify) closed by ahu fixed: Done in 3.0. 15:59 Ticket #284 (PowerDNS compilation errors on gcc 4.4) closed by ahu fixed: Fixed in 3.0, thanks. 15:57 Ticket #329 (pdns_server can not bind to IPv6 link-local addresses) closed by ahu fixed: Fixed in 3.0! 15:34 Ticket #56 (Better IPv6 support) closed by ahu fixed: Fixed differently in 3.0, thanks! 15:33 Ticket #98 (Patch for slaving over IPv6) closed by ahu fixed: Fixed differently in 3.0, thanks. 15:32 Ticket #211 (Support for masters on non-standard ports) closed by ahu fixed: Fixed differently in 3.0 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNS and pgbouncer
On Mon, Feb 14, 2011 at 02:45:43PM -0600, Mark Felder wrote: Is there any connection pooling work done by PowerDNS that would negate any possible performance benefits of pgbouncer? Hi Mark, During typical PowerDNS operation, you will see a number over very longlived database connections, plus a smaller number of briefer connections (for zonetransfers for example). So indeed, pgbouncer probably does not lead to a lot of benefit for PowerDNS. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Zone transfer MX record issue
On Mon, Feb 21, 2011 at 02:15:26PM +0800, p8x wrote: zone transfer from the primary PowerDNS seems to mangle the records slightly replacing occurrences of the domain with an @ in some cases. This seems to work for all of the records except for the MX record. As an example, here is a copy of the domain from the primary server (please note: the domain is not actually test.com, a quick sed was done): Hi 'p8x', This is a known bug in the BIND backend of 2.9.22, it is solved in 3.0 which will be released shortly. From the release notes: Aki Tuomi discovered that the BIND zonefile parser would misrepresent 'something IN MX 15 @'. Fix in commit 1621. http://wiki.powerdns.com/trac/changeset/1621 Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stuck tcp sessions on recursor
On Thu, Feb 24, 2011 at 01:33:24PM -0500, Charles Sprickman wrote: Simon Bedford, Brad Dameron and Laurient Papier discovered relatively high TCP/IP loads could cause TCP/IP service to shut down over time. Addressed in commits 1546, 1640, 1652, 1685, 1698. Additional information provided by Zwane Mwaikambo, Nicholas Miell and Jeff Roberson. Testing by Christian Hofstaedtler and Michael Renner I was scanning for stuck in CLOSED and similar stuff. I'll try 3.3 and see how that goes, thanks! this definitely sounds like 3.3 material! Bert (PowerDNS) ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stuck tcp sessions on recursor
On Thu, Feb 24, 2011 at 03:06:12PM -0500, Charles Sprickman wrote: this definitely sounds like 3.3 material! So far so good, nearly 500,000 tcp queries without any lingering sockets. Good! Totally unrelated, but I see a stat that's not mentioned in the docs: no-packet-error 492682. What is that, and is it any cause for concern? It is a debugging metric we added to see if our event multiplexing infrastructure is operating as well as it could. Can you give me the output of 'rec_control get-all' after some time of operation? It is probably of no concern, but it might waste some CPU cycles. Probably no-packet-error is a lot smaller than your number of questions and outqueries. I'm really happy with the recursor so far, we previously used dnscache and we're seeing about 1/5 the cpu usage and I believe we're also answering queries that we weren't before - our overall qps went up quite a bit after the switch. great! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Format of private keys in PowerDNSSEC (gmysql) doesn't correspond to BIND's
On Thu, Feb 24, 2011 at 05:44:01PM +0100, Maik Zumstrull wrote: As noted in the comment, I'm not sure whether this small error is on PDNS' part or in ldns, but an example in RFC 5702 suggests BIND's format is correct. As far as I can tell, this private key format has no formal specification. The only reference appears to be the BIND source code. We now output that exact format, so the problem should be gone. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] authoritative server freezes while processing NOTIFYs
On Wed, Feb 16, 2011 at 10:53:05AM +, Richard Poole wrote: We have a setup with a non-public master and two publicly visible slaves. All three servers are using the bind backend. Sometimes we need to change many zones, say about 2000, at the same time, causing the master to send out 2000 NOTIFYs to the slaves. We find that while they're processing them and doing the corresponding zone transfers from the master, they frequently stop replying to incoming queries for several seconds at a time. Has anyone else seen this? Is it something we can fix by different Hmm, this was not the original design. configuration, or a consequence of having a lot of simultaneous NOTIFYs being processed, or a consequence of using the bind backend? The BIND backend is somewhat special in that an incoming AXFR is first spooled to disk, and then reloaded from that same disk. However, the BIND backend is also fully multithreaded and should not generally stop answering questions in that case, except for zones in fact being reloaded, and even those should only suffer a brief interruption. We are running with retrieval-threads=1 and distributor-threads=1 - I can give the rest of our conf if anyone thinks it's relevant but most of it is left at defaults. There is probably some dynamic going on between various parts of PowerDNS. If I recall correctly you run with a truly staggering amount of zones on the BIND backend, which may have something to do with it. If at all possible I'd like to reproduce your problem, and will contact you off-list. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Malformed messages when not in cache
On Fri, Mar 04, 2011 at 07:38:36PM -0500, Kevin O'Connor wrote: We have a record set up with the BIND backend as follows: testing IN CNAME gci-prod-lb-0.us-east-1.elb.amazonaws.com. When you query it right after a service restart, you get: Wow, that is weird. Can you setup an isolated reproduction? So a pdns.conf, named.conf and a zonefile that reproduces the problem? And ship that to me? I've setup a domain.com zone that is similar to what you report, and it works fine here. This of course does not mean that I don't believe you, but I also can't solve your problem. should reduce its occurrence. Are there any other ways to work around this at the moment? And more importantly, do I have the issue identified correctly? I don't want to just be waiting for 3.0 hoping that will fix the problem when really it's something silly I've missed. Once you have a reproduction case, we can tell. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Mongo DB and Powerdns
On Mon, Mar 14, 2011 at 07:34:15PM +0100, Jan-Piet Mens wrote: To my knowledge there is no such back-end. What I have done is a PowerDNS pipe back-end to CouchDB. Performance is lousy of course, but I did it as a proof of concept, and it works ok. I've written about it at If the performance is lousy, it is not due to the pipe backend. People run it at very very high query rates. There is no reason why a pipe should be slower than (say) a TCP/IP socket to MySQL. I am aware of several native CouchDB backends, but none has been released pubicly as far as I know. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns-server, DNS-SD and \032 in record labels
On Fri, Mar 18, 2011 at 09:33:39PM +, Andy Smith wrote: So it seems to me that there are multiple places here that can't handle \032 in a query name or in a record label. Just changing backend is not going to get this working for me, right? Andy, Can you try to reproduce the issue with the 3.0 snapshots available linked from http://powerdnssec.org? We fixed a bunch of issues in this area, so it might just work. If it doesn't, fixes are likely to be forthcoming only for 3.0. Please let us know! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] [gmysql] How about add CLIENT_MULTI_RESULTS to smysql.cc ?
On Mon, Mar 21, 2011 at 08:35:15AM +0100, Sandro Tosi wrote:
Anyone has comment on this patch? Is there a better place I can send
it for review and (possible) inclusion?
Hi Sandro,
It has been added to revision 2084, which can be downloaded from
http://powerdnssec.org/snapshots/
It will also be part of the 3.0 release.
Thanks!
Regards,
Sandro
On 03/08/2011 04:44 PM, Sandro Tosi wrote:
Hi,
we're configuring to pdns with a MySQL backend, and using stored
procedures to query the database.
Sadly, we're facing a problem since mysql_real_connect() in smysql.cc
does not have the CLIENT_MULTI_RESULTS argument, needed[1][2] to fetch
multiple rows from a stored proc.
[1] http://dev.mysql.com/doc/refman/5.5/en/c-api-multiple-queries.html
[2] http://dev.mysql.com/doc/refman/5.5/en/mysql-real-connect.html
We're about to apply the attached patch and recompile pdns, but I'd like
to hear from you what do you think about it and if you'd like to
consider it for inclusion in the pdns upstream source code.
Regards,
Sandro
PS: this is a known problem:
http://old.nabble.com/gmysql-backend-and-stored-procedures-td19035294.html
client_multi_results
Index: debian-pdns/modules/gmysqlbackend/smysql.cc
===
--- debian-pdns.orig/modules/gmysqlbackend/smysql.cc 2011-03-08
15:57:20.0 +0100
+++ debian-pdns/modules/gmysqlbackend/smysql.cc 2011-03-08
15:57:45.0 +0100
@@ -20,7 +20,7 @@
password.empty() ? 0 : password.c_str(),
database.c_str(), port,
msocket.empty() ? 0 : msocket.c_str(),
- 0)) {
+ CLIENT_MULTI_RESULTS)) {
throw sPerrorException(Unable to connect to database);
}
@@ -91,6 +91,13 @@
return true;
}
mysql_free_result(d_rres);
+
+ while (mysql_next_result(d_db) == 0) {
+if (d_rres = mysql_use_result(d_db)) {
+ mysql_free_result(d_rres);
+}
+ }
+
d_rres=0;
return false;
}
ATT1.txt
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
--
Sandro Tosi
Product Engineer
Shared Hosting Products
RD | Dada.pro
eml sandro.t...@register.it
___
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
[Pdns-users] Heading up to PowerDNS Authoritative Server release 3.0: please check your open tickets
Dear PowerDNS Community, The big 3.0 release is coming real close, and it is going to be a big one. For the 'work in progress' release notes, please see http://doc.powerdns.com/changelog.html#changelog-auth-3-0 Today around 21 tickets on the issue tracker were either closed or resolved. Most tickets are filed anonymously, so if you entered a ticket, you probably did not receive feedback. So, please check the following list: http://wiki.powerdns.com/trac/timeline?from=03%2F22%2F11daysback=1ticket=onupdate=Update .. to see what happened to your ticket, and if you agree with the result. For your convenience, here is a summary: Ticket #217 (pdns 2.9.22-rc2 cs1316 bindbackend crash upon adding an out-of-zone record) closed by ahu worksforme: Loads was changed there, and it hasn't been reported anymore. We took out … Ticket #220 (Inappropriate case-senstive check on NOTIFY) closed by ahu fixed: sqlite was case sensitive, we fixed that. Should not be a problem anymore. Ticket #149 (zone2sql named.conf parsing error) closed by ahu wontfix: While we could fix this, it is suggested to comment out such troublesome … Ticket #309 (make godbcbackend compile again) closed by ahu fixed: Merged in CS2087. Thanks! Ticket #265 (multiple master support does not work in the case the master uses NOTIFY) closed by ahu fixed: This has been fixed in 3.0 - any one of the masters is accepted. Thanks. Ticket #189 (Using new statement prepare question for sqlite3 backend) closed by ahu fixed: Implemented in 2086, thanks! Ticket #96 (PowerDNS doesn't honor RFC1982) closed by ahu fixed: It does now! Since cs 2077. Thanks. Ticket #322 (pdns instance crashes) closed by ahu invalid: Probably due to database overload. Ticket #317 (Logging time switches to UTC with LDAP backend) closed by ahu duplicate: dup of 313 Ticket #313 (ldapbackend sets TZ to UTC but should not) closed by ahu wontfix: we are currently unable to devote time to the LDAP backend. Ticket #260 (LDAP backend doens't try to reestablish connection once lost) closed by ahu wontfix: We are currently unable to fix LDAP issues. Ticket #183 (Changing of default table names in config file) closed by ahu wontfix: This means everybody will have to change his customized sql statements, … Ticket #231 (Patch to support calling mySQL stored procedures) closed by ahu fixed: Applied in cs 2084, thanks! Ticket #298 (AXFR query fail with LDAP backend) closed by ahu wontfix: We are unable to address LDAP issues at this time. Ticket #318 (Master (Notify) functionality with ldap backend) closed by ahu wontfix: We are unable to enhance the LDAP backend. Ticket #323 (powerdns authoritative server with ldap backend hangs when ldap server is ...) closed by ahu wontfix: We are unable to fix LDAP issues. Ticket #321 (@ not recognised as shorthand for this domain in MX) closed by ahu fixed: fixed in 3.0 Ticket #190 (Show detailed error information an error happens in sqlite3 backend) closed by ahu fixed: Closed in commit 2083, thanks! Ticket #288 (recursor fails to restart with old config setting nofork=yes) closed by ahu wontfix: While I appreciate the sentiment, this would lead to heaps of … Ticket #258 (powerdns recursor fails to stop due invalid controlsocket when fork=yes) closed by ahu invalid: --fork is gone in recent versions Ticket #305 (Disable a zone / domain / record) closed by ahu wontfix: To do this, please customize the SQL queries to have an 'active' field. Kind regards, Bert Hubert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] Status of the LDAP backend in 3.0 release
People, Unless something happens, the LDAP backend will move to 'unmaintained' status in the 3.0 release. Please read below for the how and why of this, and what could possibly be done to change this. The brief version is that someone will have to step up to maintain the LDAP backend, or a PowerDNS user will have to fund us to do so. But see below for more background on how PowerDNS development happens. On Wed, Mar 23, 2011 at 10:10:13AM +0200, Nick Milas wrote: I always hope that a developer can sometime provide fixes for these, [LDAP issues] esp. 260 313 which are bugs (and not feature requests). To clarify, PowerDNS development happens because one or more of the following three reasons: 1) We think something has wide utility, or is good for the internet or DNS, and should be in PowerDNS. 2) There are people in the PowerDNS community developing maintaining it. 3) There are end-users with support contracts that need it, or there are end-users willing to fund the development directly. (there are also some other reasons, for example, we sometimes build features for users in return for other things they have done for us, sort of an open source exchange of favours. Part of PowerDNSSEC happened in this way. We also develop quite some things because, frankly, we find them cool) For LDAP, right now none if these things is the case. 1) We don't feel that LDAP is a particularly good or interesting place to store DNS data. It will for example have big problems with PowerDNSSEC because of lack of ordering. 2) We thank Norbert for his years of maintenance, but apparently he feels the same way, or at least has no time. But he did a great job. 3) Finally, nobody has come forward with more than 'hope' that we'd restart work on the LDAP backend (ie, support contracts or funding). If we spend time on LDAP, we don't spend it on something else unless we hire more help. And as long as '3' is not the case, that won't happen. It may be good to realise that almost all big new PowerDNS features (TSIG, (Power)DNSSEC, Lua filtering, DNS64) have been made possible by PowerDNS users funding the development. So, unless something changes, we will only make sure that OpenLDAP keeps compiling, and to merge patches submitted by the community. The documentation will be updated to this effect, and so will the 3.0 release notes. Would it help to request e.g. openldap developers with DNS background (through their mailing list) to possibly show interest in resolving them (since no one in pdns mailing list has volunteered and Norbert has stopped support)? What you are probably seeing is that the level of 'care' for LDAP is not quite there. I don't think the OpenLDAP developers would be interested in maintaining one of their dependencies. So while I feel your pain, and I'm not happy about it, for now this is the way it is going to be, unless someone steps up to either maintain the LDAP backend, or comes up with some funding to do so. Kind regards, Bert Hubert PowerDNS ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] SOA serial number editing on re-signing of a zone / RRSIG changes
On Wed, Mar 23, 2011 at 12:39:42AM +0100, Christof Meerwald wrote: Just wanted to check what the status is on having a PowerDNS master with a non-PowerDNS slave for DNSSEC signed zone - we had briefly discussed this some time ago and I think the slave (if it's not PowerDNS) currently won't do an AXFR when the RRSIG changes (and the SOA won't change automatically). Will this be supported in the 3.0 release? Hi Christof, (Jan Piet), It only took half a week of thinking, apologies for not getting back to you earlier. This feature has now been added. 3.0 is really getting close, so we need to figure out quickly if the solution offered is sufficient for both your needs. The currently implemented adds yet another domain metadata item (how did we ever survive without that table?) called SOA-EDIT. You can set SOA-EDIT to either 'INCEPTION', in which case the SOA serial number will be replaced by MMDD01 of the currently issued RRSIG inception, the one that rolls over each Thursday at midnight GMT. You can also set it to INCEPTION-WEEK, in which case the serial number will be very different, the integral number of weeks since the epoch of the currently issued inception. I'm pondering 'SERIAL-INCREMENT' that will attempt to upgrade the current serial number with the number of weeks that have passed since the original serial number found in the SOA record. So if your original SOA serial number was 2011022701, and the SOA would be requested today, '4' would be added to the serial number, to get 2011022405, which would indicate that the original serial date is still 20110224, but that 4 'small' changes have been made. This gets messy after 100 weeks. Please let me know your thoughts! This code can be found in 2103, which has been uploaded to http://powerdnssec.org/downloads (including 64 bits packages). I hope you can let me know quickly if this hits the mark so we can wrapup 3.0! Good luck! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] current svn crushes...
On Wed, Mar 30, 2011 at 02:36:14PM +0400, Vasiliy G Tolstov wrote: I'm build current svn trunk, something work's fine, but sometimes i get this error: Hi Vasiliy, Can you verify that the crash always starts: pdns[28785]: /usr/sbin/pdns_server-instance(_ZN11GSQLBackend8setFreshEj +0x73) [0x81acd53] Mar 30 14:33:34 monitoring pdns[28785]: /usr/sbin/pdns_server-instance(_ZN17CommunicatorClass12slaveRefreshEP13PacketHandler+0x1a8b) [0x8169c2b] Mar 30 14:33:34 monitoring Here? If it doesn't always start there, can you paste some other traces? Thanks! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] probably fixed Re: current svn crushes...
On Wed, Mar 30, 2011 at 02:59:34PM +0400, Vasiliy G Tolstov wrote: If it doesn't always start there, can you paste some other traces? Thanks! pdns[31390]: /usr/sbin/pdns_server-instance(_ZN17CommunicatorClass12slaveRefreshEP13PacketHandler+0x1a8b) [0x8169c2b] Mar 30 14:52:25 monitoring pdns[31390]: /usr/sbin/pdns_server-instance(_ZN17CommunicatorClass8mainloopEv+0x11c) [0x8175f5c] Mar 30 14:52:25 monitoring Based on your fine debugging traces, I've been able to reproduce the crash, and I solved what I could reproduce in: http://wiki.powerdns.com/trac/changeset/2109 fix crashes reported by Vasiliy G Tolstov and Frank Altpeter - turns out we were handing a copy of the database connection to the master/slave connection.. while we were still using it! New packages are now building. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] error notify master to itself with it's own zone
On Thu, Mar 31, 2011 at 12:10:00PM +0400, Vasiliy G Tolstov wrote: Another problem (may be not related to current trunk..) Received NOTIFY for clodo.ru from 188.127.236.4 which is not a master But pdns on 188.127.236.4 already master for zone clodo.ru ? Why this happened? This is a master notifying itself? bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Status of the LDAP backend in 3.0 release
On Sun, Apr 03, 2011 at 11:44:56PM +0200, Udo Rader wrote: Before promising something I can't keep: yes, I will give my best to fix the issues above and if things go well, it is not unlikely that either I myself or one of our developers will invest some more time into enhancements, but one step after the other. Ok - I'll also be available to answer questions on side effects etc. ETA for the fixes should be in during the coming week- hopefully :-) So chances exist that the fixes can make it into the 3.0 release. RC1 is planned for tomorrow, I expect a further three releases, probably weekly, to iron out issues. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] release date for pdns 3?
On Sun, Apr 03, 2011 at 09:57:47PM +0400, Vasiliy G Tolstov wrote: Hello. Where i can find release date for powerdns 3 ? roadmap in wiki says nothing... The open source plan is always to release when ready ;-) Tomorrow (Monday) will see RC1, I expect three subsequent releases (RC2, RC3 and RC4) before final. I'm aiming for weekly RC's. So tentatively, around a month from now. But a lot depends on what we'll find - so far there is still a trickle of bugs that comes with the increasing amount of users. The more testing things get, the faster it will go! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNS Authoritative Server 3.0 Release Candidate 1 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, Release Candidate 1 of the PowerDNS Authoritative Server 3.0 is available from: http://powerdnssec.org/downloads/pdns-3.0-rc1.tar.gz http://powerdnssec.org/downloads/packages/pdns-static-3.0rc1-1.i386.rpm http://powerdnssec.org/downloads/packages/pdns-static-3.0rc1-1.x86_64.rpm http://powerdnssec.org/downloads/packages/pdns-static_3.0-rc1-1_amd64.deb http://powerdnssec.org/downloads/packages/pdns-static_3.0-rc1-1_i386.deb You are cordially invited to (carefully) test this Release Candidate for correct behaviour. Full release notes, with clickable links, are available from: http://doc.powerdns.com/changelog.html#changelog-auth-3-0 Here is a text-only version: Version 3.0 of the PowerDNS Authoritative Server is a major upgrade. Please refer to Section 1, “From PowerDNS Authoritative Server 2.9.x to 3.0” for important information on correct and stable operation, as well as notes on performance and memory use. Known issues as of RC1 include: * Not all new features are documented yet * Queries for 'empty non-terminals' may give confusing results * We are not 100% convinced all corner cases of NSEC3/NXDOMAIN give correct responses. Common cases function well * DNSSEC has only been benchmarked up to 2000 queries/second but not beyond * A lot more database connections are made and released Version 3.0 of the PowerDNS Authoritative Server brings a number of important features, as well as over two years of accumulated bug fixing. The largest news in 3.0 is of course the advent of DNSSEC. Not only does PowerDNS now (finally) support DNSSEC, we think that our support of this important protocol is among the easiest to use available. In addition, all important algorithms are supported. Complete detail can be found in Chapter 12, Serving authoritative DNSSEC data. The goal of 'PowerDNSSEC' is to allow existing PowerDNS installations to start serving DNSSEC with as little hassle as possible, while maintaining performance and achieving high levels of security. Tutorials and examples of how to use DNSSEC in PowerDNS can be found linked from http://powerdnssec.org. This release has received exceptional levels of community support, and we'd like to thank the following people in addition to those mentioned explicitly below: Peter Koch (DENIC), Olaf Kolkman (NLNetLabs), Wouter Wijngaards (NLNetLabs), Marco Davids (SIDN), Markus Travaille (SIDN), Leen Besselink, Antoin Verschuren (SIDN), Olafur Gudmundsson (IETF), Dan Kaminsky (Recursion Ventures), Roy Arends (Nominet), Miek Gieben (SIDN), Stephane Bortzmeyer (AFNIC), Michael Braunoeder (nic.at), Peter van Dijk, Maik Zumstrull, Jose Arthur Benetasso Villanova (Locaweb), Stefan Schmidt, Roland van Rijswijk (Surfnet), Paul Bakker (Brainspark/Fox-IT), Mathew Hennessy, Johannes Kuehrer (Austrian World4You GmbH), Marc van de Geijn (bHosted.nl), Stefan Arentz and Martin van Hensbergen (Fox-IT), Christof Meerwald, Detlef Peeters, Jack Lloyd, Frank Altpeter, frederik danerklint, Vasiliy G Tolstov, Brielle Bruns, Evan Hunt, Ralf van der Enden. On to the release notes. Next to DNSSEC, other major new features include: * TSIG for authorizing and authenticating AXFR requests incoming zone transfers (Code in 2024, 2025, 2033, 2034). This allows for retrieving TSIG protected content, as well as serving it. * Per zone also-notify. * MyDNS compatible backend, allowing for 'instantaneous' migration from this authoritative nameserver. Code in commit 1418, contributed by Jonathan Oddy. * PowerDNS can now slave zones over IPv6 and notify IPv6 remotes of updates. Already. Code in commit 2009 and beyond. * Lua based incoming zone editing, allowing masters or signing slaves to add information to the zone they will (re-)serve. Implemented in commit 2065. To enable, use LUA-AXFR-SCRIPT zone metadata setting. * Native Oracle backend with full DNSSEC support. Contributed by Maik Zumstrull, then at the Steinbuch Centre for Computing at the Karlsruhe Institute of Technology. * Also-notify support, implemented by Aki Tuomi in commit 1400. Support for Generic SQL backends and for the BIND backend. Further code in commit 1360. * Support for binding to thousands of IP addresses, code in commit 1443. * Generic MySQL backend now supports stored procedures. Implemented in commit 2084, closing ticket 231. * Generic ODBC backend compiles again, and is reported to work for some users that need it. Code contributed in ticket 309, author unknown. * Massively parallel slaving infrastructure, able to check the freshness of thousands of remote zones per second, plus perform many incoming zone transfers simultaneously. Sponsored by Tyler Hall, code in 1449, 1500, 1859 * Core DNS logic replaced completely to deal with the brave new world of DNSSEC. Bugs fixed: * sqlite2 and sqlite3 backends used
Re: [Pdns-users] PowerDNS Authoritative Server 3.0 Release Candidate 1 available
Thank you Kees! In addition, Kees spotted that RC1 would not find the postgresql libraries automatically on RHEL5/6, this has been fixed in cs 2144: http://wiki.powerdns.com/trac/changeset/2144 Bert On Tue, Apr 05, 2011 at 08:57:53AM +0200, Kees Monshouwer wrote: Hello all, RHEL/CentOS 5 and 6 rpms of Release Candidate 1 are available from: http://www.monshouwer.eu/download/3th_party/pdns-server/el5/rc/ http://www.monshouwer.eu/download/3th_party/pdns-server/el6/rc/ required lua rpms for RHEL/CentOS 5: http://www.monshouwer.eu/download/3th_party/lua/el5/ Regards, Kees On 4-4-2011 16:50, bert hubert wrote: Hi everybody, Release Candidate 1 of the PowerDNS Authoritative Server 3.0 is available from: http://powerdnssec.org/downloads/pdns-3.0-rc1.tar.gz http://powerdnssec.org/downloads/packages/pdns-static-3.0rc1-1.i386.rpm http://powerdnssec.org/downloads/packages/pdns-static-3.0rc1-1.x86_64.rpm http://powerdnssec.org/downloads/packages/pdns-static_3.0-rc1-1_amd64.deb http://powerdnssec.org/downloads/packages/pdns-static_3.0-rc1-1_i386.deb You are cordially invited to (carefully) test this Release Candidate for correct behaviour. ___ 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] General DNS questions...
On Thu, Apr 07, 2011 at 10:14:31PM -0400, Mohamed Lrhazi wrote: I hope you guys don't mind a couple of non pdns specific questions... For once ;-) - When you declare 2 or 3 NS records for your domain, does the order of those names correlate with their usage? by that I mean can I expect a bigger percentage of traffic to go to ns1, compared to ns2? No, this is perfectly distributed. - How does that load translate in practice when you declare three, and how about four or five? do these extras even get used at all? They do. - What free tools are there to use to test the latency, response quality, and stress load, a DNS server? Response quality can be determined against a 'reference' implementation using dnsreplay http://doc.powerdns.com/analysis.html Latency can be measured using dnsscope described on the same page. Alternatively, for resolvers within PowerDNS there is also the tool 'dnsbulktest' (undocumented, only available from Subversion) which can consume the Alexa 'top 1 million' list, available from http://www.alexa.com/topsites and check their resolution status. Stress load can also be generated using the excelent dnsperf and resperf tools from Nominum, http://www.nominum.com/resources/measurement-tools Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Recursor v3.2 and v3.3 malformed answer in case of big response from authoritative
On Mon, Apr 11, 2011 at 04:53:16PM +0200, Thor Spruyt wrote: Last week I discovered an issue with recursor v3.2. This is probably fixed in 3.3.1: Discovered by John J and Robin J, the PowerDNS Recursor did not process packets that were truncated in mid-record, and also did not act on the 'truncated' (TC) flag in that case. This broke a very small number of domains, most of them served by very old versions of the PowerDNS Authoritative Server. Fix in commit 1740. 3.3.1 has not been formally released, but is in wide production and can be found on http://svn.powerdns.com/snapshots/pdns-recursor-3.3.1.tar.bz2 3.3.1 here resolves auinmeio.com.br|MX just fine, although it takes a stunning 193 packets (!!). However, it does end up delivering a slightly weird answer, which we are investigating (trailing bytes). Can you open a ticket on http://wiki.powerdns.com? thanks! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Recursor v3.2 and v3.3 malformed answer in case of big response from authoritative
On Mon, Apr 11, 2011 at 05:11:41PM +0200, bert hubert wrote: On Mon, Apr 11, 2011 at 04:53:16PM +0200, Thor Spruyt wrote: Last week I discovered an issue with recursor v3.2. Hi Thor, Thanks! You've uncovered an interesting bug which was quite devious. It has been solved in http://wiki.powerdns.com/trac/changeset/2150 The problem was that powerdns would indeed try to serve infinitely large answers over TCP/IP, even though TCP/IP answers are still limited to 65KB. However, since yesterday the domain auinmeio.com.br appears to have developed its own problems, so it still does not resolve, but for a new reason. It looks like it is just broken. Can you verify using http://svn.powerdns.com/snapshots/pdns-recursor-3.4-pre.tar.bz2 ? Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns_recursor 3.3-hooks ... possible cache issue
On Wed, Apr 13, 2011 at 11:53:35AM -0700, Alfred B. M. Cordero wrote: Using the postresolve hook in lua to alter TTL that are too low. I log queries that hit the lua code and I see log events for that same host that occur within the same one second period and sometimes within a few or more seconds. I don't understand why there are multiples. Shouldn't they be cached and then served from the cache? Hi Alfred, Try reproducing with 'threads=1'. You may be seeing hits from multiple separate caches. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns_recursor 3.3-hooks ... possible cache issue
On Thu, Apr 14, 2011 at 09:40:58AM -0700, Alfred B. M. Cordero wrote: On Wed, 13 Apr 2011 12:11:34 -0700 bert hubert bert.hub...@netherlabs.nl wrote: Try reproducing with 'threads=1'. You may be seeing hits from multiple separate caches. You are telling me that each thread maintains its own cache. I restarted with threads=1 but I still see the same. Ok - in that case it may be good to know that the output of the Lua scripts is only cached in the packet cache, and not within the main dns cache. So whatever TTL you set, the result will not be cached for longer than packetcache-ttl seconds. And only for *exactly* identical questions. Perhaps this clarifies the situation? Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
