Coder Legion - Recent posts tagged dns

Drill the Safe Open: How IANA's 2020 Root Key Ceremony Ran Four Days Late

Mon, 26 Oct 2026 15:36:01 +0000

In February 2020 the safe holding the internet's root signing key would not open. IANA's published, hand-initialed ceremony scans show the custody behind the cryptography: a repair script written before anyone drilled, and a signing that took four minutes and fifteen seconds.

Page 6 of the script is a table with four columns: Step, Activity, Initials, Time. In step 5 a locksmith replaces a combination lock, and the first task on the list reads "a) Drill the lock/safe open." Beside it, in blue pen, someone has initialed the box and written a time: 21:48+1.

The safe is Equipment Safe #1 in the Key Management Facility that IANA runs in El Segundo, California. It holds the hardware security modules that keep the private half of the root zone's key-signing key, the trust anchor that validating resolvers chain every signed DNS answer back to. In February 2020 it would not open. IANA publishes the paperwork from its key ceremonies, scanned with the handwriting left in, so the story of how it got into its own safe can be read page by page, initials and all.

Most writing about the root key ceremony is about cryptography. The paperwork is mostly about custody: who held what, who watched, and what got written down when something went wrong. That February the cryptography took four minutes and fifteen seconds. Getting into the safe took most of four days.

How a ceremony runs

The root zone is signed in quarters, and the key-signing key is brought out of its safe four times a year to sign the keys for the next one. The rule in force in 2020, in IANA's DNSSEC Practice Statement, was that each quarter's ceremony is held "approximately 60 days but no later than 33 days, before the time cycle commences."

The people are set out in roles. A Ceremony Administrator runs the script and an Internal Witness keeps the record. Safe Security Controllers hold the combinations, two people for each of the two safes: the Equipment Safe with the hardware, and the Credentials Safe with the safe deposit boxes. Crypto Officers hold the keys to those boxes. The Practice Statement describes "successive barriers in three tiers, requiring at least seven trusted persons from four different roles," and activating a hardware module "requires three out of seven Crypto Officers to extract activation material from above safe deposit boxes using their physical key." The Crypto Officers are Trusted Community Representatives, picked from statements of interest that IANA solicits from the internet community, and its roster page states the rule that keeps them independent: "Persons considered directly affiliated with PTI, ICANN or VeriSign may not become a Trusted Community Representatives."

The script's preamble says how the room behaves. "CA reads each step aloud prior to its performance." "Upon completion of each step, IW announces the time of completion, records the completion time, and initials their copy of the script." And then the paragraph the rest of this story runs on:

Ceremony participants who notice a problem or an error during the ceremony should interrupt the ceremony. Ceremony participants agree on a resolution before proceeding ... Unplanned events (exceptions) during the ceremony are evaluated, documented, and acted upon. It is the CA's sole responsibility to decide on proper actions after consulting with the IW. In either case, an exception is regarded as an incident, and incident handling procedures are enacted.

"Documented" has a form. The Root DNSSEC Script Exception is a one-page sheet. Its first row asks for the Act, the Step, the Page, and the date and time, and its second says "IW describes the exception(s) and action(s) below," with a box for initials and a box for the time on each row. An exception is filed against a place in the script, the way a bug is filed against a line of code.

The day the dial was due for replacement

The trouble surfaced during maintenance, and the maintenance was itself a ceremony with its own script. Administrative ceremonies are smaller affairs, with no signing, but the same rules apply: a Ceremony Administrator, an Internal Witness, cameras, and a participants table. In that week's tables the participants included a locksmith from an outside lock-and-security company.

The work was to replace the combination dials on both safes, swapping each Kaba Mas X-09 for a new X-10. The day before, at a ceremony to program the safe deposit boxes' lock assemblies, one assembly had misbehaved. That got a sheet too:

The last KMF West Lock Assembly was malfunctioning, and we delayed the bagging of the unit to allow more time for the locksmith to troubleshoot. Once the lock assembly was functioning, we placed it in TEB BB91951419 and continued where we left off in the script.

TEB is a tamper-evident bag, and the bag's serial number goes in the record.

The script for the Equipment Safe, dated Tuesday 11 February, has an Act 2 called "Safe #1 Equipment Maintenance." Step 1, initialed at 21:34, has the administrator and the witness carry "a flashlight, phillips screwdriver, change key tool" into the safe room. Step 2 reads "SSC1_A opens Safe #1 while shielding the combination from the camera," with a note that the controller "will begin by rapidly spinning the dial counter-clockwise in order to charge it." The lock powers itself from the dial. Step 4 is the job they had come to do: "a) Remove the current Kaba Mas X-09. b) Install a new Kaba Mas X-10."

Step 2 has no initials. The exception sheet behind it is filed against Act 2, Step 2, Page 6, dated 2020/02/11 and initialed at 23:14:

SSC1_A was unable to open the safe due to malfunctioning hardware. Escorted out by IW2 to verify combination with other SSC. Locksmith contacted manufacturer and they suggested the issue was a faulty logic board and the dial will require drilling. Ended ceremony to discuss steps going forward.

So the dial that failed was the one they had come to replace, and it failed at the one step that needed it to work. A second ceremony a couple of hours later opened the Credentials Safe without trouble and swapped its X-09 for an X-10.

The next day ICANN's blog announced that the 40th ceremony, "originally scheduled for 12 February 2020 in El Segundo, California, has been postponed." "One of the security mechanisms that protects the contents of the secure safes was found to be malfunctioning." "The issue was identified yesterday, 11 February 2020, during routine maintenance of the Key Management Facility." The post said there would be "no interruption to Domain Name System Security Extensions (DNSSEC) service," that "We maintain a complete replica facility in Culpeper, Virginia," and that the repair was scheduled for Friday the 14th.

The branch was written before anyone drilled

The 11 February script had no step for a safe that would not open. Step 2 simply assumed it would. When it failed, nobody improvised the repair in the room. They filed the sheet, ended the ceremony, and wrote a new script.

The repair ceremony began on the 14th, and its Act 2 opens with a section titled "Confirmation of Equipment Safe #1 Dial Malfunction." Before anyone was allowed to drill, the controller tried the safe again, under the cameras, at 17:26. The step carries a note that "Locksmith may provide additional advice/techniques to attempt to operate the safe dial." Then the script splits:

If the safe opens: Complete the safe log by following the steps below ...

If the lock malfunctions: Continue with the steps below.

If the safe had opened on that attempt, the script would have sent everyone to the safe log and the dial swap, and there would have been no drilling. It didn't open. Step 5 begins "The locksmith performs the following tasks to replace the combination lock," and lists them: "a) Drill the lock/safe open," "b) Remove the current Kaba Mas X-09 Safe Dial," "c) Return the safe door to a secure state by performing necessary repairs," "d) Install a new Kaba Mas X-10 Safe Dial." Under the first task sits a note about breaks: "A ceremony break will be performed as required. All personnel will be escorted out of the Tier 5 (Safe Room) and Tier 4 (Ceremony Room.)" Each lettered task has its own box for initials and time.

Drilling into the safe that guards the root key was written down in advance as a numbered, witnessed, timed step, with a branch for the possibility that it wasn't needed.

What the sheets caught

The repair took two days, and the packet of exception sheets behind its script reads like a log of everything the plan didn't specify. I read four of them, all filed against Act 2, Step 5, Page 6. I didn't read every page of the packet, so four is a floor.

The first, dated the 14th at 21:00, records that an external witness "left the room on a break and stayed outside until the next break," returning at 22:19, and adds: "Due to the length of the ceremony carrying into the next day, other non essential participants came and went as well." The second is one sentence: "Ceremony was paused overnight and resumed in the morning."

The third, at 19:26 on the 15th, is about the building. A security guard used the hand scanner outside Tier 3 to escort an external witness in, and that triggered the alarm. The witness was asked to step out and wait in the conference room, "and the alarm was triggered again when he manually opened the door."

The fourth is about the order of steps:

Steps e, f, g, and h were performed immediately after opening the safe for the first time which occurred between steps a and b.

Steps e to h are the safe log: the controller shows the old log to the camera, takes the pre-printed one from the witness, writes the time and signs where it says "Open Safe," and the witness checks and initials the entry. The script had them after the new dial went on. In the room, they did them the moment the drilled door first opened, and the times in the script's own columns agree: a at 21:48, e to h at 21:54, the new dial at 23:56. Doing the log first was arguably the better order, since it put the opening on paper at once. Nobody rewrote the script to match. The deviation went on its own sheet, and the record shows the steps in the order they happened.

The times in that column all carry a "+1," which the script never defines. I read it as the day after the ceremony began, which puts the drilling at 21:48 UTC on the 15th. Three other records agree with that reading: the overnight sheet is dated the 15th at 00:38, IANA's announcement that the safe was open went out at 22:10 UTC on the 15th, and the participants signed the ceremony off at 00:44 on the 16th. The discovery sheet was initialed at 23:14 on the 11th, so the drilling step was initialed 3 days, 22 hours and 34 minutes after it.

IANA's message to the root-dnssec-announce list read: "We have successfully opened the safe with the failed mechanism, and are in the final stages of remediation, with the repair work and installation of a new lock underway. We are therefore arranging resources to start the KSK Ceremony 40 at 0000 UTC, or shortly thereafter."

Four minutes and fifteen seconds

The signing went the way the script said it would. The signer's log for Ceremony 40 opens with "Starting: ksrsigner /media/KSR/KSK40/ksr-root-2020-q2-0.xml (at Sun Feb 16 02:21:33 2020 UTC)." Twenty-two seconds later the hardware module is activated. At 02:25:48 the log reads "Generated new SKR," a signed key response whose first signature period begins on 1 April 2020, made with the key whose tag is 20326. The log prints the response's SHA-256 hash in hex, and then again as a run of English words: "unwind leprosy fracture savagery tactics speculate Neptune miracle slingshot aftermath …"

From start to signed response is four minutes and fifteen seconds. Against the Practice Statement's rule, the latest date for the second-quarter ceremony was 28 February, so the signing finished with nearly twelve days to spare.

The ceremony's closing act has the administrator read every exception out before anyone signs. Step 1 of the participants' signing reads "CA reads all exceptions that occurred during the ceremony." In step 2 each attendee comes to the table and signs the witness's list, and "All signatures declare that this script is a true and accurate record of the ceremony." The read-back comes first. You hear what went wrong before you put your name to the record.

April: nobody could come

Two months later the failure was the people. Ceremony 41 was set for 23 April 2020, in the first weeks of the pandemic. IANA's published questions-and-answers document says there were no representatives for the El Segundo facility "located close enough to allow unrestricted and safe travel to the facility," and says where they were: "Mauritius, Spain, Russia, Tanzania, Uruguay and east-coast United States."

The plan IANA used kept the custody chain and moved the people. "Four trusted community representatives (TCRs) who fulfil Cryptographic Officer roles in the ceremony have transmitted their safe deposit keys to separate ICANN and PTI staff. These staff will act as surrogates, but the TCRs will participate in the ceremony remotely and monitor their credential's use." The keys travelled sealed: "The TCRs have wrapped their deposit keys with opaque material, and then transmitted them in tamper-evident bags. This bag will not be opened until within the ceremony so that each TCR can witness their key is in the same condition as when they released it." The ceremony would sign three quarters at once instead of one, and "The additional generated signatures will be initially withheld."

The plan they didn't use is in the same document. "The first version of our contingency plan assumed the trusted community representatives would not transmit their safe deposit box keys for performance of the ceremony. In such a scenario, a trained locksmith would drill and replace the locks to three safe deposit boxes during the ceremony in order to retrieve the smart cards needed to activate the hardware security module." Two months after the safe, the first version of the fallback was to drill again.

One part of the April plan broke the rules as they stood, and the document says which: "The only element of our revised approach that was inconsistent with the DPS was signing additional quarters of KSRs during the ceremony. The Policy Management Authority, an internal committee that reviews changes to the DPS, convened on 6 April and approved revisions that allow for signing additional quarters of KSRs as a disaster recovery response." The rule was changed by its owner seventeen days before it was needed, and not by the people in the room on the day.

The Ceremony 41 script also adds a step to its closing act. After reading the exceptions, the administrator "asks any COs who are participating remotely if they have any concerns pertaining to the ceremony or exceptions which may have occurred."

By November the bend was standing policy. The Practice Statement in force in February 2020, the fourth edition, has no variance clause. The sixth edition, dated 4 November 2020, carries section 4.5.4.1, and the eighth edition of 2025 still carries it word for word:

In the event of a declaration of a disaster recovery or business continuity response, the adverse event may necessitate variances to the procedural controls and technical security controls. These variances shall be limited in scope to those necessary for the successful conduct of key signing operations, and according to protocols that best ensures a proper record of the chain-of-custody and limiting sensitive operations to trusted persons.

The clause ends by requiring that variances are "consented by the RZ KSK Operator's management, are documented and communicated." I didn't read the fifth edition, so I can't say which edition first carried it, only that it arrived between February and November 2020.

The record since

IANA's schedule lists 63 held ceremonies from June 2010 to August 2026, counting Ceremony 53's two parts separately. In 2020 and 2021 there were two each, the only full years with fewer than four. Ceremonies 41 and 42 are the only ones that signed more than one quarter, and the 294 days between them is the longest gap in the schedule.

The public archive runs to 65 directories and 940 files, among them 315 video files from the ceremony cameras. Files from administrative ceremonies first appear in the directory for Ceremony 40, the safe repair, and turn up again in 15 later directories. I didn't read what those later administrative ceremonies were for. Everything here comes from IANA's and ICANN's own record. That is the point of reading it, and also its limit, because an outside auditor's view isn't quoted here.

