DNS DevRoom at FOSDEM2024 - Call for Participation
Hello DNS enthusiasts and other developers, After four earlier successful and packed DNS devrooms, we are happy to announce a half-day DNS devroom at FOSDEM 2024. As with the previous events, we hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure. We have been allotted a room on Saturday the 3rd of February 2024, the second half of the day, starting around 13:00 (CET). If you have something you’d like to share with your fellow developers, please head to the submission page at https://fosdem.org/submit . Examples of topics are measuring, monitoring, DNS libraries, anecdotes on how you’ve (ab)used the DNS, and group discussions of upcoming technologies. For the upcoming technologies, we're looking for submissions on Applications Doing DNS (ADD), SVCB/HTTPS records and applications thereof, and stub-resolver configuration. Here’s the 2023 schedule, for your inspiration: https://archive.fosdem.org/2023/schedule/track/dns/ . We expect to schedule 30 minutes per talk, including questions, but if you need more or less time, we can discuss this. The deadline for submissions is December 8th 2023. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. this CfP lives online at https://blog.powerdns.com/2023/11/16/fosdem-2024-dns-developer-room-call-for-participation - any important changes will be posted at least there See you there! Cheers, The FOSDEM 2024 DNS Devroom organizers -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ zone response delay time ?
On Fri, 2023-04-07 at 17:27 +0100, Jason Vas Dias wrote: > > *.google-analytics.com A 0.0.0.0 > *.clarity.ms A 0.0.0.0 > *.adtelligent.com A 0.0.0.0 > > (there are over 15,000 entries in it). > > This serves to speed up my internet accesses about 10 times, > normally, and acts great as an ad+spyware site blocker, > like a do-it-yourself RBL list. > > I create a static route at boot-up : > > blackhole 0.0.0.0/8 A /8 blackhole route will not win from the 0.0.0.0/32 "route" (it is implicit, but you can see it with `ip route get` on Linux) that goes to your local system. 0.0.0.0 is not the right DNS response here, or almost anywhere. NXDOMAIN likely fits better. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND caching of nxdomain responses
On Fri, 2021-10-22 at 13:22 -0400, Dan Hanks wrote: > On Fri, Oct 22, 2021 at 9:57 AM Dan Hanks wrote: > > Greetings, > > > > As I understand RFC 2308, when receiving an NXDOMAIN response, and when > > deciding how long to cache that NXDOMAIN response, a resolver should use > > whichever value is lower of the SOA TTL, and the SOA.minimum value as the > > length of time to cache the NXDOMAIN. > > I interpret this to mean that an authoritative resolver should set the > TTL on the SOA record included in the AUTHORITY section of an NXDOMAIN > response to be the minimum of the zone SOA TTL, and the SOA.minimum > field. It does not look like Route53 is doing this. Indeed, Route53 is not doing this, but they should. I spoke to them about this some time ago, and they do intend to fix it, as far as I understand. See also https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021362.html Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.10.4 may have a fatal crash defect.
Hello, On 12 May 2016, at 15:44, Peter van Dijk wrote: I’ve heard two proposals: (1) brew fakes up a version number X that sorts 9.10.4 < X < Y, where Y is whatever ISC is going to release next (2) ISC ‘clones’ 9.10.3-P4 into 9.10.5 (or 9.10.4-P1 but that seems wrong) so the highest version in the BIND version tree is in fact a stable version There’s also (3) do nothing, wait for ISC to figure the issue out and fix it (which will obviously be in a version higher than 9.10.4); doing nothing increases the odds of somebody running into the crash but one might argue that this is helpful! I think all three options are a bit ugly, to be fair. I don’t have any preference. A fourth proposal, just posted at https://github.com/Homebrew/homebrew-core/pull/796#issuecomment-218763988 - homebrew just rolls back, and users who get in trouble will complain and get instructions to downgrade. This is my favourite option. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.10.4 may have a fatal crash defect.
Hello Michael, On 11 May 2016, at 10:49, Michael McNally wrote: To our users: Recently, on Thursday 28 April, ISC released two maintenance releases of BIND 9: - BIND 9.9.9 - BIND 9.10.4 Beginning after the release of BIND 9.10.4 we started receiving a small number of reports from recursive server operators who have encountered an INSIST assertion in code which checks the consistency of the Red-Black Tree structure in which BIND stores cache information. OSX Homebrew had already upgraded to 9.10.4. They are now interested in rolling back, but they cannot simply undo the update - ‘brew upgrade’ will not ‘go back’ automatically then. As there is no ‘epoch’ support like RPM and dpkg have, something else needs to happen. I’ve heard two proposals: (1) brew fakes up a version number X that sorts 9.10.4 < X < Y, where Y is whatever ISC is going to release next (2) ISC ‘clones’ 9.10.3-P4 into 9.10.5 (or 9.10.4-P1 but that seems wrong) so the highest version in the BIND version tree is in fact a stable version There’s also (3) do nothing, wait for ISC to figure the issue out and fix it (which will obviously be in a version higher than 9.10.4); doing nothing increases the odds of somebody running into the crash but one might argue that this is helpful! I think all three options are a bit ugly, to be fair. I don’t have any preference. Thoughts? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
