{"id":989,"date":"2026-09-28T16:29:38","date_gmt":"2026-09-28T16:29:38","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=989"},"modified":"2026-10-03T12:20:55","modified_gmt":"2026-10-03T12:20:55","slug":"what-is-dns-propagation-how-long-does-it-take","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/what-is-dns-propagation-how-long-does-it-take\/","title":{"rendered":"What Is DNS Propagation? How Long Does It Take?"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; DNS Propagation<\/p>\n<p>DNS propagation is mostly the process of cached answers expiring. The authoritative server may have the new record immediately, while different resolvers continue returning the old answer for different lengths of time.<\/p>\n<ul>\n<li><strong>Typical timing<\/strong> \u2014 An ordinary record may appear across networks within minutes or its current TTL, but there is no universal exact deadline.<\/li>\n<li><strong>TTL matters<\/strong> \u2014 A resolver can keep an old answer until its cached TTL expires, and lowering TTL later cannot shorten an existing cache.<\/li>\n<li><strong>Nameserver changes<\/strong> \u2014 Changing NS records can take longer because parent-zone delegation and old resolver caches are involved.<\/li>\n<li><strong>Check layers<\/strong> \u2014 Compare the authoritative server, public recursive resolvers, local DNS, and HTTP response separately.<\/li>\n<li><strong>Check IPv6<\/strong> \u2014 An old AAAA record can send IPv6 clients to a different server even when the A record is correct.<\/li>\n<li><strong>Watch exceptions<\/strong> \u2014 NXDOMAIN, DNSSEC failures, and CDN caching can resemble propagation delays but require separate checks.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">DNS propagation usually means cached answers expiring, not a new record being pushed across the internet. An ordinary change may appear within minutes or its TTL, while nameserver changes, DNSSEC errors, negative caching, and an overlooked AAAA record can make the delay look like a broken migration.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 13 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#dns-propagation-is-mostly-a-cache-expiry-problem\">DNS propagation is mostly a cache-expiry problem<\/a><\/li>\n<li><a href=\"#how-long-should-dns-propagation-take\">How long should DNS propagation take?<\/a><\/li>\n<li><a href=\"#ttl-only-helps-if-you-lower-it-early-enough\">TTL only helps if you lower it early enough<\/a><\/li>\n<li><a href=\"#the-record-changed-so-why-is-the-old-site-still-loading\">The record changed, so why is the old site still loading?<\/a><\/li>\n<li><a href=\"#why-nameserver-changes-usually-take-longer\">Why nameserver changes usually take longer<\/a><\/li>\n<li><a href=\"#query-the-layers-yourself\">Query the layers yourself<\/a><\/li>\n<li><a href=\"#dnssec-and-negative-caching-change-the-diagnosis\">DNSSEC and negative caching change the diagnosis<\/a><\/li>\n<li><a href=\"#a-migration-routine-i-can-trust\">A migration routine I can trust<\/a><\/li>\n<li><a href=\"#check-these-before-calling-it-dns-propagation\">Check These Before Calling It DNS Propagation<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"dns-propagation-is-mostly-a-cache-expiry-problem\">DNS propagation is mostly a cache-expiry problem<\/h2>\n<p>I have watched a DNS panel show the new address while my own browser continued opening the old server. The panel was not necessarily wrong, and the browser was not necessarily broken. Usually, different recursive resolvers simply had different cached answers.<\/p>\n<p>When you change an IP address, record type, or nameserver delegation, there is no central switch that updates every resolver at once. The authoritative server may return the new answer immediately, while ISP resolvers, operating systems, browsers, and company networks continue using the old answer until its cache lifetime ends.<\/p>\n<p>That is what people usually mean by DNS propagation. A new record is not being pushed across the internet. Recursive resolvers are expiring old answers and asking the authoritative server again.<\/p>\n<h3>Authoritative server versus recursive resolver<\/h3>\n<p>An authoritative DNS server holds the records for a domain. A recursive resolver looks up those records on behalf of your computer, VPS, or application. Your ISP&#8217;s resolver, Google Public DNS, and Cloudflare Resolver are all examples of recursive resolvers.<\/p>\n<p>If an A record has a TTL of 3,600 seconds, a resolver can normally keep that answer for up to one hour. It does not need to ask the authoritative server again before the cached answer expires. That is why a DNS panel can show the new record while some visitors still reach the old IP.<\/p>\n<p><strong>Start here<\/strong> &#8211; Before changing anything, check the TTL, confirm the authoritative nameservers, and query the authoritative server directly.<\/p>\n<h2 id=\"how-long-should-dns-propagation-take\">How long should DNS propagation take?<\/h2>\n<p>For a normal A, AAAA, or CNAME change, different networks may see the update within minutes or sometime before the record&#8217;s TTL expires. There is no exact moment when every user must see the new answer.<\/p>\n<p>A TTL of 300 seconds does not mean that everyone switches exactly five minutes after your edit. A resolver that queried just before the change may keep the old response for nearly five minutes. Another resolver may query after the change and see the new response immediately.<\/p>\n<table>\n<thead>\n<tr>\n<th>Change<\/th>\n<th>Typical planning range<\/th>\n<th>What affects it<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>A record with TTL 300<\/td>\n<td>Minutes<\/td>\n<td>The resolver&#8217;s cache age and any local caching.<\/td>\n<\/tr>\n<tr>\n<td>A record with TTL 3600<\/td>\n<td>Up to about one hour<\/td>\n<td>The old answer may remain valid until its cached TTL expires.<\/td>\n<\/tr>\n<tr>\n<td>Nameserver change<\/td>\n<td>Several hours or longer<\/td>\n<td>Parent-zone delegation and resolver caches are involved.<\/td>\n<\/tr>\n<tr>\n<td>NXDOMAIN response<\/td>\n<td>Negative TTL from the SOA record<\/td>\n<td>A missing record can be cached just like a positive answer.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Nameserver changes need more care than ordinary record edits. The delegation in the parent zone changes, and some resolvers may still use the old nameservers. Lowering the TTL now also cannot shorten an answer that was already cached with a higher TTL.<\/p>\n<p>For an ordinary record, plan around its current TTL. For a nameserver migration, allow several hours and keep watching the delegation. If old answers still appear consistently after 48 hours, inspect the delegation, DNSSEC, and resolver behavior instead of waiting blindly.<\/p>\n<p><strong>Keep in mind<\/strong> &#8211; TTL is an approximate cache lifetime, not a promise that every visitor changes at the same time.<\/p>\n<h2 id=\"ttl-only-helps-if-you-lower-it-early-enough\">TTL only helps if you lower it early enough<\/h2>\n<p>TTL tells a resolver, in seconds, how long a DNS answer may be cached. A value of 300 means five minutes; 86,400 means 24 hours. The TTL field is part of the DNS resource-record format described in RFC 1035.<\/p>\n<p>Before a planned server move, I usually lower important records to 300 or 600 seconds. That lower value must reach recursive resolvers before the migration. If I reduce the TTL immediately before changing the address, some resolvers may still hold the previous answer with its higher TTL.<\/p>\n<pre><code>dig +noall +answer example.com A\n\ndig @1.1.1.1 +noall +answer example.com A\ndig @8.8.8.8 +noall +answer example.com A<\/code><\/pre>\n<p>The first command uses your configured resolver. The next two query Cloudflare and Google Public DNS directly. The number beside the record is the remaining TTL. Run a command twice and watch whether that number counts down; that gives you a useful view of the resolver&#8217;s cache age.<\/p>\n<p>A low TTL is not automatically the right answer. It can create more queries for your authoritative DNS service and reduce cache efficiency. For a site that rarely changes, 3,600 seconds or more may be perfectly reasonable. Lower it for a planned migration, then raise it again after the move is stable.<\/p>\n<p>I have forgotten this timing before and lowered a TTL only a few minutes before a change. The DNS panel accepted the edit, but it could not retroactively clear caches around the internet. DNS is patient in a very literal way.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>Lowering TTL immediately before a migration does not erase answers already cached with the previous, higher TTL.<\/p>\n<\/div>\n<h2 id=\"the-record-changed-so-why-is-the-old-site-still-loading\">The record changed, so why is the old site still loading?<\/h2>\n<p>An old page does not identify the failing layer by itself. I separate DNS from HTTP before touching the configuration.<\/p>\n<ul>\n<li><strong>Local cache:<\/strong> Your operating system or browser may still have the earlier answer.<\/li>\n<li><strong>Recursive resolver:<\/strong> Your provider&#8217;s resolver may return the old IP until its TTL expires.<\/li>\n<li><strong>Authoritative DNS:<\/strong> You may have edited the wrong zone or a nameserver that is not authoritative for the domain.<\/li>\n<li><strong>Application layer:<\/strong> You may already be reaching the new IP, but a redirect, CDN cache, or web server is serving old content.<\/li>\n<li><strong>Hosts file:<\/strong> On Linux, <code>\/etc\/hosts<\/code> can override DNS. On Windows, check <code>C:\\Windows\\System32\\drivers\\etc\\hosts<\/code>.<\/li>\n<\/ul>\n<p>Refreshing a browser is not a reliable test. First find the IP returned by DNS, then check what HTTP response that IP serves. I use the same separation when diagnosing the <a href=\"https:\/\/www.vps.tc\/blog\/en\/how-to-fix-dns-probe-finished-nxdomain-error\/\">How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error<\/a>.<\/p>\n<pre><code>dig +short NS example.com\ndig +short A example.com\ncurl -I --resolve example.com:443:203.0.113.20 https:\/\/example.com\/<\/code><\/pre>\n<p><code>dig +short NS<\/code> lists the delegation returned by your resolver, while <code>dig +short A<\/code> shows the address it returns. The <code>--resolve<\/code> option makes curl connect to the specified IP while still sending the requested hostname and SNI. That makes it useful for testing the HTTPS service without changing DNS.<\/p>\n<p><strong>Do this first<\/strong> &#8211; Test NS, A or AAAA, and HTTP separately. A browser result alone cannot tell you which layer is wrong.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>A domain can have a correct A record and an old AAAA record at the same time. IPv4 and IPv6 clients may then reach different servers.<\/p>\n<\/div>\n<h2 id=\"why-nameserver-changes-usually-take-longer\">Why nameserver changes usually take longer<\/h2>\n<p>Changing an A record edits one record inside the existing authoritative zone. Changing nameservers changes the delegation in the parent zone, which tells resolvers where the zone should be queried.<\/p>\n<p>During the transition, both DNS providers should serve the same records. A resolver with the old delegation may query the old provider, while another resolver with the new delegation queries the new one. Do not shut down the old zone immediately.<\/p>\n<p>Compare A, AAAA, MX, TXT, CAA, and CNAME records on both providers. The website is only one part of the migration. MX records affect mail, TXT records may be used for SPF, DKIM, or verification, and CAA records can affect certificate issuance.<\/p>\n<p>Export the zone before making the change. I once treated an NS migration as a website-only task and nearly missed a verification TXT record. The page opened, which was not enough.<\/p>\n<p>The staged approach in <a href=\"https:\/\/www.vps.tc\/blog\/en\/cloud-migration-checklist-step-by-step-planning-guide\/\">Cloud Migration Checklist: A Step-by-Step Planning Guide<\/a> works well here too: prepare the new service, test it, then change the delegation during a planned window.<\/p>\n<h2 id=\"query-the-layers-yourself\">Query the layers yourself<\/h2>\n<p>Online DNS checkers can be useful, but they may have their own caches and resolver pools. When I need an answer I can trust, I query several resolvers directly from a shell.<\/p>\n<pre><code>dig @1.1.1.1 example.com A +noall +answer\ndig @8.8.8.8 example.com A +noall +answer\ndig @9.9.9.9 example.com A +noall +answer\n\ndig +trace example.com A<\/code><\/pre>\n<p>The first three commands compare recursive resolvers. The <code>+trace<\/code> query follows the delegation chain from the root servers. It does not show your local resolver&#8217;s cache, but it helps reveal whether the delegation reaches the expected authoritative servers.<\/p>\n<p>Query an authoritative server directly as well:<\/p>\n<pre><code>dig +short NS example.com\ndig @ns1.example-dns.com example.com A +noall +answer<\/code><\/pre>\n<p>If the authoritative server returns the new IP while public resolvers return the old one, ordinary caching is the likely explanation. If the authoritative server also returns the old IP, check whether you edited the wrong zone, saved the record, or identified the correct DNS provider.<\/p>\n<p>Check IPv6 every time. An A record can point to the new server while an AAAA record still points to the old one. IPv6 clients then take a different path, and the result looks like propagation trouble even though both records are following their configuration.<\/p>\n<p><strong>Compare both families<\/strong> &#8211; Query A and AAAA through at least two public resolvers and directly through an authoritative nameserver.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Query the authoritative nameserver directly before blaming propagation. If it still returns the old record, a recursive resolver cache is not the main problem.<\/p>\n<\/div>\n<h2 id=\"dnssec-and-negative-caching-change-the-diagnosis\">DNSSEC and negative caching change the diagnosis<\/h2>\n<p>DNSSEC adds signatures and a chain of trust to DNS answers. During a nameserver migration, an outdated DS record at the parent combined with an incompatible DNSSEC configuration can make validating resolvers reject the response with <code>SERVFAIL<\/code>. That is not an ordinary TTL delay.<\/p>\n<p>Missing records can be cached too. RFC 2308 describes negative caching and the SOA values used to determine how long a resolver may remember an NXDOMAIN or other negative response. If a subdomain did not exist when someone queried it, creating it a minute later may not make it visible everywhere immediately.<\/p>\n<pre><code>dig example.com SOA +noall +answer\ndig example.com DNSKEY +dnssec +noall +answer\ndig example.com A +dnssec +noall +answer<\/code><\/pre>\n<p>The SOA serial helps confirm that you are looking at the expected zone version. Its fields also provide information used for negative caching. A DNSSEC query may include <code>RRSIG<\/code> records. When the result is <code>SERVFAIL<\/code>, inspect the DNSSEC chain instead of assuming the resolver is merely slow.<\/p>\n<p>A CDN adds another cache layer. DNS may already point to the new service while the CDN continues serving an older HTTP response according to <code>Cache-Control<\/code> or its own policy. That is separate from the DNS caching described in <a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-a-cdn-how-it-speeds-up-websites\/\">What Is a CDN? How It Speeds Up Websites<\/a>.<\/p>\n<p><strong>Separate the errors<\/strong> &#8211; For NXDOMAIN, inspect negative caching. For SERVFAIL, check DNSSEC and delegation before changing records again.<\/p>\n<h2 id=\"a-migration-routine-i-can-trust\">A migration routine I can trust<\/h2>\n<h3>Before changing DNS<\/h3>\n<ol>\n<li>Export the current A, AAAA, CNAME, MX, TXT, CAA, and NS records.<\/li>\n<li>Verify the authoritative nameservers with <code>dig +short NS yourdomain.tld<\/code>.<\/li>\n<li>Test the new web, mail, TLS, and application services by direct IP or temporary hostname.<\/li>\n<li>Lower critical TTLs early enough for recursive resolvers to receive the lower value.<\/li>\n<\/ol>\n<h3>After changing DNS<\/h3>\n<ol>\n<li>Query the new answer directly from an authoritative nameserver.<\/li>\n<li>Compare 1.1.1.1, 8.8.8.8, and your local resolver.<\/li>\n<li>Confirm that A and AAAA follow the same migration plan.<\/li>\n<li>Test mail delivery, verification TXT records, TLS, redirects, and CDN behavior separately.<\/li>\n<\/ol>\n<p>The virtual-host and TLS checks in How to Install and Configure Nginx on Ubuntu are useful before changing DNS. DNS can point to the correct IP while Nginx still selects the wrong site because of an incorrect <code>server_name<\/code>.<\/p>\n<p>Keep the old DNS provider, mail records, and monitoring checks active for at least one full TTL cycle after the change. For an NS migration, I keep them longer when practical.<\/p>\n<p>That habit came from my homelab. I changed an A record, checked IPv4, and declared the move finished. The AAAA record still pointed to the old machine, so IPv6 clients quietly went somewhere else. Since then, A and AAAA sit beside each other on every migration checklist.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I once checked only IPv4 after a homelab DNS change and missed an unchanged AAAA record. IPv6 clients kept reaching the old machine, so both address families are now on my migration checklist.<\/p>\n<\/div>\n<h2 id=\"check-these-before-calling-it-dns-propagation\">Check These Before Calling It DNS Propagation<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Export all current DNS records before changing the zone.<\/li>\n<li>Verify the authoritative nameservers with dig.<\/li>\n<li>Lower important TTLs before the migration, not at the last minute.<\/li>\n<li>Test the new server directly by IP or temporary hostname.<\/li>\n<li>Query the authoritative server and at least two public resolvers.<\/li>\n<li>Check both A and AAAA records after the change.<\/li>\n<li>Keep the old DNS service and monitoring active for one full TTL cycle.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>During your next DNS migration, start with the authoritative answer rather than the browser. A few direct dig queries usually show whether you are waiting for cache expiry or debugging the wrong layer.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<p>When I troubleshoot DNS propagation, I also make sure I understand what is actually being resolved, so I recommend reading our guide, <a href=\"https:\/\/www.vps.tc\/blog\/en\/domain-vs-url-difference\/\">Domain vs URL: What Is the Difference?<\/a>, for a clear explanation of domains, hosts, and complete URLs.<\/p>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>How long does DNS propagation take for an A record?<\/summary>\n<p>Most A record changes appear on different networks within a few minutes to the record&#039;s TTL. A 300-second TTL allows a resolver to cache the answer for about five minutes, but the timing depends on when that resolver last queried the record. Local DNS, browser caches, and hosts files can add another layer.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Does lowering TTL make DNS propagation instant?<\/summary>\n<p>No. Lowering TTL helps only after resolvers have seen and cached the lower value. A resolver that already stored the old answer with a higher TTL can keep using it until that original cache lifetime ends. Lower the TTL before a planned change, then restore it after the migration is stable.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Why does my DNS panel show the new IP while visitors see the old site?<\/summary>\n<p>The panel may show the authoritative zone while visitors use recursive resolvers that still have the old answer cached. You may also have edited the wrong nameserver, left an AAAA record pointing to the old host, or reached the new IP where an HTTP configuration or CDN still serves old content. Compare DNS and HTTP separately.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Why do nameserver changes take longer than A record changes?<\/summary>\n<p>An A record change affects a record inside the existing authoritative zone. A nameserver change affects the delegation stored in the parent zone, so resolvers can temporarily use either the old or new provider. Keep both providers serving matching records until the transition settles, and plan for several hours rather than one short TTL.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can DNS propagation cause an NXDOMAIN error?<\/summary>\n<p>Yes. Resolvers can cache a negative answer when a record does not exist. RFC 2308 describes how SOA values provide information for negative caching. If you create a record shortly after someone queried its nonexistent state, some resolvers may continue returning NXDOMAIN until that negative cache lifetime expires.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>How can I tell whether DNS or my web server is the problem?<\/summary>\n<p>Query the authoritative nameserver and several recursive resolvers with dig, then test the destination directly with curl &#8211;resolve. If the authoritative server returns the new IP but public resolvers return the old one, caching is likely. If the correct IP answers but the wrong website appears, inspect the virtual host, TLS configuration, redirects, and CDN cache.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc1035\" target=\"_blank\" rel=\"noopener\">RFC 1035 &#8211; Domain Names: Implementation and Specification<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc2308\" target=\"_blank\" rel=\"noopener\">RFC 2308 &#8211; Negative Caching of DNS Queries<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/icann.org\/\" target=\"_blank\" rel=\"noopener\">ICANN &#8211; DNS Basics<\/a> \u2014 icann.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>DNS propagation is mainly the expiry of cached answers. Learn how TTL, nameserver changes, DNSSEC, negative caching, and IPv6 affect a migration.<\/p>\n","protected":false},"author":2,"featured_media":987,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-989","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-domain"],"lang":"en","translations":{"en":989,"tr":988},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/989","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=989"}],"version-history":[{"count":3,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/989\/revisions"}],"predecessor-version":[{"id":1028,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/989\/revisions\/1028"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/987"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=989"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=989"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=989"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}