Skip to main content
The Service Gateway includes a DNS resolver for guests. Most guest queries pass through to upstream resolvers unchanged — but the DNS tab under Service Gateway lets you layer on custom entries for names the internet doesn’t know about (internal services, venue-specific shortcuts) and for names you want to override for the Sign In flow.

​
Custom entries list

Each entry is a simple name-to-value mapping:
  • Name — the hostname guests will query.
  • Record type — usually A (IPv4), AAAA (IPv6), or CNAME.
  • Value — the address or hostname to return.
  • TTL — how long clients should cache the answer.
Typical uses:
  • Internal services — return a venue-local IP for an internal hostname.
  • Landing-page shortcuts — point a friendly hostname at the Captive Portal, so signage can say wifi.example.com instead of a long URL.
  • Sign In flow overrides — intercept a hostname the sign-in flow depends on when the venue’s routing would otherwise send it the wrong way.

​
When to use custom DNS

  • The venue has internal services that guests should reach but the public DNS doesn’t advertise them.
  • You want short, memorable hostnames for guest-visible surfaces.
  • You need to force resolution of a specific name to an internal IP for the sign-in flow.
Don’t use custom DNS to block sites — that’s a firewall / policy concern, not a DNS concern.

​
Adding an entry

1

Decide the record type

A / AAAA for direct IP mapping, CNAME to alias one hostname to another.
2

Add the entry

From the DNS tab, click Add Entry and supply the name, type, value, and TTL.
3

Verify resolution

From a device in the venue’s DHCP scope, run dig <name> or nslookup <name>. You should see the value you configured and the TTL you set.

​
TTLs and propagation

  • Short TTLs (a few minutes) make changes propagate quickly but increase resolver load.
  • Long TTLs (hours) keep caches warm but slow down rollouts.
For entries that change rarely, long TTLs are fine. For anything tied to the Sign In flow or changing infrastructure, keep TTLs short enough to support quick rollback — ten minutes is a sensible default.

​
Debugging lookups

Per-query logs are not surfaced in the Context admin. When debugging a custom entry, run dig / nslookup from a device in the venue’s DHCP scope — that’s the fastest way to confirm whether the query is resolving to the configured value.

DHCP

DHCP hands out the DNS server address; DNS resolves the names.

Gateways

DNS entries apply to every Gateway in the Context.