Geo-blocking DNS by client country

Most DNS resolvers are happy to answer anyone who can reach them. That is the wrong default for a resolver that exists to serve a specific population — the staff of one company, the subscribers of one regional ISP, the devices on one campus. If you only ever serve clients in two or three countries, every query arriving from somewhere else is, at best, noise, and at worst, the front edge of an attack. Geo-blocking by client country is the blunt-but-effective tool for that situation: you decide which countries your resolver answers, and queries from everywhere else get refused before they cost you anything.

This is not content filtering, and it is not the same as blocking where a domain resolves to. It operates one layer up — on the source IP of the device asking the question. Done well, it shrinks your attack surface and cleans up your logs. Done carelessly, it locks out a legitimate user roaming on a foreign mobile network. This article walks through the mechanism, the honest accuracy caveats, where it fits, and where it does not.

The idea: refuse queries by where the client is

The mechanism is simple to state. For each incoming query, take the client's source IP address, look it up in a GeoIP database to get a country code, and compare that code against a policy list. If the country is on the deny list (or absent from an allow list), the query is rejected; otherwise it proceeds through normal resolution and filtering.

The country code is the standard two-letter ISO 3166-1 alpha-2 identifier — FR, US, BD, AF, and so on. The policy can be expressed two ways, and the distinction matters:

For a resolver that serves a single country, the allow-list model is dramatically more effective: you whitelist your one country and the entire rest of the planet is silenced. A deny list is the right shape when you genuinely serve a worldwide audience but want to shed a few specific sources of abuse.

How GeoIP lookups actually work

There is no field in an IP packet that says "France." Geolocation is an inference built from external data: regional internet registry allocations, BGP routing announcements, the addresses operators publish for their networks, and a long tail of corrections. A commercial or open GeoIP database packages all of that into a compact, queryable form that maps an IP range to a country (and often a city, with much lower confidence).

At query time the resolver does a single in-memory lookup — a range match against the loaded database — so the cost per query is negligible. To keep that fast under load, sensible implementations cache the per-client verdict: the first query from an address triggers the lookup, and subsequent queries from the same address reuse the cached country until the entry ages out.

192.0.2.45    →  GeoIP lookup  →  "FR"  →  allow-list match  →  resolve
203.0.113.9   →  GeoIP lookup  →  "XX"  →  not on allow list  →  refuse
198.51.100.7  →  (cached)      →  "FR"  →  allow-list match  →  resolve

The database is a snapshot, not a live feed. Address space is reassigned between operators and across borders constantly, so the database has to be refreshed on a schedule — weekly is a reasonable cadence — or its accuracy drifts. A geo-blocking feature that ships a database once and never updates it will slowly start making wrong calls.

The accuracy caveats nobody should hide

GeoIP is an estimate, and you should treat it as one. The failure modes are well understood, and being honest about them is what separates a useful control from a support nightmare.

• VPNs and proxies. A user in an allowed country tunneling through a VPN exit in a blocked country will be refused. The reverse is also true: an attacker in a blocked country renting a VPS in an allowed one sails right through. Geo-blocking does not see people, it sees exit IPs.
• Mobile carriers and CGNAT. Mobile networks pool subscribers behind large carrier-grade NAT ranges, and those ranges are not always geolocated where the subscriber physically stands. A roaming customer can appear in the carrier's home country, or in a neighbouring one, regardless of where the handset is.
• Database staleness. Reassigned address blocks can be mislabelled for weeks after they change hands. City-level data is far less reliable than country-level data; do not build country policy on city granularity.
• Anycast and cloud egress. Traffic that egresses through a cloud provider's network may carry the provider's regional IP, not the end user's location.

The right mental model: geo-blocking removes the uninvited majority cheaply. It is a coarse filter that turns a planet of potential sources into your handful of expected ones. It is not an identity check, and it is not a security boundary you can lean your whole weight on.

Blocking clients vs blocking destinations

This is the distinction people most often confuse, so it deserves its own section. There are two completely different "geography" questions a resolver can answer, and they have nothing to do with each other.

The topic of this article is the first column. The second — mapping the countries your resolved answers point to — is a reporting and situational-awareness feature: it tells you that your network is reaching servers in, say, forty countries this week, which is useful for spotting anomalies but is not an access control. Keep them mentally separate. Blocking a client country says "we do not serve people there." Charting a destination country says "our traffic ended up there." Conflating the two leads to policies that do not do what their author intended.

Where it earns its place

A national or regional service

If you run a resolver for subscribers in one country, an allow list containing that country is the single highest-leverage setting available. Internet-facing resolvers are scanned constantly by researchers, botnets, and reflection-attack tooling probing for open or misconfigured servers. Refusing every query whose source falls outside your footprint removes the overwhelming bulk of that background radiation before it touches resolution logic — which also means your query logs and statistics start reflecting your actual users instead of the world's scanners.

Cutting off a known-abusive region

A global service that observes a sustained stream of garbage — random-subdomain floods, malformed queries, scripted reflection attempts — concentrated in one or two countries it does not serve can add those to a deny list. This is triage, not strategy: it stops a specific bleed quickly while you investigate. Expect the abuse to migrate to VPS providers in allowed countries eventually, which is exactly why geo-blocking is one layer and not the whole stack.

It complements rate-limiting — it does not replace it

A common mistake is to treat geo-blocking as a DDoS defence. It is not, and the reason is structural. Geo-blocking answers "should this country be allowed?" Rate-limiting answers "is this specific source sending more than its share, right now?" An attacker operating entirely from inside your allowed countries — a botnet of compromised home routers in your own market, say — passes every geo check and still needs to be throttled.

The two controls sit at different points and catch different threats. Use them together:

• Geo-blocking removes the uninvited regions outright — a static, coarse cut.
• Response rate limiting (RRL) dampens amplification and reflection by capping responses to a given source, per RFC-grade rate-limiting practice.
• Per-client rate limits and auto-blacklisting catch the abusive sources that survive the geo cut because they are inside your allowed footprint.

Geo-blocking shrinks the population that rate-limiting has to police. Rate-limiting handles the bad actors that geo-blocking cannot, because they look geographically legitimate. Neither is a substitute for the other.

Legal and ethical notes — do not overclaim

Two cautions, because geo-blocking is easy to oversell.

First, do not market it as a security guarantee. It raises the cost of casual abuse and dramatically cleans up the easy noise, but a motivated adversary defeats it with a VPS in an allowed country in minutes. Describe it honestly as attack-surface reduction, not as a wall.

Second, blocking by country has real-world consequences for real people. A legitimate user travelling abroad, a roaming subscriber, or a researcher behind a VPN can be cut off with no obvious reason. If your resolver serves end users, decide in advance how someone who is wrongly refused gets a path back in, and make sure your operations team knows the allow list exists before they spend an afternoon debugging a "DNS is down" ticket that is really a geo policy doing exactly what it was told. Where regulation or service obligations require you to serve particular populations, confirm your policy does not inadvertently exclude them.

Geo-blocking is one of the few DNS controls where a single checkbox can erase the majority of your hostile traffic — and also lock out a colleague on holiday. Treat it as the coarse, powerful, slightly dangerous tool it is: scope it to a footprint you actually understand, keep the database fresh, pair it with rate-limiting, and never mistake "wrong country" for "definitely an attacker."