What carries over

None of this is exotic. It is a procedure that expects to be interrupted, and a record that treats the interruption as a first-class entry. Anyone running software that acts where actions can't be taken back, a deployment pipeline or an agent holding production credentials, can copy four habits from it.

An exception there is a typed record: act, step, page, time, initials, and a description written by the witness rather than the actor. When the script doesn't cover a failure, the response in that room was to stop and write a new script, with a branch for each outcome, before taking the irreversible step. When steps happen out of order, the record says so instead of being tidied. And when a rule has to bend, its owner bends it in advance, in writing, and later turns the bend into a clause with limits.

At the back of the Ceremony 40 script is a page for the Internal Witness alone. It is two sentences long: "I hereby attest that the Key Ceremony was conducted in accordance to this script. Any exceptions that occurred were accurately and properly documented."

Sources

IANA, Key Signing Ceremonies, the schedule of held and planned ceremonies (as fetched 7 October 2026).
IANA, ceremony archive, 65 directories of scripts, logs and video.
IANA, Ceremony 40 administrative scripts, annotated scans: AC40_1, 10 February 2020 (lock assembly exception, page 7); AC40_2, 11 February 2020 (Act 2 and the discovery exception); AC40_3, 11 February 2020 (the Credentials Safe); AC40_4, 14 to 16 February 2020 (the drilling, script page 6, and the exception sheets).
IANA, Ceremony 40 script (preamble, closing act, Appendix C) and signer log, 16 February 2020.
Kim Davies, "Root Key Signing Key Ceremony Postponed," ICANN blog, 12 February 2020.
Kim Davies, "[Root KSK Ceremony 40 scheduled for 0000 UTC](https://lists.icann.org/hyperkitty/list/*Emails are not allowed*/message/Z7KNDGDKD5PNZJ52XHP5Y4W3GIYM23H3/)," root-dnssec-announce, 15 February 2020.
IANA, Questions and Answers on COVID-19 mitigations for KSK Ceremony 41, and the Ceremony 41 script, April 2020.
DNSSEC Practice Statement for the Root Zone KSK Operator: 4th edition, 1 October 2016, as published at iana.org/dnssec/icann-dps.txt in February 2020 (Wayback Machine capture, 16 February 2020), sections 4.2.2 and 6.6; 6th edition, 4 November 2020 and 8th edition, 14 April 2025, sections 4.2.2 and 4.5.4.1.
IANA, Trusted Community Representatives (as fetched 7 October 2026).

How this was checked. Typed quotations were checked word for word against the saved text of the source named beside them. The handwritten ones were transcribed from the scanned pages of the annotated scripts and checked against the images; the scans have no text layer. Times are UTC, as the scripts record them, and the "+1" day is read as explained in the text. The intervals (3 days, 22 hours and 34 minutes; 4 minutes and 15 seconds; the margin before 28 February) and the counts from the schedule and the archive listings were computed by script from those sources. Four exception sheets is the number read in the repair ceremony's packet, not a total for the month.

Originally published at vibeagentmaking.com. If you want a tamper-evident, dated record of what an automated system did and what went off-script: pip install chain-of-consciousness or npm install chain-of-consciousness, or try Hosted Chain of Consciousness.

How to get alerted when someone changes your DNS records

Wed, 14 Oct 2026 14:40:51 +0000

TL;DR. Most DNS changes do not take your site down. A new MX record or an edited SPF record usually still resolves, so your uptime checks stay green. To catch these changes, list every record a name should have. Then get an alert when the live answer is different in any way. The original post has the same text with a short FAQ at the end.

A DNS change does not look like an outage

Uptime monitors wait for something to break. A DNS change often breaks nothing you can see.

Here is an example. Someone adds a second MX record to your domain. MX records tell other servers where to deliver your email. Maybe it was a test of a new email provider, and nobody removed it. Maybe someone stole the password to your DNS account.

Each MX record has a priority number, and senders try the lowest one first. If the new record has a lower number than yours, your email now goes to another server first. Your website works, your checks are green, and nobody notices for weeks.

Other changes work the same way:

Someone changes your nameservers at the registrar. Now a different server answers for your whole domain.
Someone edits your SPF record during a migration. SPF lists the servers that may send email as you, and your newsletter tool is no longer on it.
Someone deletes your _dmarc record while cleaning up old records.
Someone changes your CAA record. Now a different certificate authority can issue certificates for your domain.

These changes can leave your DNS lookups and website checks passing.

This happens in real attacks

In January 2019, the US Cybersecurity and Infrastructure Security Agency (CISA) published Emergency Directive 19-01. Attackers had changed DNS records on several US government domains.

They obtained credentials for a DNS account. They changed A, MX and NS records to point to their own servers. Then they could read web and email traffic as it passed through.

CISA's first order to the agencies was simple: check your public DNS records, and make sure each one points to the right place. Start with NS records.

A check like that tells you the records were right on one day. A monitor does the same check every few minutes, so you find out on the day of the change.

Why "does it resolve?" is not enough

Most DNS checks ask one of two questions.

The first is "Does the name resolve?" This catches a deleted record or an expired domain. It does not catch a changed record, because a changed record still resolves.

The second is "Does the answer contain this value?" For example, you enter your mail server, and the check fails if it disappears. This is better. But the check passes as long as your value is somewhere in the answer. So it misses:

an extra MX or NS record next to yours;
an SPF record changed around the part you check;
one A record replaced, when you have several.

To catch these, the check must know every record that should be there. Then it can fail on anything else.

Watch the exact record set

An exact record set is a list of every record that one name should have, for one record type. The check reads the live answer and compares it with your list:

A record in your list but not in the answer is missing.
A record in the answer but not in your list is unexpected.
A changed record shows up as both. The old value is missing and the new value is unexpected.

Any difference fails the check. The order of the records does not matter, and neither does the TTL.

To write the list, start from the records your domain has now. The DNS lookup tool shows them from Cloudflare and Google side by side. Check that every record is one you expect. If the two resolvers disagree, a change is still spreading, so wait until they match.

In Uptimepage, create a DNS monitor and choose exact set as the answer match. Write one record per line, the way a DNS answer shows it:

10 mail.example.com.
20 alt.example.com.

Say someone adds a third MX record. The next check fails, and the result shows what changed:

{
  "domain": "example.com",
  "record_type": "MX",
  "missing": [],
  "unexpected": ["5 mx.attacker.example."],
  "answers": ["10 mail.example.com.", "20 alt.example.com.", "5 mx.attacker.example."],
  "expected_contains": null,
  "matched": false
}

The new MX record has priority 5, lower than yours, so senders try it first.

The check ignores small differences that would only cause false alarms:

Upper and lower case in names do not matter, so 10 Mail.Example.com matches 10 mail.example.com.
The dot at the end of a name is optional.
Numbers and IP addresses are compared by value, so 2001:0db8::1 matches 2001:db8::1.

TXT values must match exactly, including case. In SPF and DKIM, every character counts.

Enter only the record value, without the name, TTL or type. For TXT records, you can paste quoted strings from your zone file, with all parts on one line.

Which records to watch

You do not need this for every record. Start with the ones where a quiet change hurts the most.

Record	Name	What it controls
NS	`example.com`	Which servers answer for your whole domain
MX	`example.com`	Where your email goes
TXT	`example.com`	Your SPF record: who may send email as you
TXT	`_dmarc.example.com`	Your DMARC policy: what receivers do with fake email from your domain
TXT	`selector._domainkey.example.com`	Your DKIM public key, which receivers use to check your email signatures
CAA	`example.com`	Which certificate authorities may issue certificates for you
A, AAAA	your server hostnames	Only if your servers have fixed IP addresses

Your main domain often has other TXT records too, such as verification records from other services. Put all of them in the list. A new one means someone connected a new service to your domain, and you want to know about that.

One monitor watches one name and one record type. Start with six monitors, one for each of the first six rows. Then add one for each other DKIM selector you use, and one for each fixed A or AAAA record set. A hostname with both an A and an AAAA record needs two monitors.

If you set up only one, make it NS. CISA put NS first too. Whoever changes your NS records controls all your other records.

Query your own nameserver

Normally a DNS lookup goes through a resolver, such as 1.1.1.1 or the one from your internet provider. The resolver keeps each answer for a while. This time is called the TTL. If your MX record has a TTL of one hour, the resolver can show the old answer for about an hour after a change. Sometimes it is longer: a resolver that cannot reach your nameserver may keep serving the old answer until it can.

You can skip this delay. Set the monitor's resolver to the IP address of your own nameserver, the one that holds your real records (your authoritative nameserver). Then every check sees your records as they are right now.

There is one exception: NS records. If someone changes your nameservers at the registrar, your own nameserver does not know. It still answers with the old, correct list. So watch NS through a public resolver, such as 1.1.1.1 or 8.8.8.8. A public resolver follows the registrar, like your visitors do. You can check what a public resolver sees for any name before you create the monitor.

When not to use an exact set

Some records change on purpose. An exact set on them only gives you false alarms.

Names behind a CDN or a load balancer get their IP addresses from a pool. The answer can change over time and depending on where you query from. I wrote about this in why DNS returns different IP addresses. An exact A set on such a name would fail all the time. Watch the CNAME record that points to the CDN instead.

SOA records change every time you edit your zone, because their serial number goes up. _acme-challenge TXT records come and go with each certificate renewal. Do not use an exact set for these either.

Keep the list next to your DNS

If you manage DNS with Terraform, put the monitor in the same repository:

resource "uptimepage_target" "mx" {
  name     = "mx example.com"
  interval = 300

  check = {
    type = "dns"
    dns = {
      domain           = "example.com"
      record_type      = "MX"
      expected_records = ["10 mail.example.com.", "20 alt.example.com."]
    }
  }
}

Now a pull request that changes an MX record must change the monitor too. An MX change that nobody reviewed fails the check. You need Terraform provider 0.15.0 or later. Read more in monitoring as code. All DNS options are in the DNS monitor docs.

Where Uptimepage fits

I build Uptimepage, an uptime monitor that checks your services from several regions and alerts you when one fails. The exact set match above is part of its DNS monitor. A DNS change alerts you once the failure is confirmed: by default two failed checks in a row, from more than half of the regions. The result names the missing and the unexpected records, so you see the change without running dig yourself. It is open source under AGPL, so it can also run on your own server.

Whatever you use, look up your NS records today and check that every name in the answer is one you expect.

Now the question for the comments: has a DNS record on one of your domains ever changed without anyone noticing? I would like to hear how you found out, and how long it took.

Diagnosing DNS Filtering Delays Without Resetting the Network

Wed, 07 Oct 2026 08:33:32 +0000

When a filtering change appears to have no effect, waiting is useful only after you know which setting and resolver the client is using. This checklist keeps the diagnosis focused.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 9, 2026 and updated September 27, 2026. AI assisted editing, platform-specific framing, and the documentation note; the substantive source guidance is human-authored.

A DNS change may not be visible immediately because a device, browser or resolver still has an earlier answer cached. Caching is one possible explanation, not proof that a configuration is correct or that waiting will resolve the problem.

What DNS caching retains

DNS translates a domain name into records a client can use. Cached records are normally reusable for their time to live (TTL). The DNS specification describes this caching model. There is no single waiting period that fits every domain, resolver and application.

DNS cache is different from downloaded page content and an existing network connection. A page can keep displaying an already-loaded ad after DNS settings change. A running app may reuse an established connection without performing another lookup.

Check the setting before blaming the cache

Confirm the profile's active plan and whether DNS AdBlock is included.
Confirm the intended VPN profile is connected.
Identify the domain or application and note the time of the change.
Check whether the browser or device uses a separate secure-DNS resolver.
Compare a fresh request under the same conditions after allowing the relevant cache time to pass.

A browser using another resolver can show different results even after its cache expires. A changed setting on one profile does not establish that another device or profile has the same configuration.

For a documented browser example, Mozilla describes different DNS-over-HTTPS protection modes in Firefox. Default protection can disable secure DNS when a VPN or enterprise policy is active, while other modes use the selected provider differently. Read the active mode and policy; do not assume every browser sends every lookup to the same resolver.

Why devices disagree

Devices may hold answers obtained at different times or use different resolvers, clients and network routes. A new result on one device and an old result on another can be consistent with caching, but the difference is not enough to diagnose caching by itself.

Keep the comparison narrow: same destination, intended profile and network where possible. Record browser secure-DNS and device DNS settings without changing managed policies.

Do you need to restart?

Usually start by confirming the applied settings and opening a fresh request. Reopening an application or restarting a device may clear some local state, but it does not clear an upstream resolver's cache or guarantee a different answer. Save work before any restart.

A full network reset, client reinstall or router restart is not a routine first step for a suspected DNS cache delay. If a local cache flush is specifically needed, use the operating system's documented procedure; a managed device or network may require its administrator.

If nothing changes

Report the domain, time, device, client, profile entitlement, network and the expected versus actual result to the service support team. Do not send your complete profile or credentials. Check whether the issue is actually an ad served from the same allowed domain: DNS filtering cannot separate that ad from the content by domain alone.

Frequently asked questions

How long should I wait? There is no universal delay. The relevant TTL, resolver behavior and application state matter.

Will restarting clear every DNS cache? No. It may affect local state, but upstream caches and application behavior are separate.

Does an unchanged result mean the setting failed? Not necessarily. Check whether it was applied, which resolver is used and whether an old answer or existing connection is being reused.

