Re: [Pdns-users] Possible bug observed in PowerDNS Recursor 3.2.1
On Thu, 2010-08-05 at 11:55 +0100, K Storbeck wrote: Hello all, We've been experiencing the problem too, on 3.2. NB: As far as I know, there is no 3.2.1 version: http://downloads.powerdns.com/releases/ does not list such a version. Stop assuming it exists :) You're right, my bad, I installed it using the RPM and misread the version number when I reported this. :-) -- Nuno Nunes (nuno.nu...@optimus.pt) Tel: 351931003485 | Fax: 351931023485 Edifício Optimus Av. D. João II - Lt. 1.06.2.4 1990-095 Lisboa Portugal ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] Manual AXFR works, automatic does not
Hi all, I am having this problem for quite some time now. I have rechecked the configuration many times, but I'm confident it is accurate. I have installed two nameservers, ns1.domain.com and ns2.domain.com. The first is a super-master server. I use the Debian PowerDNS 2.9.22 package, and only added settings to /etc/powerdns/pdns.d/ ns1 (super-master) configuration: gmysql-host=127.0.0.1 gmysql-user= gmysql-password=X gmysql-dbname= master=yes --- Note: in docs "on" is mentioned. It seems both work. slave=no local-address=95.215.63.212 query-local-address=95.215.63.212 setuid=pdns setgid=pdns allow-axfr-ips=84.243.213.33 disable-axfr=no slave-cycle-interval=60 ns2 (slave) configuration: launch=gmysql gmysql-host=XXX gmysql-user=XXX gmysql-password= gmysql-dbname= local-address=84.243.213.33 query-local-address=84.243.213.33 slave=yes setuid=pdns setgid=pdns and one row on supermasters table on slave: ip: 95.215.63.212 nameserver: ns2..com (refers to slave itself) I am running some domains on the master server. I did install the slaveserver, and shutdown the master-server and slaveserver. Then, I started the slave-server, and thereafter, started the master-server. I would expect the master server to start sending notifications about the domains to the slaveserver, but this is not happening, not even after 15 minutes. This makes the slave respond Not authoritative for . for each domain, whereas the master-server is, of course, working fine. The only solution is to manually issue the "notify DOMAIN" command for each domain. That is not a workable setup. Why is the slave not automatically notified? Thanks for your help! p.s. Company name of client is blank to make sure Google won't index it. -- With kind regards / Met vriendelijke groet, Pierre van den Oord LikeFiction Kleyn Proffijtlaan 49 2343 DB Oegstgeest The Netherlands T +31 (0)85 7850699 (Mo-Fr 10-17, GMT +1) T +31 (0)6 12469791 (Mobile) M i...@likefiction.com W www.LikeFiction.com --- Please include the original message when you reply! --- ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] anual AXFR works, automatic does not (txt-version)
Hi all, (Text-version instead of previous HTML, sorry for that) I am having this problem for quite some time now. I have rechecked the configuration many times, but I'm confident it is accurate. I have installed two nameservers, ns1.domain.com and ns2.domain.com. The first is a super-master server. I use the Debian PowerDNS 2.9.22 package, and only added settings to /etc/powerdns/pdns.d/ ns1 (super-master) configuration: gmysql-host=127.0.0.1 gmysql-user= gmysql-password=X gmysql-dbname= master=yes --- Note: in docs on is mentioned. It seems both work. slave=no local-address=95.215.63.212 query-local-address=95.215.63.212 setuid=pdns setgid=pdns allow-axfr-ips=84.243.213.33 disable-axfr=no slave-cycle-interval=60 ns2 (slave) configuration: launch=gmysql gmysql-host=XXX gmysql-user=XXX gmysql-password= gmysql-dbname= local-address=84.243.213.33 query-local-address=84.243.213.33 slave=yes setuid=pdns setgid=pdns and one row on supermasters table on slave: ip: 95.215.63.212 nameserver: ns2..com (refers to slave itself) I am running some domains on the master server. I did install the slaveserver, and shutdown the master-server and slaveserver. Then, I started the slave-server, and thereafter, started the master-server. I would expect the master server to start sending notifications about the domains to the slaveserver, but this is not happening, not even after 15 minutes. This makes the slave respond Not authoritative for . for each domain, whereas the master-server is, of course, working fine. The only solution is to manually issue the notify DOMAIN command for each domain. That is not a workable setup. Why is the slave not automatically notified? Thanks for your help! p.s. Company name of client is blank to make sure Google won't index it. -- With kind regards / Met vriendelijke groet, Pierre van den Oord LikeFiction Kleyn Proffijtlaan 49 2343 DB Oegstgeest The Netherlands T +31 (0)85 7850699 (Mo-Fr 10-17, GMT +1) T +31 (0)6 12469791 (Mobile) M i...@likefiction.com W www.LikeFiction.com --- Please include the original message when you reply! --- ___ 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
On 8/4/2010 6:36 AM, Nuno Nunes wrote: Hello all, I've gone through the last few months of the ML, up until the announcement of the release of 3.2.1, and didn't find any reference to this bug I'm apparently seeing, so I'm reporting this to you all for help. I work at an ISP where we have a number of servers running PowerDNS Resolver 3.2.1 as our customer-facing resolvers. We have had this setup for a few months now and sometimes a weird thing happens (and no, I can't reproduce it in any deterministic way and it only happens sometimes): when the TTL for a record of a given zone expires and a new request comes in for it, some of the caches on the farm go out and get the new information, but some others just seem to ignore the TTL and stick with the old data forever. This is most notable when a zone changes name servers and the owner of the zone comes complaining to us that we still have the old data, even after the appropriate amount of time has elapsed for it to have been refreshed (and on these cases we typically observe this behaviour on NS records, but we have observed it on A records also, for example). 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? 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
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
Re: [Pdns-users] anual AXFR works, automatic does not (txt-version)
On Thu, Aug 05, 2010 at 03:55:24PM +0200, LikeFiction wrote: and one row on supermasters table on slave: ip: 95.215.63.212 nameserver: ns2..com (refers to slave itself) Please read section 13.2.1. of http://doc.powerdns.com/slave.html#SUPERMASTER very slowly and carefully. I would suspect that your problem is in the third bulletin point The set of NS records for the domain, as retrieved by the slave from the supermaster, must include the name that goes with the IP address in the supermaster table Yes, it should work right after restart of the master server. I would not go so far as to say that it usually does work right after configuration as many people struggle with exactly that point. ;) As always with DNS, not giving out the actual domain name prevents us from looking at the actual data and hinting you at possible typos or delegation problems. Stefan -- 7. Security Considerations Anyone who gets in between me and my morning coffee should be insecure. - RFC 2324 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Hidden supermasters
Hi Richard, Richard McLean schreef: Hi all, From Stefan's answer yesterday on the AXFR question: On 06/08/2010, at 12:55 AM, Stefan Schmidt wrote: The set of NS records for the domain, as retrieved by the slave from the supermaster, must include the name that goes with the IP address in the supermaster table I have wondered about this. We'd love to implement a hidden supermaster type setup, using AXFR, which auto-updates the 4 main name servers, but is *not* in the list of name servers for a domain and is not publicly available. Is the restriction above able to be worked around or turned off? No, this is not a restriction. In our setup we've added the ip address in the supermasters-table like this: +---++--+ | ip| nameserver | account | +---++--+ | xx.xx.xx.xx | name of primary server in public NS list | internal | The hidden master on xx.xx.xx.xx will send the update-notification to all public ns's as listed in the zone. The public ns's in turn will axfr the new domain from the hidden master on it's ip. Regards, Ton I' ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
