Meta Title: AT&T DNS Servers Guide to Setup, Changes, and Fixes 2026
Meta Description: Find AT&T DNS server addresses, change settings on routers and devices, and fix cases where AT&T intercepts custom DNS with practical steps.
68.94.156.1 and 68.94.157.1 are the most common AT&T DNS server IPv4 addresses, and 2600:1700:2ce0:40::1 and 2600:1700:2ce0:40::2 are the most common IPv6 defaults. If you're trying to change DNS on an AT&T connection, the bigger issue usually isn't finding the addresses. It's confirming your devices are using the resolvers you intended.
This is often the scenario prompting a search for AT&T DNS servers. A site won't load, a Pi-hole install isn't behaving, a BGW210 or BGW320 looks like it accepted your settings, and then name resolution still follows AT&T policy. DNS on AT&T is straightforward only when you leave the network on provider defaults. The moment you want control, you need to validate DHCP behavior, gateway proxying, and whether the upstream path is being intercepted.
If you manage internet-facing infrastructure, this matters for more than browsing. DNS policy affects filtering, troubleshooting, privacy, and whether local controls such as pfSense, Pi-hole, or secure DNS settings are enforced.
Need fewer manual infrastructure chores outside the network stack? Explore Server Scheduler for scheduled cloud operations and predictable maintenance windows.
Stop paying for idle resources. Server Scheduler automatically turns off your non-production servers when you're not using them.
For most readers, this is the part you need immediately. Primary means the resolver your device will try first. Secondary means the fallback if the first server doesn't answer. Keep them in the intended order if you're entering them manually.
| Type | IPv4 Address | IPv6 Address |
|---|---|---|
| Primary | 68.94.156.1 | 2600:1700:2ce0:40::1 |
| Secondary | 68.94.157.1 | 2600:1700:2ce0:40::2 |
These are the most commonly referenced AT&T DNS servers. Independent listings also identify 68.94.156.1 and 68.94.157.1 as AT&T resolvers, which lines up with AT&T's long-running public DNS footprint and operational use across access networks (AT&T DNS listings on DNSChecker).
Practical rule: If DNS is broken, test name resolution first. Link lights and a valid WAN address don't prove the resolver path is healthy.
A common failure pattern on AT&T looks like this: you set Cloudflare or Google DNS, save the change, and clients still resolve through the gateway or through AT&T resolvers. The reason is usually not a bad IP entry. It is AT&T's default design, where the gateway receives DNS settings automatically and often hands out itself as the DNS server to local devices.
That behavior exists for operational stability. Automatic DNS through DHCP keeps endpoints from drifting onto stale manual settings, and it lets AT&T keep resolver assignment aligned with the access network serving that line. In practice, that can mean your device does not talk directly to the public resolver IPs you expected. It may query the gateway first, and the gateway decides where the request goes.
AT&T has also used regional resolver assignment rather than one fixed server pair for every customer. Older small business documentation shows state-specific DNS values, including 205.152.37.23 for Georgia, and advises customers to stay on automatic assignment unless they have a specific reason to override it (AT&T support guidance for legacy state-specific DNS settings). If you manage your own LAN, review DHCP server configuration practices for DNS option delivery before assuming the gateway is the only system influencing resolver choice.
The practical implication is simple. Changing DNS in one place does not guarantee clients will use it.
| Default behavior | Why AT&T uses it |
|---|---|
| Automatic DNS via DHCP | Reduces client misconfiguration and keeps resolver settings consistent after renewals and resets |
| Gateway advertised as DNS to clients | Lets the gateway proxy queries and maintain control over how resolver traffic leaves the network |
| Regional resolver assignment | Keeps queries on infrastructure selected for that service area, which can improve reliability and supportability |
This is why custom DNS changes sometimes appear to "stick" in the admin page but fail in live traffic. To make a DNS override hold, you need to verify which device is handing out DNS in practice, whether the AT&T gateway is proxying requests, and whether clients renewed their leases after the change.
If you want network-wide DNS behavior, change it at the gateway or at the firewall behind it. On AT&T hardware such as BGW210 and BGW320, the menu labels vary by firmware, but the workflow is consistent. Sign in to the gateway, find the LAN or home network settings, locate DNS fields, and decide whether you're keeping automatic assignment or applying manual values.
AT&T business DNS configuration guidance).
After you apply the change, renew a client lease and inspect the endpoint, not just the router page. If the client still shows the gateway as DNS, the gateway may be acting as a proxy instead of passing your custom resolver directly.
A short walkthrough can help if your gateway interface is unfamiliar:
Don't trust the settings page alone. Trust what the client receives and what the resolver path actually does.
Device-level changes are useful when you can't edit the AT&T gateway, or when you want to test a resolver before rolling it out across the whole network. This is common with work laptops, lab systems, or a single machine you use for diagnostics.
On Windows, open the adapter settings for Ethernet or Wi-Fi, edit the IPv4 or IPv6 properties, and replace automatic DNS with the manual servers you want to test. On macOS, open Network settings, choose the active interface, and edit the DNS list for that connection. Remove stale entries rather than stacking too many resolvers. Resolver order still matters.

