- NLNOG - NLNOG

Spoofer Report for NLNOG for Sep 2026
by CAIDA Spoofer Project 08 Oct '26

08 Oct '26

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within nld. Inferred improvements during Sep 2026: ASN Name Fixed-By 202585 bgp-rodeo 2026-09-08 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Sep 2026: ASN Name First-Spoofed Last-Spoofed 215605 Informatiq 2024-11-11 2026-09-30 215296 LOWPING-NL 2025-02-19 2026-09-24 35316 PRODACOM 2025-12-17 2026-09-29 60781 LEASEWEB-NL-AMS-01 2026-02-08 2026-09-26 58232 haderan 2026-04-04 2026-09-03 64289 MACARNE 2026-06-14 2026-09-30 214783 DEDICATEDNODES 2026-09-10 2026-09-24 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1 Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

PCH 2026 global peering survey
by Bill Woodcock 28 Sep '26

28 Sep '26

tl;dr: the survey is at https://pch.net/survey Background: Every five years, beginning in 2011, PCH has conducted a comprehensive global survey characterizing Internet peering agreements. They are the only ones of their kind, and are relied upon not only by network operators, but also by legislators and regulators throughout the world to understand the Internet interconnection landscape. Our write-ups of the prior surveys can be found here: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011… https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016… https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2021… …and video of the NANOG presentation of the 2016 results is here: https://www.youtube.com/watch?v=lPuoBmxyXMc At the time of the 2011 survey, we committed to repeating the survey every five years, to provide time-series data about the direction peering trends take. We’re now conducting the fourth iteration of the survey. Among other things, the surveys have helped establish a better understanding of trends in: • The increasingly uniform global norms of interconnection • National preferences within the network operator community for country of governing law • The long tail of small networks which don’t yet support IPv6 routing • The significance of multilateral peering agreements in the density of the interconnection mesh These findings, particularly the first, have been invaluable in giving regulators in the vast majority of the world’s countries a data-driven basis for refraining from prescriptively regulating Internet interconnection. They have demonstrated in objective terms that the Internet self-regulates in a way that’s more globally uniform and closely harmonized than any coordination of national regulatory bodies could accomplish. Participation: The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world. Your participation ensures that your norms and ways of doing business are represented accurately and proportionately in the dataset. If you don’t participate, the way you do business will be less well-represented in the data, and will seem less normal to regulators and policy-makers. We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 41% of the world’s ISPs, across 96 countries; in 2016, 65% of the world’s ISPs, across 148 countries; in 2021, 76% of the world’s ISPs across 192 countries. Our aim is to be equally inclusive this year. Since our principal method of soliciting participation is via NOG mailing lists, I’m afraid many of you will see this message several times, on different lists, for which we apologize in advance. Privacy: In 2011, 2016, and 2021, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as was successfully employed the last three times. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed. The Survey: We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with: • Your peer’s ASN (peers only, not upstream transit providers or downstream customers) • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement") • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes) • What jurisdiction of governing law is defined, if any • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are) The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean [true,1,yes,y] or [false,0,no,n] Symmetric: Boolean [true,1,yes,y] or [false,0,no,n] Governing Law: ISO 3166 two-letter country-code, or empty IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n] For instance: 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr> We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. We'd like to finish collecting data in the first week of October, about two weeks from now. If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine. If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs. If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that. If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Finally, if there are questions you’d like us to try to answer when we analyze the data, please suggest them, and if there are any additional questions you’d like us to include in future iterations of the survey, please let us know so that we can consider including them in the 2031 survey. Please respond by submitting your survey at https://pch.net/survey or emailing it to me directly (woody(a)pch.net, not replying to the NOG mailing list), by the second week of October. Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community. -Bill Woodcock Secretary General Packet Clearing House

1 0

Reminder: Root Zone KSK Rollover on October 11
by Moritz Müller 24 Sep '26

24 Sep '26

