PING

APNIC
  • 5.0 (4)
  • TECH NEWS
  • UPDATED BIWEEKLY
PING

PING is a podcast for people who want to look behind the scenes into the workings of the Internet. Each fortnight we will chat with people who have built and are improving the health of the Internet. The views expressed by the featured speakers are their own and do not necessarily reflect the views of APNIC.

  1. 1D AGO

    Night of the BGP Zombies

    In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/) explores bgp "Zombies" which are routes which should have been removed, but are still there. They're the living dead of routes. How does this happen?Back in the early 2000s Gert Döring (https://www.ripe.net/community/wg/active-wg/previous-working-group-chair-bios/gert-doring/) in the RIPE NCC region was collating a state of BGP for IPv6 report, and knew each of the 300 or so IPv6 announcements directly. He understood what should be seen, and what was not being routed. He discovered in this early stage of IPv6 that some routes he knew had been withdrawn in BGP still existed (https://ripe42.ripe.net/presentations/ripe42-ipv6-doering/R42-v6-table/page10.html)when he looked into the repositories of known routing state. This is some of the first evidence of a failure mode in BGP where withdrawal of information fails to propagate, and some number of BGP speakers do not learn a route has been taken down. They hang on to it.Because BGP is a protocol which only sends differences to the current routing state as and when they emerge (if you start afresh you get a LOT of differences, because it has to send everything from ground state of nothing. But after that, you're only told when new things come and old things go away) it can go a long time without saying anything about a particular route: if its stable and up, nothing to say, and if it was withdrawn, you don't have it, to tell people it's gone, once you passed that on. So if somehow in the middle of this conversation a BGP speaker misses something is gone, as long as it doesn't have to tell anyone it exists, nobody is going to know it missed the news.In more recent times, there has been a concern this may be caused by a problem in how BGP sits inside TCP messages and this has even led to an RFC in the IETF process to define a new way to close things out. (https://www.rfc-editor.org/rfc/rfc9687.txt)Geoff isn't convinced this diagnosis is actually correct or that the remediation proposed is the right one. From a recent NANOG presentation Geoff has been thinking about the problem, and what to do. He has a simpler approach which may work better.Read more about BGP zombies at the APNIC Blog and the web:* BGP Zombies at NANOG 93 (https://blog.apnic.net/2025/02/10/bgp-zombies-at-nanog-93/) (Geoff Huston, APNIC Blog February 2025)* NANOG 93 presentation on BGP Zombies (https://storage.googleapis.com/site-media-prod/meetings/NANOG93/5333/20250202_Xygkou_Reviving_Bgp_Zombies__v1.pdf) (Iliana Xygkou from Thousand Eyes, NANOG presentation)* RFC9687 SendHold Timers (https://www.rfc-editor.org/rfc/rfc9687.txt) (IETF RFC)

    59 min

  2. FEB 19

    RPKi Views: The archive of RPKI state

    In this episode, Job Snijders (https://blog.apnic.net/author/gautam-akiwate/) discusses RPKIViews (https://rpkiviews.org/), his long term project to collect the "views" of RPKI state every day, and maintain an archive of BGP route validation states. The project is named to reflect route views (https://www.routeviews.org/routeviews/), the long-standing archive of BGP state maintained by the University of Oregon, which has been discussed on PING (https://blog.apnic.net/2024/05/16/podcast-measuring-rpki-and-bgp-with-oregon-routeviews/).Job is based in the Netherlands, and has worked in BGP routing for large international ISPs and content distribution networks as well as being a board member of the RIPE NCC. He is known for his work producing the Open-Source rpki-client (https://rpki-client.org/) RPKI Validator, implemented in C and distributed widely through the OpenBSD project (https://www.openbsd.org/).RPKI is the Resource PKI, Resource meaning the Internet Number Resources, the IPv4, IPv6 and Autonomous System (AS) numbers which are used to implement routing in the global internet. The PKI provides cryptographic proofs of delegation of these resources and allows the delegates to sign over their intentions originating specific prefixes in BGP, and the relationships between the AS which speak BGP to each other.Why rpkiviews? Job explains that there's a necessary conversation between people involved in the operational deployment of secure BGP, and the standards development and research community: How many of the worlds BGP routes are being protected? How many places are producing Route Origin Attestations (ROA) (https://datatracker.ietf.org/doc/rfc9582/) which are the primary cryptographic object used to perform Route Origin Validation (ROV) (https://manrs.org/2020/10/what-is-rov/)and how many objects are made? Whats the error rate in production, the rate of growth, a myriad of introspective "meta" questions need to be asked in deploying this kind of system at scale, and one of the best tools to use, is an archive of state, updated frequently, and as for route views collected from a diverse range of places worldwide, to understand the dynamics of the system.Job is using the archive to produce his annual "RPKI Year in review" (https://blog.apnic.net/2025/01/28/rpkis-2024-year-in-review/) report, which was published this year on the APNIC Blog (it's posted to operations, research and standards development mailing lists and presented at conferences and meetings normally) and products are being used by the BGPAlerter (https://blog.apnic.net/2020/07/27/easy-bgp-monitoring-with-bgpalerter/) service developed by Massimo Candela (https://blog.apnic.net/author/massimo-candela/)Read about the rpkiviews archive on the APNIC Blog, and on the web:* RPKI's 2024 Year in review (https://blog.apnic.net/2025/01/28/rpkis-2024-year-in-review/) - (Job Snijders, APNIC Blog January 2025)* RPKIViews (https://rpkiviews.org/) - (the RPKI views Web archive)

    50 min

  3. FEB 5

    How Many DNS Nameservers is enough?

    In his first episode of PING for 2025, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/) returns to the Domain Name System (DNS) and explores the many faces of name servers behind domains. Up at the root, (the very top of the namespace, where all top-level domains like .gov or .au or .com are defined to exist) there is a well established principle of 13 root nameservers. (https://www.icann.org/root-server-system-en) Does this mean only 13 hosts worldwide service this space? Nothing could be farther from the truth! literally thousands of hosts act as one of those 13 root server labels, in a highly distributed worldwide mesh known as "anycast" which works through BGP routing. (https://www.cloudflare.com/en-gb/learning/cdn/glossary/anycast-network/)The thing is, exactly how the number of nameservers for any given domain is chosen, and how resolvers (the querying side of the DNS, the things which ask questions of authoritative nameservers) decide which one of those servers to use isn't as well defined as you might think. The packet sizes, the order of data in the packet, how it's encoded is all very well defined, but "which one should I use from now on, to answer this kind of question" is really not well defined at all.Geoff has been using the Labs measurement system to test behaviour here, and looking at basic numbers for the delegated domains at the root. The number of servers he sees, their diversity, the nature of their deployment technology in routing is quite variable. But even more interestingly, the diversity of "which one gets used" on the resolver side suggests some very old, out of date and over-simplistic methods are still being used almost everywhere, to decide what to do.Read more about Geoff's research on DNS nameserver selection and diversity on the APNIC Blog:* DNS nameservers: Service performance and resilience (https://blog.apnic.net/2025/02/04/dns-nameservers-service-performance-and-resilience/) (Geoff Huston, APNIC Blog February 2025)

    59 min

  4. JAN 22

    RISKY BIZ-ness

    Welcome back to PING, at the start of 2025. In this episode, Gautam Akiwate (https://blog.apnic.net/author/gautam-akiwate/), (now with Apple, but at the time of recording with Stanford University) talks about the 2021 Advanced Network Research Prize (https://www.irtf.org/anrp/) winning paper, co-authored with Stefan Savage, Geoffrey Voelker and Kimberly Claffy which was titled "Risky BIZness: Risks Derived from Registrar Name Management". (https://cs.stanford.edu/~gakiwate/papers/risky_bizness_imc21.pdf)The paper explores a situation which emerged inside the supply chain behind DNS name delegation, in the use of an IETF protocol called Extensible Provisioning Protocol or EPP (https://datatracker.ietf.org/doc/html/rfc5730.html). EPP is implemented in XML over the SOAP mechanism, and is how registry-registrar communications take place, on behalf of a given domain name holder (the delegate) to record which DNS nameservers have the authority to publish the delegated zone. The problem doesn't lie in the DNS itself, but in the operational practices which emerged in some registrars, to remove dangling dependencies in the systems when domain names were de-registered. In effect they used an EPP feature to rename the dependency, so they could move on with selling the domain name to somebody else.The problem is that feature created valid names, which could themselves then be purchased. For some number of DNS consumers, those new valid nameservers would then be permitted to serve the domain, and enable attacks on the integrity of the DNS and the web.Gautam and his co-authors explored a very interesting quirk of the back end systems and in the process helped improve the security of the DNS and identified weaknesses in a long-standing "daily dump" process to provide audit and historical data.Read more about RISKY BIZness and the supply chain attack on the web:* The 2021 ANRP paper "Risky BIZness: Risks Derived from Registrar Name Management (https://cs.stanford.edu/~gakiwate/papers/risky_bizness_imc21.pdf)"* 2017 Grand Jury indictment of Zhang et al (https://www.justice.gov/d9/press-releases/attachments/2018/10/30/indictment_zhang_et_al_0.pdf)* 2022 IMC paper "Retroactive Identification of Targeted DNS Infrastructure Hijacking (https://cs.stanford.edu/~gakiwate/papers/imc22-dns_hijacking.pdf)* The prevalence, persistence, and perils of lame delegations (https://blog.apnic.net/2021/03/16/the-prevalence-persistence-perils-of-lame-nameservers/) (APNIC blog, 2021)

    44 min

  5. 12/11/2024

    Post-Quantum Cryptography

    In the last episode of PING for 2024, APNIC’s Chief Scientist Geoff Huston (https://blog.apnic.net/author/geoff-huston/) discusses the shift from existing public-private key cryptography using the RSA and ECC algorithms to the world of ‘Post Quantum Cryptography. These new algorithms are designed to withstand potential attacks from large-scale quantum computers and are capable of implementing Shor’s algorithm (https://en.wikipedia.org/wiki/Shor%27s_algorithm), a theoretical approach for using quantum computing to break the cryptographic keys of RSA and ECC.Standards agencies like NIST are pushing to develop algorithms (https://csrc.nist.gov/projects/post-quantum-cryptography) that are both efficient on modern hardware and resistant to the potential threats posed by Shor’s Algorithm in future quantum computers. This urgency stems from the need to ensure ‘perfect forward secrecy’ for sensitive data — meaning that information encrypted today remains secure and undecipherable even decades into the future.To date, maintaining security has been achieved by increasing the recommended key length as computing power improved under Moore’s Law, with faster processors and greater parallelism. However, quantum computing operates differently and will be capable of breaking the encryption of current public-private key methods, regardless of the key length.Public-private keys are not used to encrypt entire messages or datasets. Instead, they encrypt a temporary ‘ephemeral’ key, which is then used by a symmetric algorithm to secure the data. Symmetric key algorithms (where the same key is used for encryption and decryption) are not vulnerable to Shor’s Algorithm. However, if the symmetric key is exchanged using RSA or ECC — common in protocols like TLS and QUIC when parties lack a pre-established way to share keys — quantum computing could render the protection ineffective. A quantum computer could intercept and decrypt the symmetric key, compromising the entire communication.Geoff raises concerns that while post-quantum cryptography is essential for managing risks in many online activities — especially for protecting highly sensitive or secret data—it might be misapplied to DNSSEC. In DNSSEC, public-private keys are not used to protect secrets but to ensure the accuracy of DNS data in real-time.If there’s no need to worry about someone decoding these keys 20 years from now, why invest significant effort in adapting DNSSEC for a post-quantum world? Instead, he questions whether simply using longer RSA or ECC keys and rotating key pairs more frequently might be a more practical approach.Read more about Post-Quantum Cryptography and DNSSEC on the APNIC blog and the web.* Post-Quantum Cryptography (https://blog.apnic.net/2024/11/29/post-quantum-cryptography/) (Geoff Huston, APNIC Blog November 2024)* [Podcast] Testing Post-Quantum Cryptography DNSSEC (https://blog.apnic.net/2024/07/11/podcast-testing-post-quantum-cryptography-dnssec/) (Podcast July 2024)* A quantum-safe cryptography DNSSEC testbed (https://blog.apnic.net/2024/02/16/a-quantum-safe-cryptography-dnssec-testbed/) (Caspar Schutijser (https://blog.apnic.net/author/caspar-schutijser/), APNIC Blog 2024)* [Podcast] The SIDN Labs post-quantum DNSSEC testbed (https://blog.apnic.net/2024/08/08/podcast-the-sidn-labs-post-quantum-dnssec-testbed/) (Podcast August 2024)*

    1h 6m

  6. 11/27/2024

    Measuring DNSSEC keying "drift" between parent and child

    This time on PING, Peter Thomassen (https://github.com/peterthomassen) from SSE (https://www.securesystems.de/) and DEsec.io (https://desec.io/) discusses his analysis of the failure modes of CDS and CDNSKEY records between parent and child in the DNS. These records are used to provide in-band signalling of the DS record, fundamental to the maintenance of a secure path from the trust anchor to the delegation through all the intermediate parent and grandparent domains. Many people use out-of-band methods to update this DS information, but the CDS and the CDNSKEY records are designed to signal this critical information inside the DNS, avoiding many of the pitfalls of passing through a registry-registrar web service.The problem is, as Peter has discovered, the information across the various nameservers (denoted by the NS record in the DNS) of the child domain can get out of alignment, and the tests a parent zone need to do checking CDS and CDNSKEY information aren't sufficiently specified to wire down this risk.Peter performed a "meta analysis" inside a far larger cohort of DNS data captured by Florian Steurer and Tobias Fiebig at the Max Planck Institute and discovered a low but persisting error rate, a drift in the critical keying information between a zones NS and the parent. Some of these related to transitional states in the DNS (such as when you move registry or DNS provider) but by no means all, and this has motivated Peter and his co-authors to look at improved recommendations for managing CDS/CDNSKEY data, to minimise the risk of inconsistency, and the consequent loss of secure entry path to a domain name.Read more about DNSSEC delegation at the APNIC Blog, and the IETF:* Authenticated bootstrapping of DNSSEC delegations (https://blog.apnic.net/2022/03/08/authenticated-bootstrapping-of-dnssec-delegations/) (NIls Wisiol, APNIC Blog March 2022)* Measurement of CDS/CDNSKEY inconsistencies (https://datatracker.ietf.org/meeting/119/materials/slides-119-dnsop-measurement-of-cdscdnskey-inconsistencies-01) (IETF119 Presentation, March 2024)* Generalised DNS NOTIFY (https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/) (IETF Draft)

    36 min

  7. 11/13/2024

    The IPv6 Transition

    In his regular monthly spot on PING, APNIC’s Chief Scientist Geoff Huston (https://blog.apnic.net/author/geoff-huston/) discusses the slowdown in worldwide IPv6 uptake. Although within the Asia-Pacific footprint we have some truly remarkable national statistics, such as India which is now over 80% IPv6 enabled (https://stats.labs.apnic.net/ipv6/IN)by APNIC Labs measurements, And Vietnam which is not far behind on 70% (https://stats.labs.apnic.net/ipv6/VN) the problem is that worldwide, adjusted for population and considering levels of internet penetration in the developed economies, the pace of uptake overall has not improved and has been essentially linear since 2016 (https://stats.labs.apnic.net/ipv6/XA). In some economies like the US, a natural peak of around 50% capability was reached in 2017 (https://stats.labs.apnic.net/ipv6/US) and since then uptake has been essentially flat: There is no sign of closure to a global deployment in the US, and many other economies.Geoff takes a high level view of the logisitic supply curve with the early adopters, early and late majority, and laggards, and sees no clear signal that there is a visible endpoint, where a transition to IPv6 will be "done". Instead we're facing a continual dual-stack operation of both IPv4 (increasingly behind Carrier Grade Nats (CGN) deployed inside the ISP) and IPv6.There are success stories in mobile (such as seen in India) and in broadband with central management of the customer router. But, it seems that with the shift in the criticality of routing and numbering to a more name-based steering mechanism and the continued rise of content distribution networks, the pace of IPv6 uptake worldwide has not followed the pattern we had planned for.Read more about the IPv6 transition at the APNIC Blog* The IPv6 Transition (https://blog.apnic.net/2024/10/22/the-ipv6-transition/) (Geoff Huston, APNIC Blog November 2024)* The Transition to IPv6 are we there yet (https://blog.apnic.net/2022/05/04/the-transition-to-ipv6-are-we-there-yet/) (Geoff Huston, APNIC Blog May 2022)

    1 hr

  8. 10/30/2024

    A student-led IPv6 deployment at NITK Karnataka

    In this episode of PING, Vanessa Fernandez and Kavya Bhat, two students from the National Institute of Technology Karnataka (NITK) (https://www.nitk.ac.in/) discuss the student led, multi-year project to deploy IPv6 at their campus. Kavya & Vanessa have just graduated, and are moving into their next stages of work and study in computer sciences and network engineering.Across 2023 and 2024 they were able to attend IETF118 and IETF119 and present on their project and it’s experiences to the IPv6 working groups and off-Working Group meetings, in part funded by the APNIC ISIF Project and the APNIC Foundation.This multi-year project is supervised by the NITK Centre for Open-source Software and Hardware (COSH) and has outside review from Dhruv Dhody (ISOC) and Nalini Elkins (Inside Products inc). Former students have also acted as alumni and remain involved in the project as it progresses.We often focus on IPv6 deployment at scale in the telco sector, or experiences with small deployments in labs, but another side of the IPv6 experience is the large campus network, in scale equivalent to a significant factory or government department deployment but in this case undertaken by volunteer staff, with little or no prior experience of networking technology. Vanessa and Kavya talk about their time on the project, and what they got to present at IETF.Read more information on the NITK and their IPv6 deployment project on the APNIC Blog, the IETF website and the APNIC Foundation pages:* Migrating the NITK Surathkal Campus Network to IPv6 (https://apnic.foundation/projects/migrating-nitk-surathkal-campus-network-to-ipv6/) (APNIC Foundation)* How Deploying IPv6 at NITK Led me to IETF (https://blog.apnic.net/2024/07/08/how-deploying-ipv6-at-nitk-led-me-to-ietf/) (Vanessa Fernandez, APNIC Blog)* IPv6 Deployment at NITK (https://datatracker.ietf.org/meeting/118/materials/slides-118-v6ops-ipv6-deployment-at-nitk-00) (IETF118 Presentation)

    28 min
See All (50)

Ratings & Reviews

5
out of 5
4 Ratings

About

PING is a podcast for people who want to look behind the scenes into the workings of the Internet. Each fortnight we will chat with people who have built and are improving the health of the Internet. The views expressed by the featured speakers are their own and do not necessarily reflect the views of APNIC.

Information

  • Creator
    APNIC
  • Years Active
    2021 - 2025
  • Episodes
    50
  • Rating
    Clean
  • Copyright
    © Copyright 2025 PING
  • Show Website
    PING

You Might Also Like

To listen to explicit episodes, sign in.

Stay up to date with this show

Sign in or sign up to follow shows, save episodes, and get the latest updates.
Select a country or region

Africa, Middle East, and India

Asia Pacific

Europe

Latin America and the Caribbean

The United States and Canada