[Pdns-users] Goodbye DNS, Goodbye PowerDNS!
Goodbye DNS, Goodbye PowerDNS! Please read the whole post on https://blog.powerdns.com/2020/11/27/goodbye-dns-goodbye-powerdns/ which also has clickable links. But the gist is: After over 20 years of DNS and PowerDNS, I am moving on. Separate from this page, I am releasing a series of three huge posts on the history of PowerDNS, so I won’t dwell too much on that here. This is not an easy story to write. I don’t like to grandstand, but when the founder of a project decides to leave after two decades, people do expect some form of an explanation. It is also customary to describe such an exit in upbeat terms, sometimes to the point that you wonder that if things were so great, why is this person leaving? But the reality is, I got bored and wanted to do new things. PowerDNS and the wonderful people who I met along the way have taught me so much – software development, operations, marketing, sales, business development, community building, writing internet standards & much more. It has been a wonderful ride. But now it appears DNS and I are somewhat at the end of our relationship (even though I will remain a minor PowerDNS shareholder). Formally I leave on December 31st. Helping build PowerDNS to what it is today – a flourishing department of Open-Xchange, able to fund itself by delivering its software to paying users, while maintaining good relations with the open source community, has been an incredible honour. As I leave the company, management and software development have long been in the hands of people I am proud to call my successors. They are doing a better job than I ever did – the only claim I have on the current success is that I helped recruit this next generation. I don’t think there is much more to aspire to when you create a company than leaving it behind in good shape. ... please do read on at https://blog.powerdns.com/2020/11/27/goodbye-dns-goodbye-powerdns/ Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] pdns query wrong SOA records with ipv6 and miss the right domain this way
On Tue, Oct 06, 2020 at 08:29:49PM +0200, Oliver Dzombic via Pdns-users wrote: > SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records > WHERE disabled=0 and type='SOA' and > name='7.3.c.f.9.0.2.0.0.0.0.0.3.1.0.0.8.d.2.1.0.0.a.2.ip6.arpa' Can you run that query on your database and tell us what it reports? Thanks! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Issues with PowerDNS Authoritative Server on CentOS7
On Mon, Aug 17, 2020 at 09:33:17PM +, Fabio Perez via Pdns-users wrote: > Hello, > My name is Fabio. > I installed 2 VMs each running PowerDNS as Authoritative servers, but for > whatever reason I cannot make this to work. > When I set other VMs with the nameserver of my DNS, none of my query get > resolved. > I need assistance with this. How can I troubleshoot this? > What information do I need to provide? Hi Fabio, If you tell us the IP address of your server we could send it questions and see if it responds. Alternatively, please show us your configuration (including network setup, firewalls etc) and how you determined none of your queries are getting resolved. Also please include the full startup log of PowerDNS, which will show on which IP addresses it listens. There is nothing specific about Centos7 and your problem is likely network related, or perhaps powerdns is not even running. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Recursor and LUA scripting: I don't understand why preresolve answering a CNAME won't cascade to other records
On Sun, May 31, 2020 at 12:08:36PM +0200, Oscar Koeroo via Pdns-users wrote: > I’m using the following LUA script to intercept, but I don’t understand > the results. Why doesn’t the dig get the CNAME to got to the A record I > have in my domain.local zone? I expected dig to try to get the CNAME > value of qr.domain.net and the CNAME value of that result, which seems to > halt there. Hi Oscar! So firstly, a resolver is expected to provide a complete answer. If it supplies only a CNAME, a client can assume there is nothing more. A stub-resolver won't itself recurse. > The expected result I was looking for was: The good news is, we thought of this scenario, and we have this: "CNAME chain resolution It may be useful to return a CNAME record for Lua, and then have the PowerDNS Recursor continue resolving that CNAME. This can be achieved by setting dq.followupFunction to followCNAMERecords and dq.followupDomain to “www.powerdns.com”. PowerDNS will do the rest. " https://doc.powerdns.com/recursor/lua-scripting/hooks.html#cname-chain-resolution Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] SERVFAIL on all requests
On Mon, May 25, 2020 at 04:46:15PM -0400, Dave Burkholder via Pdns-users wrote: > I did wonder too if there's an issue of reaching root servers, or firewall > modifying responses, so I did try installing unbound on the same machine, > and it's working fine. unbound on port 3053 always works, but pdns on > port 2053 always FAIL. Your network is faulty: May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] com: Trying IP 202.12.27.33:53, asking 'com|A' May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] com: Got 0 answers from m.root-servers.net (202.12.27.33), rcode=0 (No Error), aa=0, in 6ms If it happens to work for unbound, well, good luck there. But as long as someone is intercepting your traffic to the root servers and modifying it, all bets are off. May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] reddit.com: Trying IP 192.58.128.30:53, asking 'reddit.com|A' May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] reddit.com: Got 4 answers from j.root-servers.net (192.58.128.30), rcode=0 (No Error), aa=0, in 62ms May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] Removing record 'reddit.com|A|151.101.1.140' in the answer section without the AA bit set received from . May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] Removing record 'reddit.com|A|151.101.193.140' in the answer section without the AA bit set received from . May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] Removing record 'reddit.com|A|151.101.65.140' in the answer section without the AA bit set received from . May 25 16:14:04 system.cdc.lan pdns_recursor[8655]: [1] Removing record 'reddit.com|A|151.101.129.140' in the answer section without the AA bit set received from . This is also a clear indication someone is intercepting and breaking your traffic to root servers. The real J-root will not answer with IP addresses for reddit.com. Bert > > Regards, > > Dave > > On 5/25/20 4:04 PM, bert hubert wrote: > >On Mon, May 25, 2020 at 03:57:22PM -0400, Dave Burkholder via Pdns-users > >wrote: > >>When I enable trace, I get lines like: > >> > >>May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] bing.com: Got 3 answers from b.root-servers.net (199.9.14.201), rcode=0 (No Error), aa=0, in 6ms > >>May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] Removing record > >>'bing.com|A|204.79.197.200' in the answer section without the AA bit set > >>received from . > >>May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] Removing record > >>'bing.com|A|13.107.21.200' in the answer section without the AA bit set > >>received from . > >Could you please send a complete output of trace? It appears someone is > >intercepting and changing your DNS responses. > > > >Thanks! > > > > Bert > > > ___ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] SERVFAIL on all requests
On Mon, May 25, 2020 at 03:57:22PM -0400, Dave Burkholder via Pdns-users wrote: > When I enable trace, I get lines like: > > May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] bing.com: Got 3 > answers from b.root-servers.net (199.9.14.201), rcode=0 (No Error), aa=0, in > 6ms > May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] Removing record > 'bing.com|A|204.79.197.200' in the answer section without the AA bit set > received from . > May 25 15:36:44 system.cdc.lan pdns_recursor[16801]: [2] Removing record > 'bing.com|A|13.107.21.200' in the answer section without the AA bit set > received from . Could you please send a complete output of trace? It appears someone is intercepting and changing your DNS responses. Thanks! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] why CAP_CHOWN?
On Sat, May 16, 2020 at 08:42:21PM +0200, Michael Ströder via Pdns-users wrote: > But I wonder why CAP_CHOWN is set in CapabilityBoundingSet= and > AmbientCapabilities= and I could not find a reason in the git history of > that file. Hi Michael, We chown the UNIX domain control socket to the 'setgid' and 'setuid' setting. This is likely why we need CAP_CHOWN. Good luck! Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] SERVFAIL on backend failure - is this possible?
On Wed, Feb 26, 2020 at 12:35:21AM +0200, Vytenis A via Pdns-users wrote: > While trying to implement authoritative DNS server using "remote" > backend, I've stumbled into an issue when HTTP backend is unreachable > - PowerDNS is returning NXDOMAIN. Can you reproduce this for us so we can check? It is not supposed to ever happen. Please also let us know which version of PowerDNS you are using. > What I would like to achieve is return SERVFAIL in case my HTTP > endpoint is unavailable. Is this possible? Maybe Lua fallback backend > could assist here? This is what should be happening. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
