PowerDNS Blog

Quite a good read but I think we killed his personal blog for now. I recommend this article on the site: https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privac…

PowerDNS got caught out too: https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6-4-9-3-5-0…

A better criticism of DoH is here: https://blog.powerdns.com/2019/12/03/doh-anti-competitive-and-network-… I just hate that it breaks Split Horizon which is totally legitimate. Leaking local-to-the-LAN queries onto the public internet is also a concern. IMO the right way to do this is to run your own local DNS recursive resolver, and deploy DNSCurve. This doesn't work for myopic browser vendors though...

yes you CAN if you wish of course. on the other hand nowadays 95% of domains on the Internet can be identified by IP[1][2]. so ISPs still have a pretty good guess what sites do you visit even without DNS or SNI data. [1] https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privac… [2] https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-addres…

One of the purported benefits of DoH, and especially of not using one's ISP's DNS servers, was privacy from authoritative governments. Some critics of DoH, and especially centralized DoH, said that it would not help; see "DoH for oppressive regimes": * https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privac… See also Paul Vixie: * https://blog.apnic.net/2019/11/04/dns-wars/ Personally I prefer DoT: it allows me to control resolution on my network, but if you want to allow 953 and use a third party DNS service because of your ISP, you still can.

Hi! Author of that page here. Let me know your thoughts, or express your feelings in a pull request! https://github.com/ahupowerdns/hello-dns/ - you might also appreciate the DNS RFC viewer on https://powerdns.org/dns-camel . Finally, this all started based on this IETF presentation: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-…

Their homepage is http://powerdns.net/, not http://powerdns.com/; and yes they are incorporated as TriLab. Like I said, they're (PowerDNS application & TriLab) hosted on their own their own infrastructure, which is currently hosed. So basically, PowerDNS.COM BV is doing a public service to TriLab BV by putting up a notice. And of course, one is bound to lose politesse when held responsible for stuff one hasn't done or isn't responsible for. And, no I am not with Trilab and I have nothing to do with their service besides being a harrowed paying customer. Edit: Blog post by the people at PowerDNS BV (not related to PowerDNS.NET) http://blog.powerdns.com/2014/04/13/on-powerdns-com-and-express-powerd…

From the described mistakes two come from lack of understanding how exactly DNS works. But I agree it's in fact hard, see [1]). 1. "This strict DNS spec enforcement will reject a CNAME record at the apex of a zone (as per RFC-2181), including the APEX of a sub-delegated subdomain. This was the reason that customers using VPN providers were disproportionately" - This is non intuitive and maay people are surprised by that. You cannot create any subdomain (even www.domain.tld) if you created "domain.tld CNAME something...". Looks like not every server/resolver enforces that restriction. 2. "based on expert advice, our understanding at the time was that DS records at the .com zone were never cached, so pulling it from the registrar would cause resolvers to immediately stop performing DNSSEC validation." - like any other record, they can be cached. DNS has also negative caching (caching of "not found responses". Moreover there are resolvers that allow configuring minimum TTL that can be higher that what your NS servers returns (like unbound - "cache-min-ttl" option) or can be configured to serve stale responses in case of resolution failures after the cached data expires [2]. That means returning TTL of "1s" will not work as you expect. [1] https://blog.powerdns.com/2020/11/27/goodbye-dns-goodbye-powerdns/ [2] https://www.isc.org/blogs/2020-serve-stale/

> in particular, you have no power to make the users polite. So very (and unfortunately) true. However they also have no power to make you do the thing they need straight away, or ever. > Even if you put hard work in it, you sacrifice a bit of your life. And this is bad. We need to move the needle away from this. It is incredibly exclusionary I am a younger person, no kids, in a job where I was able to negotiate for open source maintenance time. By making "sacrifice" a requirement it makes it off putting for someone with kids, or working in a job that has them working long hours, or working multiple jobs. > But the user, well, they just are what they are, software can't fix that. No, software can't fix it. but highlighting the problem, and letting people possibly see what they are doing is not useful may change the user. I have been a maintainer of a project for a long time, and I get everything from people pinging me in our IRC channel, to DMing me, to asking if I give them my skype ID so I can call into a bridge to help them debug an issue at midnight. We need to highlight this is not OK. Personally, I really like the PowerDNS rule for open source support [1] - it sets expectations, and the base requirements from someone looking for help. > the success, at least to me, was measured by the number of users That is a valid metric, but just one. I personally measured the success of the project based on what people were using it (e.g. I would rather wikimedia vs 20…