Can DNS AdBlock remove an ad already on screen? No. It affects relevant lookups; it does not edit content that has already loaded.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

How Does One Server Find Another Server? DNS, Private DNS, and Service Discovery Explained

Fri, 28 Aug 2026 16:58:06 +0000

Hey developers! 👋

Welcome back to our networking and infrastructure deep-dive series.

In the previous article

we learned something surprising:

Two servers inside AWS, Azure, GCP, or a private datacenter can communicate without touching the public internet.

No ISP.

No public IP.

No internet routing.

Just private networking.

But that raises a much bigger question.

A question every backend developer eventually encounters.

The Mystery Nobody Talks About

Imagine you have:

Web Server
    |
    |
    ▼
PostgreSQL Server

Your application needs to connect to PostgreSQL.

Simple.

Right?

Not really.

Because the web server doesn't magically know:

Where PostgreSQL is.

Servers are not humans.

They cannot read dashboards.

They cannot open AWS Console.

They cannot browse Kubernetes UI.

So the real question becomes:

How does one server discover another server?

This seemingly simple question led to the creation of:

DNS
Private DNS
Service Discovery
Consul
Eureka
Kubernetes DNS
Cloud Map
Service Meshes

And ultimately became one of the most important problems in distributed systems.

Today we're going deep into that rabbit hole.

Imagine a New City

Suppose you move into a new city.

You need to find:

Hospital
Bank
Police Station
Restaurant

Do you memorize every building's GPS coordinates?

Of course not.

Instead you use:

Names

Such as:

city-hospital.com

instead of:

104.22.18.150

Computers do exactly the same thing.

Humans prefer names.

Networks use IP addresses.

Something must translate between them.

That something is DNS.

DNS: The Internet's Phonebook

DNS stands for:

Domain Name System

Its job is simple:

Name -> IP Address

Example:

google.com

↓

142.250.x.x

When you visit:

https://google.com

your computer first asks:

What's the IP address of google.com?

DNS replies:

142.250.x.x

Only then can the connection begin.

Without DNS:

The internet would be a giant spreadsheet of IP addresses.

Nobody wants that.

What Actually Happens?

When your browser requests:

google.com

the flow looks like:

Browser
   |
   ▼
DNS Resolver
   |
   ▼
Root DNS
   |
   ▼
.com Nameserver
   |
   ▼
Google Nameserver
   |
   ▼
IP Address Returned

Then:

Browser
   |
   ▼
Google Server

Connection established.

This process often completes in milliseconds.

Billions of times every day.

But Cloud Infrastructure Has a Problem

Public DNS works great for public websites.

But what about:

Backend API
Redis
PostgreSQL
RabbitMQ
Elasticsearch

These services are not public.

In fact:

They should NEVER be public.

Example:

api.company.com

can be public.

But:

postgres.company.com

should almost never be exposed to the internet.

So where do we keep internal server names?

This is where Private DNS enters the picture.

Private DNS: The Hidden Phonebook

Think of Private DNS as:

An internal company directory.

Only employees can access it.

Not outsiders.

Example:

db.internal
redis.internal
auth.internal
payments.internal

These names resolve only inside the private network.

Outside users see:

Nothing.

Inside AWS this is common.

Example:

ip-10-0-4-25.ec2.internal

db.production.internal

Only resources inside the VPC can resolve these names.

The public internet has no idea they exist.

Real Production Example

Suppose you're building an e-commerce platform.

Architecture:

Internet
    |
    ▼
Load Balancer
    |
    ▼
Web Servers
    |
    ▼
API Service
    |
    ├────────► PostgreSQL
    |
    ├────────► Redis
    |
    └────────► RabbitMQ

Question:

How does API Service find PostgreSQL?

Do we hardcode:

10.0.12.55

inside the application?

Never.

Because servers change.

Instances restart.

Containers move.

Databases failover.

IP addresses evolve.

Hardcoded IPs become operational nightmares.

Instead:

DATABASE_HOST = "postgres.internal"

Now infrastructure can move PostgreSQL anywhere.

DNS updates.

Application remains unchanged.

Beautiful.

The IP Address Problem

Modern infrastructure is dynamic.

Very dynamic.

Consider Kubernetes.

A container crashes.

A new container starts.

The new container may receive:

Completely different IP

within seconds.

Imagine every service storing IPs manually.

The system would collapse.

This is why names matter.

Names remain stable.

IPs do not.

Enter Service Discovery

DNS solved:

Find a machine

Service Discovery solves:

Find a service

Those sound similar.

They are not.

Let's see why.

The Microservice Nightmare

Imagine:

User Service

Order Service

Payment Service

Notification Service

Inventory Service

Recommendation Service

Each service runs:

Multiple Instances

Example:

Payment Service

payment-1
payment-2
payment-3
payment-4

Now User Service wants Payment Service.

Which instance should it choose?

payment-1 ?
payment-2 ?
payment-3 ?
payment-4 ?

Hardcoding doesn't work.

Static DNS doesn't fully solve it.

We need something smarter.

What Service Discovery Actually Does

A service registry keeps track of:

Who exists
Where they are
Whether they are healthy

Think of it like:

Air Traffic Control

for services.

Every service announces:

I'm alive.
Here's my address.

Registry stores that information.

Other services ask:

Where is Payment Service?

Registry responds:

payment-2
payment-3
payment-4

Now requests can flow.

Netflix Solved This Years Ago

When Netflix moved to microservices they faced a huge challenge.

Thousands of services.

Millions of requests.

Servers constantly scaling.

They created:

Eureka

A service discovery platform.

Services register themselves.

Other services discover them dynamically.

Without manual configuration.

This became one of the foundational patterns of cloud-native architecture.

Kubernetes: Service Discovery on Steroids

Kubernetes has built-in service discovery.

Suppose you deploy:

payment-service

with:

4 Pods

Kubernetes automatically creates:

payment-service.default.svc.cluster.local

Your application simply uses:

PAYMENT_URL = "http://payment-service"

No IP required.

No server management.

No lookup tables.

Kubernetes DNS handles everything.

Behind the scenes:

payment-service
        |
        ▼
Cluster DNS
        |
        ▼
Healthy Pods

Magic?

Not really.

Just extremely sophisticated automation.

What Happens During a Request?

Imagine:

Order Service

calls:

Payment Service

Flow:

Order Service
       |
       ▼
DNS Query
       |
       ▼
Cluster DNS
       |
       ▼
Payment Service Endpoints
       |
       ▼
Healthy Pod Selected
       |
       ▼
Request Sent

All this happens in milliseconds.

Most developers never see it.

Yet every request depends on it.

Health Checks Change Everything

Modern service discovery isn't just:

Where is the service?

It also asks:

Is the service healthy?

Suppose:

payment-3

crashes.

Registry detects failure.

Immediately removes it.

Now traffic goes only to:

payment-1
payment-2
payment-4

No code changes required.

No deployment required.

Infrastructure heals itself.

This is one of the superpowers of modern cloud systems.

DNS vs Service Discovery

Many engineers confuse them.

Let's simplify.

Feature	DNS	Service Discovery
Finds Machines	Yes	Yes
Finds Services	Limited	Yes
Tracks Health	No	Yes
Dynamic Scaling	Limited	Excellent
Cloud Native	Partial	Yes
Microservices Friendly	Partial	Excellent

Think of DNS as:

A phonebook

Think of Service Discovery as:

A live GPS system with traffic updates.

Huge difference.

AWS Example

AWS provides:

AWS Cloud Map

Services register themselves.

Applications discover services dynamically.

Instead of:

10.0.22.17

you use:

payment.production.internal

AWS continuously keeps records updated.

Your applications stay clean.

Infrastructure stays flexible.

The Hidden System Every Developer Uses

Whenever your application connects to:

Database
Cache
Queue
API
Microservice

one of the following is usually working behind the scenes:

DNS

Private DNS

Service Discovery

Without them:

Modern cloud architecture would be impossible.

Not difficult.

Impossible.

Visual Mental Model

Application
     |
     ▼
Service Name

(payment-service)

     |
     ▼
DNS / Service Discovery

     |
     ▼
Healthy Instance

(payment-2)

     |
     ▼
TCP Connection

     |
     ▼
Response

Simple.

Powerful.

Cloud Native.

Why System Designers Care

Junior developers often think:

Database Host = Some String

System designers think:

How is that string resolved?

Who owns it?

What happens during failover?

How is health tracked?

How does scaling affect discovery?

How quickly do updates propagate?

These questions separate:

Application Development

from

Infrastructure Engineering

Understanding service discovery is one of the first steps toward thinking like a platform engineer, DevOps engineer, cloud architect, or distributed systems designer.

TL;DR Quick Recap

Servers communicate using IP addresses.
Humans prefer names.
DNS translates names into IP addresses.
Private DNS provides internal-only naming.
Modern infrastructure avoids hardcoded IPs.
Service Discovery tracks service locations dynamically.
Kubernetes provides built-in service discovery.
Healthy instances are automatically discovered.
Failed instances are automatically removed.
Every modern cloud platform depends heavily on these mechanisms.

Final Thoughts: The Invisible Map of the Cloud 🗺️

Most developers spend years writing:

DATABASE_HOST="postgres"

without asking:

Who told the application where postgres is?

Behind that tiny configuration value sits an enormous ecosystem:

DNS Servers
Private DNS
Service Registries
Health Checks
Load Balancers
Cloud Networking
Kubernetes Controllers

All working together to answer one deceptively simple question:

"Where is the thing I'm trying to talk to?"

And surprisingly, that question powers almost every distributed system on Earth.

In the next article, we'll go even deeper:

How Does Traffic Know Which Server Should Receive the Request?

Load Balancers → Reverse Proxies → Traffic Routing → Health Checks

Because finding a service is only half the story.

Choosing the right instance is where things get really interesting. 🚀

DNS Propagation Explained: Why DNS Changes Take Time and What Actually Happens Behind the Scenes

Wed, 12 Aug 2026 17:44:34 +0000

In the previous article, we explored:

How DNS works
How DNS records power websites, email systems, and cloud infrastructure

At this point, a natural question emerges:

If DNS changes are just records stored on a server, why don’t updates happen instantly?

Imagine moving a website to a new server.

You update the DNS record.

You refresh your browser.

Nothing changes.

An hour later, some users see the new website.

Others still see the old one.

A colleague in another country sees something completely different.

Monitoring tools report mixed results.

Suddenly everyone starts asking:

Has DNS propagated yet?

This is one of the most misunderstood concepts in networking.

In reality, DNS propagation is not magic.

It is not a global synchronization event.

And contrary to popular belief, DNS records do not slowly travel across the internet.

What actually happens is far more interesting.

Understanding DNS propagation requires understanding three critical concepts:

DNS Cache
DNS TTL
Recursive Resolvers

Once those concepts click, DNS behavior becomes predictable instead of mysterious.

The Biggest Misconception About DNS Propagation

Most explanations describe DNS propagation like this:

code

DNS Change
      ↓
Internet Updates Everywhere
      ↓
Propagation Complete

This sounds reasonable.

Unfortunately, it isn’t how DNS works.

There is no global “update internet” button.

There is no mechanism that pushes your DNS change to every network on Earth.

The internet doesn’t work that way.

A more accurate model looks like this:

code

DNS Change
      ↓
Old Answers Expire
      ↓
Resolvers Ask Again
      ↓
New Answers Are Cached

This distinction is important.

Because understanding it helps explain nearly every DNS propagation issue.

What DNS Propagation Actually Means

When people say:

DNS propagation is taking time

What they usually mean is:

Some systems are still using cached DNS information.

That’s it.

Propagation is largely a caching problem.

Not a distribution problem.

The internet already knows where your DNS records live.

The challenge is that millions of systems may still trust older answers.

Understanding DNS Cache

DNS would be incredibly inefficient without caching.

Imagine every website visit requiring:

Contact Root Servers
Contact TLD Servers
Contact Authoritative Nameservers
Retrieve DNS Records

For every request.

For every user.

For every page load.

The internet would be overwhelmed.

Instead, DNS uses caching extensively.

Where DNS Is Cached

Most people assume DNS is cached in only one location.

In reality, DNS is cached everywhere.

Browser Cache

Your browser remembers previous DNS lookups.

For example:

code

chrome
firefox
safari
edge

all maintain their own caches.

Operating System Cache

The operating system also stores DNS responses.

Examples:

code

Windows
Linux
macOS
Android
iOS

all implement DNS caching.

Router Cache

Many routers cache DNS responses.

This includes:

Home routers
Office routers
Enterprise firewalls

ISP Cache

Internet Service Providers often cache DNS records.

Recursive Resolver Cache

Resolvers such as:

code

Google DNS
8.8.8.8

Cloudflare DNS
1.1.1.1

maintain massive DNS caches.

This is where most DNS propagation delays originate.

Why DNS Caching Exists

Caching solves several major problems.

Faster Performance

Without caching:

Every DNS lookup would require multiple network requests.

Caching dramatically reduces lookup times.

Reduced Infrastructure Load

DNS infrastructure handles billions of requests daily.

Caching prevents unnecessary traffic.

Improved Reliability

Cached answers remain available even when upstream systems experience temporary issues.

Caching is one of the reasons DNS scales globally.

DNS TTL Explained

TTL stands for:

Time To Live

TTL determines how long a DNS response can remain cached before it must be refreshed.

Example:

code

example.com. 3600 IN A 203.0.113.10

Here:

code

3600 seconds

equals:

code

1 hour

This means:

A resolver may reuse this answer for one hour before requesting a fresh copy.

TTL Is the Heart of DNS Propagation

