In this episode of PING, APNIC Chief Scientist Geoff Huston (https://blog.apnic.net/author/geoff-huston/) explores the complex landscape of undersea cables. They have always had a component of strategic interest, communications and snooping on communications has been a constant since writing was invented, and the act of connecting two independent nation states by a telegraph wire invokes questions of ownership and jurisdiction right from the start.After the initial physics of running a long distance wire to make an electric circuit was worked out, telegraph services became a vital part of a states economic and information gathering processes. This is why at the beginning of world war 1 and again in world war 2 the submarine cables linking europe out into the world were cut by the British Navy: forcing the communications flows into radio meant it was possible to listen in, and with luck (and some smart people) decode the signals.Modern day fibre optic communications are no different in this regard. Many incidents of cable cutting have simple explanations, not all paths the subsea cables run through are especially deep and in shallow waters near landfall with lots of fish, trawlers cause a lot of damage. But there is now good reason to believe state actors are also disrupting fiber communications by breaking links, and a strong trend now to direct which sources of equipment (from the physical fibre up to the active routing systems) are used for a landfall into any given economy. This in turn is influencing the flow of capital, and the paths taken by subsea fibre systems, as a result of the competing pressures.

In this episode of PING, Shumon Huque (https://blog.apnic.net/author/shumon-huque/) from Salesforce discusses how protocols with extensible flag fields can benefit from regular testing of the values possible in the packet structure. This technique is known as "greasing" and has a strong metaphorical meaning of "greasing the wheels" to ensure future uses aren't blocked by mistaken beliefs about the possible values.Intermediate systems (so-called "middleboxes") have to try and determine "risky" packetflows, and one of the mechanisms they use is to consider unexpected values in the known packetflows as possibly dangerous. This is an over-simplistic approach, and risks "ossifying" a protocol into the range of values which are actively in use now. Protocols usually include extra potential values for flag-fields, settings, options and the like, and these frequently have a large range of "reserved" values which are held in trust in an IANA registry, for future use. Greasing is a proposed mechanism to test out some of these values, and see what happens "on the wire" for the protocol in question.Shumon and his co-author and collaborator Mark Andrews from ISC have been applying the greasing model to the DNS, and we talked about it's history in other protocols, and how in practice greasing can be applied on the global internet.Read more about Shumon, Mark and Roy Arends' greasing activity on the web:* DNS Grease (https://www.ietf.org/archive/id/draft-huque-dnsop-grease-02.html) (IETF draft, in the IETF Datatracker)* the TLS DNSSEC Chain Extension (https://www.rfc-editor.org/rfc/rfc9102.html) ( IETF DANE WG, IETF RFC):* DELEG Testing Report (https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/materials/slides-interim-2024-dnsop-01-sessa-legacy-resolver-compliance-testing-00) (with Roy Arends, DNSOP WG interim meeting presentation, IETF)

In this episode of PING, APNIC Chief Scientist Geoff Huston (https://blog.apnic.net/author/geoff-huston/) discusses a problem which cropped up recently with the location tagging of IP addresses seen in the APNIC Labs measurement system. For compiling national/economic and regional statistics, and to understand the experimental distribution into each market segment, Labs relies on the freely available geolocation databases from maxmind.com, and IPinfo.io -which in turn are constructed from a variety of sources such as BGP data, the RIR compiled resource distribution reports, Whois and RDAP declarations and the self-asserted RFC8805 format resource distribution statements that ISPs self publish.At best this mechanism is an approximation, and with increasing mobility of IP addresses worldwide it has become harder to be confident in the specific location of an IP address you see in the source of an internet dataflow, not the least because of the increasing use of Virtual Private Networks (VPN) and address cloaking methods such as Apple Private Relay, or Cloudflare Warp (although as Geoff notes, these systems do the best they can to account for the geographic distribution of their users in a coarse grained “privacy preserving” manner).Geoff was contacted by Ben Roberts (https://www.linkedin.com/in/ben-roberts-9085592/?originalSubdomain=ke) of Digital Economy Kenya (https://www.digitaleconomy.ke/), a new boardmember of AFRINIC and long-time industry analyst and technical advisor. He’d noticed anomolies with the reporting of Internet statistics from Yemen, which simply could not be squared away with the realities of that segment of the Internet Economy. This in turn has lead Geoff to examine in detail the impact of Starlink on distribution of internet traffic, and make adjustments to his measurement Geolocation practices, which will become visible in the labs statistics as the smoothing functions work through the changes.Low Earth Orbit (LEO) Space delivery of Internet has had rapid and sometimes surprising effects on the visibility of Internet worldwide. The orbital mechanics mean that virtually the entire surface of the globe is now fully internet enabled, albiet for a price above many in the local economy. This is altering the fundamentals of how we “see” Internet use and helps explain some of the problems which have been building up in the Labs data model.Read more about Geolocation and Starlink on the APNIC Blog and on the web:* Geolocation and Starlink (https://blog.apnic.net/2025/09/30/geolocation-and-starlink/) (Geoff Huston, APNIC Blog September 2025)* RFC8805 A Format for Self-Published IP Geolocation Feeds (https://www.rfc-editor.org/info/rfc8805) (IETF RFC website)* The NRO RIR Statistics on delegations (https://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats) with geographic tagging of the delegated entity (NRO Website)* Maxmind GeoIP resources (https://www.maxmind.com/en/solutions/ip-geolocation-databases-api-services) (maxmind website)* IPinfo.io (https://ipinfo.io/) (IPinfo website)* Labs statistics portal (https://labs.apnic.net/measurements/) (APNIC Labs website)

RSSAC047 - a document from the Root Server System Advisory Committee proposed a set of metrics to measure DNS root servers, and the DNS root server system as a whole. the document was approved in 2020, and ICANN worked on an implementation of the metrics as code, and a deployment into 20 points of measurement distributed worldwide.ISC and Verisign, two of the root server operators proposed a review of this measurement and retained SIDN Labs (who are part of the Dutch body operating .NL as a CountryCode Top-Level Domain or ccTLD) to look into how well the measurement was performing.In this episode of PING, Moritz Mullër (https://blog.apnic.net/author/moritz-muller/) from SIDN Labs (https://www.sidnlabs.nl/en) and Duane Wessels (https://blog.apnic.net/author/duane-wessels/) from Verisign (http://verisign.com) respectively, discuss this "measurement of the measurement" exercise, what they found out, and what it may mean for the future of metrics at the DNS Root.It's an interesting "meta conversation" about measuring things which themselves are measurements. We see this all the time in the real world, for example diagnostic imaging machines designed to measure bone density (for osteoporosis checks) require calibration, and when you want to compare a baseline over time that calibration and the specific machine become questions the clinician may want to check, assessing the results. Change machine, you get different sensitivity. So how do you line up the data?Moritz's investigations show that in some respects, the ICANN implementation of RSSAC047 was incomplete, and didn't tell an entirely accurate story about the state of the DNS Root Server System. Also, there are questions of scale and location which means a re-implementation or future improvement is worth discussing.Read more about the DNS Root Server System, Moritz's report, and the RSSAC on the APNIC blog and on the web:* Root-Servers.org website (https://root-servers.org/)* Monitoring highly distributed DNS deployments: Challenges and recommendations (https://blog.apnic.net/2025/04/24/monitoring-highly-distributed-dns-deployments-challenges-and-recommendations/) (APNIC Blog)* RSSAC047: RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System (https://itp.cdn.icann.org/en/files/root-server-system-advisory-committee-rssac-publications/rssac-047-12mar20-en.pdf) (ICANN)* SIDN Labs (https://www.sidnlabs.nl/en)* Verisign Labs (https://www.verisign.com/en_US/company-information/verisign-labs/index.xhtml)

In this episode of PING, APNIC Chief Scientist Geoff Huston (https://blog.apnic.net/author/geoff-huston/) shares a story from the recent AusNOG in Melbourne and connects it to measurement work at APNIC Labs, exploring how modern IP flow control manages ‘fair shares’ of the network.At AusNOG 2025, Geoff attended a talk by Lincoln Dale of Amazon AWS titled “No Packet Left Behind: AWS’s Approach to Building and Operating Reliable Networks (https://www.ausnog.net/events/ausnog-2025/program)”. The presentation examined how AWS scales its data centre networks, highlighting massive investments in high-speed routers and switches to support both global internet services and the vast flows of traffic between servers and other Amazon resources.What AWS doesn’t do is rely on highly complex protocols like Segment Routing over IPv6 (SRv6), Resource Reservation Protocol (RSVP), or other modern traffic engineering techniques unless absolutely necessary. Instead, they use a radically simplified, on-chip model of data management, pushing as much processing as possible into a single VLSI circuit and minimizing the amount of ‘smart’ work in the network. The question is: How can simplifying the IP stack to this extent actually work?Geoff has long been sceptical of higher-layer protocols that try to manage bandwidth reservation and shaping. He recalls an earlier attempt by Digital Equipment Corporation (DEC) to signal congestion with Explicit Congestion Notification (ECN), a mechanism that still exists in the protocol stack and now underpins new bandwidth management approaches such as Apple and Comcast’s ‘L4S’.APNIC Labs has measured how the wider Internet responds to ECN signal (https://stats.labs.apnic.net/ecn)s using an advertising-based model, and the results suggest this approach struggles outside tightly controlled, ‘walled garden’ networks. He contrasts this with advances in flow control through Google’s BBR, now in its third version, which refines the aggressive, bandwidth-seeking behaviour of TCP window management.Read more about the story of IP, flow control and the modern Internet on the APNIC Blog, and the AusNOG website (video recordings of Lincon Dale’s talk and others should be released shortly)* Measuring Explicit Congestion Notification (ECN) (https://blog.apnic.net/2025/09/11/measuring-explicit-congestion-notification/) (Geoff Huston, APNIC Blog)* Notes from AusNOG 2025 (https://blog.apnic.net/2025/09/15/notes-from-ausnog-2025/) (Geoff Huston, APNIC Blog)* The AusNOG 2025 program (https://www.ausnog.net/events/ausnog-2025/program) (AusNOG Website, videos to be released shortly)*

In this episode of PING, Adli Wahid (https://blog.apnic.net/author/adli-w/), APNIC's Security Specialist discusses the APNIC honeypot network, an investment in over 400 collectors distributed throughout the Asia Pacific, collecting data on who is trying to break into systems online and use them for malware, destributed denial of service, and command-and-control systems in the bad traffic economy.Adli discusses how APNIC Members can get access to the results of honeynet traffic capture coming from their network address ranges, and originated from their AS in BGP using the DASH (https://dash.apnic.net/) system. and explores some work planned for the APNIC Honeynet systems to extend their systems coverage.As well as publishing reports on APNIC's Blog and presenting at NOG meetings and conferences, Adli has coordinated information sharing from this collector network with a range of international partners such as the Shadow Server Foundation (https://www.shadowserver.org/). He continues to offer training and technical assistance in security to the APNIC community and works with the CERT, CSIRT and FIRST community at large.Read more about Honeypots, bad traffic and systems security on the APNIC Blog and the web:* Blogs on the honeynet (https://blog.apnic.net/tag/honeynet/) (APNIC Blog)* Adli's posts on the APNIC Blog (https://blog.apnic.net/author/adli-w/)* The APNIC Dashboard for AS Health (DASH) (https://dash.apnic.net/) (requires an APNIC member account)* The Shadow Server Foundation (https://www.shadowserver.org/statistics/) dashboard

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), discusses the economic inevitability of centrality, in the modern Internet. Despite our best intentions, and a lot of long standing belief amongst the IETF technologists, no amount of open standards and end-to-end protocol design prevents large players at all levels of the network (from the physical infrastructure right up to the applications and the data centres which house them) from seeking to acquire smaller competitors, and avoid sharing the space with anyone else.Some of this is a consequence of the drive for efficiency. A part has been fuelled by the effects of Moore’s law, and the cost of capital investment against the time available to recover the costs. In an unexpected outcome, networking has become (to all intents and purposes) “free” and instead of end-to-end, we now routinely expect to get data through highly localised, replicated sources. The main cost these days is land, electric power and air-conditioning. This causes a tendency to concentration, and networks and protocols play very little part in the decision about who acquires these assets, and operates them.The network still exists of course, but increasingly data flows over private links, and is not subject to open protocol design imperatives.A quote from Peter Thiel highlights how the modern Venture Capitalist in our space does not actively seek to operate in a competitive market. As Peter says: “competition is for losers” (https://www.youtube.com/watch?v=3Fx5Q8xGU8k&t=13s) – It can be hard to avoid the “good” and “bad” labels talking about this, but Geoff is clear he isn’t here to argue what is right or wrong, simply to observe the behaviour and the consequences.Geoff presented on centrality to the Decentralised Internet Research Group or DINRG at the recent IETF meeting held in Madrid, and as he observes, “distributed” is not the same as “decentralised” -we’ve managed to achieve the first one, but the second eludes us.Read more about the policy issues of the modern Internet at the apnic labs blog, the DINRG (IETF) and APNIC Blog* Decentralizing Services? (https://datatracker.ietf.org/meeting/123/materials/slides-123-dinrg-decentralising-services-00) (Geoff Huston, talk to DINRG IETF123 Madrid)* Centralization topics at the APNIC Blog (https://blog.apnic.net/tag/centralization/)* DINRG at the IETF Wiki (https://wiki.ietf.org/group/dinrg) (IETF web page)

In this episode of PING, Robert Kisteleki (https://www.ripe.net/about-us/press-centre/publications/speakers/robert-kisteleki/) from the RIPE NCC discusses the RIPE Atlas system (https://www.ripe.net/analyse/internet-measurements/ripe-atlas/) -a network of over 13,000 measurement devices deployed worldwide in homes, exchange points, stub and transit AS, densely connected regions and sparse island states.Atlas began with a vision of the world at night (https://en.wikipedia.org/wiki/Globe_at_Night) -a powerful metaphor for where people are, and where technology reaches. Could a measurement system achieve sufficient density to "light up the internet" in a similar manner? Could network measurement be "democratized" to include internet citizens at large?From it's launch at the RIPE 61 (https://www.ripe.net/meetings/calendar/ripe-61/) meeting held in Rome Italy. with 500 probes based on a small ucLinux device designed as an ethernet converter, to 5 generations of probe hardware and now a soft probe design (https://www.ripe.net/analyse/internet-measurements/ripe-atlas/host-a-probe/) which can be installed on linux, and an "anchor" (https://www.ripe.net/analyse/internet-measurements/ripe-atlas/host-an-anchor/) device which not only sends tests but can receive them, Atlas has become core technology for network monitoring, measurement and research. Rob discusses the history, design, methodology and futures of this system. A wonderful contribution from the RIPE NCC for the community at large.

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), discusses "a day in the life of BGP" (https://blog.apnic.net/2025/06/09/a-day-in-the-life-of-bgp/) -Not an extraordinary day, not a special day, just the 8th of May.What happens inside the BGP system, from the point of view of AS4608, one ordinary BGP speaker on the edge of the network? What kinds of things are seen, and why are they seen?Geoff has been measuring BGP for almost it's entire life as the internet routing protocol, but this time looks at the dynamics at a more "micro" level than usual. In particular there are some things about the rate of messages and changes which points to the problems BGP faces. A small number of BGP speakers produce the vast majority of change, and overall the network information BGP speakers have to deal with as a persisting view of the world increases more slowly. Both kinds of message dynamics have to be dealt with.Can we fix this? Is there even anything worth fixing here, or is BGP just doing fine?Read more about the dynamics of BGP on the APNIC Blog:* A Day in the life of BGP (https://blog.apnic.net/2025/06/09/a-day-in-the-life-of-bgp/) (Geoff Huston June 2025 APNIC Blog)* BGP topics at the APNIC Blog (https://blog.apnic.net/tag/bgp/)* Geoff's archive of BGP data at bgp.potaroo.net (https://bgp.potaroo.net/)

In this episode of PING, Doug Madory (https://blog.apnic.net/author/doug-madory/) from Kentik discusses his rundown of the state of play in secure BGP across 2024 and 2025. Kentik has it’s own internal measurements of BGP behaviour and flow data across the surface of the internet, which combined with the Oregon University curated routeviews archive means Doug can analyse both the publicly visible state of BGP from archives, and Kentik’s own view of the dynamics of BGP change, along side other systems like the worldwide RPKI model, and the Internet Routing Registry systems.Doug has written about this before on the APNIC Blog in May of 2024. (https://blog.apnic.net/2024/05/08/rpki-rov-deployment-reaches-major-milestone/)RPKI demands two outcomes, Firstly that the asset holders who control a given range of Internet Address sign an intent regarding who originates it the ROA, and secondly that the BGP speakers worldwide implement validation of the routing they see, known as Route Origin Validation or ROV. ROA signing is easy, and increases very simply if the delegate uses an RIR hosted system to make the signed objects. ROV is not always simple and has to be deployed carefully so has a slower rate of deployment, and more consequence in costs to the BGP speaker. Doug has been tracking both independently, as well as looking at known routing incidents in the default free zone, and therefore the impact on RPKI active networks, and everywhere else.Read more about RPKI and BGP on the APNIC Blog, the web, and at Doug’s own blogging at Kentik:* RPKI ROV reaches a Major Milestone (https://blog.apnic.net/2024/05/08/rpki-rov-deployment-reaches-major-milestone/) (APNIC Blog, May 2024)* Blog Articles by Doug Madory on the APNIC Blog (https://blog.apnic.net/author/doug-madory/)* The Oregon Routeviews Project (https://www.routeviews.org/routeviews/)* Doug Madory’s blog posts at Kentik (https://www.kentik.com/blog/author/doug-madory/)* A shorter interview with Doug Madory on AS_SET problems (https://blog.apnic.net/2025/04/17/podcast-pulse-internet-measurement-forum-at-apricot-2025-part-2/) features in an earlier PING episode, recorded at the ISOC Pulse “PIMF” session at APRICOT 2025.

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), discusses the root zone of the DNS, and some emerging concerns in how much it costs to service query load at the root.In the absence of cacheing, all queries in the DNS (except ones the DNS system you ask is locally authoritative for anyway) have to be sent through the root of the DNS, to find the right nameserver to ask for the specific information. Thanks to cacheing, this system doesn't drown in the load of every worldwide query, all the time, going through the root. But, even taking cacheing into account there is an astronomical amount of query seen at the root, and it has two interesting qualitiesFirstly, its growing significantly faster than the normal rate of growth of the Internet. We're basically at small incremental growth overall in new users, but query load at the root increases significantly faster, even after some more unexpected loads have been reduced.Secondly, almost all of the queries demand the answer "No, that doesn't exist" and the fact most traffic to the root hunts the answer NO means that the nature of distributed DNS cacheing of negative answers isn't addressing the fundamental burden here.Geoff thinks we may be ignoring some recent developments in proving the contents of a zone, the ZONEMD record which is a DNSSEC signed check on the entire zone contents, and emerging systems to download the root zone, and localise all the queries sent onwards into a copy of the root held in the resolver.Basically, "can we do better" -And Geoff thinks, we very probably can.Read more about the economics of the root zone and ZONEMD at the APNIC Blog and on the web:* The Root of the DNS (https://blog.apnic.net/2025/03/18/the-root-of-the-dns-2/) (Geoff Huston, APNIC Blog March 2025)* ZoneMD: Message digest for DNS Zones RFC8976 (https://www.rfc-editor.org/rfc/rfc8976.html) (IETF RFC)

In this episode of PING, We’re talking to Leslie Daigle (https://www.globalcyberalliance.org/team-members/leslie-daigle/) from the Global Cyber Alliance (GCA) again, discussing GCA’s honeynet project (https://blog.apnic.net/2022/10/07/dealing-with-the-undercurrent-of-unwanted-traffic/). Leslie spoke with PING back in January 2024, and in this episode we re-visit things. Honeynets (or Honey farms) are deliberately weakly protected systems put online, to see what kinds of bad traffic exist out in the global Internet, where they come from and what kinds of attack they are mounting.In the intervening period GCA has continued to develop its honeyfarm, building out it’s own systems images, and can now capture more kinds of bad traffic. They have also bedded in the MANRS community, which is now supported by GCA worldwide.In this episode, Leslie is actually asking more questions than providing answers. If we accept that there is now a persisting problem at scale, what kinds of approaches do we need to take to “get on top” of bad traffic? It used to be we thought of this in terms of technical solutions but increasingly Leslie feels we now need to broaden the conversation and take this into Public policy and governance communities, to understand what kinds of social cost we can bear, and what socially driven objectives we want to drive to. The problem is, this is one of the tasks technologists are often the least equipped to do: Talk to people.GCA is showcasing the AIDE system, reachable at https://gcaaide.org/ (https://gcaaide.org/) as a way of opening up the conversation with national strategic policy makers, and the wider community. It’s a simple economy & region model summarising the state of honeynet detected bad traffic levels worldwide, and helps to set an agenda with which the individual ISPs and routing-active community can engage, for their locus of control.Read more about GCA, Honey nets, AIDE on the APNIC blog and the web:* The invisible War: Why securing Internet Traffic is Everyone’s Responsibility (https://blog.apnic.net/2025/05/20/the-invisible-war-why-securing-the-internet-is-everyones-responsibility/) (Leslie Daigle, APNIC Blog May 2025)* Global Cyber Alliance measurements (https://blog.apnic.net/2024/01/25/podcast-global-cyber-alliance-measurements/) (Podcast, PING at APNIC Jan 2024)* Dealing with the undercurrent of unwanted Traffic (https://blog.apnic.net/2022/10/07/dealing-with-the-undercurrent-of-unwanted-traffic/) (Leslie Daigle, APNIC Blog October 2022)* AIDE: Addressing unwanted Internet Traffic at it’s source (GCA Website)

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), revisits changes underway in how the Domain Name System (DNS) delegates authority over a given zone and how resolvers discover the new authoritative sources. We last explored this in March 2024. (https://blog.apnic.net/2024/03/07/podcast-deleg-in-band-dns-delegation/)In DNS, the word ‘domain’ refers to a scope of authority. Within a domain, everything is governed by its delegated authority. While that authority may only directly manage its immediate subdomains (children), its control implicitly extends to all subordinate levels (grandchildren and beyond). If a parent domain withdraws delegation from a child, everything beneath that child disappears. Think of it like a Venn diagram of nested circles — being a subdomain means being entirely within the parent’s scope.The issue lies in how this delegation is handled. It’s by way of nameserver (NS) records. These are both part of the child zone (where they are defined) and the parent zone (which must reference them). This becomes especially tricky with DNSSEC. The parent can’t authoritatively sign the child’s NS records because they are technically owned by the child. But if the child signs them, it breaks the trust chain from the parent.Another complication is the emergence of third parties to the delegate, who actually operate the machinery of the DNS. We need mechanisms to give them permission to make changes to operational aspects of delegation, but not to hold all the keys a delegate has regarding their domain name.A new activity has been spun up in the IETF (https://datatracker.ietf.org/doc/charter-ietf-deleg/) to discuss how to alter this delegation problem by creating a new kind of DNS record, the DELEG record. This is proposed to follow the Service Binding model defined in RFC 9460. Exactly how this works and what it means for the DNS is still up in the air.DELEG could fundamentally change how authoritative answers are discovered, how DNS messages are transported, and how intermediaries interact with the DNS ecosystem. In the future, significant portions of DNS traffic might flow over new protocols, introducing novel behaviours in the relationships between resolvers and authoritative servers.Read more about DELEG on the APNIC Blog and the web:* DNS and the proposed DELEG record (https://blog.apnic.net/2024/02/08/dns-and-the-proposed-deleg-record/) (APNIC Blog, February 2024)* DELEG Working Group Charter (https://datatracker.ietf.org/doc/charter-ietf-deleg/) (IETF Website)* Service Binding and Parameter Specification via the DNS (https://datatracker.ietf.org/doc/rfc9460/) (IETF RFC 9460)*

In this episode of PING, Professor Cristel Pelsser (https://cristel.pelsser.eu/) who holds the chair of critical embedded systems at UCLouvain (https://www.uclouvain.be/en) Discusses her work measuring BGP and in particular the system described in the 2024 SIGCOMM “best paper” award winning research: “The Next Generation of BGP Data Collection Platforms” (https://cristel.pelsser.eu/publication/alfroy-2024-a/)Cristel and her collaborators Thomas Alfroy, Thomas Holterbach, Thomas Krenc and K. C. Claffy have built a system they call GILL, available on the web at https://bgproutes.io (https://bgproutes.io/) This work also features a new service called MVP, to help find the “most valuable vantage point” in the BGP collection system for your particular needs. GILL has been designed for scale, and will be capable of encompassing thousands of peerings. it also has an innovative approach to holding BGP data, focussed on the removal of demonstrably redundant information, and therefore significantly higher compression of the data stream compared to e.g. holding MRT files.The MVP system exploits machine learning methods to aide in the selection of the most advantageous data collection point reflecting a researchers specific needs. Application of ML methods here permits a significant amount of data to be managed and change reflected in the selection of vantage points.Their system has already been able to support DFOH, an approach to finding forged origin attacks from peering relationships seen online in BGP, as opposed to the peering expected both from location, and declarations of intent inside systems like peeringDB.Read more about Cristel’s work, and their BGP analysis tools on the web:* The Next Generation of BGP Data Collection Platforms (https://cristel.pelsser.eu/publication/alfroy-2024-a/) (Best Paper Award at ACM SIGCOMM 2024 (https://conferences.sigcomm.org/sigcomm/2024/))* bgproutes.io (https://www.bgproutes.io/) (web portal to GILL, MVP and DFOH systems)* Measuring Internet Routing from the Most Valuable Points (https://arxiv.org/pdf/2405.13172)* A system to Detect Forged-Origin Hijacks (DFOH) (https://www.usenix.org/system/files/nsdi24-holterbach.pdf)

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), discusses the history and emerging future of how Internet protocols get more than the apparent link bandwidth by using multiple links and multiple paths.Initially, the model was quite simple, capable of handling up to four links of equal cost and delay reasonably well, typically to connect two points together. At the time, the Internet was built on telecommunications services originally designed for voice networks, with cabling laid between exchanges, from exchanges to customers, or across continents. This straightforward technique allowed the Internet to expand along available cable or fibre paths between two points. However, as the system became more complex, new path options emerged, and bandwidth demands grew beyond the capacity of individual or even equal-cost links, increasingly sophisticated methods for managing these connections had to be developed.An interesting development at the end of this process is the impact of a fully encrypted transport layer on the intervening infrastructure’s ability to manage traffic distribution across multiple links. With encryption obscuring the contents of the dataflow, traditional methods for intelligently splitting traffic become less effective. Randomly distributing data can often worsen performance, as modern techniques rely on protocols like TCP to sustain high-speed flows by avoiding data misordering and packet loss.This episode of PING explores how Internet protocols boost bandwidth by using multiple links and paths, and how secure transport layers affect this process.Read more about multipath network protocols on the web:* IETF Draft on Multipath for QUIC (https://quicwg.org/multipath/draft-ietf-quic-multipath.html) (IETF, April 2025)* Multipath TCP: Revolutionising connectivity one path at a time  (https://blog.cloudflare.com/multi-path-tcp-revolutionizing-connectivity-one-path-at-a-time/)(Cloudflare Blog, January 2025)* RFC 8684 (https://www.rfc-editor.org/rfc/rfc8684) (IETF, 2020)*

Last month, during APRICOT 2025 / APNIC 59 (https://2025.apricot.net/), the Internet Society hosted its first Pulse Internet Measurement Forum (https://pulse.internetsociety.org/blog/pulse-internet-measurement-forum) (PIMF). PIMF brings together people interested in Internet measurement from a wide range of perspectives — from technical details to policy, governance, and social issues. The goal is to create a space for open discussion, uniting both technologists and policy experts.In this second special episode of PING, we continue our break from the usual one-on-one podcast format and present a recap of why the PIMF forum was held, and the last 3 short interviews from the workshop.First we hear a repeat of Amreesh Phokeer's (https://www.internetsociety.org/author/phokeer/) presentation. Amreesh is from the Internet Society and discusses his role in managing the Pulse activity within ISOC. Alongside Robbie Mitchell (https://blog.apnic.net/author/robbie-mitchell/), Amreesh helped organize the forum, aiming to foster collaboration between measurement experts and policy professionals.Next we hear from Beau Gieskens (https://blog.apnic.net/author/beau-gieskens/), a Senior Software Engineer from APNIC Information Products. Beau has been working on the DASH system and discusses his PIMF presentation on a re-design to an event-sourcing model which reduced database query load and improved speed and scaling of the service.We then have Doug Madory (https://blog.apnic.net/author/beau-gieskens/) from Kentik who presented to PIMF on a quirk in how Internet Routing Registries or IRR are being used, which can cause massive costs in BGP filter configuration and is related to some recent route leaks being seen at large in the default free zone of BGP.Finally, we hear from Lia Hestina (https://blog.apnic.net/author/lia-hestina/) from the RIPE NCC Atlas project. Lia is the community Development officer, and focusses on Asia Pacific and Africa for the Atlas project. Lia discusses the Atlas system and how it underpins measurements worldwide, including ones discussed in the PIMF meeting.For more insights from PIMF, be sure to check out the PULSE Forum recording (https://www.youtube.com/watch?v=YlEjEb_o4h0) on the Internet Society YouTube feed

In this episode of PING, APNIC’s Chief Scientist, Geoff Huston (https://blog.apnic.net/author/geoff-huston/), discusses the surprisingly vexed question of how to say ‘no’ in the DNS. This conversation follows a presentation (https://indico.dns-oarc.net/event/52/contributions/1147/) by Shumon Huque at the recent DNS OARC meeting, who will be on PING in a future episode talking about another aspect of the DNS protocol.You would hope this is a simple, straightforward answer to a question, but as usual with the DNS, there are more complexities under the surface. The DNS must indicate whether the labels in the requested name do not exist, whether the specific record type is missing, or both. Sometimes, it needs to state both pieces of information, while other times, it only needs to state one.The problem is made worse by the constraints of signing answers with DNSSEC. There needs to be a way to say ‘no’ authoritatively, and minimize the risk of leaking any other information.NSEC3 records are designed to limit this exposure by making it harder to enumerate an entire zone. Instead of explicitly listing ‘before’ and ‘after’ labels in a signed response denying a label’s existence, NSEC3 uses hashed values to obscure them. In contrast, the simpler NSEC model reveals adjacent labels, allowing an attacker to systematically map out all existing names — a serious risk for domain registries that depend on name confidentiality. This is documented in RFC 7129 (https://datatracker.ietf.org/doc/html/rfc7129).Saying ‘no’ with authority also raises the question of where signing occurs — at the zone’s centre (by the zone holder) or at the edge (by the zone server). These approaches lead to different solutions, each with its own costs and consequences.In this episode of PING, Geoff explores the differences between a non-standard, vendor-explored solution, and the emergence of a draft standard in how to say ‘no’ properly.

At the APRICOT/APNIC59 meeting held in Petaling Jaya in Malaysia last month, The internet society held it's first PIMF meeting. PIMF, or the Pulse Internet Measurement Forum (https://pulse.internetsociety.org/blog/pulse-internet-measurement-forum) is a gathering of people interested in Internet measurement in the widest possible sense, from technical information all the way to policy, governance and social questions. ISOC is interested in creating a space for the discussion to take place amongst the community, and bring both technologists and policy specialists into the same room.This time on PING, instead of the usual one-on-one format of podcast we've got 5 interviews from this meeting, and after the next episode from Geoff Huston at APNIC Labs we'll play a second part, with 3 more of the presenters from this session.First up we have Amreesh Phokeer (https://www.internetsociety.org/author/phokeer/) from the Internet Society who manages the PULSE activity in ISOC, and along with Robbie Mitchell set up the meeting.Then we hear from Christoph Visser (https://www.iijlab.net/en/members/christoff.html) from IIJ Labs in Tokyo, who presented on his measurements of the "Steam" Game distribution platform used by Valve Software to share games. It's a complex system of application-specific source selection, using multiple Content Distribution Networks (CDN) to scale across the world, and allows Christoph to see into the link quality from a public API. No extra measurements required, for an insight into the gamer community and their experience of the Internet.The third interview is with Anand Raje (https://portal.aiori.in/author/anandraje/), from AIORI-IMN, India’s Indigenous Internet Measurement System. Anand leads a team which has built out a national measurement system using IoT "orchestration" methods to manage probes and anchors, in a virtual-environment which permits them to run multiple independent measurement systems hosted inside their platform.After this there's an interview with Andre Robachevsky (https://globalcyberalliance.org/team-members/andrei-robachevsky/) from Global Cyber Alliance (GCA). Andre established the MANRS system, it's platform and nurtured the organisation into being inside ISOC. MANRS has now moved into the care of GCA and Andre moved with it, and discusses how this complements the existing GCA activities.FInally we have a conversation with Champika Wijayatunga (https://icannwiki.org/Champika_Wijayatunga) from ICANN on the KINDNS project. This is a programme designed to bring MANRS-like industry best practice to the DNS community at large, including authoritative DNS delegates and the intermediate resolver and client supporting stub resolver operators. Champika is interested in reaching into the community to get KINDNS more widely understood and encourage its adoption with over 2,000 entities having completed the assessment process already.Next time we'll here from three more participants in the PIMF session: Doug Madory from Kentik, Beau Gieskins from APNIC Information Products, and Lia Hestina, from the RIPE NCC.* PULSE Forum recording () (Internet Society YouTube feed)

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)

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)