{"id":5053,"date":"2026-08-29T19:33:52","date_gmt":"2026-08-29T16:33:52","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5053"},"modified":"2026-08-29T19:33:52","modified_gmt":"2026-08-29T16:33:52","slug":"what-is-dnssec-how-to-protect-your-domain","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/what-is-dnssec-how-to-protect-your-domain\/","title":{"rendered":"What Is DNSSEC? How to Protect Your Domain"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#A_green_DNSSEC_status_can_still_hide_a_broken_chain\"><span class=\"toc_number toc_depth_1\">1.<\/span> A green DNSSEC status can still hide a broken chain<\/a><\/li><li><a href=\"#Where_ordinary_DNS_leaves_room_for_attack\"><span class=\"toc_number toc_depth_1\">2.<\/span> Where ordinary DNS leaves room for attack<\/a><\/li><li><a href=\"#The_records_behind_the_trust_chain\"><span class=\"toc_number toc_depth_1\">3.<\/span> The records behind the trust chain<\/a><ul><li><a href=\"#KSK_and_ZSK_have_different_jobs\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> KSK and ZSK have different jobs<\/a><\/li><\/ul><\/li><li><a href=\"#DNSSEC_and_HTTPS_protect_different_layers\"><span class=\"toc_number toc_depth_1\">4.<\/span> DNSSEC and HTTPS protect different layers<\/a><\/li><li><a href=\"#Map_your_DNS_setup_before_enabling_DNSSEC\"><span class=\"toc_number toc_depth_1\">5.<\/span> Map your DNS setup before enabling DNSSEC<\/a><\/li><li><a href=\"#Enabling_DNSSEC_through_a_hosting_or_DNS_panel\"><span class=\"toc_number toc_depth_1\">6.<\/span> Enabling DNSSEC through a hosting or DNS panel<\/a><\/li><li><a href=\"#Validating_DNSSEC_from_Linux\"><span class=\"toc_number toc_depth_1\">7.<\/span> Validating DNSSEC from Linux<\/a><\/li><li><a href=\"#Tests_I_run_after_enabling_DNSSEC\"><span class=\"toc_number toc_depth_1\">8.<\/span> Tests I run after enabling DNSSEC<\/a><\/li><li><a href=\"#Where_I_look_first_when_I_see_SERVFAIL\"><span class=\"toc_number toc_depth_1\">9.<\/span> Where I look first when I see SERVFAIL<\/a><\/li><li><a href=\"#DNSSEC_has_limits_and_needs_maintenance\"><span class=\"toc_number toc_depth_1\">10.<\/span> DNSSEC has limits and needs maintenance<\/a><\/li><li><a href=\"#A_practical_DNSSEC_plan_for_your_domain\"><span class=\"toc_number toc_depth_1\">11.<\/span> A practical DNSSEC plan for your domain<\/a><\/li><li><a href=\"#Frequently_asked_questions\"><span class=\"toc_number toc_depth_1\">12.<\/span> Frequently asked questions<\/a><ul><li><a href=\"#What_is_DNSSEC_and_does_every_domain_need_it\"><span class=\"toc_number toc_depth_2\">12.1.<\/span> What is DNSSEC, and does every domain need it?<\/a><\/li><li><a href=\"#Does_DNSSEC_slow_down_a_website\"><span class=\"toc_number toc_depth_2\">12.2.<\/span> Does DNSSEC slow down a website?<\/a><\/li><li><a href=\"#Do_I_still_need_an_SSL_certificate_after_enabling_DNSSEC\"><span class=\"toc_number toc_depth_2\">12.3.<\/span> Do I still need an SSL certificate after enabling DNSSEC?<\/a><\/li><li><a href=\"#My_domain_returns_SERVFAIL_after_DNSSEC_was_enabled_What_should_I_do\"><span class=\"toc_number toc_depth_2\">12.4.<\/span> My domain returns SERVFAIL after DNSSEC was enabled. What should I do?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"A_green_DNSSEC_status_can_still_hide_a_broken_chain\">A green DNSSEC status can still hide a broken chain<\/span><\/h2>\n<p>I have learned not to trust a DNS panel&#8217;s green badge until I have checked the answer from outside that panel. During a late-night test in my Proxmox lab, I found that the authoritative servers were not serving the same DNSKEY data. The domain looked healthy in the provider interface, but a validating resolver had already started returning <code>SERVFAIL<\/code>.<\/p>\n<p>There were no customers involved, just a broken test zone and a cup of tea. Still, it reinforced a rule I use in production: DNSSEC is a chain, and every link needs to be checked.<\/p>\n<p>DNSSEC verifies that a DNS response came from the authoritative source and was not changed in transit. It does not encrypt DNS traffic, hide your passwords, or protect your website application. It adds digital signatures to DNS records so a validating resolver can decide whether the response is trustworthy.<\/p>\n<p>The short answer to &#8220;what is DNSSEC?&#8221; is this: DNSSEC helps prevent a resolver from accepting forged DNS data for your domain. When a validating resolver requests an A, AAAA, MX, or TXT record, it checks the signature and the chain of trust behind the answer.<\/p>\n<h2><span id=\"Where_ordinary_DNS_leaves_room_for_attack\">Where ordinary DNS leaves room for attack<\/span><\/h2>\n<p>DNS translates a domain name into an IP address. When your browser asks for the A or AAAA record for <code>example.com<\/code>, a recursive resolver usually contacts the domain&#8217;s authoritative nameservers and caches the response. With ordinary DNS, the resolver has no cryptographic proof that the answer really came from the domain owner.<\/p>\n<p>That gap can be abused through cache poisoning or forged responses sent between the client and resolver. An attacker may try to send visitors to a server they control even though those visitors typed the correct domain name. HTTPS certificate warnings expose some attacks, but users can ignore warnings, and not every service uses a browser certificate.<\/p>\n<p>DNSSEC adds a signature chain to the lookup. The resolver can ask, &#8220;Did this address really come from the authoritative records for this domain?&#8221; and verify the answer using cryptographic data instead of trusting the server&#8217;s claim. If validation fails, a validating resolver rejects the response and usually returns <code>SERVFAIL<\/code>.<\/p>\n<h2><span id=\"The_records_behind_the_trust_chain\">The records behind the trust chain<\/span><\/h2>\n<p>DNSSEC terminology looks crowded at first. In support tickets, I separate the main record types like this:<\/p>\n<ul>\n<li><strong>DNSKEY:<\/strong> Contains the domain&#8217;s DNSSEC public keys. With managed services, the details may be hidden; on a BIND installation, you will commonly encounter KSK and ZSK roles.<\/li>\n<li><strong>RRSIG:<\/strong> A digital signature for a DNS record set such as A, MX, or TXT. The resolver verifies it using the appropriate DNSKEY.<\/li>\n<li><strong>DS:<\/strong> A Delegation Signer record. It carries a digest of a DNSKEY into the parent zone and connects your domain to the trust chain above it.<\/li>\n<li><strong>NSEC or NSEC3:<\/strong> Used to prove that a record does not exist. DNSSEC validates both &#8220;this record exists&#8221; and &#8220;there is no record at this name.&#8221;<\/li>\n<\/ul>\n<p>The flow is easier to follow than the names suggest: the root zone provides the trust anchor for the TLD, the TLD publishes the DS record for your domain, the DS helps validate the domain&#8217;s DNSKEY, and the DNSKEY validates the RRSIG signatures for A, MX, TXT, and other records.<\/p>\n<p>One mismatched link is enough to break validation. DNSSEC may appear enabled in your DNS provider&#8217;s panel while the registrar still publishes a DS record for an old key. A green status indicator is not proof by itself. Test from outside the panel.<\/p>\n<h3><span id=\"KSK_and_ZSK_have_different_jobs\">KSK and ZSK have different jobs<\/span><\/h3>\n<p>DNSSEC deployments commonly use two key roles. The Zone Signing Key, or ZSK, signs the ordinary records in the zone. The Key Signing Key, or KSK, signs the DNSKEY record set, and a digest of that key is published in the parent zone as the DS record.<\/p>\n<p>This separation makes key rotation easier to manage. A ZSK can be changed without changing the DS record; changing the KSK also requires a coordinated DS update. Managed DNS providers often automate the process. If you run your own BIND servers, monitor that automation instead of assuming a scheduled job is alive.<\/p>\n<p>I learned that distinction the hard way with a certificate-renewal cron job that stopped running silently. Scheduled does not mean monitored.<\/p>\n<h2><span id=\"DNSSEC_and_HTTPS_protect_different_layers\">DNSSEC and HTTPS protect different layers<\/span><\/h2>\n<p>These technologies are sometimes treated as alternatives, but they solve different problems. HTTPS protects the connection between the browser and web server with TLS. DNSSEC validates the DNS response. An SSL\/TLS certificate does not, by itself, prevent a forged DNS answer from pointing a domain at the wrong address.<\/p>\n<table>\n<thead>\n<tr>\n<th>Technology<\/th>\n<th>What it protects<\/th>\n<th>Primary purpose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DNSSEC<\/td>\n<td>The authenticity of DNS responses<\/td>\n<td>Validate that domain records are genuine and unchanged<\/td>\n<\/tr>\n<tr>\n<td>HTTPS \/ TLS<\/td>\n<td>The connection between browser and server<\/td>\n<td>Encrypt data and authenticate the server with a certificate<\/td>\n<\/tr>\n<tr>\n<td>SPF, DKIM, DMARC<\/td>\n<td>Email sending and authentication<\/td>\n<td>Reduce forged email sent on behalf of your domain<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>You still need an HTTPS certificate on a domain protected by DNSSEC. Email also needs separate SPF, DKIM, and DMARC records. One layer does not configure the others.<\/p>\n<h2><span id=\"Map_your_DNS_setup_before_enabling_DNSSEC\">Map your DNS setup before enabling DNSSEC<\/span><\/h2>\n<p>You may be able to enable DNSSEC with one button. I still write down where DNS is actually managed first. The registrar, authoritative DNS provider, and hosting company do not have to be the same business.<\/p>\n<ol>\n<li><strong>Identify the authoritative nameservers.<\/strong> Check the nameserver values at the registrar and establish which service is really publishing the zone.<\/li>\n<li><strong>Understand the provider&#8217;s DNSSEC workflow.<\/strong> Some panels generate and publish signatures automatically; others give you DS values to enter at the registrar. Do not apply both workflows at random.<\/li>\n<li><strong>Export the current records.<\/strong> Save A, AAAA, MX, TXT, CNAME, CAA, and any custom SRV records. If these record types are unfamiliar, <a href=\"https:\/\/www.dchost.com\/blog\/dns-kayit-turleri-nedir-a-aaaa-mx-cname-txt-srv-ve-caa-icin-uygulamali-rehber\/\">DNS Record Types Explained: Practical Guide to A, AAAA, MX, CNAME, TXT, SRV and CAA<\/a> covers the common examples.<\/li>\n<li><strong>Check for secondary DNS or a DNS proxy.<\/strong> If a CDN, WAF, and registrar DNS service are all involved, be certain which system creates and serves the signatures.<\/li>\n<li><strong>Prepare another way to contact you.<\/strong> A DNSSEC mistake can also break email addresses tied to the domain. Check the phone number and alternate email address on the registrar account.<\/li>\n<\/ol>\n<p>If you are changing nameservers, include DNSSEC in the change plan. For a domain transfer, confirm where DNS is hosted and how the DS record will be handled. The checklist in <a href=\"https:\/\/www.dchost.com\/blog\/alan-adi-transferi-nasil-yapilir\/\">How to Transfer a Domain Name Without Downtime<\/a> should include this DNSSEC check. Debugging <code>SERVFAIL<\/code> after the transfer is a poor time to discover that nobody owns the DS change.<\/p>\n<h2><span id=\"Enabling_DNSSEC_through_a_hosting_or_DNS_panel\">Enabling DNSSEC through a hosting or DNS panel<\/span><\/h2>\n<p>With a managed DNS service, the process usually has three parts: enable DNSSEC at the authoritative provider, enter the resulting DS information at the registrar, and validate the result from outside. Some registrars add the DS record automatically through an API integration.<\/p>\n<p>When a panel asks you to enter DS information, it will generally show:<\/p>\n<ul>\n<li>Key tag<\/li>\n<li>Algorithm<\/li>\n<li>Digest type<\/li>\n<li>Digest<\/li>\n<\/ul>\n<p>A single mistyped character can break the chain. Check for spaces at the beginning or end when copying values. Compare the DS data with the value generated by the DNS provider, and make sure you are not using information from an old key.<\/p>\n<p>If several DS records are present, do not delete them all without checking. During a controlled key transition, old and new keys may both be valid for a period of time. Follow the provider&#8217;s rotation procedure. If you do not manage the keys yourself, an automated DNSSEC workflow usually means less manual work and fewer opportunities for this particular mistake.<\/p>\n<h2><span id=\"Validating_DNSSEC_from_Linux\">Validating DNSSEC from Linux<\/span><\/h2>\n<p>When a DNS ticket arrives, I inspect the chain with <code>dig<\/code> before trusting what a panel says. A basic query is:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig example.com A +dnssec<\/code><\/pre>\n<p>An <code>RRSIG<\/code> in the response means the server returned signature data. The <code>ad<\/code> flag indicates that the resolver considers the answer authenticated. The <code>+dnssec<\/code> option requests DNSSEC records; it does not perform validation by itself.<\/p>\n<p>That last detail catches people out.<\/p>\n<p>To inspect the DS record published by the parent zone:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig example.com DS +short<\/code><\/pre>\n<p>You can compare the digest with the DNSKEY data published by your DNS provider. To query an authoritative server directly, first list the nameservers:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig example.com NS +short\ndig @ns1.example-dns.net example.com DNSKEY +dnssec<\/code><\/pre>\n<p>The first command lists the authoritative nameservers. The second asks one of them for its DNSKEY and signature data. Replace the example domain and nameserver with your actual values.<\/p>\n<p>For a clearer view of local DNSSEC validation, use <code>delv<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">delv example.com A<\/code><\/pre>\n<p>When validation succeeds, the output includes information about the trust chain. Errors such as <code>broken trust chain<\/code> or <code>no valid signature<\/code> mean you should inspect DS, DNSKEY, and RRSIG together. Looking only at the A record can hide the real fault.<\/p>\n<h2><span id=\"Tests_I_run_after_enabling_DNSSEC\">Tests I run after enabling DNSSEC<\/span><\/h2>\n<p>I do not test only from my own laptop. I query through different recursive resolvers, a mobile connection, and a separate network. Caches expire at different times, so answers will not necessarily change everywhere at once.<\/p>\n<p>My practical test order is:<\/p>\n<ol>\n<li>Query the domain&#8217;s A and AAAA records.<\/li>\n<li>Check that MX records validate and confirm that email still flows.<\/li>\n<li>Query TXT records and verify that SPF, DKIM, and domain-verification records are returned.<\/li>\n<li>Check the DS record at the TLD level.<\/li>\n<li>Run <code>dig<\/code> or <code>delv<\/code> through a resolver that performs DNSSEC validation.<\/li>\n<li>Confirm that at least two authoritative nameservers return the same DNSKEY and signature state.<\/li>\n<\/ol>\n<p>Do not stop because the website opens in a browser. Many teams check the A record and forget MX and TXT. Email delivery and third-party verification services may expose a broken chain before the website does.<\/p>\n<p>Check the quiet records too.<\/p>\n<h2><span id=\"Where_I_look_first_when_I_see_SERVFAIL\">Where I look first when I see SERVFAIL<\/span><\/h2>\n<p>A DNSSEC failure often looks like the entire website is down. First separate a problem affecting every client from one affecting only particular resolvers. To compare two public validating resolvers:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig @1.1.1.1 example.com A\ndig @8.8.8.8 example.com A<\/code><\/pre>\n<p>Then check these possibilities:<\/p>\n<ul>\n<li>The registrar may still have a DS record belonging to the previous DNS provider.<\/li>\n<li>The new DNS provider may be serving a DNSKEY set that does not match the DS at the parent.<\/li>\n<li>An authoritative server may be serving an old zone file or stale DNSSEC data.<\/li>\n<li>The DNS server&#8217;s clock may be wrong. RRSIG records have validity periods, and a serious clock error can make an otherwise correct signature fail.<\/li>\n<li>A DNSSEC key rotation may have stopped halfway through.<\/li>\n<li>A record set may have changed without a valid replacement RRSIG being published.<\/li>\n<\/ul>\n<p>These queries show whether two independent validating resolvers are seeing the same answer. They do not, by themselves, identify every broken link.<\/p>\n<p>People sometimes suggest deleting the DS record as a quick fix. That disables validation and may restore resolution, but it also removes DNSSEC protection. Find the cause first. If operational pressure forces you to remove the DS record, document the decision and restore DNSSEC after correcting the underlying problem.<\/p>\n<p>Do not turn an outage into a permanent downgrade.<\/p>\n<h2><span id=\"DNSSEC_has_limits_and_needs_maintenance\">DNSSEC has limits and needs maintenance<\/span><\/h2>\n<p>DNSSEC does not protect your registrar account. If that account is compromised, an attacker may change the nameservers or manage the DS record. Use multi-factor authentication, protect the recovery email address, and limit administrative access.<\/p>\n<p>DNSSEC also does not patch vulnerabilities in your web server. An outdated WordPress plugin, an administrator password such as <code>123456<\/code>, or incorrect filesystem permissions remain problems. DNSSEC helps validate that the DNS record points to the expected IP address; it does not prove that the application running there is secure.<\/p>\n<p>A wrongly signed record can have a harsher effect than an unsigned record because a validating resolver rejects it. Monitor DNSSEC keys, signature validity periods, and DS changes. If you operate your own DNS infrastructure, log changes, create alerts, and write the rollback step before making the change.<\/p>\n<p>Nameserver performance, TTL values, and resolver behavior still matter. <a href=\"https:\/\/www.dchost.com\/blog\/dns-performansini-olcmek-ve-iyilestirmek-anycast-coklu-dns-saglayici-ve-health-check-mimarisi\/\">Measuring and Improving DNS Performance with Anycast, Multi-DNS and Health Checks<\/a> looks at those subjects from an operational angle. DNSSEC adds signatures; it does not make a poorly designed DNS architecture fast or resilient by itself.<\/p>\n<h2><span id=\"A_practical_DNSSEC_plan_for_your_domain\">A practical DNSSEC plan for your domain<\/span><\/h2>\n<p>For a small WordPress site, I prefer a DNS provider that supports DNSSEC and automates key rotation. I export the current zone, enable DNSSEC at the provider, enter the generated DS information at the registrar, and validate the result through different resolvers. I also record the date, DS digest, and provider used.<\/p>\n<p>If you manage multiple sites or an ecommerce platform, make the process stricter. Follow DNS provider maintenance notices, do not leave registrar access in one person&#8217;s account, and require a second check for DS changes. One incorrect DNS record can affect a customer&#8217;s website, email, and third-party API integrations at the same time.<\/p>\n<p>Add these items to the migration plan:<\/p>\n<ul>\n<li>Record the current DS and DNSKEY values.<\/li>\n<li>Validate DNSSEC on the new authoritative nameservers.<\/li>\n<li>Change the DS record only after the new key is ready and being served consistently.<\/li>\n<li>Do not shut down the old DNS provider immediately.<\/li>\n<li>Query A, AAAA, MX, and TXT records through different resolvers.<\/li>\n<li>Monitor signature validity and nameserver consistency.<\/li>\n<\/ul>\n<p>I keep this checklist beside the change window now. The extra five minutes are cheaper than explaining to a customer why a resolver somewhere on the internet refuses to believe their domain exists.<\/p>\n<h2><span id=\"Frequently_asked_questions\">Frequently asked questions<\/span><\/h2>\n<h3><span id=\"What_is_DNSSEC_and_does_every_domain_need_it\">What is DNSSEC, and does every domain need it?<\/span><\/h3>\n<p>DNSSEC is a security layer that validates whether DNS responses came from the authoritative source and were not modified. It is not mandatory for every domain, but it is useful when you want to reduce the risk of forged DNS responses or altered DNS records.<\/p>\n<h3><span id=\"Does_DNSSEC_slow_down_a_website\">Does DNSSEC slow down a website?<\/span><\/h3>\n<p>DNS responses become larger because signature and validation data are added. With a correctly configured DNS service, this normally does not create website slowness that users notice. Nameserver performance, TTL values, and resolver behavior should still be evaluated separately.<\/p>\n<h3><span id=\"Do_I_still_need_an_SSL_certificate_after_enabling_DNSSEC\">Do I still need an SSL certificate after enabling DNSSEC?<\/span><\/h3>\n<p>Yes. DNSSEC validates DNS records, while SSL\/TLS encrypts the connection between the browser and server and authenticates the server. They protect different layers and are not substitutes for each other.<\/p>\n<h3><span id=\"My_domain_returns_SERVFAIL_after_DNSSEC_was_enabled_What_should_I_do\">My domain returns SERVFAIL after DNSSEC was enabled. What should I do?<\/span><\/h3>\n<p>Compare the DS record at the registrar with the DNSKEY and relevant RRSIG records on every authoritative server. <code>dig +trace<\/code>, <code>dig +dnssec<\/code>, and queries through different resolvers can show where the chain breaks. Removing the DS record should be treated as a controlled emergency measure, not the first diagnostic step.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>DNSSEC validates DNS responses through a chain of cryptographic signatures. Learn how it works, how to enable it, and how to troubleshoot SERVFAIL safely.<\/p>\n","protected":false},"author":4,"featured_media":5050,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[175],"tags":[395,250,397,231,396,60],"class_list":["post-5053","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-domain","tag-dns-records","tag-dns-security","tag-dns-troubleshooting","tag-dnssec","tag-domain-security","tag-linux"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5053","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5053"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5053\/revisions"}],"predecessor-version":[{"id":5054,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5053\/revisions\/5054"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5050"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5053"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5053"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5053"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}