When people ask:

Why hasn’t my DNS update appeared yet?

The answer is often:

The previous TTL has not expired.

Resolvers continue trusting old information until the cache expires.

Only then do they ask for new information.

A Practical Example

Imagine a website currently points to:

code

203.0.113.10

The DNS record has:

code

TTL = 86400

which equals:

code

24 hours

At 9:00 AM you update the record:

code

203.0.113.50

What happens?

Many resolvers continue using:

code

203.0.113.10

until their cached record expires.

The new server may not become visible everywhere for many hours.

This is normal.

Why Some People See Changes Before Others

A common source of confusion:

Two people check the same domain.

One sees the new website.

The other sees the old website.

Why?

Because they are not necessarily using the same resolver.

Example:

code

User A → Cloudflare DNS
User B → ISP Resolver

If one cache expires earlier than another, different answers appear temporarily.

This creates the illusion that DNS propagation is inconsistent.

In reality, different caches are simply operating on different timelines.

The Lifecycle of a DNS Change

A DNS update generally follows this pattern:

Step 1

A record changes on the authoritative nameserver.

Step 2

Existing caches continue using older answers.

Step 3

TTL expires.

Step 4

Resolvers request fresh information.

Step 5

New answers are cached.

Step 6

Traffic gradually shifts to the new destination.

This process is what people call:

DNS Propagation

Why Lowering TTL Before Migrations Matters

Experienced infrastructure teams rarely make DNS changes without preparation.

Suppose a website migration is scheduled for Friday.

The existing record has:

code

TTL = 86400

One day before the migration:

code

TTL = 300

is configured.

This reduces cache duration to:

code

5 minutes

Now when the migration occurs, resolvers refresh much faster.

The transition becomes significantly smoother.

The Most Common DNS Migration Mistake

A surprisingly common scenario:

Monday

TTL remains:

code

Tuesday

Migration begins.

Tuesday Afternoon

Traffic appears inconsistent.

Tuesday Evening

People assume DNS is broken.

In reality:

The TTL strategy was never planned.

The migration itself may be perfectly correct.

DNS Propagation and Website Launches

Launching a new website often involves:

DNS updates
SSL certificates
CDN configuration
Email setup
Search engine verification

DNS propagation affects all of them.

Many launch-day issues are actually cache-related issues.

Understanding propagation helps avoid unnecessary panic.

DNS Propagation and Email Systems

Email migrations are especially sensitive.

A website outage is obvious.

Email failures often aren’t.

If MX records change:

code

example.com IN MX 10 mail.old-provider.com

becomes:

code

example.com IN MX 10 mail.new-provider.com

different mail servers may temporarily use different routes.

Proper TTL planning becomes critical.

DNS Propagation and Search Visibility

Search engines rely on DNS continuously.

They must:

Crawl websites
Verify ownership
Access resources

Poorly planned DNS changes can temporarily impact accessibility.

This doesn’t automatically harm rankings.

However, prolonged outages or misconfigured migrations can create crawl issues.

Infrastructure reliability remains an important foundation for search visibility.

DNS Propagation and GEO

As AI-powered discovery systems become more common, reliable infrastructure becomes increasingly important.

Large language models, answer engines, and AI search platforms must access content consistently.

DNS instability can affect:

Content accessibility
Crawling consistency
Service reliability

Strong DNS practices contribute to long-term discoverability.

How to Check DNS Propagation

Several approaches exist.

Using dig

code

dig example.com

Query Specific Resolvers

code

dig @8.8.8.8 example.com

code

dig @1.1.1.1 example.com

Comparing results helps identify cache differences.

Online DNS Checkers

DNS propagation tools query multiple locations worldwide.

These tools provide a useful snapshot of resolver behavior across regions.

Does DNS Propagation Really Take 48 Hours?

One of the oldest myths in networking is:

DNS propagation takes 24 to 48 hours.

Historically, this was often true.

Modern DNS infrastructure behaves differently.

Most changes appear much faster.

The real answer depends on:

TTL values
Resolver behavior
Cache state
Network policies

Many updates become visible within minutes.

Others may take significantly longer.

The key variable is caching.

Not geography.

Not distance.

Not internet speed.

Caching.

Common DNS Propagation Myths

Myth #1

DNS changes spread slowly around the world.

Reality:

Resolvers refresh cached information when TTL expires.

Myth #2

DNS propagation always takes 48 hours.

Reality:

Many changes appear within minutes.

Myth #3

DNS propagation can be forced globally.

Reality:

You cannot instantly clear every cache on the internet.

Myth #4

DNS propagation means DNS is broken.

Reality:

Propagation is usually normal DNS behavior.

Best Practices for DNS Changes

Reduce TTL Before Major Changes

Prepare caches before migrations.

Verify Records Before Updating

Prevent avoidable mistakes.

Monitor Multiple Resolvers

Avoid relying on a single DNS source.

Plan Email Migrations Carefully

Email outages are often harder to detect than website outages.

Understand Cache Behavior

Most propagation issues are cache issues.

Key Takeaways

DNS propagation is primarily a caching phenomenon.
DNS records do not physically spread across the internet.
DNS TTL controls cache lifetime.
DNS cache exists in browsers, operating systems, routers, ISPs, and recursive resolvers.
Different users may see different DNS answers during propagation.
Lower TTL values can simplify migrations.
Most propagation issues are cache-related rather than DNS-related.
Understanding propagation reduces downtime, confusion, and migration risk.
Reliable DNS practices support website availability, email delivery, and long-term discoverability.

DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV Records in Modern Internet Infrastructur

Mon, 10 Aug 2026 16:35:02 +0000

In the previous article, we explored how DNS translates human-friendly domain names into machine-friendly IP addresses and how a request travels through recursive resolvers, root servers, TLD servers, and authoritative nameservers before finally reaching a destination.

That journey answers how DNS works.

This article answers a different question:

What information is DNS actually returning?

When a DNS resolver contacts an authoritative nameserver, it isn’t simply asking for an IP address.

It is asking for a specific record.

Those records determine:

Where websites live
Where email should be delivered
Which servers are authoritative
How domains are verified
How email is authenticated
How cloud services are discovered
How SaaS platforms connect custom domains
How modern internet infrastructure operates

In other words:

DNS resolution is the process.

DNS records are the data.

Understanding DNS records is where DNS knowledge becomes practical.

Whether you’re launching a website, migrating infrastructure, configuring email, deploying applications, implementing custom domains, or troubleshooting production systems, DNS records sit at the center of the operation.

Why DNS Records Matter More Than Most People Realize

Many internet outages aren’t caused by application bugs.

They aren’t caused by database failures.

They aren’t caused by cloud providers.

They’re caused by configuration mistakes.

A misplaced DNS record can:

Take an entire website offline
Stop customer emails from arriving
Break API connectivity
Prevent SSL certificate issuance
Disrupt SaaS onboarding
Cause search engines to lose access to content

The irony is that DNS records are often configured once and forgotten until something breaks.

That’s why understanding them matters.

DNS Records: The Source of Truth Behind Every Domain

Imagine someone enters:

code

example.com

into a browser.

Eventually the request reaches the authoritative nameserver.

The authoritative nameserver responds with records stored inside its DNS zone.

Example:

code

example.com. IN A 203.0.113.10

The response tells the internet:

code

example.com
       ↓
203.0.113.10

That single record determines where traffic goes.

Without DNS records, DNS itself would be useless.

Understanding DNS Record Types

Modern DNS contains dozens of record types.

However, seven records power the overwhelming majority of websites, applications, email systems, and cloud services.

Record TypePrimary PurposeAMaps hostname to IPv4AAAAMaps hostname to IPv6CNAMECreates aliasesMXRoutes emailTXTVerification and securityNSDefines authoritative nameserversSRVService discovery

These records form the foundation of modern internet infrastructure.

A Record Explained

The A Record is the most fundamental DNS record.

The “A” stands for:

Address

It maps a hostname directly to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This creates a direct relationship:

code

example.com
       ↓
203.0.113.10

When someone visits the domain, traffic is sent to that server.

Why A Records Are So Important

Every website needs a destination.

The A Record provides that destination.

Without it:

Browsers cannot locate servers
Applications cannot connect
APIs become unreachable

Even the most advanced infrastructure eventually depends on records that resolve to an IP address.

Where A Records Are Commonly Used

Typical examples include:

code

company.com
portfolio.com
store.com
api.company.com
app.company.com

Almost every publicly accessible website uses A records somewhere in its architecture.

Production Reality: A Record Migrations

One of the most common infrastructure projects involves moving applications between servers.

For example:

code

Old Server
203.0.113.10

becomes:

code

New Server
203.0.113.50

Updating the A Record redirects traffic globally without requiring users to change anything.

This simple capability is one reason DNS remains such a powerful abstraction layer.

AAAA Record Explained

The AAAA Record performs the same role as an A Record.

The difference is the addressing standard.

RecordProtocolAIPv4AAAAIPv6

Example:

code

example.com. IN AAAA 2001:db8::1

Why IPv6 Exists

IPv4 provides approximately:

code

4.3 Billion Addresses

That seemed enormous in the early days of the internet.

Today, it isn’t.

Cloud computing, smartphones, IoT devices, smart vehicles, and connected infrastructure accelerated address consumption dramatically.

IPv6 was created to solve that limitation.

Should Every Website Use AAAA Records?

Not necessarily.

A common mistake is enabling IPv6 before infrastructure is ready.

If an application doesn’t properly support IPv6, users may experience connectivity problems despite having perfectly functioning IPv4 infrastructure.

IPv6 should be enabled deliberately rather than automatically.

CNAME Record Explained

CNAME stands for:

Canonical Name

Unlike an A Record, a CNAME does not point to an IP address.

Instead, it points to another hostname.

Example:

code

www.example.com IN CNAME example.com

Which effectively means:

code

www.example.com
         ↓
example.com
         ↓
203.0.113.10

Why CNAME Records Exist

Imagine managing:

code

www.example.com
blog.example.com
docs.example.com
shop.example.com

If each hostname pointed directly to an IP address, every infrastructure change would require updating multiple records.

CNAME records eliminate that complexity.

One change updates every dependent hostname.

Why Modern SaaS Platforms Love CNAME Records

Custom domains have become a standard expectation.

Instead of:

code

customer.platform.com

many organizations prefer:

code

app.customer-domain.com

The most common implementation relies on CNAME records.

This approach allows millions of customer domains to connect to shared infrastructure while maintaining branding and flexibility.

The Hidden Complexity of Custom Domains

What appears simple on the surface often requires:

Domain ownership verification
DNS validation
SSL certificate provisioning
Traffic routing
Edge network configuration

Behind a single CNAME record is often a surprisingly sophisticated platform architecture.

CNAME vs A Record

One of the most common questions is:

When should an A Record be used?

When pointing directly to an IP address.

Example:

code

example.com IN A 203.0.113.10

When should a CNAME be used?

When pointing to another hostname.

Example:

code

www.example.com IN CNAME example.com

Simple Rule

Use:

code

A Record

for servers.

Use:

code

CNAME

for aliases.

MX Record Explained

MX stands for:

Mail Exchange

MX records tell the internet where incoming email should be delivered.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email cannot function.

Why MX Records Matter More Than Most Websites

A website outage is visible.

An email outage often isn’t.

Messages simply disappear.

Leads go unanswered.

Support requests never arrive.

Invoices are missed.

Customers assume silence means neglect.

The business impact can be substantial.

Understanding MX Priority

Example:

code

MX 10 mail-primary.example.com
MX 20 mail-backup.example.com

Lower values receive priority.

If the primary server becomes unavailable, mail automatically flows to the backup system.

This redundancy improves reliability.

TXT Record Explained

TXT records are among the most flexible records in DNS.

Historically they stored simple text.

Today they support critical infrastructure functions.

TXT Records Power Modern Trust Systems

Many internet services rely on TXT records to verify ownership.

Examples include:

Google Search Console
Microsoft 365
Cloud platforms
Email providers
SSL certificate services

Example:

code

google-site-verification=abc123

This proves domain ownership without requiring direct server access.

TXT Records and Email Security

TXT records are heavily used by:

SPF

Defines authorized email senders.

code

v=spf1 include:_spf.google.com ~all

DKIM

Provides cryptographic email signatures.

DMARC

Defines authentication policies.

Together these technologies help reduce:

Email spoofing
Phishing
Domain impersonation

In modern environments, email security is largely a DNS problem before it becomes an email problem.

NS Record Explained

NS stands for:

Name Server

NS records define which nameservers hold authority over a domain.

Example:

code

example.com IN NS ns1.cloudflare.com
example.com IN NS ns2.cloudflare.com

These records tell the internet:

These servers contain the source of truth.

Why NS Records Matter

Without NS records, the DNS hierarchy breaks.

Resolvers would have no way of discovering where authoritative information lives.

Every lookup ultimately depends on NS records.

They form the bridge between domain ownership and DNS management.

A Real Infrastructure Example

A domain may be registered through one provider.

DNS may be hosted elsewhere.

For example:

code

Registrar:
Namecheap

DNS Provider:
Cloudflare

NS records connect those two systems.

SRV Record Explained

SRV stands for:

Service Record

SRV records provide more information than a simple address.

They specify:

Service
Protocol
Port
Priority
Weight

Example:

code

_sip._tcp.example.com

Why SRV Records Exist

Many applications need more than an IP address.

Examples include:

SIP systems
VoIP platforms
Active Directory
Enterprise applications
Gaming infrastructure

SRV records allow applications to discover services automatically.

This reduces manual configuration and improves scalability.