#### Dutch (English below) #### Mogelijk weten de meeste het al, maar op 11.10.2026 wordt routinematig het sleutelpaar van de DNS root vervangen (een zogenaamde "rollover"). Dat betekent dat vanaf dit moment DNS resolvers die DNSSEC handtekeningen valideren, de nieuwe publieke sleutel moeten vertrouwen. Zo niet, kunnen binnen 48 uur na de rollover validatiefouten bij de resolver optreden. Uiteindelijk zal de resolver geen enkele DNS query meer succesvol resolven. SIDN vindt DNSSEC nogal belangrijk en we raden daarom iedereen die een resolver beheert en DNSSEC validatie aan heeft staan, om te controleren of zijn/haar resolver de nieuwe sleutel ondersteunt. De meeste resolver software zal de nieuwe sleutel al vertrouwen (bijvoorbeeld door een software update of omdat de software RFC 5011 ondersteunt). Resolver software heeft verschillende manieren om te controleren welke sleutel ze vertrouwen. De nieuwe sleutel heeft het ID 38696, de oude sleutel 20326. Beneden wat voorbeelden: unbound: Gebruik de tool 'dig': ` dig @jouw.resolver.ip trustanchor.unbound -c CH -t TXT ` powerdns: Gebruik rec_control om de sleutel IDs op te vragen: `rec_control get-tas` bind: In veel gevallen configureert bind een `bind.keys` bestand. Daarin zou de nieuwe sleutel opgevoerd moeten zijn. Op de website van ICANN staat nog meer informatie hierover: https://www.icann.org/resources/pages/ksk-rollover-en Groet, Moritz Research Engineer SIDN Labs #### English #### Most of you may already be aware, but on October 11, 2026, the DNS root key pair will undergo a routine replacement (a so-called "rollover"). This means that from that moment on, DNS resolvers that validate DNSSEC signatures must trust the new public key. If they do not, validation errors may occur at the resolver within 48 hours of the rollover. Eventually, the resolver will fail to successfully resolve any DNS queries. SIDN considers DNSSEC very important; we therefore recommend that anyone managing a resolver with DNSSEC validation enabled checks whether their resolver supports the new key. Most resolver software will already trust the new key (for example, due to a software update or because the software supports RFC 5011). Resolver software uses various methods to check which keys are trusted. The new key has ID 38696; the old key ID is 20326. Some examples are provided below: unbound: Use the 'dig' tool: ` dig @your.resolver.ip trustanchor.unbound -c CH -t TXT ` powerdns: Use rec_control to query the key IDs: `rec_control get-tas` bind: In many cases, BIND uses a `bind.keys` configuration file. The new key should be listed there. Further information is available on the ICANN website: https://www.icann.org/resources/pages/ksk-rollover-en Regards, Moritz Research Engineer SIDN Labs

3 3

Spoofer Report for NLNOG for Aug 2026
by CAIDA Spoofer Project 08 Sep '26

08 Sep '26

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within nld. Inferred improvements during Aug 2026: none inferred Source Address Validation issues inferred during Aug 2026: ASN Name First-Spoofed Last-Spoofed 3920 PUSHPKT 2023-10-06 2026-08-29 35316 PRODACOM 2025-12-17 2026-08-24 60781 LEASEWEB-NL-AMS-01 2026-02-08 2026-08-28 906 DMIT 2026-03-14 2026-08-02 6206 NETROUTING 2026-04-30 2026-08-28 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1 Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Techsummit.io / free tickets
by Robert van der Meulen 08 Sep '26

08 Sep '26

Hi all, My employer (Leaseweb) is organizing https://techsummit.io/agenda-and-speakers-2026/ this year in Pakhuis de Zwijger in Amsterdam, on the 30th of September. It's less network focused but goes into infrastructure/development/operations, talks are selected via a cfp / technical committee, and there is no marketing involved in selecting content. We sell tickets to make sure people show up (and donate proceeds to Bits of Freedom), but I'd like to give out a bunch of tickets to the community / interested people. If you want to come (or you have coworkers/etc who are interested), ping me off-list with the amount of tickets you'd like to have, and i'll send you a voucher so you and yours can get in for free. As with all events, be reasonably certain you'll come if you register as to not waste catering and goodies :) Cheers, Robert -- Robert van der Meulen nlnog(a)wiretrip.org

1 0

NLNOG Day 2026
by Teun Vink (Stichting NLNOG) 24 Aug '26

24 Aug '26

