Share via

Changes are not fully propagated worldwide after migration to Public Azure DNS after 1week

Tadas Šukys 45 Reputation points
2026-05-25T09:19:31.2333333+00:00

Hello,

I've transferred my DNS records to Azure Public DNS on 19th May, updated name servers at my domain registrar to point to Azure DNS.

My Azure DNS name servers are:
ns1-01.azure-dns.com.

ns2-01.azure-dns.net.

ns3-01.azure-dns.org.

ns4-01.azure-dns.info.

Now, almost after a whole week DNS changes not fully propagated worldwide.

The tool https://digwebinterface.com/ shows that some of name servers are updated, but some still not (for example 1.1.1.1 Cloudflare, 8.8.8.8 Google).

What is the issue here and how to fix it?

User's image

Azure DNS
Azure DNS

An Azure service that enables hosting Domain Name System (DNS) domains in Azure.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Thanmayi Godithi 10,820 Reputation points Microsoft External Staff Moderator
    2026-05-29T11:28:02.0366667+00:00

    Hey Tadas Šukys, it looks like you’ve correctly created your Azure DNS zone and pointed your registrar at the four Azure name‐servers, but some public resolvers (1.1.1.1, 8.8.8.8, etc.) are still serving the old data from cache. Here’s how to diagnose and fix it:

    1. Confirm proper delegation • Run a trace from the root down to your domain’s NS records: dig NS your-domain.com +trace • At the “.com” step you should see exactly: ns1-01.azure-dns.com. ns2-01.azure-dns.net. ns3-01.azure-dns.org. ns4-01.azure-dns.info. If you see anything different here, update your registrar’s NS entries accordingly.
    2. Check your registrar’s panel • Verify the four Azure NS entries are an exact match. • Watch out for trailing dot vs. no-dot issues—some registrars want you to omit the final “.”.
    3. Understand TTL and caching • Parent (TLD) servers publish their NS record TTL (often 48 hours or more). • Public resolvers cache that NS set for the full TTL. Even after you update at the registrar, caches can hold the old set until the TTL expires.
    4. Test specific resolvers • Do a direct query against Azure’s servers to bypass caches: dig @ns1-01.azure-dns.com your-domain.com • Then test popular public DNS to see what they still return: dig NS your-domain.com @1.1.1.1 dig NS your-domain.com @8.8.8.8
    5. Wait out propagation (if delegation is correct) • Once your registrar and trace show the Azure NS, it’s just a matter of waiting for all caches to time out—usually 48–72 hours, but some resolvers can be slower.

    If after that you still see old servers on known public resolvers, please share:

    • Your actual domain name

    • The full output of dig NS your-domain.com +trace

    • Screenshots or copy-pastes of what your registrar’s NS settings look like

    With that we can pinpoint if it’s a delegation typo, a TTL issue, or something else. Good luck!

    Kindly let us know if the above helps or you need further assistance on this issue.

    If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    2 people found this answer helpful.

  2. AI answer

    2026-05-25T09:19:57.0266667+00:00

    The issue is almost certainly not with Azure DNS itself but with how recursive resolvers (like 1.1.1.1 and 8.8.8.8) are caching or querying your zone. Azure DNS starts serving the zone as soon as the delegation is correct; if some public resolvers still show old data after a week, it usually means one of the following:

    1. Delegation or records are not exactly as expected.
    2. Queries are being made against non‑authoritative resolvers or cached results.

    Use these steps to verify and fix:

    1. Confirm records in Azure DNS
      In the Azure portal, open the DNS zone and verify:
      • Zone name is correct.
      • Each record (A, CNAME, MX, TXT, etc.) has the expected name and type.
        This ensures Azure DNS is serving the right data.
    2. Query Azure DNS name servers directly
      Use a tool like digwebinterface and explicitly set the name servers shown in the Azure portal (for example ns1-01.azure-dns.com, ns2-01.azure-dns.net, etc.):
      • Enter the fully qualified record name (including the zone name).
      • Choose the correct record type.
        If the records are correct when querying Azure’s authoritative name servers, Azure DNS is configured properly.
    3. Verify delegation is correct
      Run a delegation (SOA/NS) check for just the zone name (not an individual record).
      • Ensure the parent zone (your registrar/registry) lists exactly the Azure DNS name servers for your domain.
      • Tools that perform “DNS delegation validation” can confirm this.
    4. Check from multiple locations without local caching
      When testing from a PC or corporate network, results may be affected by local DNS caches or DNS proxies.
      • Use web-based tools (like digwebinterface) with default name server settings to see what typical recursive resolvers return after you’ve confirmed delegation and authoritative records.
    5. Allow for propagation and cache expiry
      Once delegation and records are correct at Azure DNS and visible on the Azure name servers, recursive resolvers will update as their existing cache entries expire. If previous records had long TTLs at the old DNS host, some resolvers may keep old data until those TTLs time out. After a week, this should normally be resolved, but confirming steps 1–4 ensures there is no configuration issue prolonging it.

    If all checks above pass (correct records in Azure DNS, correct delegation, and correct responses from Azure name servers), no further action is required on Azure DNS; remaining inconsistencies will clear as external caches expire.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.