DNS Records Every Modern Website Typically Uses

A standard production setup often includes:

Website Access

code

A Record
CNAME Record

Email Infrastructure

code

MX Record
SPF
DKIM
DMARC

Security and Verification

code

TXT Record

DNS Authority

code

NS Record

DNS Records During Website Migrations

Website migrations often fail because DNS planning is treated as an afterthought.

Common mistakes include:

Forgetting MX records
Removing TXT records
Incorrect TTL settings
Deleting verification records
Breaking email authentication

Successful migrations involve auditing DNS before moving infrastructure.

DNS Records and Search Visibility

DNS records do not directly improve rankings.

However, they influence systems that do.

Reliable DNS supports:

Website availability
Search engine accessibility
Email trust
User experience
Infrastructure reliability

Poor DNS management can undermine otherwise excellent websites.

Quick Reference Table

GoalRecord TypeHost a WebsiteAEnable IPv6AAAACreate an AliasCNAMEReceive EmailMXVerify Domain OwnershipTXTConfigure SPFTXTConfigure DKIMTXTConfigure DMARCTXTDelegate DNS AuthorityNSDiscover ServicesSRV

Key Takeaways

DNS records are the data layer of DNS.
A Records connect hostnames to IPv4 addresses.
AAAA Records connect hostnames to IPv6 addresses.
CNAME Records create aliases.
MX Records control email routing.
TXT Records power verification and security.
NS Records define authoritative nameservers.
SRV Records support service discovery.
Modern websites, cloud platforms, SaaS applications, and email systems depend on DNS records.
Understanding DNS records helps prevent outages, improve reliability, and simplify infrastructure management.

DNS Explained: The Complete Guide for Founders, Developers, and Modern Businesses

Sat, 08 Aug 2026 17:06:27 +0000

Most people don’t think about DNS until something breaks.

A founder launches a new website and suddenly email stops working.

A developer migrates infrastructure and traffic starts disappearing.

A marketing team changes a domain setting and the website becomes unreachable.

A SaaS company adds custom domains and discovers that domain management is far more complicated than expected.

The reality is simple:

DNS is one of the most critical systems on the internet, yet it’s one of the least understood.

Every website, API, SaaS platform, email service, mobile application, cloud platform, and online business depends on DNS.

Google depends on DNS.

Cloudflare depends on DNS.

AWS depends on DNS.

Your startup depends on DNS.

And while DNS often appears simple from the outside, there is an incredible amount of engineering hidden beneath a single domain lookup.

This article is designed for both founders and developers.

If you’re a founder, you’ll understand how DNS impacts business continuity, SEO, security, email delivery, and customer experience.

If you’re a developer, you’ll understand how DNS resolution actually works, why DNS records matter, how cloud platforms use DNS internally, and how production-grade systems are built around it.

Let’s start at the beginning.

What Is DNS?

DNS stands for:

Domain Name System

The easiest explanation is:

DNS translates human-friendly names into machine-friendly addresses.

Humans prefer:

code

openai.com

Computers prefer:

code

104.18.33.45

DNS acts as the translation layer between those two worlds.

Without DNS, every website visit would require memorizing numerical IP addresses.

Instead of typing:

code

google.com

you would need to type something similar to:

code

142.250.190.78

for every website you wanted to visit.

Clearly, that wouldn’t scale.

DNS solves this problem by creating a globally distributed naming system.

DNS Is the Internet’s Directory Service

Imagine the internet as a massive city.

Every building has a street address.

Computers only understand addresses.

Humans prefer names.

DNS functions like a directory service that translates:

code

Company Name
        ↓
Street Address

code

Domain Name
        ↓
IP Address

The idea sounds simple.

The engineering required to make this work globally, reliably, and within milliseconds is not.

Why Founders Should Care About DNS

Many founders think DNS is purely a technical concern.

That’s a mistake.

DNS directly affects:

Website Availability

If DNS fails:

Your website disappears.

Not slow.

Not degraded.

Gone.

Users can’t reach it.

Search engines can’t crawl it.

Customers can’t buy from it.

Email Delivery

Many businesses discover DNS only after email breaks.

DNS controls:

Google Workspace
Microsoft 365
Zoho Mail
Custom email servers

A single DNS mistake can prevent:

Sales emails
Customer support
Password resets
Transactional notifications

from reaching users.

SEO Performance

DNS impacts:

Availability
Website speed
Crawlability
User experience

Search engines cannot rank websites they cannot consistently access.

Brand Trust

Imagine a customer visiting:

code

yourbusiness.com

and seeing:

code

This site can't be reached

Trust disappears instantly.

DNS is part of your brand infrastructure.

Why Developers Must Understand DNS

Modern development isn’t just writing code.

Today developers manage:

APIs
Cloud infrastructure
Containers
Load balancers
SSL certificates
SaaS platforms
Multi-region deployments

DNS sits in the middle of all of them.

A surprising number of production incidents ultimately trace back to DNS.

Understanding DNS turns infrastructure troubleshooting from guesswork into engineering.

The DNS Resolution Process

When a user enters:

code

www.example.com

inside a browser, what actually happens?

Most people imagine:

code

Browser
    ↓
Website

Reality is significantly more complex.

Step 1: Browser Cache

The browser first asks:

Have I looked up this domain recently?

If yes:

The browser already knows the answer.

No external DNS request is needed.

The website loads immediately.

This is called DNS caching.

Step 2: Operating System Cache

If the browser doesn’t know the answer, it asks the operating system.

Windows, Linux, macOS, Android, and iOS maintain DNS caches.

Again:

If the answer exists locally, the process ends here.

Step 3: Recursive Resolver

If no cached answer exists, the request reaches a recursive DNS resolver.

Examples include:

Cloudflare DNS:

code

1.1.1.1

Google DNS:

code

8.8.8.8

Your ISP’s DNS servers.

The resolver’s job is:

Find the answer on behalf of the user.

Step 4: Root Nameservers

The resolver begins at the top of the DNS hierarchy.

The internet contains root DNS servers.

These servers don’t know the IP address of every website.

Instead they know:

Which servers are responsible for top-level domains.

For example:

code

.com
.org
.net
.io
.dev

Step 5: Top-Level Domain Servers

Suppose you’re looking for:

code

example.com

The root server responds:

Ask the .com nameservers.

The resolver now contacts the .com infrastructure.

Step 6: Authoritative Nameservers

The .com servers respond:

The authoritative DNS servers for example.com are located here.

Now the resolver knows exactly where to find the truth.

Step 7: Final Answer

The authoritative DNS server returns:

code

203.0.113.10

The resolver caches the answer.

The browser receives the answer.

The website loads.

All of this often happens in less than 100 milliseconds.

The DNS Hierarchy

DNS is not a giant database.

It’s a distributed hierarchy.

Think of it as:

code

Root
 ├── .com
 ├── .org
 ├── .net
 ├── .io
 └── .dev

Under each TLD:

code

example.com
openai.com
github.com

Under each domain:

code

www.example.com
api.example.com
mail.example.com

This hierarchical design is one reason DNS scales globally.

Understanding DNS Records

DNS records are instructions.

Different record types solve different problems.

Understanding them is essential for production systems.

A Record

Maps a hostname to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This is the most common DNS record.

AAAA Record

Maps a hostname to an IPv6 address.

Example:

code

example.com. IN AAAA 2001:db8::1

IPv6 adoption continues growing across cloud providers and ISPs.

CNAME Record

Creates an alias.

Example:

code

www.example.com IN CNAME example.com

Useful when multiple hostnames point to the same service.

MX Record

Controls email routing.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email fails.

TXT Records

One of the most versatile DNS record types.

Used for:

Domain verification
SPF
DKIM
DMARC
Third-party integrations

Founders often encounter TXT records when connecting:

Google Workspace
Microsoft 365
Search Console
Cloud providers

NS Records

NS records define authoritative nameservers.

Example:

code

example.com IN NS ns1.provider.com
example.com IN NS ns2.provider.com

These servers become responsible for your DNS zone.

Why DNS Propagation Takes Time

One of the most common questions:

Why isn’t my DNS change working?

Usually because of caching.

Understanding TTL

TTL means:

Time To Live

Example:

code

TTL = 3600

This means:

code

Cache for 1 hour

Resolvers keep answers cached until TTL expires.

The Truth About DNS Propagation

DNS doesn’t actually “spread” changes.

Resolvers simply stop trusting cached data and ask again.

This process creates the appearance of propagation.

Understanding this distinction helps developers troubleshoot DNS issues more effectively.

DNS and Website Performance

DNS is the first network request most users make.

Before:

HTML
CSS
JavaScript
APIs

DNS must succeed.

Slow DNS creates slower websites.

Measuring DNS Performance

Common metrics include:

DNS lookup time
TTFB
Latency
Availability

A slow DNS provider adds measurable delays before page rendering begins.

DNS and SEO

Many SEO guides barely discuss DNS.

That’s unfortunate because DNS indirectly impacts search performance.

Availability Matters

Search engines need consistent access.

If DNS failures occur:

Crawling suffers
Indexing suffers
Rankings may suffer

Performance Matters

Google increasingly rewards user experience.

Fast DNS contributes to:

Faster page loads
Better engagement
Improved performance metrics

Reliability Matters

Enterprise-grade DNS infrastructure improves uptime.

Uptime improves trust.

Trust improves long-term search visibility.

DNS and GEO (Generative Engine Optimization)

A new challenge is emerging.

Users increasingly discover businesses through AI systems.

Large language models, AI search engines, and answer engines rely heavily on accessible infrastructure.

Reliable DNS contributes to:

Consistent crawling
Better accessibility
Reliable content retrieval

As GEO evolves, infrastructure quality becomes increasingly important.

DNS Security Explained

DNS is also a major attack surface.

DNS Spoofing

Attackers attempt to redirect users toward malicious destinations.

The victim enters:

code

bank.com

but reaches:

code

attacker-site.com

without realizing it.

DNS Cache Poisoning

Attackers inject false DNS responses into caches.

Users receive incorrect answers.

This can lead to phishing and credential theft.

DNSSEC

DNSSEC adds cryptographic signatures.

Benefits include:

Authenticity
Integrity
Protection against spoofing

DNSSEC doesn’t encrypt DNS.

It verifies DNS.

That’s an important distinction.

Email Authentication and DNS

Email security relies heavily on DNS.

Three records are especially important.

SPF

Defines which servers can send email.

DKIM

Provides cryptographic email signatures.

DMARC

Defines enforcement policies.

Together they reduce:

Spoofing
Phishing
Email fraud

How Cloud Providers Use DNS

Cloud infrastructure relies heavily on DNS.

AWS.

Azure.

Google Cloud.

Cloudflare.

DigitalOcean.

All use DNS extensively.

Load Balancing

DNS can distribute traffic.

Example:

code

app.example.com

might resolve to multiple servers.

Benefits:

Scalability
Redundancy
Reliability

Geographic Routing

Users in Singapore may reach Asian infrastructure.

Users in Germany may reach European infrastructure.

Users in New York may reach US infrastructure.

DNS can make these routing decisions automatically.

DNS for SaaS Applications

This is where things become particularly interesting.

Suppose you’re building a SaaS platform.

Your customers want:

code

client-company.com

instead of:

code

client.yourapp.com

This requires custom domain support.

Custom domain support requires DNS verification.

DNS verification requires ownership validation.

DNS becomes part of your product architecture.

Many SaaS founders underestimate this complexity.

Common DNS Mistakes in Production

Over the years, the same mistakes appear repeatedly.

Deleting Records Accidentally

Migration projects frequently break email because MX records were forgotten.

Ignoring TTL

Developers make changes expecting instant results.

DNS doesn’t work that way.

No DNS Monitoring

Businesses discover outages from customers instead of monitoring systems.

No Redundancy

Single-provider DNS creates unnecessary risk.

Missing Email Security Records

SPF, DKIM, and DMARC are often ignored until deliverability problems appear.

Practical DNS Tools Every Developer Should Know

dig

code

dig example.com

The gold standard for DNS troubleshooting.

nslookup

code

nslookup example.com

Widely available across operating systems.

host

code

host example.com

Quick and simple DNS lookups.

whois

code

whois example.com

Useful for domain ownership and registration information.

Key Takeaways

DNS is the internet’s naming system.
Every website, API, email service, and cloud platform relies on DNS.
DNS translates domain names into IP addresses.
DNS is hierarchical and globally distributed.
DNS records control websites, email, security, and service routing.
DNS impacts performance, reliability, SEO, and user experience.
DNSSEC improves DNS trust and authenticity.
SaaS applications often depend heavily on DNS architecture.
Understanding DNS is valuable for founders and essential for developers.

Final Thoughts

The best infrastructure is often invisible.

Users never think about DNS when everything works.

Yet every successful online business depends on it.

Founders view DNS as a domain setting.

Developers eventually realize it’s a foundational internet protocol.

The deeper you go into cloud architecture, distributed systems, SaaS platforms, cybersecurity, and modern software engineering, the more often you’ll encounter DNS.

Understanding DNS isn’t just about configuring records.

It’s about understanding how the internet itself finds, trusts, and connects systems together.

And once you understand that, you’ll start seeing DNS everywhere.

Your domain can expire while your uptime monitor stays green

Tue, 04 Aug 2026 14:19:13 +0000

TL;DR. One HTTP check on your homepage is not enough to know your site works. It cannot tell you when your domain expires, because an expired domain still returns 200 OK from a parking page. Mail dies at the same time, just as quietly, and you keep losing money while every monitor stays green. The fix is not one clever check. It is a few plain ones, starting with the two that fail on a known date: domain and TLS expiry.