Use this method when you need isolation. If one laptop works with custom DNS and the rest of the network doesn't, the problem is probably upstream at the gateway, DHCP scope, or interception layer, not the resolver itself.
Most technical users often waste time due to this. They assume changing the DNS IP means the network will honor it. On some AT&T setups, that assumption fails.
Troubleshooting reports show users checking local settings, seeing the AT&T router listed as the DNS server, and still dealing with behavior tied to DNS Error Assist or similar interception patterns. That points to a transparent proxy model, where the visible DNS setting on the client isn't the whole story (documented troubleshooting around router DNS display and DNS Error Assist behavior). If you're also seeing odd web failures after forcing DNS paths, some of the symptoms can resemble application-layer problems such as a Privoxy internal error scenario.
Start by disabling any AT&T DNS assistance feature available in the account or gateway controls. Then renew DHCP leases on clients. After that, verify where queries are going, not just what address the interface displays.
For homes and small offices that care about deterministic filtering, local enforcement matters. A Pi-hole or pfSense box only works as intended if devices can't bypass it unnoticed. That's also why browser-level encrypted DNS complicates troubleshooting. Premier Broadband's privacy insights are a useful companion read if you're evaluating what your ISP can still observe when DNS policy is in play.
If the gateway advertises itself as DNS, assume nothing. Validate whether it's forwarding your choice or enforcing its own.
A third-party resolver is the right move when AT&T's default DNS works, but not in the way your network needs. I usually switch for one of three reasons: tighter privacy, better malware and content filtering, or consistent behavior across multiple sites and devices.
The biggest advantage is control. With an ISP resolver, you accept AT&T's caching behavior, logging practices, and policy choices. With a third-party provider, you choose the trade-off that fits the network. Some prioritize privacy. Others add threat blocking, category filtering, or reporting that helps with incident response and policy enforcement. If you run your own local controls, a well-maintained custom DNS block list strategy often matters more than the name on the upstream resolver.
There is a cost. Custom DNS adds operational work.
You need to validate that clients are using the resolver you set, that fallback paths are sane, and that browsers or mobile apps are not sending queries somewhere else over encrypted DNS. On AT&T connections, that last part matters more than it does on many other ISPs because a DNS setting can look correct in the client or gateway and still fail to produce the policy you expect. If the network is intercepting or rewriting queries, changing the DNS IP alone does not give you real control.
Use third-party DNS for a reason, then verify the outcome. If the goal is family filtering, malware blocking, split policy by VLAN, or cleaner auditability, the change is worth it. If the goal is only shaving a few milliseconds off lookup time, the operational overhead may not justify the switch.
The best alternative depends on what you value most. Some teams want a resolver that feels invisible. Others want policy enforcement and reporting.

| Provider | Primary DNS | Secondary DNS | Best fit |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Privacy-focused setups |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | Broad compatibility |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | Filtering and controls |
Cloudflare is a common pick when you want a simple resolver with a privacy-first reputation. Google Public DNS is often chosen because almost every platform and guide supports it cleanly. OpenDNS remains useful when filtering and policy controls matter more than minimalism.
Community discussions also note that some AT&T gateways appear to override or intercept custom DNS, which is why advanced users sometimes fall back to firewall rules, bridge-style workarounds, or local enforcement behind the ISP device (community discussion of AT&T gateway DNS override behavior). If you're already thinking about layered control, it's worth understanding how intermediary services can reshape traffic paths, much like using Google as a proxy changes what sits between the client and destination.
Choose one resolver family, apply it consistently across IPv4 and IPv6, and then test for leaks. Mixed policies create inconsistent results that look random but usually aren't.
Yes, provided you use valid DNS resolvers and apply the change consistently across the network. Problems usually come from mixed settings, such as changing IPv4 DNS but leaving IPv6 on the gateway default, or updating one device while the router still hands out AT&T DNS through DHCP.
It can reduce lookup delay, especially on sites your current resolver handles poorly, but it will not fix congestion, weak Wi-Fi, or high latency to the destination. The practical benefit is usually faster name resolution, better cache behavior, or more predictable filtering and privacy controls.
Name resolution fails first. Devices often stay connected to Wi-Fi or Ethernet, but hostnames stop resolving, apps hang on startup, and browsers return lookup failures or timeout behavior. If the symptoms look broader than DNS alone, compare them with these common connection timed out error causes.
Many AT&T gateways present themselves as the DNS server to clients, then forward requests upstream. That means the device display only shows the first hop. It does not confirm whether the gateway is using AT&T DNS, your custom resolver, or ignoring your setting altogether.
This is one of the more common AT&T-specific complaints. Some gateway models continue to proxy DNS, some push their own values back through DHCP, and some networks appear to intercept port 53 traffic unless you enforce DNS from your own router or firewall behind the gateway.
Test it instead of trusting the admin page. Query a known hostname, then verify which resolver answered. If results still point to AT&T after you changed the settings, the gateway is likely overriding or redirecting DNS somewhere in the path.
Router-level DNS is easier to manage and keeps policy consistent across the network. Device-level DNS gives tighter control, which matters if the AT&T gateway ignores custom values or if you want different policies for workstations, phones, and smart home gear.
In practice, use both when troubleshooting. Set the preferred resolver on your downstream router, then confirm critical devices are not falling back to AT&T through cached settings or automatic reconfiguration.
Usually yes. Clients and browsers can keep cached answers for a while, which makes it look like nothing changed even when the new resolver is active. Flushing cache and renewing DHCP removes stale results and gives you a clean test.
If you're cleaning up infrastructure operations beyond DNS, Server Scheduler helps teams automate start, stop, resize, and reboot windows for cloud resources without scripts or cron sprawl. It's a practical fit for engineers who want predictable maintenance, lower cloud waste, and less manual work across AWS environments.