Hi all, Hoi allemaal, hi all! (English text can be found below) Over iets meer dan een week is het zo ver, en vind NLNOG Day 2026 plaats in Gooiland te Hilversum! Afgelopen week is het programma afgerond, en dit jaar denken we weer een hele mooie selectie sprekers klaar te hebben staan. Het volledige programma kan je vinden op https://nlnog.net/events/nlnog-day-2026/ . Inschrijven kan nog! Meestal zijn we rond deze tijd 'uitverkocht', maar door de grotere locatie is er nog ruimte. We willen je wel vragen om, als je komt, je snel in te schrijven - zodat we rekening kunnen houden met de catering en t-shirts. Je kan je registreren via https://nlnog.net/tickets . Als je een ticket hebt maar toch niet komt verzoeken we je om dit te annuleren. Afgelopen jaar hebben we het eerst gewerkt met vrijwilligers om te helpen met de voorbereiding en op de dag zelf. Dat beviel goed, dus doen we dat dit jaar weer. Mocht je zin en tijd hebben om te helpen bij NLNOG Day 2026, laat het ons dan even weten via stichting(a)nlnog.net . We zien jullie graag vrijdag 4 September in Gooiland, Hilversum (Let op, dit is dus niet in Amsterdam :) ). Tot dan! (English) In little over a week it's time for NLNOG Day 2026 in Gooiland, Hilversum! Last week the programme was finalized, and we think we've prepared a very nice selection of speakers again. The full programme can be found at https://nlnog.net/events/nlnog-day-2026/ . You can still register! Usually we are 'sold out' around this time, but due to the bigger location there are tickets available still. We would like to ask you (if you want to come) to register, so we can take this into account in catering and t-shirt preparation and orders. You can register via https://nlnog.net/tickets . If you do have a ticket but can’t make it, please cancel the ticket. Last year we've (for the first time) worked with volunteers to help with preparation and assistance on the day itself. This worked really well, so we'd love to do that again this year. Should you want to help with NLNOG Day 2026, please let us know via stichting(a)nlnog.net . We'd love to see you on Friday the 4th of September in Gooiland, Hilversum (note: so this is NOT Amsterdam :) ). See you then! Met vriendelijke groet, kind regards, Het NLNOG Bestuur / The NLNOG Board

1 0

OARC 47 Call for Contribution - less than two weeks to go before the CfP closes on 24th August!
by Willem Toorop 12 Aug '26

12 Aug '26

The OARC 47 Call for Contributions is open but is closing soon - if you are planning to submit a talk, please don't leave it too late and miss the deadling! This workshop will be a hybrid event. Date - 09-10 November 2026 Location - Vancouver, British Columbia Times - approximately 10:00-17:00 PDT (Local time PDT is UTC -7; note that British Columbia has opted to remain on PDT all year round) Deadline for Submissions - 2026-08-24 23:59 UTC https://indico.dns-oarc.net/event/58/abstracts/ All DNS-related subjects and discussion topics are welcome although we're particularly keen to hear more about operational and security related experiences, best practices and practical advice; both for newcomers to the DNS arena and those who have been around for longer who want to learn more about new features and opportunities to improve resilience, security and privacy. (These topics we think will complement the usual high-quality data-based research submissions we always hope to receive!) If you have something interesting to share with the community that lies outside of the focus above, please don't be put off - if it's good, we'll be happy to include it. You can also contact us directly at submissions(a)dns-oarc.net if you would like to ask about the suitability of a potential presentation submission topic. If you'd like to offer a talk, but are not quite sure what to pick, here's a non-exhaustive list of ideas: 1. Operations & Deployment * Configuration management, deployment processes, and interoperability experiences. * Tools, tips, and making effective use of DNS software features. 2. Performance, Resilience & Scaling * Provisioning, load-balancing, and planning for resilience. * DNS performance management, efficiency improvements, and metrics. * Monitoring infrastructure: log pipelines, analytics, and anomaly detection. 3. Security, Privacy & Policy * DoS attacks, DNS abuse, DNSSEC signing and validation. * Privacy considerations, for example: encrypted transport, qname minimization, data anonymization. * Relevant global and regional policies, legislation, and compliance. 4. Research & Innovation * Data-driven testing, measurement, and analysis. * New protocols, protocol extensions, and next-generation namespace management. 5. Lessons & Learnings * Outage experiences, recovery stories, and cautionary tales For further details please see https://www.dns-oarc.net/oarc47 Willem Toorop, for the DNS-OARC Programme Committee

1 0

Spoofer Report for NLNOG for Jul 2026
by CAIDA Spoofer Project 08 Aug '26

