DNS and the Holiday Code Freeze

The freeze that forgot about DNS

Every year around mid-November, the announcement goes out. Code freeze starts on the 20th. No deploys, no schema changes, no infrastructure work until the new year. Product managers nod, release trains stop, and the engineering org settles into a quieter few weeks.

Then, on December 23rd, someone adds a CNAME for a marketing landing page. Or a contractor repoints a record because a vendor asked them to. Or a certificate renewal needs a validation TXT record. None of these are "deploys," so nobody thinks of them as covered by the freeze. But DNS is production. A bad record change takes your site, your email, or your SSO offline just as effectively as a bad release, and it usually does so with less review.

The holiday freeze is the time of year when this gap matters most. Staffing is thin, the people who know the system are on vacation, and the person on call may be seeing the environment for the first time.

Why DNS is the riskiest change during a freeze

It bypasses the pipeline

Freezes are usually enforced in CI/CD. Merges are blocked, pipelines are locked, and deploy tooling refuses to run. DNS consoles, whether Route 53, Azure DNS, Cloudflare, or the Windows DNS Manager on a domain controller, sit entirely outside that system. Anyone with credentials can make a change, and nothing in your freeze tooling will notice.

Changes are instant and global

A bad deploy can be rolled back by redeploying. A bad DNS change is cached by resolvers around the world the moment it's published. Even after you fix the record, clients keep serving the broken answer until their cached TTL runs out. If you're not sure how long that is, our guide to TTL strategy covers it.

Nobody is watching

In a normal week, someone notices when a record changes unexpectedly. Over the holidays, a bad change can sit for hours before anyone looks. The people best equipped to diagnose it are the ones who are offline.

The "quick favor" problem

Holiday DNS requests tend to be small and urgent: a vendor needs a verification record, a campaign needs a new subdomain, a certificate is about to expire. Each one feels harmless, which is exactly why they skip review. They add up to untracked changes in a window where you have the least capacity to deal with the fallout.

Before the freeze: a DNS readiness checklist

The best freeze is one where you've already done the work you'd otherwise be tempted to do in the middle of it. A week or two before the freeze starts, go through the following.

1. Finish pending migrations and cutovers

Anything half-done is a liability. If you're mid-migration to a new load balancer, CDN, or provider, either complete it before the freeze or explicitly pause it with a documented rollback state. The worst outcome is a partial cutover that nobody remembers the details of in three weeks.

2. Review TTLs on records that might need to move

Identify the records you'd need to change in an emergency: API endpoints, load balancer CNAMEs, anything fronting a customer-facing service. If their TTL is 86400, you've effectively decided that a failover over the holidays would take a day. Lower them now, while you have time to wait out the old TTL. Remember that lowering a TTL only helps once the old value has expired, so do it at least a few days ahead.

3. Renew and validate everything that expires

Certificates, domain registrations, and DNS-based verification records tend to expire at inconvenient moments. Check renewal dates for anything that lands between now and mid-January. If a certificate authority needs a validation record, add it before the freeze rather than during it.

4. Capture a known-good baseline

Take a snapshot of your zones as they stand when the freeze begins. This gives you a reference for "what is correct" that is independent of anyone's memory. If something looks off on January 2nd, you can compare against the baseline instead of guessing. This is the same idea behind drift detection: you can only spot divergence if you know what you started with.

5. Decide what counts as an exception

Some changes can't wait. A certificate validation record or an incident failover is a legitimate reason to touch DNS during a freeze. Write down, in advance, what qualifies, who can approve it, and how it gets recorded. If that decision is made in the heat of the moment, it's usually made badly.

6. Update your on-call runbooks

Your holiday on-call person might not be your DNS expert. Make sure the runbook says where DNS is hosted, who has access, how to roll back a change, and who to escalate to. Include provider names and zone locations. Hunting for "which console is this domain in?" at 3am is a poor use of anyone's holiday.

During the freeze: keep the rules simple

Route every change through one path

The core rule: no DNS change happens outside the approved workflow, including during the freeze. Direct console edits are the single biggest source of untracked changes. If you already have a change control process, the freeze is just a stricter configuration of it. If you don't, the freeze is a good forcing function to start.

Require a second set of eyes, especially now

Holiday staffing makes it tempting to let one person handle everything. Resist this for DNS. A two-person rule means that even a thin team has a sanity check on any change. If your emergency policy allows a single responder to bypass review during an active incident, make sure that bypass is flagged and reviewed afterward. Our approval process guide goes into how to do that without creating bureaucracy.

