https://blog.apnic.net/2019/11/12/stop-using-ridiculously-low-dns-ttls/ Skip to content APNIC Home [icon-squar] MyAPNICAcademyBlogOrbitRExDASH Log in Home Whois and website search [ ] Search Advanced Whois Make a payment Close Search Search APNIC.net OR enter Whois database query [ ] * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * Blog * Help Centre * About + APNIC Region + APNIC Membership + Executive Council + Service updates + Team + Annual Reports + Transparency + APNIC Survey + Corporate Documents + Publications Archive + Careers + Glossary * Contact * Advanced Whois * Make a payment * APNIC Home * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * Blog * Help Centre * About + APNIC Region + APNIC Membership + Executive Council + Service updates + Team + Annual Reports + Transparency + APNIC Survey + Corporate Documents + Publications Archive + Careers + Glossary * Contact Skip to the article Stop using ridiculously low DNS TTLs By Frank Denis on 12 Nov 2019 Category: Tech matters Tags: DNS, Guest Post 16 Comments Tweet Blog home [Time_To_Live_banner-555x202] Domain Name System (DNS) latency is a key component to having a good online experience. And to minimize DNS latency, carefully picking DNS servers and anonymization relays plays an important role. But the best way to minimize latency is to avoid sending useless queries to start with. Which is why the DNS was designed, since day one, to be a heavily cacheable protocol. Individual records have a time-to-live (TTL), originally set by zone administrators, and resolvers use this information to keep these records in memory to avoid unnecessary traffic. Is caching efficient? A quick study I made a couple of years ago showed that there was room for improvement. Today, I want to take a new look at the current state of affairs. To do so, I patched an Encrypted DNS Server to store the original TTL of a response, defined as the minimum TTL of its records, for each incoming query. This gives us a good overview of the TTL distribution of real-world traffic, but also accounts for the popularity of individual queries. That patched version was left to run for a couple of hours. The resulting data set is composed of 1,583,579 (name, qtype, TTL, timestamp) tuples. Here is the overall TTL distribution (the X axis is the TTL in seconds): [ttls-overall]Figure 1 - Overall TTL distribution (the X-axis is the TTL in seconds). Besides a negligible bump at 86,400 (mainly for SOA records), it's pretty obvious that TTLs are in the low range. Let's zoom in: [ttls-0-10000]Figure 2 - TTL distribution from 0 to 10,000 seconds Alright, TTLs above 1 hour are statistically insignificant. Let's focus on the 0-3,600 range: [ttls-0-3600]Figure 3 - TTL distribution from 0 to 3,600 seconds. And where most TTLs sit between 0 and 15 minutes: [ttls-0-900]Figure 4 - TTL distribution from 0 to 800 seconds. The vast majority is between 0 and 5 minutes: [ttls-0-300]Figure 5 - TTL distribution from 0 to 300 seconds. This is not great. The cumulative distribution may make the issue even more obvious: [ttls-cumulative-0-3600]Figure 6 - Cumulative distribution of TTL from 0 to 3,500 seconds. Half the Internet has a 1-minute TTL or less, and three-quarters have a 5-minute TTL or less. But wait, this is actually worse. These are TTLs as defined by authoritative servers. However, TTLs retrieved from client resolvers (for example, routers, local caches) get a TTL that upstream resolvers decrement every second. So, on average, the actual duration a client can use a cached entry before requiring a new query is half of the original TTL. Maybe these very low TTLs only affect uncommon queries, and not popular websites and APIs. Let's take a look: [ttls-jointplot-reg]Figure 7 -- TTL in seconds (X axis) vs. query popularity (Y axis). Unfortunately, the most popular queries are also the most pointless to cache. Let's zoom in: [ttls-jointplot-reg-3600]Figure 8 -- TTL in seconds (X axis) vs. query popularity (Y axis). Verdict: it's really bad, or rather it was already bad, and it's gotten worse. DNS caching has become next to useless. With fewer people using their ISP's DNS resolver (for good reasons), the increased latency becomes more noticeable. DNS caching has become only useful for content no one visits. Also, note that software can interpret low TTLs differently. Why? Why are DNS records set with such low TTLs? * Legacy load balancers are left with default settings. * The urban legend that DNS-based load balancing depends on TTLs (it doesn't). * Administrators wanting their changes to be applied immediately, because it may require less planning work. * As a DNS or load-balancer administrator, your duty is to efficiently deploy the configuration people ask, not to make websites and services fast. * Low TTLs give peace of mind. I'm not including 'for failover' in that list, as this has become less and less relevant. If the intent is to redirect users to a different network just to display a fail whale page when absolutely everything else is on fire, having more than one-minute delay is probably acceptable. CDNs and load-balancers are largely to blame, especially when they combine CNAME records with short TTLs with records also having short (but independent) TTLs: $ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133 A new query needs to be sent whenever the CNAME or any of the A records expire. They both have a 30-second TTL but are not in phase. The actual average TTL will be 15 seconds. But wait! This is worse. Some resolvers behave pretty badly in such a low-TTL-CNAME+low-TTL-records situation: $ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133 This is Level3's resolver, which, I think, is running BIND. If you keep sending that query, the returned TTL will always be 1. Essentially, raw.githubusercontent.com will never be cached. Here's another example of a low-TTL-CNAME+low-TTL-records situation, featuring a very popular name: $ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88 No less than three CNAME records. Ouch. One of them has a decent TTL, but it's totally useless. Other CNAMEs have an original TTL of 60 seconds; the akamai.net names have a maximum TTL of 20 seconds and none of that is in phase. How about one that your Apple devices constantly poll? $ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85 The same configuration as Firefox and the TTL is stuck to 1 most of the time when using Level3's resolver. What about Dropbox? $ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3 safebrowsing.googleapis.com has a TTL of 60 seconds. Facebook names have a 60-second TTL. And, once again, from a client perspective, these values should be halved. How about setting a minimum TTL? Using the name, query type, TTL and timestamp initially stored, I wrote a script that simulates the 1.5+ million queries going through a caching resolver to estimate how many queries were sent due to an expired cache entry. 47.4% of the queries were made after an existing, cached entry had expired. This is unreasonably high. What would be the impact on caching if a minimum TTL was set? [ttls-jointplot-simulated]Figure 10 -- TTL in seconds (X axis) vs. percentage of queries made by a client that already had a cached entry (Y axis). The X axis is the minimum TTL that was set. Records whose original TTL was higher than this value were unaffected. The Y axis is the percentage of queries made by a client that already had a cached entry, but a new query was made and the cached entry had expired. The number of queries drops from 47% to 36% just by setting a minimum TTL of 5 minutes. Setting a minimum TTL of 15 minutes makes the number of required queries drop to 29%. A minimum TTL of 1 hour makes it drop to 17%. That's a significant difference! How about not changing anything server-side, but having client DNS caches (routers, local resolvers and caches...) set a minimum TTL instead? [ttls-jointplot-simulated-client]Figure 11 -- TTL in seconds (X axis) vs. percentage of queries made by a client that already had a cached entry (Y axis). The number of required queries drops from 47% to 34% by setting a minimum TTL of 5 minutes, to 25% with a 15-minute minimum, and to 13% with a 1-hour minimum. 40 minutes maybe a sweet spot. The impact of that minimal change is huge. What are the implications? Of course, a service can switch to a new cloud provider, a new server, a new network, requiring clients to use up-to-date DNS records. And having reasonably low TTLs helps make the transition friction-free. However, no one moving to a new infrastructure is going to expect clients to use the new DNS records within 1 minute, 5 minutes or 15 minutes. Setting a minimum TTL of 40 minutes instead of 5 minutes is not going to prevent users from accessing the service. However, it will drastically reduce latency, and improve privacy (more queries = more tracking opportunities) and reliability by avoiding unneeded queries. Of course, RFCs say that TTLs should be strictly respected. But the reality is that the DNS has become inefficient. If you are operating authoritative DNS servers, please revisit your TTLs. Do you really need these to be ridiculously low? Read: How to choose DNS TTL values Sure, there are valid reasons to use low DNS TTLs. But not for 75% of the Internet to serve content that is mostly immutable, but pointless to cache. And if, for whatever reasons, you really need to use low DNS TTLs, also make sure that cache doesn't work on your website either. For the very same reasons. If you use a local DNS cache such as dnscrypt-proxy that allows minimum TTLs to be set, use that feature. This is okay. Nothing bad will happen. Set that minimum TTL to something between 40 minutes (2400 seconds) and 1 hour; this is a perfectly reasonable range. Adapted from original post which appeared on 00f.net Frank Denis is a fashion photographer with a knack for math, computer vision, opensource software and infosec. Discuss on Hacker News --------------------------------------------------------------------- The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog. 16 Comments 1. mimmus October 6, 2020 at 6:58 pm I just read an article saying that reducing TTL is harmless https://www.researchgate.net/publication/ 224243237_Reducing_DNS_caching Reply | 2. Ted Mittelstaedt November 6, 2020 at 3:18 am The article on TTL reduction is talking about loads on internal DNS servers. Those queries are client queries made over UDP to corporate or other DNS servers, querying internal DNS records used for internal hosts. In that environment a low TTL is beneficial since the clients may be DHCP assigned IP addresses or they may be mobile where their IP address is rapidly changing. Since applications like Microsoft Active Directory use dynamically created DNS records for hosts on the internal network, a low TTL keeps things accurate. This post is talking about EXTERNAL dns serves which are serving names to the general Internet of websites and other hosts where the IP address hardly ever changes. DNS is not that difficult a concept to understand once you wrap you brain around it. But you will NOT learn it with a diet of Youtube videos and 2000 word articles that take 15 minutes to read. Before attempting to post a rebuttal to an article, learn what you are talking about. Reply | 1. Rashmi Singh October 24, 2024 at 7:33 am Most domains these days are hosted on the cloud. Your provider can change the IPs used for a CloudFront geography at any time. In such a scenario, how can you have a higher TTL? Reply | 3. Failover guy January 17, 2021 at 8:38 pm Nice article - has some very good points! Except for failover... Failover is the best argument for low TTL. A smooth failover is impossible without a very low TTL and that's the end of the story. And I'm not talking about something ridiculous like failover with the intent of showing an error page but failover to keep your service reachable. Not to mention it has virtually no downside. Reply | 1. Joe April 27, 2025 at 11:37 am When you have a a planned failover approaching, you lower the TTL in a few gradual increments as the failover time approaches, then after the new service is in place and stable, increase the TTL back to an hour or whatever. Reply | 1. L0L October 11, 2025 at 11:13 pm Planned failover, sure, what about actual failover? Do you also exptect to be notified several hours upfront? XD Reply | 4. P@ February 5, 2021 at 7:05 am Palo firewalls have a 'feature' of being able to use URL's to build ACL's (useful when some sites use multiple ip's or change their ip address). The firewall manages this by polling the names every 15 minutes and generates a table ip -> name mapping. For TTL's of less than 30 minutes, this feature becomes useless due to intermittent dropping of traffic when the ip's change. We're still hopeful Palo will allow the Polling interval to be changed to a lower value. Reply | 5. Martin P. Hellwig May 15, 2021 at 8:49 am Really? A UDP query will return around half a kb or so of data, even if you in the extreme would require every request for a hostname to be prefixed with a query to the authoritative server, this really should not be a problem at all for that service. Yes of course you want to do some caching, but a cache invalidation of 30 seconds is perfectly reasonable for such a low amount of data over the network. Especially if the potential consequence of not doing so is having a connection hanging for the timeout you suggest, this can easily have cascading failure consequences, as proven by a lot of outages that have DNS failures at their root and take hours to recover. Reply | 6. Meh Bah July 7, 2021 at 1:05 pm Oh boo hoo the clients are seeing extra delays of tens of milliseconds. Like they'll notice when the webpages usually take many magnitudes longer due to being heavy laden with videos, images, javascript and ads. For example if a client uses Google's DNS (e.g. 8.8.8.8 ). Google has many servers all over the world so in most cases that's within tens of milliseconds away, and if it's a popular DNS query it'll be cached most of the time. In contrast the users are more likely to notice if one day their clients kept using the wrong IP for 40 minutes as per your proposal. Reply | 7. raf August 2, 2021 at 8:58 pm Ha, I use a TTL of 1 week! I assume that I'll have a week's notice before I need to make any major changes. I can reduce the TTL temporarily need needed and then put it back afterwards. Reply | 8. twitter user May 20, 2022 at 8:21 am lol, and furthermore lmao it is 2022 my dude, we can afford low ttls to allow for more responsive disaster recovery and failover. imagine the facebook bgp outage but they were out for an entire week because they used a long ttl. the company would be donezo Reply | 9. Richard November 9, 2022 at 4:08 pm The way of measuring this affects (and skews) the outcome. DNS queries with low TTLs are requested more frequently and because of that, you are seeing more of them pass through your patched DNS relay, which you only left running for a few hours instead of for at least the max TTL you wanted to measure. Reply | 10. M November 10, 2022 at 8:37 pm "oh boo hoo" "lmao" "it is 2022 my dude" Yeah, some quality engineers here -- I'll be paying atention to _them_... Reply | 11. Stephen June 19, 2023 at 2:13 pm Accurate description of the problem by author. Thanks for the mention of dnscrypt-proxy. The usual commercial software we have just can't do that, whereas typically OSS easily can. Reply | 12. David Spector April 18, 2024 at 11:43 pm I set a low zone ttl in order to avoid ridiculous delays of a day or more in propagating throughout the world. I set it back manually. A simple fix would be an automatic management feature to set the ttl low for a fixed amount of time, then set it high again. The low TTL would "push" changes out to the world. Reply | 13. David Spector October 13, 2025 at 10:28 pm Some of the worst offenders are some of the biggest users. Add some feedback mechanism to standards committees and industry coalitions and these TTLs are likely to come down. Another solution is to stop dismissing DNS communication upstream. A web developer knows that they have changed their DNS Zone and need it propagated to all users of that Zone. Surely an efficient way to 'push' a zone forward to all active resolvers can be invented?! After all, it would only be used once each time full propagation is wanted, not constantly, the way TTL is implemented. Reply | Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] [ ] Save my name and email in this browser for the next time I comment. [ ] Yes, add me to your mailing list [ ] Notify me of follow-up comments via email. You can also subscribe without commenting. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Top Get Updates Please leave this field empty[ ] Email *[ ] Show options [Subscribe!] Select list(s):[ ] Daily[*] Weekly Thanks for subscribing! Check your inbox or spam folder to confirm your subscription. Authors * Adli Wahid * Aftab Siddiqui * Geoff Huston * George Michaelson * Jen Linkova * Jia Rong Low * Job Snijders * Kathleen Moriarty * Ulrich Speidel * Vitaly Kamluk * A Khalil Azizi * A S M Rizvi * AbdelRahman Abdou * Abhishek Jain * Abu Sufian * Achie Atienza * Adam Gosling * Adam McFillin * Adam Oest * Adeel Sadiq * Adiel Akplogan * Adisorn Lertsinsrubtavee * Adli Wahid * Adrian Farrel * Adrian Wan * Afifa Abbas * Afsheen Saadat * Aftab Siddiqui * Agustin Formoso * Ahmad Darki * Ajay Kumar * Akimichi Ogawa * Alain Aina * Alan Mauldin * Albert Gran Alcoz * Alden Hilton * Alec Muffett * Alejandro Acosta * Alex Band * Alex Boten * Alex Turing * Alex Yen * Alexander Azimov * Alexander Kozlov * Alfred Arouna * Ali Abedi * Ali Norouzi * Amanda H A Watson * Amaury Van Bemten * Amreesh Phokeer * Amrita Choudhury * Anand Buddhdev * Anant Shah * Andra Lutu * Andre Gelderblom * Andreas Dewes * Andreas Reuter * Andree Toonk * Andrei Robachevsky * Andrew Ayer * Andrew Campling * Andrew Cormack * Andrew Cushen * Andrew Ferguson * Andrew Gray * Andrew Sullivan * Andrew Toimoana * Andrijana Todosijevic * Andy Mindnich * Andy Newton * Anju Mangal * Anna Maria Mandalari * Annaliza Mulingbayan * Anosh Khan * Anriette Esterhuysen * Anthony Lee * Anton Strydom * Anup Changaroth * Anurag Bhatia * APNIC * Apoorv Shukla * Arash Molavi Kakhki * Arian Niaki * Aris Tzermias * Arjuna Sathiaseelan * Arlin Kokkelmans * Arth Paulite * Arthur Gilly * Artyom Gavrichenkov * Arun Neelicattu * Asad Ali * Asanka Sayakkara * Ashil Oogarah * Ashwin Kumar * Ashwin Rangan * Athina Fragkouli * Audrey Randall * Aurelien Aptel * Austin Hounsel * Austin Ruckstuhl * Avery Pennarun * Ayesha Iftikhar * Aysha Labiba * Ayush Mishra * Azfar Adib * Azhar Khuwaja * Azura Mat Salim * Baojun Liu * Baptiste Jonglez * Barry Greene * Bart Hogeveen * Basileal Imana * Bastian Kanbach * Batmagnai Erdene * Bayar Batjargal * Beau Gieskens * Ben Cox * Ben Du * Ben Schwartz * Benjz Gerard Sevilla * Benno Overeinder * Berislav Todorovic * Bert Hubert * Bhadrika Magan * Bhumika Sapkota * Bikram Shrestha * Bill Hess * Bill Stearns * Bill Woodcock * Bjorn Teigen * Blake Anderson * Blandine Cousin * Blas Trigueros * Brandon Hitzel * Brenda Buwu * Brenden Kuerbis * Brent Carey * Brett Bralley * Brian Carpenter * Brian Nisbet * Brian Trammell * Brianna Boudreau * Bruce Davie * Bruce Spang * Byambajargal Jamsran * Byron Ellacott * Byungjin Jun * Cameron Steel * Carsten Strotmann * Caspar Schutijser * Cecilia Testart * Cengiz Alaettinoglu * CF Chui * Champika Wijayatunga * Charith Amarasinghe * Che-Hoo Cheng * Cheeyong Tay * Cherie Lagakali * Chia Ling (Jolin) Chan * Chika Yoshimura * Ching-Heng Ku * Chris Amin * Chris Buckridge * Chris Grundemann * Chris Parker * Chris Ritzo * Chris Siebenmann * Christian Giese * Christian Huitema * Christoph Dietzel * Christopher Hawker * Chuan Jiang * Ciprian Popoviciu * Clarence Filsfils * Claudio Jeker * Clemens Mosig * Colin Perkins * Constance Bommelaer * Constantin Sander * Constanze Dietrich * Cordian Daniluk * Craig Miller * Craig Ng * Craig Rowland * Dale Roberts * Dan Fidler * Dan Groshev * Dan Li * Daniel Dib * Daniel Kopp * Danilo Giordano * Danny Alex Lachos Perez * Danny Pinto * Daryll Swer * Dashzeveg Baatartsogt * Dave Mill * Dave Phelan * David Anderson * David Burkett * David Dawson * David Holder * David Holsgrove * David Huberman * Dean Pemberton * Debashis Pal * Debopam Bhattacherjee * Deepak Vasisht * Denesh Bhabuta * Dennis Baaten * Desiree Miloshevic * Dewangga Alam * Dewole Ajao * Dhruv Dhody * Di Ma * Diego Pino Garcia * Dinesh Bhatia * Diptanshu Singh * Dirk Doesburg * Dirk Trossen * Dmytro Shypovalov * Donatas Abraitis * Donika Mirdita * Doug Madory * Doug Montgomery * Dr Bahaa Al-Musawi * Dr Govind * Drikus Brits * Duane Wessels * Duncan Macintosh * E. Marie Brierley * Ebrima Jaw * Ed Horley * Edward Lewis * Edwin Sandys * Ege Cem Kirci * Eliot Lear * Elizabeth Krumbach Joseph * Ellisha Heppner * Elly Tawhai * Elvin Prasad * Emile Aben * Emily Gallarde * Emily Stark * Emir Beganovic * Eneken Tikk * Enno Rey * Enric Pujol * Eric Lawrence * Eric Loos * Eric Vyncke * Erik Hjelmvik * Erik Rye * Erin Scherer * Eshaan Bansal * Esteban Carisimo * Eugene Bogomazov * Eunju Kang * Eunju Pak * Eyal Estrin * Fabian Bustamante * Fahad Hilal * Fakrul Alam * Farha Diba * Fenglu Zhang * Ferenc Fejes * Fernando Gont * Flavia Salutari * Flavio Luciani * Florentin Rochet * Florian Holzbauer * Florian Steurer * Florian Streibelt * Foy Shiver * Francesco Ferreri * Francesco Sassi * Franck Martin * Francois Michel * Frane Maroevic * Frank Denis * Frank Herberg * Franziska Lichtblau * Fred Christopher * Fred Templin * Fredrik Lindeberg * Ganga R Dhungyel * Gaurab Raj Upadhaya * Gautam Akiwate * Gavin Reid * Gavin Tweedie * Geoff Huston * George Kuo * George Michaelson * George Odagi * George Sadowsky * George Salisbury * Giacomo Giuliari * Gianmarco Pagani * Gina Mahe * Giovane Moura * Gomer Padong * Gonchig Altansukh * Gordon King * Greg Ferro * Greg Hankins * Gregory Mounier * Guangliang Pan * Guillermo Baltra * Guoliang Yang * GZ Kabir * Ha Dao * Haisheng Yu * Han Zhang * Hanna Kreitem * Hannah Durack * Hanno Bock * Hans Petter Holen * Harish Chowdhary * Haya Schulmann * Helen Hollins * Herbert Wolverson * Herve Clement * Hideyuki Sasaki * Hinne Hettema * Hiroki Kawabata * Hiroko Kamata * Hiromu Shiozawa * Hisham Ibrahim * Hoang Nguyen Phong * Holly Bergen * Houlin Zhao * Hyeonmin Lee * Hyojoon Kim * Ignacio Castro * Ihita Gangavarpu * Ike Kunze * Ilker Nadi Bozkurt * Imtiaz Rahman * Indya Bolton * Ioana Livadariu * Italo Cunha * Ivan Ristic * Ivana Tomic * Ivo A. Ivanov * Ivy Yip * Izumi Okutani * Jaclyn Knight * Jacob Davis * Jacob Ginesin * Jahangir Hossain * Jake Bauer * Jake Flint * Jake Holland * James Ah Wai * James Bensley * James Kettle * James Pavur * James Richards * James Shank * Jamie Gillespie * Jan Doskocil * Jan Harm Kuipers * Jan Ruth * Jan Schaumann * Jan Zorz * Jan-Piet Mens * Jane Yen * Jannik Peters * Jari Arkko * Jason Livingood * Jason Smith * Jasper den Hertog * Jawad Ahmed * Jay Daley * Jay Ford * Jeff Chan * Jeff Fry * Jeff Man * Jeff Osborn * Jen Linkova * Jenine Beekhuyzen * Jens Link * Jeremy Harrison * Jerry Lundstrom * Jessica Shen * Jessica Wei * Jethro Webston * Jia Rong Low * Jilong Wang * Jim Cowie * Jim Forster * Jim Vella * Jimmy Lim * Jing Qiao * Jinghua Bai * Jinwei Zhao * Joanna Kulesza * Joao L. Sobrinho * Joao Luis Silva Damas * Joao M. Ceron * Job Snijders * Joel Jaeggli * Johanna Amann * Johannes Krupp * Johannes Weber * Johannes Zirngibl * John Althouse * John Bambenek * John Curran * John Garrity * John Jack * John Jason Brzozowski * John Kristoff * John Scudder * John Welborn * Jonathan Brewer * Jonathan Magnusson * Jordan Carter * Jordan Jueckstock * Jordi Paillisse * Jordi Palet Martinez * Josef Gustafsson * Joseph Salowey * Joy Chan * Joyce Chen * Juan Ramon Santana * Juha Saarinen * Julia Evans * Julian Martin Del Fiore * Julien Gamba * Jun Murai * Justin Loye * Justin Ryburn * Justin Wilson * Kaajal Kumar * Kaan Onarlioglu * Kanagaraj Krishna * Karan Sharma * Karel Hynek * Karl Lovink * Karla Skarda * Kasek Galgal * Kashyap Thimmaraju * Katherine Izhikevich * Kathleen Moriarty * Katsuyasu Toyama * Kavya Bhat * Kazunori Fujiwara * Ke Ma * Keisuke Kamata * Kemal Sanjta * Kenjiro Cho * Kenny Huang * Kenrick Lin * Kensuke Fukuda * Kevin Backhouse * Kevin Bock * Kevin Jin * Kevin Ku * Kevin Meynell * Kevin Vermeulen * Kevon Swift * Keyu Man * Khee Hong Loke * Khwaja Zubair Sediqi * Kijush Maharjan * Kiruthika Devaraj * Klee Aiken * Kobayashi Masayuki * Koen van Hove * Koichi Kunitake * Koki Nakagawa * Konrad Wolsing * Korian Edeline * Kostas Zorbadelos * Kris Shrishak * Kurt Lindqvist * Kyle Carter * Kyle Drake * Kyle Schomp * Lan Wei * Lari Huttunen * Lars Prehn * Lars-Johan Liman * Leandro Bertholdo * Leandro Navarro * Lee Howard * Leigh Metcalf * Lenore Zuck * Leo Vegoda * Leonid Todorov * Leslie Daigle * Lia Hestina * Liang Wang * Liang Zhao * Liangcheng Yu * Libin Liu * Lindsay Graham * Linjian Song * Lisa Bruder * Lisa Corness * Lisandro Ubiedo * Liz Izhikevich * Loba Olopade * Lorenzo Cogotti * Louise Tromp * Lu Zhang * Luca Sani * Lucas Pardue * Luke Thompson * Luuk Hendriks * Lyubomir Yanev * M. Yasir M. Haq * Maarten Botterman * Maarten Wullink * Maciej Korczynski * Madeline Carr * Maemura Akinori * Mai Thu Thuy * Mailelatamai Halatuituia * Major Hayden * Makito Lay * Mallory Knodel * Manaf Gharaibeh * Mannat Kaur * Mansour Ganji * Marc Bruyere * Marcin Nawrocki * Marco Chiesa * Marco Cilloni * Marco Hogewoning * Marcus Brinkmann * Marcus Keane * Marek Majkowski * Maria Namestnikova * Maria Theresa Perez * Mariano Scazzariello * Mariko Kobayashi * Marilyn Zhang * Mario Loffredo * Mark Andrews * Mark Karpilovskij * Mark Nottingham * Mark Prior * Mark Smith * Mark Tinka * Markus Dahlmanns * Markus Legner * Markus Sosnowski * Marta Burocchi * Marten Porte * Martin Hannigan * Martin Hoffmann * Martin Langer * Martin Thomson * Martin Winter * Martino Trevisan * Mary Rose Ofianga-Rontal * Masanori Yajima * Masataka Mawatari * Massimo Candela * Mat Ford * Matsuzaki Yoshinobu * Matt Larson * Matt Oh * Matt Palmer * Matt Ringel * Matt Stith * Matthew James * Matthew Thomas * Matthias Wichtlhuber * Matthijs Mekking * Mattijs Jonker * Max von Hippel * Maxime Mouchet * Maxime Piraux * Md Abdul Awal * Md Mahedi Hasan * Md. Kamruzzaman Khan * Megan Baker * Melchior Aelmans * Melody Bendindang * Merike Kaeo * Metin Acikalin * Michael Clare * Michael Kende * Michael Patterson * Michael Rabinovich * Michael Schapira * Michael Schneider * Michael Waidner * Michelle Thorne * Mika Kerttunen * Mike Hollyman * Mike Hwang * Mike Kosek * Min Sung Jung * Mingming Zhang * Mingwei Zhang * Mingxuan Liu * Minzhao Lyu * Miwa Fujii * Mohamad Dikshie Fauzie * Mohamed Awnallah * Mohamed Boucadair * Mohamed Kassem * Mohammad Larosh Khan * Molay Ghosh * Momoka Yamamoto * Moritz Muller * Mubashir Sargana * Muhammad Moinur Rahman * Muhammad Yasir Shamim * Mujtaba Hussain * Mukhammad Andri Setiawan * Munkhbat Gansukh * Muzamer Mohd Azalan * Nachiket Kondhalkar * Nadir Hassan * Nafeez Islam * Nalini Elkins * Narayan G * Narelle Clark * Natale Bianchi * Nate Sales * Nathalie Romo Moreno * Nathalie Trenaman * Neeti Biyani * Neta Rozen Schiff * Nick Buraglio * Nick Hilliard * Nick Janetakis * Nick Nugent * Nico Schottelius * Nicola Rustignoli * Nicole Wajer * Niels Provos * Nihit Tandon * Niklas Vogel * Nikolai Hampton * Nikos Kostopoulos * Nils Wisiol * Nina Bargisen * Nirav Atre * Nooshin Eghbal * Nor Fadzilah Abdullah * Nowmay Opalinski * Nurul Islam Roman * Nusenu * Nyamkhand Buluukhuu * Oanh Nguyen * Oky Tria Saputra * Olafur Gudmundsson * Olamide Omolola * Oliver Gasser * Oliver Michel * Olivier Hureau * Olivier Tilmans * Omar Alrawi * Omar Ansari * Ondrej Caletka * Ondrej Sury * Otto Moerbeek * Pablo Hinojosa * Paolo Lucente * Paresh Khatri * Parkpoom Tripatana * Pasan Lamahewa * Pascal Huppert * Patrick McManus * Patrick Sattler * Patrik Faltstrom * Paul Dale * Paul Grubbs * Paul Wilson * Pavel Odintsov * Pawel Kowalik * Pawel Foremski * Pawel Urbanek * Pedro Marcos * Pengxiong Zhu * Pete Sclafani * Pete Stevens * Peter Blee * Peter Hansteen * Peter Lowe * Peter Maynard * Peter Peele * Petr Spacek * Petros Gigis * Phil Lavin * Phil Mawson * Philip Homburg * Philip Paeps * Philip Smith * Philipp Jeitner * Philipp Richter * Pier Carlo Chiodi * Pim van Pelt * Piotr Kijewski * Platon Kotzias * Pouyan Fotouhi Tehrani * Pranav Kondala * Praneet Kaur * Pubudu Jayasinghe * Qasim Lone * Quincy Liao * Rachee Singh * Rafael Cintra * Raffaele Sommese * Raffaele Zullo * Rahul Makhija * Rajnesh Singh * Ralph Dolmans * Ralph Holz * Ram Sundara Raman * Ramakrishna Padmanabhan * Rami Al-Dalky * Ramin Yazdani * Ran Ben Basat * Ranysha Ware * Raphael Hiesgen * Raquel Gomez * Raquel Rugani Lage * Raskia Nayanajith * Ray Bellis * Rebekah Houser * Remi Gacogne * Rene Bakker * Rene Wilhelm * Renee Burton * Richard Cziva * Richard Jimmerson * Richard Nelson * Richard Patterson * Richard Read * Rick McElroy * Rishabh Chhabra * Rob Schult * Robbie Mitchell * Robert Alexander * Robert Kisteleki * Robin Marx * Roderick Fanou * Roger Meyer * Rohana Palliyaguru * Roland Meier * Roland van Rijswijk-Deij * Rolf Winter * Romain Fontugne * Ron Bonica * Ron Winward * Ronald van Kleunen * Rowena Schoo * Roy Arends * Rudiger Birkner * Russ White * Ryan Beckett * Ryan Gerstenkorn * Ryo Nakamura * Sachin Ashok * Safiqul Islam * Said Jawad Saidi * Said Zazai * Saima Nisar * Sajidur Rahman Rabby * Salvatore Cuzzilla * Sam Sham * Samaneh Tajalizadehkhoob * Samantha Douglas * Samantha Frank * Samit Jana * Samuel Steffen * Sandra Davey * Sandra Siby * Sangeetha Abdu Jyothi * Sanjaya * Sara Dickinson * Sarah Escandor-Tomas * Sarah McAree * Sarmad Hussain * Sarvesh Mathi * Sasha Romijn * Satadal Sengupta * Satoru Matsushima * Satoru Tsurumaki * Sayda Kamrun Jahan Ripa * Scott Hollenbeck * Scott Shenker * Sebastian Castro * Sebastian Neef * Sebastian Zander * Sebastien Meriot * Seiichi Kawamura * Seluvaia Kauvaka * Seth Schoen * Shah Sahari * Shahee Mirza * Shahzeb Mustafa * Shamim Reza * Shamsullah Shams * Shane Alcock * Shane Kerr * Sharada Yeluri * Sharat Chandra Madanapalli * Shayan Azizi * Sheetal Kumar * Sheikh Md Seum * Shermaine Yung * Sherry Shek * Sheryl Hermoso * Shian-Shyong Tseng * Shinoj Pittandavida * Shishio Tsuchiya * Shivan Sahib * Shoko Nakai * Shu Hao Tung * Shuai Hao * Shucheng Liu * Shumon Huque * Shusei Tomonaga * Shyam Krishna Khadka * Siena Perry * Simon Baroi * Simon Bauer * Simran Patil * Siva Kesava * Sivaram Ramanathan * Sofia Silva Berenguer * Sonam Keba * Song Bing * Spiros Thanasoulas * Srikanth Sundaresan * Srimal Andrahennadi * Stanley Osao * Stefan Mehner * Stefan Ubbink * Steinthor Bjarnason * Stephan Marwedel * Stephane Bortzmeyer * Stephen McQuistin * Stephen Ryan * Stephen Strowes * Steve Crocker * Steve Santorelli * Stijn Pletinckx * Subha Shamarukh * Subhashini Kadurugasyaya * Sue Graves * Suetena Faatuuala Loia * Suksit Sripitchayaphan * Sunny Chendi * Suresh Krishnan * Susan Forney * Suvam Basak * Svaradiva Devi * Swapneel Patnekar * Swaran Ravindra * Sylvain Cortes * Sylvia Cadena * Szymon Trocha * Taejoong Chung * Taiji Kimura * Talha Paracha * Tan Kean Siong * Tan Tin Wee * Tanya Shreedhar * Tashi Phuntsho * Teav Sovandara * Temitope Lawal * Terry Sweetser * Teun Vink * Thein Myint Khine * Theo Jepsen * Theophilus A. Benson * Thijs van den Hout * Thomas Holterbach * Thomas King * Thomas Koch * Thomas Krenc * Thomas Liske * Thomas Millar * Thomas Patzke * Thomas Scheffler * Thomas Wirtgen * Thy Boskovic * Thymen Wabeke * Tianxiang Dai * Tim Bruijnzeels * Tim Chown * Tim Fiola * Tim Raphael * Timm Bottger * Timo Longin * Timothy Hildred * Timothy Winters * Tiong Beng Ng * Tobias Fiebig * Todd Arnold * Tom Barbette * Tom Carpay * Tom Coffeen * Tom Do * Tom Harrison * Tom Hollingsworth * Tom Krizek * Tom Perrine * Tomek Mrugalski * Tommaso Caiazzi * Tomoaki Tani * Tony Finch * Tony Li * Tony Scheid * Tony Smith * Tony Tauber * Torsten Zimmermann * Trinh Viet Doan * Truong Khanh Huyen * Tuan Nguyen * Tugsorshikh Badarch * Tushar Swamy * Ulafala Viliamu * Ulrich Hauser * Ulrich Speidel * Usama Naseer * Uta Meier-Hahn * Vanessa Maria Fernandes * Vashkar Bhattacharjee * Vasileios Giotsas * Vasileios Kotronis * Vasilis Chryssos * Venkat Arun * Veronika McKillop * Vesna Manojlovic * Vicky Risk * Vijay Sivaraman * Vijay Varadharajan * Viktor Dukhovni * Vinay Kumar * Vincent Bernat * Vincentas Grinius * Vitaly Kamluk * Vittorio Bertola * Vivek Nigam * Vivien Maidaborn * W K Shiu * Wang Hao * Wanqing Tu * Warren Finch * Warren Kumari * Wassie Goushe * Wataru Ohgai * Wayne Thayer * Wen-Tsung Chang * Werachart Muttitanon * Wes Hardaker * Wilaiwan Phanarin * Wilhelm Boeddinghaus * Willem Toorop * William Lu * Willy Sutrisno * Winfried Tilanus * Wita Laksono * Wout de Natris * Wouter de Vries * Xiang Li * Xiao Zhang * Xiaohong Deng * Xiaoqi Chen * Xing Li * Xinlei Yang * Xuewei Feng * Yali Liu * Yeo Lee Chin * Yevheniya Nosyk * Yi Cao * Yihao Chen * Yiming Zhang * Ying Tian * Ying-Chu Chen * Yoshibumi Suematsu * Yoshinori Takesako * Yoshitaka Aharen * Younghwan Choi * Yuedong Zhang * Yunfei Ma * Yurie Ito * Yury Zhauniarovich * Yuta Takata * Yuxiang Yang * Zachary Bischof * Zaid Ali Kahn * Zaifeng Zhang * Zain Shamsi * Zen Ng * Zeqi Lai * Zhenyu Li * Zhiyi Chen * Zili Meng * Zinan Lin * Zolzaya Shagdar Show All (990) Show Pinned (10) Tags * APNIC Foundation * APNIC Training * Australia * BGP * capacity development * CERTs * China * DNS * DNSSEC * Event Wrap * Guest Post * How to * IANA * ICANN * IETF * IGF * India * Indonesia * Internet Governance * IPv4 * IPv6 * ISIF Asia * ITU * IXPs * Japan * measurement * networking * NOGs * NRO * opinion * Pacific * peering * podcast * Policy * RIPE NCC * RIRs * ROAs * routing * RPKI * security * TCP * Three of the best * TLS * tools * Whois Related Articles * domain verification ftDomain verification using DNS by Shivan Sahib June 26, 2023 Guest Post: Outlining 'good' ways of doing domain verification using DNS * telemetry_FTBuilding a host telemetry solution using Tailscale by Nick Buraglio March 10, 2025 Guest Post: How to collect and analyse host flow data for network traffic insights. * honeypots-ftUsing honeybuckets to characterize cloud storage... by Katherine Izhikevich November 4, 2024 Guest Post: Researchers investigate the methods and frequency with which attackers target poorly secured cloud storage buckets. * malicious-domain_FTAssessing the risk of new .nl registrations using RegCheck by Thymen Wabeke March 30, 2023 Guest Post: New tool helps to identify potentially malicious domain name registrations. APNIC Home Connect with us * Facebook * Twitter * YouTube * Flickr * Weibo * Slideshare * LinkedIn * RSS (c) 2026 APNIC ABN 42 081 528 010 * Privacy * Contact * Help Centre * NRO News * Service Status * Careers * Feedback