skip to content

On a split-tunnel VPN, why do lookups for internal names leak to the hotel's DNS resolver, and what stops it?

level: seniorimportance: must knowfreq 30%

answer

  1. routes split packets, not names
  2. a query goes where the resolver is
  3. per-domain resolver selection
  4. INTERNAL_DNS_DOMAIN with INTERNAL_IP4_DNS
  5. is the resolver inside the include list

basics

~20 s

Routes split packets by destination address, but the client still sends every query to the resolver the hotel's DHCP gave it, so internal names leave in clear. Split DNS sends internal domains to internal resolvers through the tunnel.

solid answer

~50 s

A split tunnel routes by destination IP, and a DNS query's destination is the resolver, not the name inside it. If the client keeps the hotel's resolver for everything, a lookup for `payroll.corp.example.com` goes there: the hotel network and its upstream learn the name, and the answer is NXDOMAIN, which may be negatively cached, or the public view's address, so the application fails or connects to the wrong host. The fix is **split DNS**: queries under the internal domains go to internal resolvers reached through the tunnel, everything else to the local resolver. RFC 8598 standardises it for IKEv2: the gateway sends `INTERNAL_DNS_DOMAIN` with `INTERNAL_IP4_DNS` or `INTERNAL_IP6_DNS`, and the client MUST use only those servers for the listed domains and their subdomains. Then check the edges: the resolver's address must be routed into the tunnel, and search suffixes, CNAMEs into unlisted domains and applications with their own resolver can still leak.

go deeper

for a junior

Remember that a DNS query goes wherever the resolver is, so routing corporate subnets into the tunnel does not move the lookups. Split DNS picks a resolver by domain.

for a middle

Explain how a client chooses a resolver per domain and what RFC 8598 adds to IKEv2: internal domains plus internal resolver addresses in the configuration reply.

for a senior

Diagnose the edges: the resolver outside the include list, search suffixes, CNAMEs into an unlisted domain, applications with their own resolver, and stale cache after disconnect. Say how you would prove there is no leak.

for a principal

Weigh per-domain split DNS against sending all DNS through the tunnel: privacy of the user's other lookups and resolver load against the risk of leaks you did not list.

