DEV Community

Cover image for Client Branded Links Stopped Working After a DNS Change: What to Check
Yuto Tanaka
Yuto Tanaka

Posted on

Client Branded Links Stopped Working After a DNS Change: What to Check

#devops #infrastructure #networking

A branded short link can look like a DNS problem when it is actually a TLS problem, and vice versa. After a nameserver change, a CDN migration, or a zone edit, links.client.com may fail to resolve, resolve to the wrong target, return a certificate error, or redirect to a default page. The fastest way to narrow it down is to check the layers in order: authoritative DNS, TLS, HTTP redirects, and the link service's domain settings.

This checklist assumes the client controls client.com and uses a subdomain such as links.client.com for branded links. The same sequence works for an apex domain, but the DNS constraints are different, so that case gets its own note.

Start with the authoritative DNS answer

Do not begin in the browser. Browser caches, OS caches, and public resolver caches can all hide the current state. Query DNS directly.

dig +short links.client.com
dig +short links.client.com CNAME
dig +short links.client.com A
dig +short links.client.com AAAA
Enter fullscreen mode Exit fullscreen mode

What you want to see depends on how the link service is set up:

  • A CNAME pointing to the provider target, usually with a trailing dot such as links.provider.example.. The trailing dot is normal in DNS output.
  • An A or AAAA record if the provider uses CNAME flattening, a proxy, or a direct IP target.
  • No conflicting records at the same name. A CNAME cannot coexist with an A, AAAA, TXT, or other data at the same owner name.

If dig returns a CNAME but no final address, follow the target. The provider target may be missing, misspelled, or itself broken. If it returns an old IP address from before the migration, the zone change may not have been applied where you think it was.

Check the delegation, not just the record

A common failure is updating records at the old DNS host while the domain is delegated to different nameservers. Look at the delegation and the path resolution takes.

dig NS client.com +short
dig +trace links.client.com
Enter fullscreen mode Exit fullscreen mode

dig NS shows the nameservers currently advertised for the zone. If those are not the ones you edited, the records you changed are irrelevant. Update the registrar or the active DNS provider instead.

dig +trace shows where resolution diverges: at the root, the TLD, the zone's nameservers, or the final target. It is especially useful when one resolver gives the right answer and another gives an old one. If you see SERVFAIL and DNSSEC is enabled, check that the DS record at the registrar matches the new DNS provider. A DNSSEC mismatch can make the whole zone fail even when the records themselves look correct.

Handle apex domains differently

If the branded host is the apex, such as client.com rather than links.client.com, a normal CNAME is not valid alongside the NS and SOA records every zone needs. Some DNS providers offer ALIAS, ANAME, or CNAME flattening at the apex; others require A and AAAA records, or a redirect at the HTTP layer.

Do not assume the provider's flattening behavior is visible in the dashboard. Check what public resolvers actually return:

dig +short client.com CNAME
dig +short client.com A
dig +short client.com AAAA
Enter fullscreen mode Exit fullscreen mode

If the answer changes depending on the resolver, or if the provider returns a mixture of records, treat that as a configuration problem rather than a propagation delay. Also check that a TXT or verification record was not removed when the CNAME was added.

Check TLS before blaming the redirect

DNS can be correct and the link can still fail at HTTPS. A new CDN or reverse proxy may answer for the hostname but not have a certificate that covers it.

curl -Iv https://links.client.com/abc 2>&1 | sed -n '1,40p'
openssl s_client -connect links.client.com:443 -servername links.client.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Enter fullscreen mode Exit fullscreen mode

Check three things:

  1. The certificate is valid for links.client.com, not only for the provider's default hostname.
  2. The certificate chain is complete.
  3. The server negotiates TLS with the correct SNI name. openssl s_client with -servername tests that directly.

If the DNS target changed to a CDN, the CDN usually needs the custom hostname added and validated before it will serve the right certificate. If the site uses HSTS, a broken HTTPS response will not fall back to HTTP; the browser will fail hard. Test with curl first so you see the actual error instead of a browser-generated message.

Follow the full redirect chain

