{"id":59,"date":"2026-09-02T16:25:30","date_gmt":"2026-09-02T16:25:30","guid":{"rendered":"https:\/\/www.tkwebhosts.com\/blog\/what-is-dns-and-how-dns-records-work\/"},"modified":"2026-09-02T16:52:20","modified_gmt":"2026-09-02T16:52:20","slug":"what-is-dns-and-how-dns-records-work","status":"publish","type":"post","link":"https:\/\/www.tkwebhosts.com\/blog\/what-is-dns-and-how-dns-records-work\/","title":{"rendered":"What is DNS and How DNS Records Work"},"content":{"rendered":"<p class=\"article-byline\">By the <a href=\"https:\/\/www.tkwebhosts.com\/about\">TK WebHosts Web Team<\/a> \u00b7 Last reviewed 2 September 2026<\/p>\n<p>Almost every problem that looks like a broken website or missing email turns out to be a DNS problem. A site that loads for one person and not another, mail that vanishes after a provider change, a security certificate that will not issue \u2014 these are usually one wrong line in a zone file, not a failure of the server everyone is blaming.<\/p>\n<p>DNS has a reputation for being obscure, and it is mostly undeserved. The system does one job, records have four moving parts, and about six record types cover nearly everything a business will ever touch. What follows is that foundation, in the order it makes sense to learn it.<\/p>\n<h2>What DNS actually does<\/h2>\n<p>DNS stands for the <strong>Domain Name System<\/strong>. Its job is translation: it turns a name a person can remember into an address a machine can route to.<\/p>\n<p>A browser asked for <code>example.com<\/code> cannot do anything with that name. It needs an IP address \u2014 <code>93.184.216.34<\/code>, or an IPv6 equivalent. DNS is the lookup layer that turns the first into the second, and it runs before the connection to the website is ever opened.<\/p>\n<p>That translation is the whole purpose. Everything else \u2014 email routing, domain verification, email authentication \u2014 is built on the same lookup mechanism, reusing it to publish other kinds of information under a domain name.<\/p>\n<h2>How a lookup really happens<\/h2>\n<p>DNS is often described as one big directory copied around the world. That is a useful picture and a slightly misleading one. The system is <strong>hierarchical and delegated<\/strong>, not duplicated.<\/p>\n<p>A lookup for <code>www.example.com<\/code> walks down a chain:<\/p>\n<ol>\n<li><strong>The resolver.<\/strong> The device asks a recursive resolver \u2014 usually one run by the internet provider, or a public one such as <code>1.1.1.1<\/code> or <code>8.8.8.8<\/code>. The resolver does the legwork.<\/li>\n<li><strong>The root.<\/strong> The resolver asks a root server which servers are authoritative for <code>.com<\/code>.<\/li>\n<li><strong>The TLD servers.<\/strong> It asks the <code>.com<\/code> servers which nameservers are authoritative for <code>example.com<\/code>.<\/li>\n<li><strong>The authoritative nameservers.<\/strong> It asks those for the actual record, and gets the answer.<\/li>\n<li><strong>The answer is cached<\/strong>, then returned.<\/li>\n<\/ol>\n<p>The important consequence: <strong>there is exactly one authoritative source for a domain&#8217;s records<\/strong> \u2014 the nameservers the domain is delegated to. Copies exist everywhere, but they are cached copies with an expiry date, not independent originals. Which is where the next part comes in.<\/p>\n<h2>TTL, and why changes take time<\/h2>\n<p>Every DNS record carries a <strong>TTL<\/strong> \u2014 time to live \u2014 measured in seconds. It tells any resolver that caches the record how long it may keep serving that answer before checking again.<\/p>\n<p>A record with a TTL of <code>3600<\/code> may be served from cache for an hour. Change that record and the world does not see the change for up to an hour, because resolvers holding the old value are entitled to keep using it. This is the entire explanation for &#8220;DNS propagation&#8221;, a phrase that describes cache expiry rather than anything propagating.<\/p>\n<p>Two practical rules follow:<\/p>\n<ul>\n<li><strong>Lower the TTL before a planned change, not during it.<\/strong> Dropping a TTL from 86400 to 300 takes up to a day to take effect, because the old TTL governs how long the old TTL is cached. Reduce it a day or two ahead of a migration, make the change, then raise it again afterwards.<\/li>\n<li><strong>Negative answers are cached too.<\/strong> If a record does not exist when it is first queried, the &#8220;does not exist&#8221; answer is cached \u2014 governed by the zone&#8217;s SOA minimum, not by the record&#8217;s own TTL, because the record has no TTL yet. This is why a newly added record sometimes appears slower than expected for the one person who checked too early.<\/li>\n<\/ul>\n<h2>What a DNS record is<\/h2>\n<p>A DNS record is a single published fact about a name. In its simplest form it is a mapping:<\/p>\n<p><strong>Name \u2192 Value<\/strong><\/p>\n<p>An A record for <code>example.com<\/code> with the value <code>93.184.216.34<\/code> publishes the fact that this name resolves to that address.<\/p>\n<p>In practice every record has four parts, and a fifth for some types:<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Part<\/th>\n<th>What it is<\/th>\n<th>Example<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Name<\/strong><\/td>\n<td>The name the record applies to. <code>@<\/code> means the domain itself; <code>www<\/code> means <code>www.example.com<\/code><\/td>\n<td><code>@<\/code>, <code>www<\/code>, <code>mail<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>Type<\/strong><\/td>\n<td>What kind of fact this is<\/td>\n<td><code>A<\/code>, <code>CNAME<\/code>, <code>MX<\/code>, <code>TXT<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>Value<\/strong><\/td>\n<td>The data \u2014 an address, a hostname, or text<\/td>\n<td><code>93.184.216.34<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>TTL<\/strong><\/td>\n<td>Seconds a resolver may cache it<\/td>\n<td><code>3600<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>Priority<\/strong><\/td>\n<td>Only on some types, notably MX<\/td>\n<td><code>10<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Control panels display these differently, and some hide the TTL entirely, but the underlying record is always the same shape.<\/p>\n<h2>The record types that matter<\/h2>\n<p>There are dozens of types. These are the ones a business domain actually uses.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Type<\/th>\n<th>Purpose<\/th>\n<th>Value looks like<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>A<\/strong><\/td>\n<td>Points a name at an IPv4 address<\/td>\n<td><code>93.184.216.34<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>AAAA<\/strong><\/td>\n<td>Points a name at an IPv6 address<\/td>\n<td><code>2606:2800:220:1:248:1893:25c8:1946<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>CNAME<\/strong><\/td>\n<td>Makes one name an alias of another name<\/td>\n<td><code>shop.example.com<\/code> \u2192 <code>stores.provider.net<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>MX<\/strong><\/td>\n<td>Names the servers that accept inbound mail for the domain<\/td>\n<td><code>1 smtp.google.com<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>TXT<\/strong><\/td>\n<td>Publishes arbitrary text \u2014 the carrier for email authentication and domain verification<\/td>\n<td><code>v=spf1 include:_spf.google.com -all<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>NS<\/strong><\/td>\n<td>Names the authoritative nameservers for the domain<\/td>\n<td><code>ns1.provider.com<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>CAA<\/strong><\/td>\n<td>Restricts which certificate authorities may issue certificates for the domain<\/td>\n<td><code>0 issue \"letsencrypt.org\"<\/code><\/td>\n<\/tr>\n<tr>\n<td><strong>SRV<\/strong><\/td>\n<td>Publishes the host and port for a specific service<\/td>\n<td><code>10 0 443 sip.provider.com<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Three rules about these catch people out repeatedly:<\/p>\n<ul>\n<li><strong>A CNAME cannot coexist with any other record on the same name.<\/strong> This is why the root of a domain \u2014 <code>example.com<\/code> itself, which must carry NS and usually MX \u2014 cannot be a plain CNAME. Providers work around it with non-standard record types marketed as ALIAS, ANAME or CNAME flattening, which resolve the target and answer with an A record.<\/li>\n<li><strong>An MX record must point to a hostname that has an A or AAAA record.<\/strong> It may not point to an IP address, and it may not point to a name that is itself a CNAME. Both are common mistakes and both cause intermittent, hard-to-diagnose delivery failures.<\/li>\n<li><strong>TXT records have a 255-character limit per string.<\/strong> Longer values, such as a 2048-bit DKIM key, are published as multiple quoted strings that resolvers concatenate. Splitting one incorrectly produces a record that looks present and does not work.<\/li>\n<\/ul>\n<h2>Nameservers: the record that controls all the others<\/h2>\n<p>The single most consequential setting on a domain is not any individual record. It is the <strong>nameserver delegation<\/strong> \u2014 the NS records held at the registry that say which servers are authoritative.<\/p>\n<p>This is the source of the most common confusion in DNS. There are three places that can appear to own a domain&#8217;s records:<\/p>\n<ul>\n<li><strong>The registrar<\/strong> \u2014 where the domain is registered and paid for. It sets the delegation.<\/li>\n<li><strong>The DNS host<\/strong> \u2014 whichever nameservers the domain is delegated to. This is where records are actually read from.<\/li>\n<li><strong>The web or mail host<\/strong> \u2014 the servers the records point at.<\/li>\n<\/ul>\n<p>These are frequently three different companies, and they can be the same one. Records edited at a registrar have no effect if the domain is delegated to somebody else&#8217;s nameservers \u2014 the edits are real, saved, and simply never consulted. Before changing any record, establish where the domain is actually delegated. A public <code>whois<\/code> lookup, or <code>dig NS example.com<\/code>, answers it in seconds.<\/p>\n<p>Nameserver changes are also the slowest change in DNS, because they are cached at the TLD level with long TTLs. Moving DNS hosting means recreating every record at the new host <strong>first<\/strong>, then switching delegation \u2014 never the other way round.<\/p>\n<h2>The records that carry email<\/h2>\n<p>Email is where DNS stops being a website concern and becomes a business-continuity one, because four different record types are involved and each does a job the others cannot.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Record<\/th>\n<th>What it controls<\/th>\n<th>Direction<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>MX<\/strong><\/td>\n<td>Which servers accept mail sent <em>to<\/em> the domain<\/td>\n<td>Inbound only<\/td>\n<\/tr>\n<tr>\n<td><strong>TXT (SPF)<\/strong><\/td>\n<td>Which servers are authorised to send <em>as<\/em> the domain<\/td>\n<td>Outbound<\/td>\n<\/tr>\n<tr>\n<td><strong>TXT or CNAME (DKIM)<\/strong><\/td>\n<td>The public key that verifies a message&#8217;s signature<\/td>\n<td>Outbound<\/td>\n<\/tr>\n<tr>\n<td><strong>TXT (DMARC)<\/strong><\/td>\n<td>What receivers should do with mail that fails the checks<\/td>\n<td>Outbound policy<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>The distinction worth fixing early: <strong>MX records are inbound only.<\/strong> They say where mail arrives. They have nothing to do with sending, and nothing to do with authentication. Changing MX records does not fix mail that is landing in spam, because MX was never involved in that journey.<\/p>\n<p>An MX record also carries a <strong>priority<\/strong> \u2014 sometimes called preference \u2014 where a lower number means higher precedence. A domain on Google Workspace can publish a single <code>1 smtp.google.com<\/code>, or the older set of five records at priorities 1, 5, 5, 10 and 10; a domain on TK WebHosts mail publishes <code>10 pixel.tkwebhosts.com<\/code>. Multiple records are alternates for redundancy, not a load-sharing arrangement.<\/p>\n<p>The three outbound records \u2014 SPF, DKIM and DMARC \u2014 are what receiving providers now check before deciding whether a message is genuinely from the domain it claims. Configuring them correctly is its own subject, covered in <a href=\"https:\/\/www.tkwebhosts.com\/blog\/how-to-configure-spf-dkim-dmarc\/\" target=\"_blank\" rel=\"noopener\">how to configure SPF, DKIM and DMARC<\/a>.<\/p>\n<h2>Five mistakes worth avoiding<\/h2>\n<ol>\n<li><strong>Editing records at the registrar when the domain is delegated elsewhere.<\/strong> The edits save successfully and change nothing.<\/li>\n<li><strong>Pointing an MX record at an IP address or a CNAME.<\/strong> Some receiving servers tolerate it; enough do not that mail becomes unreliable rather than broken, which is worse to diagnose.<\/li>\n<li><strong>Switching nameservers before recreating the records.<\/strong> Anything not recreated at the new host disappears at the moment of the switch, and email is usually the first thing noticed.<\/li>\n<li><strong>Publishing two records of a type that permits only one.<\/strong> Two SPF records on a domain do not combine \u2014 they are a permanent error, and the practical result is that SPF fails entirely.<\/li>\n<li><strong>Treating a control panel&#8217;s toggles as the truth.<\/strong> The zone is the truth. Verify with a lookup after every change.<\/li>\n<\/ol>\n<h2>How to check a record<\/h2>\n<p>Every DNS answer is publicly queryable, which makes verification the cheapest step in the process. On macOS or Linux, <code>dig<\/code> gives a direct answer:<\/p>\n<ul>\n<li><code>dig +short A example.com<\/code> \u2014 the address a name resolves to<\/li>\n<li><code>dig +short MX example.com<\/code> \u2014 the inbound mail servers and their priorities<\/li>\n<li><code>dig +short NS example.com<\/code> \u2014 where the domain is actually delegated<\/li>\n<li><code>dig +short TXT example.com<\/code> \u2014 text records, including SPF<\/li>\n<li><code>dig +short TXT _dmarc.example.com<\/code> \u2014 the DMARC policy<\/li>\n<\/ul>\n<p>On Windows, <code>nslookup -type=MX example.com<\/code> covers the same ground. Adding a resolver to the query \u2014 <code>dig +short MX example.com @1.1.1.1<\/code> \u2014 bypasses a local cache that may still be serving an old answer, which is the fastest way to tell a real problem from a stale one.<\/p>\n<h2>Where this leads<\/h2>\n<p>DNS is a small system with a large blast radius. The concepts above \u2014 delegation, TTL, the shape of a record, and which type does which job \u2014 cover the great majority of what any business needs to reason about it confidently.<\/p>\n<p>The next layer is email authentication, where TXT records stop describing infrastructure and start making assertions about identity. That is where SPF, DKIM and DMARC live, and where the consequences of a mistake show up not as an error message but as mail quietly going missing.<\/p>\n<h2>Frequently asked questions<\/h2>\n<h3>What is the difference between a domain and DNS?<\/h3>\n<p>A domain is the registered name itself, held through a registrar and renewed annually; DNS is the system that publishes what that name points to. Registering a domain gives ownership of the name, while DNS records are what make it resolve to a website or accept email, which is why a newly registered domain does nothing at all until records are added. The registration side is covered separately in <a href=\"https:\/\/www.tkwebhosts.com\/blog\/how-domain-registration-works\/\" target=\"_blank\" rel=\"noopener\">how domain registration works<\/a>.<\/p>\n<h3>How long do DNS changes take to take effect?<\/h3>\n<p>As long as the old record&#8217;s TTL, which is set in seconds and commonly between 300 and 86400. A record with a TTL of 3600 can be served from cache for up to an hour after the change, so lowering the TTL a day or two before a planned migration is what actually shortens the window. Nameserver changes are slower again, because the delegation is cached at the registry level with longer TTLs.<\/p>\n<h3>Can I point an MX record at an IP address?<\/h3>\n<p>No. An MX record must name a hostname that has its own A or AAAA record, and that hostname must not itself be a CNAME. Pointing MX at an IP address or at an alias produces delivery that works with some senders and fails with others, which is considerably harder to diagnose than an outright failure.<\/p>\n<h3>Why can&#8217;t the root of my domain be a CNAME?<\/h3>\n<p>Because a CNAME cannot coexist with any other record on the same name, and the root of a domain must carry NS records, usually MX records, and often TXT records. Providers work around this with non-standard record types marketed as ALIAS, ANAME or CNAME flattening, which look like a CNAME in the control panel but answer queries with a resolved A record.<\/p>\n<h3>Where are my DNS records actually hosted?<\/h3>\n<p>Wherever the domain&#8217;s nameservers point, which is not necessarily the registrar and not necessarily the web host. Running <code>dig NS example.com<\/code>, or checking a public WHOIS record, gives the authoritative answer. Records edited anywhere other than the delegated nameservers are saved but never consulted, which is the single most common reason a correct-looking change has no effect.<\/p>\n<h3>Do I need to manage DNS myself?<\/h3>\n<p>Not necessarily, and for a business where email and a website both matter, delegating it to a provider that reviews changes before they go live removes the largest category of self-inflicted outage. <a href=\"https:\/\/www.tkwebhosts.com\/managed-dns\" target=\"_blank\" rel=\"noopener\">Managed DNS<\/a> covers what that arrangement involves.<\/p>\n<h2>Sources<\/h2>\n<ul>\n<li>Domain Names \u2014 Concepts and Facilities, RFC 1034: <code>https:\/\/www.rfc-editor.org\/rfc\/rfc1034<\/code><\/li>\n<li>Domain Names \u2014 Implementation and Specification, RFC 1035: <code>https:\/\/www.rfc-editor.org\/rfc\/rfc1035<\/code><\/li>\n<li>Clarifications to the DNS Specification, RFC 2181 (MX and CNAME target rules): <code>https:\/\/www.rfc-editor.org\/rfc\/rfc2181<\/code><\/li>\n<li>Negative Caching of DNS Queries, RFC 2308: <code>https:\/\/www.rfc-editor.org\/rfc\/rfc2308<\/code><\/li>\n<li>DNS Certification Authority Authorization (CAA), RFC 8659: <code>https:\/\/www.rfc-editor.org\/rfc\/rfc8659<\/code><\/li>\n<\/ul>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@graph\": [\n    {\n      \"@type\": \"FAQPage\",\n      \"mainEntity\": [\n        {\n          \"@type\": \"Question\",\n          \"name\": \"What is the difference between a domain and DNS?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"A domain is the registered name itself, held through a registrar and renewed annually; DNS is the system that publishes what that name points to. Registering a domain gives ownership of the name, while DNS records are what make it resolve to a website or accept email, which is why a newly registered domain does nothing at all until records are added. The registration side is covered separately in how domain registration works.\"}\n        },\n        {\n          \"@type\": \"Question\",\n          \"name\": \"How long do DNS changes take to take effect?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"As long as the old record's TTL, which is set in seconds and commonly between 300 and 86400. A record with a TTL of 3600 can be served from cache for up to an hour after the change, so lowering the TTL a day or two before a planned migration is what actually shortens the window. Nameserver changes are slower again, because the delegation is cached at the registry level with longer TTLs.\"}\n        },\n        {\n          \"@type\": \"Question\",\n          \"name\": \"Can I point an MX record at an IP address?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"No. An MX record must name a hostname that has its own A or AAAA record, and that hostname must not itself be a CNAME. Pointing MX at an IP address or at an alias produces delivery that works with some senders and fails with others, which is considerably harder to diagnose than an outright failure.\"}\n        },\n        {\n          \"@type\": \"Question\",\n          \"name\": \"Why can't the root of my domain be a CNAME?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Because a CNAME cannot coexist with any other record on the same name, and the root of a domain must carry NS records, usually MX records, and often TXT records. Providers work around this with non-standard record types marketed as ALIAS, ANAME or CNAME flattening, which look like a CNAME in the control panel but answer queries with a resolved A record.\"}\n        },\n        {\n          \"@type\": \"Question\",\n          \"name\": \"Where are my DNS records actually hosted?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Wherever the domain's nameservers point, which is not necessarily the registrar and not necessarily the web host. Running dig NS example.com, or checking a public WHOIS record, gives the authoritative answer. Records edited anywhere other than the delegated nameservers are saved but never consulted, which is the single most common reason a correct-looking change has no effect.\"}\n        },\n        {\n          \"@type\": \"Question\",\n          \"name\": \"Do I need to manage DNS myself?\",\n          \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Not necessarily, and for a business where email and a website both matter, delegating it to a provider that reviews changes before they go live removes the largest category of self-inflicted outage. Managed DNS covers what that arrangement involves.\"}\n        }\n      ]\n    }\n  ]\n}\n<\/script><\/p>\n<section class=\"cta-band\">\n<div class=\"container cta-band__inner\">\n<div>\n<p class=\"eyebrow\">Editing DNS by hand?<\/p>\n<h2>Managed DNS, with someone checking the zone before it goes live.<\/h2>\n<\/div>\n<div style=\"flex-shrink:0;\"><a class=\"btn btn--accent\" style=\"white-space:nowrap;\" href=\"https:\/\/www.tkwebhosts.com\/managed-dns\">See managed DNS<\/a><\/div>\n<\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>What the Domain Name System does, what a DNS record is made of, and what A, CNAME, MX, TXT and NS records each control \u2014 including why changes take time to appear and which records govern email.<\/p>\n","protected":false},"author":1,"featured_media":58,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-59","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-domains"],"_links":{"self":[{"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/posts\/59","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/comments?post=59"}],"version-history":[{"count":1,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/posts\/59\/revisions"}],"predecessor-version":[{"id":62,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/posts\/59\/revisions\/62"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/media\/58"}],"wp:attachment":[{"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/media?parent=59"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/categories?post=59"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tkwebhosts.com\/blog\/wp-json\/wp\/v2\/tags?post=59"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}