## Why routing alone leaks names A split-tunnel VPN client decides per packet, by **destination IP address**, whether to use the tunnel or the local interface. A DNS query is a packet addressed to a **resolver**; the name being looked up is only payload. So the route table cannot tell a query for a corporate name from a query for a public one. If the client's only resolver is the one the visited network handed out by DHCP (a hotel resolver at `192.168.1.1`, say), every name goes there, including `payroll.corp.example.com`. Three things then go wrong: - **Disclosure.** The hotel network, its resolver and whatever that resolver forwards to learn which internal hosts the user is reaching. - **Wrong answers.** An internal-only name gets NXDOMAIN, which the client may cache as a negative answer. If the organisation runs an internal and a public version of the same domain, the client gets the public address and connects to the wrong host. - **Failure that looks random.** The application fails while the tunnel is up and pinging an internal IP address works, which is why this is reported as "the VPN is broken". ## Split DNS: choosing a resolver by domain The fix is **split DNS**: the client keeps a list of internal domains, sends queries for names in those domains (and their subdomains) to internal resolvers, and sends everything else to the local resolver. The internal resolvers usually have RFC 1918 addresses reachable only through the tunnel, so their queries travel encrypted. RFC 8598 (Standards Track, 2019) defines how an IKEv2 gateway delivers this list. The gateway's `CFG_REPLY` carries `INTERNAL_DNS_DOMAIN` (attribute type 25) entries alongside `INTERNAL_IP4_DNS` or `INTERNAL_IP6_DNS` resolver addresses; a gateway that sends a domain MUST also send at least one resolver. Its first example reply, abridged to IPv4: | Attribute | Value | Meaning | |---|---|---| | `INTERNAL_IP4_ADDRESS` | `198.51.100.234` | the client's inner address | | `INTERNAL_IP4_DNS` | `198.51.100.2`, `198.51.100.4` | internal resolvers | | `INTERNAL_DNS_DOMAIN` | `example.com`, `city.other.test` | domains those resolvers answer | The client's obligations, from section 5: 1. Use the provided resolvers "as the only resolvers for the listed domains and its subdomains", and never try the external resolvers for them, so a timeout does not fall back to the hotel. 2. Match on label boundaries: for `example.test`, `mail.eng.example.test` is internal but `otherexample.test` is not. 3. Send other names (a SHOULD, not a MUST) to external resolvers configured independently of IKE, unless the client prefers to send everything through the tunnel, which RFC 8598 allows for untrusted networks. 4. When the IKE SA ends, remove the forwarding rules and flush cached data for the internal domains, negative entries included. ## Where it still leaks | Leak path | What happens | Fix | |---|---|---| | Resolver outside the include list | The query to `10.20.0.53` follows the local default route | Route each internal resolver's address into the tunnel | | Unqualified names | `payroll` is expanded with a search suffix and asked of whichever resolver matches; a suffix not in the internal list goes to the local resolver | List every internal suffix as an internal domain | | Indirect references | An internal CNAME or MX points into a second internal domain the list omits | RFC 8598 section 8: list both domains | | Applications with their own resolver | A browser or agent using its own encrypted resolver bypasses the per-domain rule | Configure or disable it on managed devices | | Reverse lookups | PTR queries for internal addresses reach the local resolver | Treat the matching reverse zone as an internal domain | RFC 8598 itself names only the indirect-reference case; the other rows are the ones leak reviews find in practice. ## Checking a deployment The test is simple and defender-side: with the tunnel up on an untrusted network, watch the local interface for DNS traffic while resolving internal names, unqualified names and an internal name reached through a CNAME. Any query for an internal domain seen there is a leak. Repeat after disconnecting to confirm the cache was flushed. A full tunnel is the other way out, sending every query through the tunnel. RFC 8598 says split-DNS attributes MUST be ignored on a connection that is not a split tunnel and that such deployments should use only the gateway's resolvers, because the local network "is often explicitly exempted" from encryption.

  • Why can an internal name still fail right after the VPN disconnects or reconnects?
    Answers for internal domains, or NXDOMAINs cached while the tunnel was down, can outlive the session. RFC 8598 requires that when the IKE SA ends the client remove the DNS forwarding rules, flush all cached data for the internal domains including negative entries, drop any trust anchors it received and clear outstanding queries. A client that skips this keeps stale internal answers or stale NXDOMAINs.
  • Why might a host's protection against private addresses in public answers break split DNS?
    Some resolvers and hosts refuse DNS answers that map a name to RFC 1918 space, a guard against DNS rebinding. Internal names legitimately resolve to such addresses. RFC 8598 says the initiator SHOULD allow the domains listed in `INTERNAL_DNS_DOMAIN` to resolve to special ranges such as RFC 1918 even when it otherwise blocks them.
  • Should a split-tunnel client simply send all its DNS through the tunnel?
    It may: RFC 8598 lets a client prefer the tunnel's resolvers for every query, for example on an untrusted hotel network. The default is per-domain, since the internal resolvers then answer only enterprise names, and the enterprise does not see, or carry the responsibility for resolving, the user's other lookups.

Routing is the choice of which phone line carries a call; DNS is whom you dial. Moving corporate calls onto a private line does not help if you still ring the hotel switchboard to ask for every internal extension.

saying these in an interview costs you the question

  • Routing internal subnets into the tunnel makes internal name lookups follow automatically.
  • A lookup that fails at the hotel resolver reveals nothing to anyone.
  • Split DNS means sending every DNS query through the tunnel.
  • Under RFC 8598 the client may fall back to external resolvers when internal ones time out.
  • Encrypting queries to a public resolver stops internal names leaking.