How Terminals Obtain DNS
After a cellular data connection is established, the terminal typically obtains the DNS server address from parameters issued by the core network or gateway. In LTE scenarios, it is common to carry IPv4/IPv6 DNS in the session establishment process through Protocol Configuration Options (PCO); IPv6 can also obtain the recursive resolver address via DHCPv6 or Router Advertisement (RA). If the terminal firmware does not correctly interpret PCO, there may be cases of "IP obtained but DNS is empty," leading to failure of all domain name access at the application layer, while direct IP connections still work. Such issues are not uncommon in custom IoT firmware.
Private Network and Dedicated Network Scenarios
Enterprise IoT often places terminals in private network address spaces, where DNS may point to internal recursive servers used to resolve domain names only visible within the internal network. If the terminal mistakenly uses public DNS, private domain names cannot be resolved, resulting in intermittent "service unavailable" issues. Conversely, if the application needs to access public SaaS services, and the carrier-side DNS hijacks or filters specific domain names, it can also cause difficult-to-diagnose failures. During debugging, the resolution results of specified DNS and default DNS should first be compared using `nslookup` or the module's AT commands.
Security and Performance
DNS is a common attack entry point. If IoT terminals do not verify response integrity, they may be subject to cache poisoning or man-in-the-middle attacks, causing connections to the wrong servers. Implementing DoH/DoT on resource-constrained modules is costly; a more practical approach is to hardcode trusted DNS, enable TLS verification for business connections, and combine it with device certificates. In terms of performance, resolution timeout retry strategies should back off to avoid DNS storms over weak networks overwhelming the module; commonly used resolution results can be cached with reasonable TTLs, but attention should be paid to domain changes during certificate rotation and CDN switching.
Relation to MTU and fragmentation
Large DNS responses over UDP may be dropped due to fragmentation on certain paths (related to MTU). If "sporadic resolution failures" occur, MTU probing combined with TCP DNS fallback strategies can be used to troubleshoot. In IPv6 dual-stack environments, incorrect global DNS configurations may cause AAAA records to be prioritized while the actual IPv6 paths are unreachable, requiring Happy Eyeballs-like strategies at the application or system layer.
The address is assigned, but the resolver is empty
Cellular DNS means that, after the data session is up, the terminal receives the recursive resolver address from parameters delivered with the session, or from the later address assignment. It is not the same step as receiving the terminal’s own address. The conditions are that firmware actually parses those parameters, that service names go through this set of resolvers, and that private names and public names are not sent to the wrong place. When the resolver field is empty, every name lookup fails while a numeric address still works. That is typical of custom firmware. Resetting the module often does not change the fact that the next result is empty again.
A private-network SIM points the resolver at the enterprise network, which is the only place names that exist only inside that network can be resolved. If the terminal switches to a public resolver, internal names fail and public names still work, so only some services are unavailable. The reverse also happens: the service needs an external host, and the operator’s resolver substitutes or filters certain names, so only those names fail. When debugging, compare a specified resolver with the default one, and record which SIM and which access point were used.
A public resolver rejects a private name
Recording a lookup failure as “the link is down” sends the investigation toward the radio. First confirm the session is still up and the local address is still assigned, then see whether the resolver address is present and whether the query left the device. If timeout retries have no backoff, a weak network produces a lookup storm and fills an uplink that was already tight. A cache reduces repeated queries, but a cache kept too long still points at the old address after a certificate or content-delivery change.
A large answer sent as a datagram can be dropped because of a path length limit, and the failure looks occasional. Look at fragmentation and fall back to a connection-based query rather than changing the antenna. In a dual-stack setting, preferring an unreachable address family also makes a name “resolve but not connect.” Parameters of the data session itself are in the existing notes. The radio side that carries the session starts from 4G attach. When a gateway should resolve locally and then forward, put the cache on an edge node so each child device does not time out and retry on its own. Record the resolver address with the attach result. An empty address and a wrong address are two classes. Do not call both a dropped link. After the access point changes, read the resolver again. Do not carry the old cache into the new session.