Approve now, apply later

Not every request needs to hit production the minute it's approved. If a low-risk change comes in on a Friday afternoon and the approver is about to leave, schedule it to apply during a defined window when someone is available to watch it. Approving during business hours and applying during a planned window keeps the review in daylight and the execution at a time you've chosen.

Watch for drift

A freeze is a promise that things won't change. Drift detection is how you verify that promise. If a record in a frozen zone differs from the approved state, someone changed it outside the process, or a provider-side automation did. Either way, you want to know within minutes, not three weeks later. Alerts should go to a channel that someone is actually watching, not an inbox that nobody checks until January.

Be strict about the audit trail

Every exception made during the freeze should be traceable: who requested it, who approved it, what changed, and why. Year-end is also when auditors and security teams start asking questions. A complete record of holiday-period changes answers them in minutes.

Common holiday DNS mistakes

Treating "it's just a TXT record" as low risk

TXT records carry SPF, DKIM, and DMARC. A malformed SPF record can quietly send your outbound email to spam during your busiest sending period. Small record types can have large consequences, so give them the same review as anything else.

Letting a marketing request become a production change

Seasonal campaigns often need new subdomains. Agree on the process ahead of time: submit the request through the normal workflow, name the record owner, and set an expiry or cleanup date so the record doesn't live forever after the sale ends.

Forgetting about dangling records after a campaign

Holiday campaigns create CNAMEs that point at third-party services. When the campaign ends and the service is deprovisioned, the CNAME is left pointing at nothing. Dangling CNAMEs are a classic subdomain takeover risk. Put the cleanup in your January plan.

Sharing credentials "just for the holidays"

When coverage is thin, people hand out console access so others can help. Those credentials rarely get revoked. A shared admin login also makes your audit trail useless, because every change now appears to come from the same person. Give people individual access through the approval workflow instead of widening direct provider access.

Making changes on the last day before leaving

A change made at 4:45pm on December 22nd that "should be fine" is the stuff of holiday incident stories. If it matters, schedule it for when people are present to verify it. If it doesn't, it can wait until January.

After the freeze: close the loop

When the freeze lifts, don't just resume normal operations. Take a short pass to confirm what happened.

• Review every exception. Walk through the changes made during the freeze. Were they all necessary? Did any need a follow-up?
• Compare against your baseline. Confirm that the only differences between the start-of-freeze snapshot and now are the ones you approved.
• Clean up temporary records. Remove campaign subdomains, temporary validation records, and anything added as a stopgap.
• Restore TTLs. If you lowered TTLs ahead of the freeze, raise them again once you're confident nothing needs to move.
• Write down what you learned. Which requests came in, which ones were truly urgent, and what would you do differently next year? Next November's checklist is easier to write when this year's is in front of you.

How Netra helps

Netra puts a single, controlled path in front of DNS across Route 53, Azure DNS, Google Cloud DNS, Cloudflare, and Windows DNS. For a holiday freeze, that means:

• Two-person approval by default. Every change gets a reviewer, even with a skeleton crew. Emergency bypass exists for real incidents and is flagged prominently in the audit log.
• Scheduled changes and maintenance windows. Approve during business hours and apply at a time you've chosen. Maintenance windows restrict when approved changes are allowed to go live, and requests submitted outside the window are queued until it opens.
• Pre-flight checks. Netra looks up live DNS before submission and warns about conflicts or overwrites, which catches the "quick favor" mistakes before they ship.
• Drift detection. Live DNS is continuously compared against expected state, with alerts when something changes outside the process.
• One-click rollback. Any applied change can be reversed through the normal approval workflow, with the full trail preserved.
• Immutable audit log. Every request, approval, and exception is recorded and can be forwarded to your SIEM for year-end review.

The goal isn't to make DNS harder to change over the holidays. It's to make sure every change that does happen is one you chose, reviewed, and can explain.

Quick reference: the holiday DNS checklist

1. Complete or pause in-flight migrations and cutovers.
2. Lower TTLs on records you might need to move, several days ahead.
3. Check expiry dates for certificates, domains, and verification records.
4. Snapshot your zones as a known-good baseline.
5. Define what qualifies as a freeze exception and who approves it.
6. Update on-call runbooks with DNS hosting, access, and rollback steps.
7. Route all changes through the approval workflow, with no console edits.
8. Alert on drift to a channel that someone is watching.
9. Review exceptions and compare against the baseline when the freeze ends.
10. Clean up temporary records and restore TTLs.