Two checks green, the server behind them is down. A status check cannot tell the difference.

I keep seeing new products treat reliability as something that takes care of itself. You ship the site, you watch it load once, and you assume it will keep loading. Hosted once, up forever. That is the most expensive assumption a young team can make, because nobody is watching on the day it stops being true.

So ask one honest question. Is one HTTP check on your homepage enough to know your whole site works?

For most teams it is not. Here is a real case that shows why.

The site was gone, but it answered 200 OK

I was looking at a startup's site last week and it would not load right. Not an error, not a timeout, just the wrong page. The domain had expired two days earlier.

When a domain lapses, the registrar does not switch the site off. It points the domain at its own parking page, the "this domain may be for sale" one. That page is a normal web page. It returns 200 OK and loads fast. It stays that way for a while too, because an expired domain is not deleted the next morning.

So the monitor sees a healthy site. Green light, no alert, everyone asleep. What could be wrong?

Your domain expired. You knew the date once, on the day you bought it a year or two ago. You told yourself you would renew closer to the time, and then you forgot. The card on file lapsed, or the reminder went to an inbox you no longer read.

Now your customers cannot get in. They panic. They email to ask whether you are still in business. And they get no answer, because the mail died with the domain too.

Why the mail dies with it

The registration carries your MX records, so when it lapses, mail to every address on the domain starts bouncing. The website looks up and the inbox goes silent, and the two failures do not obviously connect. That is why the angry email never reaches you.

The front page still answers. Behind it, nothing is running.

And the meter keeps running. While the page says 200, your ads keep sending paid clicks to a parking lander, signups never arrive, and recovery is not fully in your hands. Two days down is not a rounding error either, because downtime adds up faster than the percentages suggest. Once a domain enters redemption after expiry, getting it back can cost far more than a renewal, and the registry sets the clock, not you.

The clock after expiry

For a gTLD like a .com, the sequence is roughly this:

Grace period. The registrar parks the domain. The site is gone but the name still answers, usually for around 30 days, and a normal renewal still works.
Redemption, 30 days. Now it really goes dark. You can still get it back, but through a restore fee that is many times the renewal price.
Pending delete, about 5 days. Nothing you can do. At the end it drops to whoever is waiting.

ICANN's renewal and expiration FAQ and its grace period notes have the exact stages. The practical takeaway is that the first month, the one where an uptime monitor is happily reporting 200, is the cheap month. Everything after that costs money or the domain.

My own uptime check would miss it too

I build an uptime monitor, so here is the uncomfortable part. My own HTTP check would have called that dead site up too. A 200 is a 200. A status-code check cannot tell a real page from a parking page, and it should not pretend that it can.

That is the trap. One HTTP check on the homepage, the most common setup there is, is blind by design. The site answers, the code is green, and the part that pays your bills is broken behind it.

You can bolt on body matching, and it helps a bit. Assert that the response contains a string only your app renders, and a parking page fails it. But a keyword check is still guessing at the cause after the fact. The registration date is a fact you can read months in advance, so read it.

One check is not enough, set up several

So how do you avoid reading about your own outage in a customer's email? Not with one cleverer check. With a few plain ones, each watching a different way to fail. Start with the two that hand you a date instead of a surprise.

Domain expiry. Reads the registration record and warns you weeks before the day it lapses.
TLS certificate expiry. The same shape, a full outage with the date printed on it in advance.

Then cover the failures a homepage check never sees: a TCP check on your database port, a DNS check that reads the answer from outside your own network, and a heartbeat for the backup job that dies without a sound. The full list is in do I need an uptime monitor.

Six checks you trust beat one that only ever watches the front door.

How to set up domain expiry with an alert

Two minutes now buys you weeks of warning later. The shape is the same in any tool that supports it:

Add a monitor and choose the Domain expiry type.
Enter the registered domain, for example yourbusiness.com, not a subdomain.
Set the thresholds in days. A common choice is a warning at 30 days and a critical alert at 7.
Attach a notification channel you actually read. Telegram, Slack, PagerDuty, SMS, a webhook, or email all work. Pick the one that reaches you at night.

From then on it checks once a day, warns you when the date crosses your line, and reminds you as it gets close. No page-watching, no false green.

If you would rather not add a service for it, a cron job that runs whois and greps the expiry date will get you most of the way. The point is the date, not the tool. What you must not do is leave the only reminder in a registrar email going to a founder's old inbox.

Key takeaways

One HTTP check on the homepage is not enough. It stays green while the domain, the certificate, DNS, or a background job is broken.

An expired domain serves a parking page that returns 200 OK, so status-code monitors report it as healthy.

Email dies at the same time and even more quietly, because the MX records lapse with the registration.

You keep losing money the whole time: paid clicks to a dead page, lost signups, and a slow, costly recovery.

Add the checks that fail on a known date first, domain and TLS expiry, then the rest.

Common questions

Why does an expired domain still return 200 OK? The registrar parks it on a lander page instead of taking it offline. The old server is gone, but the parking page is a real web page that answers normally, so a check that only reads the status code sees success.

How long before an expired domain is gone for good? You usually get a month or two. Grace period, then a 30-day redemption where the site is dark but recoverable for a fee, then a short pending-delete stage before it is released to anyone.

What else breaks when a domain expires? Your email, at the same moment and more quietly. The MX records go with the registration, so mail starts bouncing while you are still looking at a page that loads.

Is a keyword check enough instead? It catches the parking page, which is better than nothing, but only once you are already down. The expiry date is knowable months ahead. Use both if you like, but do not skip the date.

I build Uptimepage because I wanted checks like this for my own services: domain and TLS expiry, HTTP, TCP, ping and DNS, heartbeats for background jobs, and browser flows for logins, from several regions. It is AGPL-3.0 open source, so you can run it on your own server if you prefer.

Now the question I actually want answered in the comments: what is the dumbest green check you have been burned by? I have seen a health endpoint that returned 200 with a hardcoded {"status":"ok"} while the database behind it was unreachable for six hours. I suspect yours is better.

Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules

Fri, 17 Jul 2026 04:25:10 +0000

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy. Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay.

What follows walks that request in order for teams who need to reduce TTFB before another theme rewrite. We stay on the network and delivery layers. For WordPress cases where code on the stack beats a bigger hosting plan, see Why Your WordPress Site Is Slow (It Is Not Always Hosting). For LCP levers once first byte is under control, see A Quick Way to Fix LCP: Four Changes That Cut Time to Paint.

What TTFB includes when you measure first byte in lab tools

Time to First Byte (TTFB) measures how long the browser waits from the start of the navigation request until the first byte of the response arrives. In PageSpeed Insights and Lighthouse, it appears as a diagnostic timing. In WebPageTest and similar waterfall tools, you can split the same wait into DNS, TCP connect, TLS, and waiting (server or edge processing). That split is what makes network work actionable for delivery teams.

TTFB is not a Core Web Vital, but it feeds Largest Contentful Paint and overall load feel. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero image or heading can paint. Field data from Chrome UX Report may show Time to First Byte as a supporting metric. Lab tools remain the fastest way to prove a DNS or CDN change after a release, because you control the URL, location, and cache state of the run.

When you read TTFB in a report, ask which hop dominated. Resolver delay looks different from a cold TLS handshake. A cache miss at the CDN looks different from an origin that regenerates HTML on every request. The sections below map each hop to what you change and what you re-test on the same priority URL.

How DNS lookup performance affects first byte

Before any TLS or HTTP work starts, the client must resolve the hostname. DNS lookup performance is the time from query to answer. On a cold visit with an empty cache, that cost sits at the front of TTFB. On a warm visit with a cached answer inside TTL, the lookup may be near zero and the problem moves downstream to connect, TLS, or waiting.

Common DNS causes of slow first byte:

Cause	What you see	Practical fix
Slow or distant resolver path	High DNS ms in WebPageTest before connect	Prefer resolvers and authoritative DNS with low latency for your audience regions
Long CNAME chains	Extra lookups before the final A/AAAA	Flatten CNAMEs where the CDN or DNS vendor allows it
Very short TTL with frequent expiry	Repeated lookups on every cold session	Raise TTL for stable records once cutovers are rare
Geo DNS mis-routing	Fast DNS, wrong PoP or origin later	Align geo policies with real user regions, not office Wi-Fi

Do not treat “add a CDN” as a DNS fix by itself. The CDN hostname still needs clean resolution. After any nameserver, record, or CNAME change, run lab tests from more than one region on the same priority URL. A London-only pass can hide resolver pain for users in another continent. Document the DNS owner per client (registrar, Cloudflare, Route 53, hosting DNS), because ownership confusion often delays the one change that would cut cold-start TTFB more than another plugin audit.

How TLS handshake timing shows up in web TTFB

After TCP connect, the TLS handshake establishes a secure session. TLS handshake cost on the web includes certificate validation, key exchange, and optional stapled OCSP data. TLS 1.3 shortens the handshake compared with older versions. Session resumption and TLS tickets reduce work on repeat connections to the same host.

When TLS shows up as a TTFB problem:

The certificate chain is incomplete or forces extra round trips to fetch intermediates.
The edge or origin still offers TLS 1.2 only, or a weak cipher suite set that clients negotiate poorly.
OCSP stapling is missing and clients block while checking revocation.
Every asset subdomain forces a fresh handshake because connection reuse and HTTP/2 multiplexing never kick in.

Fixes are usually platform configuration, not theme code: enable TLS 1.3 at the edge, staple OCSP, serve a complete chain, and consolidate hosts so the browser can reuse connections. After certificate renewals or CDN SSL mode changes (flexible versus full), re-run lab tests. A misconfigured SSL mode can add redirects that look like “slow TTFB” in a single waterfall row.

Keep handshake tuning separate from application latency. A perfect TLS setup still waits on an origin that takes 1.5 seconds to build HTML. Use the waterfall: if TLS is 40 ms and Waiting is 900 ms, move to CDN and cache rules next instead of chasing another certificate setting.

How HTTP/2, HTTP/3, and connection setup affect TTFB

HTTP version choice changes how requests share connections. HTTP/2 multiplexes many streams over one TLS connection and removes most head-of-line blocking at the HTTP layer. HTTP/3 runs over QUIC and can reduce connection setup cost on lossy mobile networks, with different trade-offs for middleboxes and debugging. Monitoring nuances for HTTP/2 and HTTP/3 belong in a later industry piece. The operational question here is simpler: is the edge speaking a modern protocol to real browsers, and are you wasting connections on cold handshakes?

Connection setup details that still matter for TTFB:

Keep-alive and connection reuse: cold connects pay DNS, TCP, and TLS again; warm navigations on the same origin should reuse.
Preconnect: use it for third-party or CDN hosts that must be ready before LCP work; do not spray preconnect across every tag manager domain.
Connection limits: too many distinct origins fragment work and multiply handshakes.
Origin versus edge: browsers talk to the CDN hostname; the CDN opens or reuses a connection to origin on miss. Origin shield and keep-alive between PoP and origin cut repeated cold connects on miss paths.

If lab tests from a single region look fine but mobile field users complain, check whether HTTP/3 is enabled at the edge and whether your synthetic tool’s protocol path matches what Chrome does for that audience. Protocol upgrades rarely fix a 2-second origin render. They do remove avoidable setup cost when you are chasing the last few hundred milliseconds of TTFB on an otherwise healthy document response.

How CDN routing and PoP selection change cache hit TTFB

CDN routing decides which point of presence answers the request and whether the response is served from cache or fetched from origin. Cache hit versus miss is often the largest swing in TTFB for cacheable HTML and static assets. A hit can return in tens of milliseconds from a nearby PoP. A miss pays PoP-to-origin latency plus origin compute, which is why “we turned on a CDN” does not guarantee a lower first byte on HTML documents.

Checklist for CDN-related TTFB work:

Confirm the URL under test is the public hostname users hit, not a bypass origin URL used only in staging.
Inspect Age, CF-Cache-Status, X-Cache, or vendor-equivalent headers on the HTML response and on the LCP asset.
Separate “CDN configured” from “HTML cacheable.” Many stacks cache CSS and images while every HTML document is private, no-store.
Enable origin shield or regional shielding when miss traffic repeatedly cold-starts the same origin from many PoPs.
Prefer stale-while-revalidate (or vendor equivalent) for pages that can tolerate brief staleness so users are not blocked on origin regeneration.

PoP selection mistakes show up as geography-specific TTFB spikes. A campaign aimed at Australia served primarily from a European PoP will look healthy in a default US or EU lab profile and poor for the real audience. Align synthetic locations with the client’s traffic share, then set performance budget thresholds on those same URLs so regressions after DNS or CDN edits are visible in the next scheduled run.

How CDN cache rules differ from browser cache

CDN cache rules decide what the edge may store and for how long. Browser cache rules decide what a returning visitor may reuse without another network hop. Mixing the two is a common source of tickets that say “we purged but TTFB did not move,” because the team purged the wrong layer or expected browser cache to fix cold document requests.

Layer	Typical policy intent	TTFB effect
Browser cache (static assets)	Long `max-age` / immutable hashed filenames	Helps repeat views; little effect on cold TTFB for HTML
CDN cache (static assets)	Long TTL at edge, purge on deploy of that asset set	Cuts miss cost for CSS, JS, images, fonts
CDN cache (HTML)	Short TTL, SWR, or selective caching for anonymous pages	Often the main lever to reduce TTFB on document requests
Origin	Correct `Cache-Control` / `CDN-Cache-Control` so the edge is allowed to store	Without this, CDN rules never engage