A branded short link is usually a redirector. DNS gets the client to the redirector; the redirector then sends the client to the destination. Both halves can break.

curl -sS -o /dev/null -w '%{http_code} %{url_effective}' https://links.client.com/abc
curl -sS -o /dev/null -w '%{http_code} %{url_effective}' -L https://links.client.com/abc
Enter fullscreen mode Exit fullscreen mode

The first command shows the first response. The second follows redirects and prints the final URL. Check for:

  • A 301, 302, 307, or 308 to the expected destination.
  • A redirect loop between HTTP and HTTPS, www and non-www, or two hostnames.
  • A path or query string that is dropped during the redirect.
  • A redirect to a default page, which often means the hostname is recognized but the short-link path is not.

While testing, prefer temporary redirects over permanent ones if you control the redirect layer. Browsers cache 301 and 308 aggressively, and a bad permanent redirect can keep failing after DNS is fixed. Clear the browser cache or test with curl from a clean environment.

Test the Host header and application routing

If DNS points to the right server but the response is a generic 404, 403, or default site, the server may not recognize the hostname. Test the IP directly with the expected Host header.

curl -I http://<new-ip>/abc -H 'Host: links.client.com'
Enter fullscreen mode Exit fullscreen mode

If that returns the link, DNS is doing its job and the problem is in virtual-host, TLS, or proxy routing. For an nginx-style reverse proxy, the relevant configuration usually looks like this:

server {
    listen 443 ssl;
    server_name links.client.com;

    location / {
        proxy_pass http://link-service.internal;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
Enter fullscreen mode Exit fullscreen mode

The exact configuration depends on the stack. The point is to verify that the hostname reaches the application, not just the server's IP address. A missing server_name, a missing certificate, or a proxy that rewrites the Host header can all produce symptoms that look like DNS failures.

Check the link service's domain state

DNS only routes traffic. The link shortener or redirect service also has to recognize the branded hostname. Check its domain settings for the hostname status, verification records, certificate status, and any default destination or path prefix.

Depending on the service, a domain may need a TXT record, a CNAME, or both before it becomes active. If the domain was removed, left pending, or re-added under a different project, links on that host may return a 404 or fall back to a generic page even though DNS resolves correctly. This is a configuration layer, not a DNS layer, and it is easy to miss after a migration.

To separate a client-domain problem from a general outbound-network problem, test a short URL on a different host from the same machine, such as LinkBit. If that resolves and redirects while links.client.com does not, focus on the client hostname, its certificate, and its link-service configuration.

Account for TTLs and negative caching

If the hostname returned NXDOMAIN or SERVFAIL during the change, resolvers may cache that negative answer. Fixing the record does not always make the error disappear immediately. Check the zone's SOA and query multiple public resolvers.

dig links.client.com SOA
dig @1.1.1.1 links.client.com
dig @8.8.8.8 links.client.com
Enter fullscreen mode Exit fullscreen mode

Also check from outside the client's network. Split-horizon DNS can make an internal resolver return an old internal address while public resolvers return the new target. If the link works in the office and fails for customers, internal DNS is a likely difference.

Before future changes, lower the TTL on the branded hostname well in advance. Keep the old target alive until the TTL has expired, and avoid changing nameservers and records at the same time unless you can watch both layers closely.

Mistakes that look like DNS failures

  • Updating records at the old DNS provider after the domain was delegated elsewhere.
  • Adding a CNAME and an A record at the same name.
  • Using a plain CNAME at the apex without provider flattening.
  • Pointing DNS at a CDN but not adding the custom hostname or certificate there.
  • Forgetting to recreate a verification TXT record after a zone migration.
  • Testing only from an internal network with split-horizon DNS.
  • Trusting a browser after a permanent redirect has been cached.
  • Changing DNSSEC settings without matching the DS record at the registrar.

The order that saves time is authoritative DNS first, then TLS, then redirects, then the link service's domain state. If the authoritative answer is right and the certificate is valid, the problem is rarely still DNS. It is usually the layer that was changed next.

DNS #WebDev #DevOps #Troubleshooting #Networking

Top comments (0)