An organisation decides to stop staff reaching a particular AI service. The quickest control to deploy, and often the first proposed, is a block in the Domain Name System: configure the internal resolver to refuse the name, and the site stops loading for anyone using that resolver. It can be in place in minutes and it needs no change to any device. Within a week, some staff still reach the service. Nothing was misconfigured. The block works exactly as designed; its design has limits, and this chapter is about where they are.
The previous chapters established that the network reads only names and addresses, and that a name is resolved before any connection. This chapter examines that resolution step, which is the earliest point at which an organisation can see intent and the earliest point it can intervene.
How a name becomes an address
The DNS is a distributed directory that turns a name such as chat.openai.com into an IP address. No single machine holds the whole directory. It is split across a hierarchy, and a lookup walks down that hierarchy until it finds the answer.
When a browser needs an address, it asks a recursive resolver: a server whose job is to do the walking and return a final answer. On a corporate network the resolver is usually one the organisation runs, handed to the device by DHCP. The resolver, if it does not already know the answer, asks the root of the hierarchy which servers are responsible for .com, asks those which servers are responsible for openai.com, and asks those for the address of chat.openai.com. The servers that hold the definitive records for a domain are its authoritative name servers. The recursive resolver collects the answer and returns it to the browser.
Answers are cached at each step, for a period set by the record's TTL, its time to live. A resolver that looked up a name a minute ago answers the next request from memory rather than repeating the walk. Caching makes DNS fast and reduces load, and it also means a change, including a block, does not always take effect immediately, because cached answers persist until their TTL expires. The main record types a defender meets are the address records, A for IPv4 and AAAA for IPv6, and CNAME, which points one name at another and is common in front of content delivery networks.
Why DNS is the cheapest control point
DNS resolution has two properties that make it attractive for control. First, it happens before the connection, so a block prevents the connection from ever starting; the device never obtains an address to connect to. Second, it is centralised on a resolver the organisation already runs, so a policy is applied in one place and covers every device using that resolver, with no software to install.
A DNS block is implemented by making the resolver answer differently for chosen names: return no address, return an error, or return the address of a controlled page that explains the block. The common mechanism is a response policy applied at the resolver, sometimes called a response policy zone. A managed, filtering resolver used for this purpose is often described as Protective DNS. The same resolver logs are a source of visibility as well as control: a DNS query log records that a device asked for chat.openai.com, which is a statement of intent captured before any content is exchanged, and is one of the cheapest detection signals an organisation has. (high)
What a DNS block does not stop
The block acts on name resolution through the organisation's resolver. It follows that it does nothing about three things.
It does not stop a device that does not ask the organisation's resolver. If the device resolves the name somewhere else, the policy is never consulted. This is the central weakness, and encrypted DNS below makes it easy to trigger.
It does not stop a connection made without a name. If a client already holds the address, from a cache, from a configuration, or from a person typing an address literal, no lookup happens and there is nothing to block. Address blocking would be needed to stop that, with the imprecision the previous chapter described.
It does not stop resolution of names the block does not list. Large services use many names and front ends, and a name not on the list resolves normally. Blocklists are therefore a maintenance task, not a one-off setting.
The largest gap is encrypted DNS. DoH, DNS over HTTPS, and DoT, DNS over TLS, send lookups to a resolver of the client's choice inside an encrypted connection, so the organisation neither sees nor controls them. Modern browsers can enable DoH on their own, to a public resolver, independent of the operating system's configured resolver. When that happens, the corporate resolver is bypassed and the DNS block silently stops applying to that browser. Blocking encrypted DNS to known public resolvers, or disabling browser DoH by policy on managed devices, is the usual response, and neither reaches an unmanaged device.
Hardcoded public resolvers, such as well-known addresses run by large providers, are a related path: a device or application configured to use them ignores the corporate resolver entirely. Caching and TTL add a timing gap, so a newly added block can lag. And the standing limit holds: a personal device on a home network uses its own resolver, over which the organisation has no control at all. A DNS block is a useful, cheap reduction in casual access on managed, on-network devices; it is not a boundary.
- A manager asks why staff can still reach an AI service the day after you blocked it at the resolver. Give the two most likely explanations, and how you would confirm each.
- Explain the difference between using DNS logs to detect intent and using a DNS block to prevent access. Which survives a browser turning on its own encrypted DNS, and why?
- Your blocklist names one address record for an AI service, but usage continues. List two reasons a single blocked name may not cover the service.
- You want to stop managed devices from bypassing the corporate resolver. Name two settings you would change, and state which devices remain out of reach afterwards.
Glossary terms used in this chapter
DNS · recursive resolver · authoritative name server · TTL · Protective DNS · DoH · DoT · IP address
Sources
- RFC 1034, Domain Names, Concepts and Facilities. IETF, November 1987. rfc-editor.org/rfc/rfc1034. Checked 9 August 2026. (high)
- RFC 1035, Domain Names, Implementation and Specification. IETF, November 1987. rfc-editor.org/rfc/rfc1035. Checked 9 August 2026. (high)
- RFC 8484, DNS Queries over HTTPS (DoH). IETF, October 2018. rfc-editor.org/rfc/rfc8484. Checked 9 August 2026. (high)
- RFC 7858, Specification for DNS over Transport Layer Security (TLS). IETF, May 2016. rfc-editor.org/rfc/rfc7858. Checked 9 August 2026. (high)
- RFC 9076, DNS Privacy Considerations. IETF, July 2021. rfc-editor.org/rfc/rfc9076. Checked 9 August 2026. (high)
- Australian Signals Directorate, ACSC guidance on Protective DNS. Publisher: ASD ACSC, cyber.gov.au. Cited for the Australian framing of Protective DNS; confirm the current page and title before quoting. Checked 9 August 2026. (medium)
Last updated 9 August 2026