Purge discipline matters as much as TTL length. Blanket purges on every content edit can collapse hit ratio and return every visitor to origin cost. Prefer purge-by-URL or purge-by-tag for the templates you changed. After a purge storm, expect temporary TTFB regressions until the edge repopulates. Tell clients that pattern is expected, then prove recovery with scheduled lab runs rather than a single screenshot.

A deeper pass on Cache-Control header design belongs in a dedicated how-to later on the calendar. For day-to-day delivery, decide per content type whether the browser, the CDN, or only the origin may cache. Write that policy down. Verify headers on the live URL after each CDN or platform change.

How to diagnose network TTFB in PageSpeed Insights and WebPageTest

Use one cold lab run to see the full path, then one repeat view if your tool supports it. Cold runs expose DNS and TLS. Repeat views show whether connection reuse and cache headers behave as you expect.

PageSpeed Insights and Lighthouse

Read the TTFB-related diagnostic and the document request in the network breakdown when available. Treat a high TTFB with a green LCP as unstable: the next slower network or colder cache will expose the wait. Compare mobile and desktop profiles; connection and CPU throttling change how much TTFB dominates the timeline.

WebPageTest waterfalls

Expand the first document request: DNS, connect, TLS, Waiting. Note protocol (h2 / h3), CDN cache headers, and redirect count before the final document. Run the same URL from two locations that match the client’s audience so geography-specific PoP and DNS issues are not invisible.

Decision order we use in delivery

Redirects and wrong hostname (fix before tuning TLS).
DNS and TLS setup cost on cold load.
CDN miss versus hit on HTML and on the LCP asset.
Origin compute and application time (hand off to code or hosting diagnosis as in the WordPress guide linked above).
Protocol and connection reuse for the last stretch of budget.

Manual one-off checks catch the first regression. They do not prove the CDN change still holds next week. Pair diagnosis with scheduled PageSpeed monitoring on priority URLs. Keep PageSpeed Insights versus automated monitoring in mind when a stakeholder wants a single green screenshot as proof that the edge is healthy.

What to re-test after DNS, TLS, or CDN changes

Ship network changes with the same discipline you use for theme releases. After nameserver cuts, SSL mode edits, HTTP/3 toggles, cache rule updates, or purge policy changes, treat the edge the way you treat a theme deploy: prove the URL still meets budget before you close the ticket.

Lab-test the homepage and at least one high-intent template (product, pricing, or primary landing URL).
Capture cache status headers and TTFB from a location that matches traffic.
Compare against the budget you already set for that URL.
Watch the next few scheduled runs for hit-ratio recovery after purges.
Only then reopen theme or plugin tickets that assumed “hosting was fine.”

Apogee Watcher fits as the continuous layer on top of this checklist: multi-site schedules, device splits, and alerts when TTFB or LCP leave budget after an edge change. It layers onto your DNS and CDN vendors; it does not replace them. Network fixes stay verified without someone remembering to open PageSpeed Insights after every Cloudflare or Fastly edit.

FAQ

Does reducing TTFB always improve Core Web Vitals?Often for LCP, when first byte was a large share of the delay and the LCP element was waiting on the document or a late resource discovery. Not always for INP or CLS, which depend on main-thread work and layout stability. Treat TTFB as a supporting budget with its own threshold, then confirm LCP on the same URLs after the network change lands.

Should we cache HTML at the CDN for logged-in or personalised pages?Usually no for fully personalised HTML. Prefer caching anonymous shells or use edge strategies your platform supports without leaking private content. Wrong HTML caching creates security and correctness incidents that dwarf a TTFB win, so write the exception list into the cache policy before you enable document caching at the edge.

Is a CDN enough to fix DNS lookup performance?No. The CDN improves delivery after resolution. Flatten CNAME chains, set sensible TTLs, and confirm geo DNS still points users at a sensible PoP. Re-test cold loads from more than one region after DNS ownership or nameserver changes.

When is origin compute the real TTFB problem?When the waterfall Waiting phase dominates after DNS, connect, and TLS are small, and cache headers show misses or bypass. Then audit application time, database work, and cron load rather than another TLS tweak. That hand-off is where the WordPress hosting-versus-code diagnosis usually starts.

How soon should we re-run lab tests after a DNS cutover?As soon as TTL and resolver caches allow the new answers to appear, then again from a second region. Do not wait for a monthly report cycle to learn the cutover raised TTFB for half the audience. Put the same URLs on a short schedule for the first week after the cutover so hit-ratio and geo routing surprises show up while ownership is still clear.

Put priority URLs on a schedule after network changes

Pick one priority URL with a high lab TTFB. Export or screenshot the waterfall split for DNS, TLS, Waiting, and cache status. Fix the largest hop first, re-test from a relevant location, then put that URL on a schedule so the next DNS or CDN change cannot silently undo the gain. If you manage many client hostnames, use Watcher’s portfolio schedules and budgets so edge regressions surface the same way application regressions do.

How to Configure Nginx as an HTTPS Proxy Server?

Tue, 02 Jun 2026 16:03:57 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article we could able to setup basic nginx server and server simple html page.

Now let's setup https for our nginx server.

Requirements

Before we start setting up https we should do the following:

Buy a domain name from any registrar.
Set up dns records to point to our server ip.
Setup Certificate for our domain name.
Install nginx on our server.
Set up nginx server to serve our website.

Buying Domain Name

We can buy domain name from any registrar like Namecheap, GoDaddy, etc.

It depends on which name it is and the charges will be around

Setting Up DNS Records

Once buy setup the dns records to point to our server ip.

Example:
For your server the ip address is [IP_ADDRESS].
And your domain name is [EMAIL_ADDRESS]

So, you need to set up a dns record to point to your server ip.

Setting up Certificate

Now let's setup certificate for our domain name.

example.com

so, we setup

sudo certbot --nginx -d `example.com` --email [EMAIL_ADDRESS] --agree-tos --no-eff-email

Here is simple workflow on how certificate is fetched and how

Key generation

The Certbot generates a private key and a CSR (Certificate Signing Request) entirely on your machine.

The private key is the core security guarantee.

HTTP-01 Challenge

Let's Encrypt needs to verify you actually control example.com. It sends Certbot a random token.

Certbot places it at:

/var/www/html/.well-known/acme-challenge/<random-token>

Nginx (already running on port 80) serves this file publicly.

Let's Encrypt fetches the token

LE makes a plain HTTP request to http://example.com/.well-known/acme-challenge/<token>.

If it gets the right response back, it's satisfied that you own the domain.

This is why DNS must be pointing to your server before you run Certbot — if the domain pointed elsewhere, LE would fetch the token from the wrong machine and the challenge would fail.

Certificate issued & saved

LE signs and returns your certificate.

Certbot saves four files to /etc/letsencrypt/live/example.com/:

File	What it is
`fullchain.pem`	Your cert + intermediate CA chain (this is what Nginx uses)
`privkey.pem`	Your private key (Nginx uses this too)
`cert.pem`	Just your cert alone
`chain.pem`	Just the CA chain alone

Nginx config is rewritten

Certbot patches your server block to add the listen 443 ssl lines and the cert paths, and adds a new server { listen 80; } block that redirects all HTTP traffic to HTTPS.

Then it reloads Nginx for you.

Setting up with nginx

