Clear support for the awkward problems between networks

When this is useful

Routing and DNS issues can look like broken websites, failed email, poor connectivity, unreachable services, or intermittent access. I can help review the records, test reachability, and put the evidence into a form your provider or vendor can use.

DNS and routing checks that reduce guesswork

A useful DNS or routing review starts by identifying the exact layer that changed. A website outage after a domain move may be nameserver delegation, an A/CNAME record, stale resolver cache, SSL, hosting configuration, or a redirect. An email outage may be MX records, SPF/DKIM/DMARC alignment, a mailbox platform issue, or a third-party sender that was never added to the record set.

Routing symptoms need a different evidence path. If a service works from one provider but not another, the useful questions are which source network fails, what the traceroute shows, when the issue started, and whether the failure is DNS resolution, TCP reachability, TLS, or application-level behavior. That evidence is what makes provider escalation less vague.

Cutover and escalation notes

• Record current registrar, nameservers, DNS host, hosting target, mail provider, and any third-party senders.
• Capture before-and-after DNS records, TTL values, and the planned rollback path before making changes.
• Test from more than one resolver or network when symptoms differ between locations.
• Separate DNS resolution results from connection tests, TLS errors, redirects, and application responses.
• Summarize affected networks, timestamps, traceroute notes, and provider ticket references for escalation.

DNS change order

DNS work is safest when the control points are checked before records are changed. Confirm the registrar, the delegated nameservers, the active DNS host, the current record values, the TTLs, and the rollback target. A domain move should not start by editing random records in a dashboard unless that dashboard is definitely authoritative for the domain.

TTL, cache, and propagation expectations

Many "propagation" issues are really cache timing, resolver differences, or a record being changed in the wrong place. TTL controls how long resolvers may cache a DNS answer, but local operating-system, browser, router, ISP, and public resolver caches can make the user experience look inconsistent for a while.

• Record the old TTL and new TTL before changing a record.
• Check authoritative DNS separately from recursive resolvers such as Google Public DNS or Cloudflare.
• Flush a public resolver cache only when it is appropriate and you understand which record type is being refreshed.
• Do not treat one resolver result as proof that every network will see the same answer immediately.
• For urgent rollback, confirm whether users are still seeing a cached old answer, a wrong new answer, or a separate hosting/application issue.

Reachability and routing evidence

If a service resolves correctly but still fails from some networks, the evidence needs to move beyond DNS. Record whether the problem is TCP reachability, TLS certificate mismatch, redirect behavior, firewall policy, provider routing, or application response. For routing symptoms, comparing source networks is more useful than running the same test ten times from one connection.

BGP context for partial outages

Most SMEs do not manage BGP directly, but BGP can still matter when a site, IP range, SaaS service, or provider-hosted system is reachable from some networks and not others. The practical role here is evidence gathering: which networks fail, which paths are visible, when the issue started, and which upstream provider or host has the authority to investigate.

• Identify the affected domain, IP address, provider, source networks, and time window.
• Check whether DNS answers point to the expected IP or CDN target before blaming routing.
• Compare traceroutes or route-visibility tools only as evidence for escalation, not as a final diagnosis by themselves.
• Keep application symptoms separate from routing symptoms: a route can work while the service itself fails.
• Escalate with concise evidence so the ISP, hosting provider, CDN, or upstream network can reproduce the path.