Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
Hi Jake! This answers are probably worth some for consulting. Anyways... > -Ursprüngliche Nachricht- > Von: Pdns-users Im ... > Does PowerDNS load all of the zones into memory, and then start serving > (like BIND), or does it load each zone and start serving said zone > immediately upon load (like KNOT)? It may depend on the backend. I can only talk about the postgresql backend. As the zone data is stored in the backend, PowerDNS will not load any zones into memory. Hence it will answer queries immediately. Where immediately means, that of course the backend hast o load the data from the disk. But this is not done in advance but on request. Btw: My Knots (secondaries) will only start answering if ALL zones are loaded. > When in "secondary" mode, how does PowerDNS select which "primary" to > retrieve a zone from? Is it based on the configured list, is it based on > performance, or is it based on which server it first received a notify > from? For regular SOA Checks it should select randomly. For SOA checks triggered by NOTIFY it should query the name server that sent the NOTIFY but I have not tested this (implemented quite recently) > What's the best method for updating a backend with DNS changes in an > instance where there are 6 million+ zones? Assuming updating the database > isn't the best method, what kind of volume can the API or dynamic update > paths handle? Is my assumption correct that I only have to worry about > this in a "primary" configuration, and that a "secondary" configuration > can rely entirely on standard zone transfers? Why wouldn't updateing the DB not the best method? It is a possibilty but it requires some actions to make it correctly (rectify zone). Yes, the API would take care that everyting is correct in the DB. You could also use AXFR inbound into to your "primary" if zones are coming from some other systems. Regarding secondary you have 2 choices: standard AXFR or database replication. Standard AXFR gives you the possibilty to also integrate other name server products, but database replication would also solve the provisioning. When talking about secondaries, the zone transfer is the most easiest part. The challenges are: 1. Zone provisioning on the secondary (how will powerdns knot that it should be secondary for a certain zone?) Solutions: a) out of band management b) PowerDNs Superslave Feature (deletion of zones must be done out of band/manually) c) Catalog zones (not yet implemented in PDNS) d) database replication (the easiest solution) 2. Checking the Sync status. You probably want to know if some zone at some secondary is not in sync with the primary. NOTIFYs can get lost, AXFR can fail. There can and will be temporary network issues to your secondaries, so during 1 minute network issues you may miss plenty of NOTIFYs. To work around you could configure SOA refresh checks every hour. With 6 mio zones that would be constantly 1700q/s on your primary. With 20 secondaries you have 34kq/s only for soa checks (which fully the the backend on your primary as you usually want to disable caching on the primary, at least if you plan to manipulate the backend DB directly). Customers always detect this very fast an complain. Hence, you do want to detect such issues automatically and automatically retransfer zones. Solutions: a) plenty of SOA checks b) out of band check c) database replication (the easiest solution) - here you just monitor the replication lag which is a single metric for all your zones > CNAME @ APEX questions: Actually it is: CNAME besides other RRs, other RRs below DNAME, > Would I be right in my assumption that if one wants to use the CNAME @ > APEX recursion hack, that the entire ecosystem (both distribution servers > and cloud servers) would need to be PowerDNS to accomplish this, given > that BIND and KNOT will not load a zone with CNAME @ APEX? Knot master will accept CNAMEs/DNAME errors if semantic checks are set to "soft". NSD accepts such zones as secondary. MAybe Bind also accepts them if you disable all the syntax check. Of course, when disabling such check, you can never know if the response is what you expect - as it is not defined how the answer should look like. For example Knot with CNAME checks disabled responds differently as PowerDNS for CNAMEs@APEX. So, stop accepting CNAME bugs, and have work arounds for existing zones until the are fixed (I know this is not easy) > What about DNS software vendor diversity? Anyone else out there doing > CNAME @ APEX that you find is a good mix with PowerDNS? > > > > Capacity questions: > > Can a PowerDNS instance handle 6 million zones and 300 million records? It depends on the server and the query load. The more queries, the more CPUs you need. The more ressource records you have, the more RAM you need to have. So, with a very fat server you can handle it. > Does one backend perform better than the others at this capacity?
Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
And don't forget that there is the ALIAS pseudo resource record for this purpose. Actually I purposesly forget ALIAS as it's nonstandard. :) -JP ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
On 06/05/2022 18:02, Jan-Piet Mens via Pdns-users wrote: CNAME @ APEX questions: There is no such thing. "No CNAME and other data" is the rule. Fired off too quickly. RFC 1912 2.4 clarifies this [1] And don't forget that there is the ALIAS pseudo resource record for this purpose. https://doc.powerdns.com/authoritative/guides/alias.html ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
CNAME @ APEX questions: There is no such thing. "No CNAME and other data" is the rule. Fired off too quickly. RFC 1912 2.4 clarifies this [1] -JP [1] https://www.ietf.org/rfc/rfc1912.txt ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
Does PowerDNS load all of the zones into memory, and then start serving (like BIND), or does it load each zone and start serving said zone immediately upon load (like KNOT)? Neither nor. It waits for a query and then goes to the backend to search for an answer to that query, unless the answer is already in the packet cache in which case it answers from there. What's the best method for updating a backend with DNS changes in an instance where there are 6 million+ zones? 'best' is relative. You might want to use SQL if you have an appropriate bakend, RFC2136 dynamic updates, or the API. I would conduct tests to determine what's 'best' for you. Is my assumption correct that I only have to worry about this in a "primary" configuration, and that a "secondary" configuration can rely entirely on standard zone transfers? Correct. CNAME @ APEX questions: There is no such thing. "No CNAME and other data" is the rule. Can a PowerDNS instance handle 6 million zones and 300 million records? Probably. It's likely a backend issue and a volume of queries issue. What is the startup timing on a large PowerDNS installation? example: "I have $x million records, and that takes $y minutes until loaded? PowerDNS launches equally fast with 0 and with millions of records. -JP ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...
Some questions ranging from "anyone can answer" to "only high rollers will have this insight"...thank you for indulging me and for any guidance you might be able to provide. General questions: Does PowerDNS load all of the zones into memory, and then start serving (like BIND), or does it load each zone and start serving said zone immediately upon load (like KNOT)? When in "secondary" mode, how does PowerDNS select which "primary" to retrieve a zone from? Is it based on the configured list, is it based on performance, or is it based on which server it first received a notify from? What's the best method for updating a backend with DNS changes in an instance where there are 6 million+ zones? Assuming updating the database isn't the best method, what kind of volume can the API or dynamic update paths handle? Is my assumption correct that I only have to worry about this in a "primary" configuration, and that a "secondary" configuration can rely entirely on standard zone transfers? CNAME @ APEX questions: Would I be right in my assumption that if one wants to use the CNAME @ APEX recursion hack, that the entire ecosystem (both distribution servers and cloud servers) would need to be PowerDNS to accomplish this, given that BIND and KNOT will not load a zone with CNAME @ APEX? What about DNS software vendor diversity? Anyone else out there doing CNAME @ APEX that you find is a good mix with PowerDNS? Capacity questions: Can a PowerDNS instance handle 6 million zones and 300 million records? Does one backend perform better than the others at this capacity? If operating a global anycast network, is the backend database sitting on the DNS server itself, or does one dedicate a node or two in each site as part of a backend database cluster? How much does an on-server database impact query performance? At what point do you hit the requirement for multiple backends? Can anyone provide me a fuzzy number on RAM footprint? example: "I have $x million records, and that's using $y amount of RAM" What is the startup timing on a large PowerDNS installation? example: "I have $x million records, and that takes $y minutes until loaded? Thanks again, -jake ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Powerdns Alpine authoritative server 4.5.4 series missing zone2sql , zone2json binary
Hello Varsha, On Thu, 2022-04-28 at 16:32 +0530, Rain Musings via Pdns-users wrote: > Background: > We are using the powerdns alpine distribution in docker images . > We were previously using 4.0.8 powerdns which came with the zone2sql > , zone2json utility. > These utilities are used by our wrapper scripts to dynamically update > zone details when input zone files are updated. > > Issue: > We recently moved to Powerdns 4.5.4 version that comes with Alpine > 3.15 version. We see that the zone2* utilities are missing. Is this > intentional? > > Can you tell us how we can compile these utility programs and use it > ? zone2* are in pdns-tools. Here's a convenient trick: / # apk add cmd:zone2sql fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.15/community/x86_64/APKINDEX.tar.gz (1/9) Installing libgcc (10.3.1_git20211027-r0) (2/9) Installing boost1.77-program_options (1.77.0-r1) (3/9) Installing ca-certificates (20211220-r0) (4/9) Installing brotli-libs (1.0.9-r5) (5/9) Installing nghttp2-libs (1.46.0-r0) (6/9) Installing libcurl (7.80.0-r1) (7/9) Installing libsodium (1.0.18-r0) (8/9) Installing libstdc++ (10.3.1_git20211027-r0) (9/9) Installing pdns-tools (4.5.4-r0) Executing busybox-1.34.1-r5.trigger Executing ca-certificates-20211220-r0.trigger OK: 21 MiB in 23 packages Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] First Release Candidate of PowerDNS Recursor 4.7.0
Hello! We are proud to announce the first release candidate of PowerDNS Recursor 4.7.0. Testing of this release candidate is much appreciated! The most important change compared to the 4.7.0-beta1 release is a fix for the experimental DoT to authoritative server probing code. Compared to the previous major (4.6) release of PowerDNS Recursor, this release contains the following major changes: * A configurable way of adding Additional[1] records to answers sent to the client, so the client does not have to ask for these records. * The step sizes for Query Minimization are now computed following to guidelines in RFC 9156.[2] * The Recursor now schedules tasks to resolve IPv6 addresses of name servers not learned by glue records. This has the consequence that, if applicable, name servers will be contacted over IPv6 more often. * An experimental implementation of unilateral DoT probing[3]. This allows the Recursor to learn if a an authoritative servers supports DoT. * Recursor has gained a way to fall back[4] to parent NS set if contacting servers in the child NS set does not lead to an answer. This works around some broken authoritative servers configurations. * ZONEMD validation of the zones retrieved by the Zone to Cache[5], providing integrity guarantees for the zone retrieved. * The table recording round trip times of authoritative server IP addresses is now shared between threads to make it more effective and to reduce its memory footprint. * A Lua FFI hook for post-resolve interception: postresolve_ffi[6], providing a very fast way to do post-resolve Lua scripting. As always, there are also many smaller bug fixes and improvements, please refer to the changelog[7] for additional details. When upgrading do not forget to check the upgrade guide.[8] Please send us all feedback and issues you might have via the mailing list[9], or in case of a bug, via GitHub[10]. The tarball[11] (signature[12]) is available from our download server[13] and packages for several distributions are available from our repository[14]. With the final 4.7 release, the 4.4.x releases will be EOL and the 4.5.x and 4.6.x releases will go into critical fixes only mode. Consult the EOL policy[15] for more details. We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms. We also like to announce the upcoming removal of XPF[16] support. If you are using this feature, plan switching to the proxy protocol[17]. We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and implementations of features. -Otto and the PowerDNS Team References 1. https://docs.powerdns.com/recursor/lua-config/additionals.html 2. https://www.rfc-editor.org/rfc/rfc9156 3. https://docs.powerdns.com/recursor/settings.html#max-busy-dot-probes 4. https://docs.powerdns.com/recursor/settings.html#save-parent-ns-set 5. https://docs.powerdns.com/recursor/lua-config/ztc.html 6. https://docs.powerdns.com/recursor/lua-scripting/hooks.html#postresolve_ffipostresolve_ffi 7. https://docs.powerdns.com/recursor/changelog/4.7.html#change-4.7.0-rc1 8. https://docs.powerdns.com/recursor/upgrade.html 9. https://mailman.powerdns.com/mailman/listinfo/pdns-users 10. https://github.com/PowerDNS/pdns/issues/new/choose 11. https://downloads.powerdns.com/releases/pdns-recursor-4.7.0-rc1.tar.bz2 12. https://downloads.powerdns.com/releases/pdns-recursor-4.7.0-rc1.tar.bz2.sig 13. https://downloads.powerdns.com/releases/ 14. https://repo.powerdns.com/ 15. https://docs.powerdns.com/recursor/appendices/EOL.html 16. https://docs.powerdns.com/recursor/settings.html#xpf-allow-from 17. https://docs.powerdns.com/recursor/settings.html#proxy-protocol-from -- kind regards, Otto Moerbeek PowerDNS Developer Email: otto.moerb...@open-xchange.com - Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366 Managing Board: Andreas Gauger, Dirk Valbert, Frank Hoberg, Stephan Martin Chairman of the Board: Richard Seibt PowerDNS.COM BV, Koninginnegracht 14L, 2514 AA Den Haag, The Netherlands Managing Director: Robert Brandt, Maxim Letski - signature.asc Description: PGP signature ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Automated DNSSEC Keyrollover
Seems all Admins are cooking their own soup. ;) wouldn't be nice, if there were a opensource "script" for keyrollovers?! Signing a zone is easy, but the propper maintaining seems to be a hassle... Now i have some Holidays, where i can think about a FOSS keyrollover Project... Cheers On Thu. 5. May 2022 22:53 CEST, Florian Obser via Pdns-users wrote: On 2022-05-05 18:45 +02, Jan-Piet Mens via Pdns-users wrote: > I haven't looked recently, but it might well be possible with a judicious use > of > pdnsutil(1) to kick a rollover; create new key, wait, remove old keys. I have done algorithm rolls for my domains using pdnsutil(1). So it can be done, but it felt like banging rocks together. It's somewhere on my todo list to write something that uses the api to automate this. I do hope that someone beats me to it though. -- I'm not entirely sure you are real. ___ 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
