When you access a website, your system must translate the human-readable domain name into an IP address. This translation is handled by the Domain Name System (DNS). To reduce latency and network load, DNS responses are cached at multiple layers: your local operating system, your browser, and upstream DNS resolvers. Caching means that once a DNS query is resolved, the answer is stored temporarily so repeated requests for the same domain can be answered quickly, without contacting authoritative servers again.

Each DNS record has a property called Time-To-Live (TTL). TTL is a value, specified in seconds, that tells caches how long the record should be considered valid. When the TTL expires, the cached entry is discarded, and a new DNS query must be made to refresh the data. Setting a high TTL reduces the frequency of DNS lookups, but can cause outdated information to persist if a domain’s IP address changes. Conversely, a low TTL allows for quick updates but increases DNS traffic and lookup delays.

When a DNS query is made, the resolver first checks its cache. If a valid entry is found—meaning its TTL has not expired—the resolver returns the cached result immediately. If not, it forwards the query to the next DNS server in the hierarchy. This caching process happens at every level:

• Your device;
• Your local network’s DNS resolver;
• Your ISP’s resolver;
• Large public DNS services.

To illustrate the caching mechanism, here is a simple pseudo code for a DNS cache lookup and handling TTL expiration:

function dns_lookup(domain):
    if domain in cache:
        entry = cache[domain]
        if current_time < entry.timestamp + entry.ttl:
            return entry.ip_address  // Cache hit, TTL valid
        else:
            remove cache[domain]     // TTL expired, remove entry

    ip_address = query_dns_server(domain)  // Query upstream resolver
    cache[domain] = {ip_address, current_time, received_ttl}
    return ip_address

This logic checks the cache first. If the cached entry is valid, it is used. If the TTL has expired, the entry is deleted, and a fresh DNS query is made.

DNS caching is essential for performance, but it introduces security risks—most notably, cache poisoning. Cache poisoning occurs when an attacker manages to insert false or malicious DNS records into a resolver’s cache. This can redirect users to fraudulent websites or intercept sensitive data.

Attackers may exploit vulnerabilities in DNS software or trick a resolver into accepting forged responses. For example, if a resolver accepts a spoofed reply for a domain before receiving the legitimate answer, it may cache the fake IP address. All subsequent queries for that domain will then return the attacker’s address until the TTL expires.

To mitigate cache poisoning, several strategies are used:

• Randomizing the source port and transaction ID in DNS queries to make spoofing harder;
• Validating responses to ensure they match the original query;
• Limiting the acceptance of unsolicited DNS responses;
• Implementing DNSSEC, which uses cryptographic signatures to verify the authenticity of DNS data.

Proper configuration and up-to-date DNS software are crucial for minimizing the risk of cache poisoning.

When a cache entry is updated or validated, the resolver must ensure that only fresh and authentic data is stored. Here is a pseudo code example for cache update and validation logic:

function update_cache(domain, ip_address, ttl, response_id, expected_id):
    if response_id == expected_id:  // Validate response matches query
        cache[domain] = {ip_address, current_time, ttl}
    else:
        discard response  // Possible spoofed reply, do not update cache

This logic ensures that only responses matching the original query are allowed to update the cache, helping prevent cache poisoning.