Assuming your application running in local host 8090. and you are setting up https for your domain name example.com.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # All requests — public, no auth
    location / {
        proxy_pass http://localhost:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Add to symlink to sites enabled

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Restarting nginx

sudo nginx -t && sudo systemctl reload nginx

Conclusion

We could get https for our domain name example.com.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Why Are There Only 13 DNS Root Servers For The Whole World? Is that a problem

Thu, 07 May 2026 10:40:00 +0000

If you are studying for a networking or cloud certification (like AWS Solutions Architect), you will eventually hit a question that stops you in your tracks:

"How many DNS Root Servers are there?"
Answer: 13.

At first glance, this sounds terrifying. We have billions of devices, trillions of websites, and the entire global economy running on the internet. How can the whole thing rely on just 13 computers?

The answer lies in a fascinating mix of 1980s history, hard math, and a clever routing trick called "Anycast." Here is everything you need to know about the 13 Root Servers—and why the internet is stronger than it looks.

1. The History Lesson: The 512-Byte Box

To understand why we have 13 servers, you have to go back to the early days of the internet (IPv4).

In the 1980s, the engineers building the Domain Name System (DNS) faced a strict physical constraint: The UDP Packet Limit.

Data travels across the internet in "packets." Back then, the maximum safe size for a UDP packet (the protocol used for fast, lightweight messages) was 512 bytes. As detailed in RFC 1035, if a packet was bigger than that, old routers would chop it into pieces (fragmentation), causing data loss, or force the connection to switch to TCP (which is reliable but much slower).

The Math Problem

Engineers had to fit the "map" of the internet's root into that tiny 512-byte box. They needed to list the server Names (e.g., a.root-servers.net). They needed the IP Addresses. They needed protocol overhead (headers, flags, etc.).

When you added up the byte cost for the headers and the addresses, they hit a hard limit. They could fit exactly 13 addresses into the packet before it overflowed.

So, the limit isn't political or arbitrary; it’s basically the digital equivalent of fitting people into a small elevator. The 14th person just wouldn't fit.

2. The Myth of the "Kill Switch"

A common fear is that if these 13 servers are destroyed, the internet turns off. This fear is amplified when you look at who runs them.

The 13 IP addresses (A through M) are managed by 12 different organizations (Verisign manages two). The list reads like a "Who's Who" of the US establishment:

NASA (Yes, the space agency manages the E-Root)
The US Army Research Lab
The US Department of Defense
University of Southern California
University of Maryland

It looks incredibly US-centric. This leads to the "Doomsday Scenario": What if the US Government decides to shut off the internet? Or what if a disaster takes the US offline?

This is where the distinction between Logical and Physical becomes crucial.

3. The "Cheat Code": Anycast

Here is the secret: There are not 13 servers. There are 13 IP Addresses.

In reality, there are thousands of physical servers scattered around the globe (over 1,900 sites as of 2026). They use a routing technology called Anycast.

How Anycast Works

Imagine you call the emergency number 911 (or 112).

There is only one phone number.
But thousands of operators exist across the country.
The telephone network automatically routes your call to the closest call center to your physical location.

The Root Servers work the exact same way.

If you are in Nairobi, Kenya, and your computer queries the "E-Root" (managed by NASA), your request doesn't travel under the ocean to Washington D.C..
Instead, it travels to a local data center in Nairobi where NASA has placed a physical copy of the server. (You can check the interactive map of all root servers here).

Why this is "Doomsday Proof"

If the entire North American continent went dark tomorrow:

Decentralization: The physical servers in Europe, Africa, and Asia would keep running because they have a local copy of the database (the "Root Zone").
Jurisdiction: While many operators are US-based, others are international. Netnod is in Sweden, RIPE is in the Netherlands, and WIDE is in Japan.
Result: Your local internet would keep resolving DNS queries just fine.

4. Why Does This Matter for AWS?

If you are studying for a cloud certification, you won't be managing root servers. However, understanding them is the key to understanding Route 53.

AWS Route 53 is an "Authoritative" DNS service. It uses the exact same principles as the Root Servers to keep your application online:

High Availability: Just like the Root Servers, AWS Route 53 uses Anycast. When you create a domain, AWS propagates that record to thousands of servers globally.
Latency: By understanding that users connect to the closest server (not a central master server), you understand how to lower latency for your customers.
TTL (Time To Live): The reason DNS changes take time to "propagate" is that the Root and TLD servers cache information. You are at the mercy of the hierarchy.

Summary

The "13 Root Servers" are a relic of 1980s packet limits, but they have evolved into one of the most robust distributed systems on Earth.

The Limit: 512 Bytes (UDP Packet Size).
The Managers: 12 organizations (Heavy US military/university presence + International partners).
The Reality: Thousands of physical servers using Anycast to ensure that even if nations go offline, the network stays up.

Istio ServiceEntry Explained: External Services, DNS, and Traffic Control

Tue, 14 Apr 2026 20:49:24 +0000

Every production Kubernetes cluster talks to the outside world. Your services call payment APIs, connect to managed databases, push events to SaaS analytics platforms, and reach legacy systems that will never run inside the mesh. By default, Istio lets all outbound traffic flow freely — or blocks it entirely if you flip outboundTrafficPolicy to REGISTRY_ONLY. Neither extreme gives you what you actually need: selective, observable, policy-controlled access to external services.

That is exactly what Istio ServiceEntry solves. It registers external endpoints in the mesh’s internal service registry so that Envoy sidecars can apply the same traffic management, security, and observability features to outbound calls that you already enjoy for east-west traffic. No new proxies, no egress gateways required for the basic case — just a YAML resource that tells the mesh “this external thing exists, and here is how to reach it.”

In this guide, I will walk through every field of the ServiceEntry spec, explain the four DNS resolution modes with real-world use cases, and show production-ready patterns for external APIs, databases, TCP services, and legacy workloads. We will also cover how to combine ServiceEntry with DestinationRule and VirtualService to get circuit breaking, retries, connection pooling, and even sticky sessions for external dependencies.

What Is a ServiceEntry

Istio maintains an internal service registry that merges Kubernetes Services with any additional entries you declare. When a sidecar proxy needs to decide how to route a request, it consults this registry. Services inside the mesh are automatically registered. Services outside the mesh are not — unless you create a ServiceEntry.

A ServiceEntry is a custom resource that adds an entry to the mesh’s service registry. Once registered, the external service becomes a first-class citizen: Envoy generates clusters, routes, and listeners for it, which means you get metrics (istio_requests_total), access logs, distributed traces, mTLS origination, retries, timeouts, circuit breaking — the full Istio feature set.

Without a ServiceEntry, outbound traffic to an external host either passes through as a raw TCP connection (in ALLOW_ANY mode) with no telemetry, or gets dropped with a 502/503 (in REGISTRY_ONLY mode). Both outcomes are undesirable in production. The ServiceEntry bridges that gap.

ServiceEntry Anatomy: All Fields Explained

Let us look at a complete ServiceEntry and then break down each field.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-api
  namespace: production
spec:
  hosts:
    - api.stripe.com
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: TLS
  resolution: DNS
  exportTo:
    - "."
    - "istio-system"

hosts

A list of hostnames associated with the service. For external services, this is typically the DNS name your application uses (e.g., api.stripe.com). For services using HTTP protocols, the hosts field is matched against the HTTP Host header. For non-HTTP protocols and services without a DNS name, you can use a synthetic hostname and pair it with addresses or static endpoints.

addresses

Optional virtual IP addresses associated with the service. Useful for TCP services where you want to assign a VIP that the sidecar will intercept. Not required for HTTP/HTTPS services that use hostname-based routing.

ports

The ports on which the external service is exposed. Each port needs a number, name, and protocol. The protocol matters: setting it to TLS tells Envoy to perform SNI-based routing without terminating TLS. Setting it to HTTPS means HTTP over TLS. For databases, you’ll typically use TCP.

location

MESH_EXTERNAL or MESH_INTERNAL. Use MESH_EXTERNAL for services outside your cluster (third-party APIs, managed databases). Use MESH_INTERNAL for services inside your infrastructure that are not part of the mesh — for example, VMs running in the same VPC that do not have a sidecar, or a Kubernetes Service in a namespace without injection enabled. The location affects how mTLS is applied and how metrics are labeled.

resolution

How the sidecar resolves the endpoint addresses. This is the most critical field and I will dedicate the next section to it. Options: NONE, STATIC, DNS, DNS_ROUND_ROBIN.

endpoints

An explicit list of network endpoints. Required when resolution is STATIC. Optional with DNS resolution to provide labels or locality information. Each endpoint can have an address, ports, labels, network, locality, and weight.

exportTo

Controls the visibility of this ServiceEntry across namespaces. Use "." for the current namespace only, "*" for all namespaces. In multi-team clusters, restrict exports to avoid namespace pollution.

Resolution Types: NONE vs STATIC vs DNS vs DNS_ROUND_ROBIN

The resolution field determines how Envoy discovers the IP addresses behind the service. Getting this wrong is the number one cause of ServiceEntry misconfigurations. Here is a clear breakdown.

Resolution	How It Works	Best For
`NONE`	Envoy uses the original destination IP from the connection. No DNS lookup by the proxy.	Wildcard entries, pass-through scenarios, services where the application already resolved the IP.
`STATIC`	Envoy routes to the IPs listed in the `endpoints` field. No DNS involved.	Services with stable, known IPs (e.g., on-prem databases, VMs with fixed IPs).
`DNS`	Envoy resolves the hostname at connection time and creates an endpoint per returned IP. Uses async DNS with health checking per IP.	External APIs behind load balancers, managed databases with DNS endpoints (RDS, CloudSQL).
`DNS_ROUND_ROBIN`	Envoy resolves the hostname and uses a single logical endpoint, rotating across returned IPs. No per-IP health checking.	Simple external services, services where you do not need per-endpoint circuit breaking.

When to Use NONE

Use NONE when you want to register a range of external IPs or wildcard hosts without Envoy performing any address resolution. This is common for broad egress policies: “allow traffic to *.googleapis.com on port 443.” Envoy will simply forward traffic to whatever IP the application resolved via kube-dns. The downside: Envoy has limited ability to apply per-endpoint policies.

When to Use STATIC

Use STATIC when the external service has known, stable IP addresses that rarely change. This avoids DNS dependencies entirely. You define the IPs in the endpoints list. Classic use case: a legacy Oracle database on a fixed IP in your data center.

When to Use DNS

Use DNS for most external API integrations. Envoy performs asynchronous DNS resolution and creates a cluster endpoint for each returned IP address. This enables per-endpoint health checking and circuit breaking — critical for production reliability. This is the mode you want for services like api.stripe.com or your RDS instance endpoint.

When to Use DNS_ROUND_ROBIN

Use DNS_ROUND_ROBIN when the external hostname returns many IPs and you do not need per-IP circuit breaking. Envoy treats all resolved IPs as a single logical endpoint and round-robins across them. This is lighter weight than DNS mode and avoids creating a large number of endpoints in Envoy’s cluster configuration.

Practical Patterns

Pattern 1: External HTTP API (api.stripe.com)

The most common ServiceEntry pattern. Your application calls a third-party HTTPS API. You want Istio telemetry, and optionally retries and timeouts.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: stripe-api
  namespace: payments
spec:
  hosts:
    - api.stripe.com
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: tls
      protocol: TLS
  resolution: DNS

Note the protocol is TLS, not HTTPS. Since your application initiates the TLS handshake directly, Envoy handles this as opaque TLS using SNI-based routing. If you were terminating TLS at the sidecar and doing TLS origination via a DestinationRule, you would set the protocol to HTTP and handle the upgrade separately — but for most external APIs, let the application manage its own TLS.

Pattern 2: External Managed Database (RDS / CloudSQL)

Managed databases expose a DNS endpoint that resolves to one or more IPs. During failover, the DNS record changes. You need Envoy to respect DNS TTLs and route to the current primary.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: orders-database
  namespace: orders
spec:
  hosts:
    - orders-db.abc123.us-east-1.rds.amazonaws.com
  location: MESH_EXTERNAL
  ports:
    - number: 5432
      name: postgres
      protocol: TCP
  resolution: DNS

For TCP services, Envoy cannot use HTTP headers to route, so it relies on IP-based matching. The DNS resolution mode ensures Envoy periodically re-resolves the hostname and updates its endpoint list. This is critical for RDS multi-AZ failover scenarios where the DNS endpoint flips to a new IP.

Pattern 3: Legacy Internal Service Not in the Mesh

You have a monitoring service running on a set of VMs at known IP addresses inside your VPC. It is not part of the mesh, but your meshed services need to talk to it.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: legacy-monitoring
  namespace: observability
spec:
  hosts:
    - legacy-monitoring.internal
  location: MESH_INTERNAL
  ports:
    - number: 8080
      name: http
      protocol: HTTP
  resolution: STATIC
  endpoints:
    - address: 10.0.5.10
    - address: 10.0.5.11
    - address: 10.0.5.12

Key differences: location is MESH_INTERNAL because the service lives inside your network, and resolution is STATIC because we know the IPs. The hostname legacy-monitoring.internal is synthetic — your application uses it, and Istio’s DNS proxy (or a CoreDNS entry) resolves it to one of the listed endpoints.

Pattern 4: TCP Services with Multiple Ports

Some external services expose multiple TCP ports — for example, an Elasticsearch cluster with both data (9200) and transport (9300) ports.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-elasticsearch
  namespace: search
spec:
  hosts:
    - es.example.com
  location: MESH_EXTERNAL
  ports:
    - number: 9200
      name: http
      protocol: HTTP
    - number: 9300
      name: transport
      protocol: TCP
  resolution: DNS

Each port gets its own Envoy listener configuration. The HTTP port benefits from full Layer 7 telemetry and traffic management. The TCP port gets Layer 4 metrics and connection-level policies.

Combining ServiceEntry with DestinationRule

A ServiceEntry alone registers the external service. To apply traffic policies — connection pooling, circuit breaking, TLS origination, load balancing — you pair it with a DestinationRule. This is where things get powerful.

Connection Pooling and Circuit Breaking

External APIs have rate limits. Your managed database has a maximum connection count. Protecting these dependencies at the mesh level prevents cascading failures.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: stripe-api
  namespace: payments
spec:
  hosts:
    - api.stripe.com
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: tls
      protocol: TLS
  resolution: DNS
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: stripe-api-dr
  namespace: payments
spec:
  host: api.stripe.com
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 50
        connectTimeout: 5s
      http:
        h2UpgradePolicy: DO_NOT_UPGRADE
        maxRequestsPerConnection: 100
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 100

This configuration caps outbound connections to Stripe at 50, sets a 5-second connection timeout, and ejects endpoints that return 3 consecutive 5xx errors. In production, this prevents a degraded third-party API from consuming all your connection slots and causing a domino effect across your services.

TLS Origination

Sometimes your application speaks plain HTTP, but the external service requires HTTPS. Instead of modifying application code, you can offload TLS origination to the sidecar.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-api
  namespace: default
spec:
  hosts:
    - api.external-service.com
  location: MESH_EXTERNAL
  ports:
    - number: 80
      name: http
      protocol: HTTP
    - number: 443
      name: https
      protocol: TLS
  resolution: DNS
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: external-api-tls
  namespace: default
spec:
  host: api.external-service.com
  trafficPolicy:
    portLevelSettings:
      - port:
          number: 443
        tls:
          mode: SIMPLE

Your application sends HTTP to port 80. A VirtualService (shown in the next section) redirects that to port 443. The DestinationRule initiates TLS to the external endpoint. The application never knows TLS happened.

Combining ServiceEntry with VirtualService

VirtualService gives you Layer 7 traffic management for external services: retries, timeouts, fault injection, header-based routing, and traffic shifting. This is invaluable when you are migrating between API providers or need resilience policies for unreliable external dependencies.

Retries and Timeouts

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: stripe-api-vs
  namespace: payments
spec:
  hosts:
    - api.stripe.com
  http:
    - route:
        - destination:
            host: api.stripe.com
            port:
              number: 443
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable

Reverse DNS Lookup — Free IP to Hostname

Mon, 16 Mar 2026 20:39:14 +0000

Instantly resolve any IP address to its corresponding hostname with our free Reverse DNS Lookup tool. Enter an IPv4 or IPv6 address to perform quick rDNS checks, verify PTR records, and troubleshoot network issues—perfect for webmasters, sysadmins, and SEO pros.

Instant CNAME Lookup Tool – Check DNS Al

Wed, 11 Mar 2026 21:25:19 +0000

Use this free CNAME Lookup Tool to quickly find the canonical name (CNAME) records for any domain or subdomain. It helps you verify DNS aliases, troubleshoot configuration issues, and ensure your domains are pointing to the correct targets without using complex command-line tools.

DNS Lookup & Records Viewer

Tue, 24 Feb 2026 08:28:11 +0000

This DNS Lookup Tool instantly pulls every public DNS record for your domain into a single, easy‑to‑scan table—A, AAAA, NS, MX, TXT and more, complete with TTL values. Just enter a domain, click “Run DNS Lookup,” and see exactly how your DNS is configured so you can debug email issues, verify CDN or nameserver changes, and confirm that everything is resolving correctly worldwide.

DNS LookUp Tool

Wed, 18 Feb 2026 14:46:50 +0000

DNS Lookup Tool lets you instantly query A, AAAA, MX, TXT, CNAME, NS, and other DNS records for any domain, helping you verify configuration, troubleshoot issues, and understand how your domain is mapped on the internet.

Global DNS Propagation Checker

Mon, 16 Feb 2026 09:05:31 +0000

DNS Propagation Checker lets you instantly see how your domain’s DNS records resolve from multiple global locations, so you can verify updates, spot issues, and confirm your site is live everywhere.

Internal Engineering Standard

Wed, 11 Feb 2026 12:27:38 +0000

DNS-First Connectivity for Distributed Systems

1. Mandatory Rule

All services must be addressed by DNS/service name.
localhost, 127.0.0.1, or static IPs are forbidden outside single-process unit tests.

2. Scope

Applies to:

Applications

ETL / MDM jobs

Kafka producers & consumers

Kafka Connect

CI/CD pipelines

Batch jobs, CronJobs, sidecars

3. Environment-Specific Naming Policy

Local (Docker / Compose)

kafka:9092
zookeeper:2181
elasticsearch:9200
connect:8083

Kubernetes

kafka.<namespace>.svc.cluster.local:9092
elasticsearch.<namespace>.svc.cluster.local:9200
connect.<namespace>.svc.cluster.local:8083

Rule:

Service name stays constant.
Only the DNS suffix changes per environment.

4. Prohibited Patterns

The following are architecture violations:

localhost:*

127.0.0.1:*

Hard-coded pod IPs

Node IPs

Hostnames tied to machines

5. Configuration Requirements

All endpoints must be externalized (env vars, config files, Helm values)

No environment-specific logic in code

No string replacement during deployment

6. CI/CD Enforcement

Pipelines must fail if:

localhost appears in configs

IP literals are detected

Environment-specific rewrites are required

Static scans are mandatory.

7. Kafka-Specific Rules

bootstrap.servers must use DNS

Kafka Connect REST must be addressed via service DNS

No broker IPs in configs

No advertised.listeners pointing to localhost

8. Kubernetes Requirements

All services exposed via Service objects

Stateful systems use headless services when required

Pods may never reference other pods directly by IP

9. Reliability & Audit Rationale

This standard ensures:

Zero config rewrites across environments

Predictable scaling

Restart tolerance

CI/CD portability

MDM lineage stability

Audit-safe deployments

10. Non-Compliance Impact

Violations will cause:

Deployment rejection

CI/CD failure

Architecture review

Mandatory refactor before promotion

Final Principle

DNS is not networking detail — it is system architecture.
If a component is not reachable by DNS, it is not production-ready.