08 Aug '26

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within nld. Inferred improvements during Jul 2026: none inferred Source Address Validation issues inferred during Jul 2026: ASN Name First-Spoofed Last-Spoofed 39647 REDHOSTING 2019-12-02 2026-07-11 3920 IMS-RTFM 2023-10-06 2026-07-04 39686 ASN-EUROFIBER 2025-04-28 2026-07-14 35316 PRODACOM 2025-12-17 2026-07-27 60781 LEASEWEB-NL-AMS-01 2026-02-08 2026-07-05 906 2026-03-14 2026-07-26 32519 DMITI-SERVICES 2026-03-28 2026-07-11 6206 PARK-3 2026-04-30 2026-07-31 204983 Cyberfusion 2026-07-07 2026-07-07 47216 CVKS-MSK-IX 2026-07-11 2026-07-19 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1 Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Help us identify community-driven sessions for the November 11 following OARC 47
by Willem Toorop 23 Jul '26

23 Jul '26

Hi, We are planning to offer a full day of community-driven sessions on Wednesday, 11 November, immediately following the main OARC 47 workshop. We'd like to hear from the broader DNS and Internet operations community. What topics or activities would you like to see happen, and what could be realistically organized—or that you would be interested in helping organize? Recent workshop feedback included interest in tutorials and short training sessions, working group and interest group side meetings, BOFs, hackathons, tool demos, and operator round-tables. To make this useful, we need more than topic suggestions: we are especially looking for people who are willing to host a session, help organize one, or point us toward someone who has already expressed interest in leading a specific project, topic, or discussion. This additional day will not require a separate registration fee for OARC 47 attendees. We have conference rooms available from 08:30–16:30 on the 11 November. Each room can accommodate up to 15 participants and includes basic boardroom AV. The day is currently planned around the following schedule: * 08:30–10:00 session block * 10:00–10:30 morning coffee break * 10:30–12:00 session block * 12:00–13:00 lunch * 13:00–14:30 session block * 14:30–15:00 afternoon coffee break * 15:00–16:30 session block Sessions may use one or more blocks depending on the format, organizer availability, and room scheduling. Possible formats include: * hands-on tutorials * OARC tools training or demos * software demos * BOFs * hackathons * focused working group or interest group meetings (for instance standards or BCP discussions) * operator round-tables "help me brainstorm this problem" sessions If you are willing to host something, help organize something, or connect us with someone who may be a good lead for a specific session, please complete the following form by *24 August 2026 23:59 UTC*. Form Link <https://zfrmz.com/arOnEOkvgGa9UoqvwOGn> The form also includes a small section for attendee interest, but our immediate priority is identifying sessions with a potential host, organizer, or named point of contact. Submitting a proposal does not guarantee a confirmed room or time slot. OARC staff will review responses and follow up to confirm session details, timing, room fit, and any support needed. We hope this additional day can create space for practical work, smaller-group discussions, and hands-on knowledge sharing that can be difficult to fit into the regular workshop agenda. Best, Willem Toorop for the DNS-OARC

1 0

RTBH Support Across the Industry
by James Bensley 22 Jul '26

22 Jul '26

Dear Community, We see that RTBH is not as effective as it could be, for various reason, just a few include: * Not all networks support RTBH. * Networks that do support RTBH implement it differently to each other. * There is no one place where one can easily find the info for how to use RTBH with a given network. * Operators have different ideas about how / when / where / why someone should / shouldn't use RTBH. To this end, we have created the first of two surveys. This first one is quantitative and captures how networks have implemented RTBH and provides (1) a public repository which anyone can use to look-up the RTBH details for their peers/upstreams, and (2) an insight into the (mis-)alignment of RTBH implementations across the industry. Please take the time to fill out the short survey for your own network (even if you don’t support RTBH!), and if you can, please fill it out for other networks where you know how they have implemented RTBH (e.g., peers you use RTBH with): https://docs.google.com/forms/d/e/1FAIpQLScg2Bvr_14onOtZRdoK2SNd0kCHFtqsdw-… (^ No login required) The data ends up in this public repository (you can of course make a pull request directly if you want): https://remotely-triggered-black-hole.github.io/rtbh/ The second survey we are working on will be qualitative, to gather information from the industry community on why you do / don't support RTBH, when do you use it, how do you think the routing should be secured, etc. The long term goal is to use the data from both surveys as input in to a community effort to improve RTBH alignment across the industry and improve it’s effectiveness for all (e.g. maybe we produce a new BCOP for implementing RTBH, or usage guidelines for blackholing, or maybe a new RFC is required to secure the filtering; regardless, the first step is to gather data about the status quo and review that data to get a baseline of where we are at today). Any questions, please let me know, and thank you for your time and help, it is appreciated. With kind regards, James

1 0