{"id":180,"date":"2024-01-24T17:47:27","date_gmt":"2024-01-25T00:47:27","guid":{"rendered":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-connection-interruptions\/configuring-bind-as-a-caching-dns-server"},"modified":"2024-02-01T12:28:51","modified_gmt":"2024-02-01T19:28:51","slug":"configuring-bind-as-a-caching-dns-server","status":"publish","type":"docs","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-connection-interruptions\/configuring-bind-as-a-caching-dns-server","title":{"rendered":"The Basic Necessities"},"content":{"rendered":"\n<p>The bind DNS server is massive, so we&#8217;re only going to cover some basic necessities commonly found for it today.<br><br>As previously mentioned, the most common use for the bind DNS server is for forwarding and caching:<\/p>\n\n\n\n<p>Configuring BIND as a caching DNS server<br><a href=\"https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/9\/html\/managing_networking_infrastructure_services\/assembly_setting-up-and-configuring-a-bind-dns-server_networking-infrastructure-services#proc_configuring-bind-as-a-caching-dns-server_assembly_setting-up-and-configuring-a-bind-dns-server\">https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/9\/html\/managing_networking_infrastructure_services\/assembly_setting-up-and-configuring-a-bind-dns-server_networking-infrastructure-services#proc_configuring-bind-as-a-caching-dns-server_assembly_setting-up-and-configuring-a-bind-dns-server<\/a><\/p>\n\n\n\n<p><strong>However<\/strong>, in most situations there are 5 typical &#8220;Needs&#8221; for a DNS server to fulfill:<\/p>\n\n\n\n<p><strong>Need 1<\/strong>: client machines need to be able to resolve each other&#8217;s hostnames (<strong>resolve local network hostnames within the internal business domain both forward and reverse<\/strong>)<br><br><strong>Need 2<\/strong>:  client machines need to be able to resolve the internal webserver&#8217;s subdomain and\/or IP (<strong>resolve web application subdomain within the internal business domain both forward and reverse<\/strong>)<br><br><strong>Need 3<\/strong>:  client machines need to be able to resolve internet domains as well (<strong>resolve external internet domains<\/strong>)<br><br><strong>Need 4<\/strong>:  client machines need DNS caching (<strong>cache all DNS query results for faster DNS performance<\/strong>)<br><br><strong>Need 5<\/strong>: We&#8217;re paranoid, we want our DNS server to run in a chroot (<strong>run our DNS server in a chrooted environment<\/strong>)<\/p>\n\n\n\n<p>Let&#8217;s set up an example.<\/p>\n\n\n\n<ul>\n<li>We have 3 servers on our network, all under the internal domain fakedomain.dev<\/li>\n\n\n\n<li>One is our DNS server (rhel92)<\/li>\n\n\n\n<li>One is a webserver hosting a custom subdomain used for an internal web application (rhel89)<\/li>\n\n\n\n<li>One is just a desktop machine used by the office staff to perform work on the internal web application (rhel88)<\/li>\n<\/ul>\n\n\n\n<p>You&#8217;re going to want to do two things here.<\/p>\n\n\n\n<p>1. Setup caching + forwarding locally on the 2 servers that are -not- the DNS server with something lightweight like dnsmasq or unbound.<br><br>Set the forward nameserver to your BIND dns server. In our example our BIND server&#8217;s IP is 192.168.0.66<\/p>\n\n\n\n<p>rhel89, rhel88:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># dnf install dnsmasq\n# systemctl enable --now dnsmasq\n# echo 'nameserver 127.0.0.1' &gt; \/etc\/resolv.conf\n# echo 'options edns0' &gt;&gt; \/etc\/resolv.conf\n# echo 'resolv-file=\/etc\/resolv.dnsmasq' &gt;&gt; \/etc\/dnsmasq.conf\n# echo 'cache-size=1000' &gt;&gt; \/etc\/dnsmasq.conf\n# echo 'interface=lo' &gt;&gt; \/etc\/dnsmasq.conf\n# echo 'bind-interfaces' &gt;&gt; \/etc\/dnsmasq.conf\n# echo 'nameserver 192.168.0.66' &gt; \/etc\/resolv.dnsmasq\n# systemctl restart dnsmasq<\/code><\/pre>\n\n\n\n<p>We didn&#8217;t use all of the options required for dnsmasq in our example, just a few for basic functionality. It&#8217;s advised to follow along here for proper configuration:<\/p>\n\n\n\n<p>How to configure DNS caching server with dnsmasq in RHEL<br><a href=\"https:\/\/access.redhat.com\/solutions\/2189401\">https:\/\/access.redhat.com\/solutions\/2189401<\/a><\/p>\n\n\n\n<p>Alternatively you could just point all of the servers to the DNS server IP, but then you would be missing per-machine DNS caching. Having something like DNS or unbound running on each machine before it forwards to the DNS server allows each machine to have their own personal cache on the client side. The BIND DNS nameserver itself will also have caching itself for the server side. <\/p>\n\n\n\n<p><strong>\u2611<\/strong> This resolves &#8220;<strong>Need 4<\/strong>&#8221; in the list. (<strong>cache all DNS query results for faster DNS performance<\/strong>)<br><br>When each server queries for another server&#8217;s hostname, we also need to search under the domain &#8216;fakedomain.dev&#8217;<br>So we need to add these additional \/etc\/resolv.conf lines to all machines:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># echo 'search .fakedomain.dev' &gt;&gt; \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<p>All 3 machines should have an \/etc\/resolv.conf that looks like this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>nameserver 127.0.0.1\noptions edns0\nsearch fakedomain.dev<\/code><\/pre>\n\n\n\n<p>And on each server we need to make sure to set the fqdn:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># hostname rhel88.fakedomain.dev\n# hostname rhel89.fakedomain.dev\n# hostname rhel92.fakedomain.dev<\/code><\/pre>\n\n\n\n<p>These steps are <strong>part<\/strong> of the requirements for &#8220;<strong>Need 1<\/strong>&#8221; and &#8220;<strong>Need 2<\/strong>&#8220;.<\/p>\n\n\n\n<p>2. By default, the BIND DNS server has caching, we just need to configure two things:<\/p>\n\n\n\n<ul>\n<li>Configure forwarding external internet queries<\/li>\n\n\n\n<li>Configure our internal domain and hostnames (and webserver subdomain)<\/li>\n<\/ul>\n\n\n\n<p>This will allow our bind dns server to answer queries from the other four systems for both internal and external domains.<\/p>\n\n\n\n<p>On the bind dns server (rhel92):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># dnf install bind bind-chroot bind-utils\n# echo 'nameserver 127.0.0.1' &gt; \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<p>And enable dns access in our firewall:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># firewall-cmd --permanent --add-service=dns\n# firewall-cmd --reload<\/code><\/pre>\n\n\n\n<p>First, let&#8217;s edit our configuration file to allow caching and forwarding of external internet domain queries:<\/p>\n\n\n\n<p>Configuring BIND as a caching DNS server<br><a href=\"https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/9\/html\/managing_networking_infrastructure_services\/assembly_setting-up-and-configuring-a-bind-dns-server_networking-infrastructure-services#proc_configuring-bind-as-a-caching-dns-server_assembly_setting-up-and-configuring-a-bind-dns-server\">https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/9\/html\/managing_networking_infrastructure_services\/assembly_setting-up-and-configuring-a-bind-dns-server_networking-infrastructure-services#proc_configuring-bind-as-a-caching-dns-server_assembly_setting-up-and-configuring-a-bind-dns-server<\/a><\/p>\n\n\n\n<p>Note in the example below &#8216;\u2026.&#8217; is just to show skipping of unrelated configurations. They are not part of the configuration file.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># vim \/etc\/named.conf\n\noptions {\n....\n        listen-on port 53 { 127.0.0.1;192.168.0.66; };\n        allow-query { localhost; 192.168.0\/24; };\n        allow-recursion { localhost; 192.168.0\/24; };\n        forwarders { 8.8.8.8;8.8.4.4; }; # forward unknown domains to google dns servers\n....\n}<\/code><\/pre>\n\n\n\n<p>This tells our nameserver:<\/p>\n\n\n\n<ul>\n<li>Listen on localhost and on IP 192.168.0.66<\/li>\n\n\n\n<li>Allow queries and recursion only from localhost and any IP address in the 192.168.0.* range.<\/li>\n\n\n\n<li>Forward unknown queries to google<\/li>\n<\/ul>\n\n\n\n<p>So, with this we should be able to resolve something like www.redhat.com from all 3 machines:<\/p>\n\n\n\n<p>rhel88, rhel89 dnsmasq caching -&gt; bind dns server:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel88 ~]# nslookup redhat.com\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nNon-authoritative answer:\nName:   redhat.com\nAddress: 52.200.142.250\nName:   redhat.com\nAddress: 34.235.198.240\n\n&#91;root@rhel89 ~]# nslookup redhat.com\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nNon-authoritative answer:\nName:   redhat.com\nAddress: 52.200.142.250\nName:   redhat.com\nAddress: 34.235.198.240<\/code><\/pre>\n\n\n\n<p>and our bind server rhel92 directly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# nslookup redhat.com\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nNon-authoritative answer:\nName:   redhat.com\nAddress: 34.235.198.240\nName:   redhat.com\nAddress: 52.200.142.250<\/code><\/pre>\n\n\n\n<p><strong>\u2611<\/strong> Great! This resolves &#8220;<strong>Need 3<\/strong>&#8221; in the list. (<strong>resolve external internet domains<\/strong>)<\/p>\n\n\n\n<p>3. Now, we need them to be able to resolve eachother&#8217;s hostnames within fakedomain.dev<\/p>\n\n\n\n<p>The RHEL admin manual tells you how to create records for new zones:<\/p>\n\n\n\n<p>4.6.2. Setting up a forward zone on a BIND primary server<br><a href=\"https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/8\/html\/deploying_different_types_of_servers\/assembly_setting-up-and-configuring-a-bind-dns-server_deploying-different-types-of-servers#proc_setting-up-a-forward-zone-on-a-bind-primary-server_assembly_configuring-zones-on-a-bind-dns-server\">https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/8\/html\/deploying_different_types_of_servers\/assembly_setting-up-and-configuring-a-bind-dns-server_deploying-different-types-of-servers#proc_setting-up-a-forward-zone-on-a-bind-primary-server_assembly_configuring-zones-on-a-bind-dns-server<\/a><\/p>\n\n\n\n<p>Once again, let&#8217;s open up \/etc\/named.conf.<\/p>\n\n\n\n<p>This time we&#8217;re going to go to the bottom and add another zone:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># vim \/etc\/named.conf\nzone \"fakedomain.dev\" {\n    type master;\n    file \"fakedomain.dev.zone\";\n};<\/code><\/pre>\n\n\n\n<p>Save and close the file. Next we need to create &#8216;fakedomain.dev.zone&#8217; and fill it with records. Again &#8212; continue following the &#8216;4.6.2. Setting up a forward zone on a BIND primary server&#8217; directions, step 3:<\/p>\n\n\n\n<p>Create the \/var\/named\/fakedomain.dev.zone file, for example, with the following content:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$TTL 8h\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n                          2022070601 ; serial number\n                          1d         ; refresh period\n                          3h         ; retry period\n                          3d         ; expire time\n                          3h )       ; minimum TTL\n\n                  IN NS   ns1.fakedomain.dev.\n\nns1                  IN A    192.168.0.66\nrhel92               IN A    192.168.0.66<\/code><\/pre>\n\n\n\n<p>We have to add the ns1 entry for our nameserver because as noted in the admin manual to be functional, a zone requires at least one name server (NS) record.<br>We also add the A record so that our DNS server IP resolves to it&#8217;s hostname (rhel92.fakedomain.dev)<\/p>\n\n\n\n<p>After that, reload named:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># systemctl reload named<\/code><\/pre>\n\n\n\n<p>And NOW &#8212; verify our hostname lookup works locally on the bind server:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# nslookup rhel92\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel92.fakedomain.dev\nAddress: 192.168.0.66<\/code><\/pre>\n\n\n\n<p>Now we need to map the other two servers and the subdomain for our webapp to our records:<\/p>\n\n\n\n<p>Once again open the zone file, and add our entries:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># vim \/var\/named\/fakedomain.dev.zone\n.....\n$TTL 8h\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n                          2022070601 ; serial number\n                          1d         ; refresh period\n                          3h         ; retry period\n                          3d         ; expire time\n                          3h )       ; minimum TTL\n\n                  IN NS   ns1.fakedomain.dev.\n\nns1                  IN A    192.168.0.66\nrhel92               IN A    192.168.0.66\nrhel89               IN A    192.168.0.63\nwebapp               IN A    192.168.0.63\nrhel88               IN A    192.168.0.67\n.....<\/code><\/pre>\n\n\n\n<p>Remember, our rhel89 system is a webserver, which hosts a custom webapp within our organization&#8217;s subdomain, this is why both the &#8216;rhel89.fakedomain.dev&#8217; and &#8216;webapp.fakedomain.dev&#8217; both point to the same IP.<\/p>\n\n\n\n<p>Save and close the file, reload the service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># systemctl reload named<\/code><\/pre>\n\n\n\n<p>And now, magically all of our systems should be able to resolve any of those addresses:<\/p>\n\n\n\n<p>rhel92:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# nslookup rhel88\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel88.fakedomain.dev\nAddress: 192.168.0.67\n\n&#91;root@rhel92 ~]# nslookup rhel89\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel89.fakedomain.dev\nAddress: 192.168.0.63\n\n&#91;root@rhel92 ~]# nslookup webapp\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   webapp.fakedomain.dev\nAddress: 192.168.0.63<\/code><\/pre>\n\n\n\n<p>rhel89:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel89 ~]# nslookup rhel92\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel92.fakedomain.dev\nAddress: 192.168.0.66\n\n&#91;root@rhel89 ~]# nslookup rhel89\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel89.fakedomain.dev\nAddress: 192.168.0.63\n\n&#91;root@rhel89 ~]# nslookup webapp\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   webapp.fakedomain.dev\nAddress: 192.168.0.63<\/code><\/pre>\n\n\n\n<p>rhel88:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel88 ~]# nslookup rhel92\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel92.fakedomain.dev\nAddress: 192.168.0.66\n\n&#91;root@rhel88 ~]# nslookup rhel89\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   rhel89.fakedomain.dev\nAddress: 192.168.0.63\n\n&#91;root@rhel88 ~]# nslookup webapp\nServer:         127.0.0.1\nAddress:        127.0.0.1#53\n\nName:   webapp.fakedomain.dev\nAddress: 192.168.0.63<\/code><\/pre>\n\n\n\n<p>That handles forward lookups for &#8220;<strong>Need 1<\/strong>&#8221; and &#8220;<strong>Need 2<\/strong>&#8221; but we still need reverse lookups for looking up domains based on IP address.<\/p>\n\n\n\n<p>Again, RHEL admin manual has you covered:<\/p>\n\n\n\n<p>4.6.3. Setting up a reverse zone on a BIND primary server<br>https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/8\/html\/deploying_different_types_of_servers\/assembly_setting-up-and-configuring-a-bind-dns-server_deploying-different-types-of-servers#proc_setting-up-a-reverse-zone-on-a-bind-primary-server_assembly_configuring-zones-on-a-bind-dns-server<\/p>\n\n\n\n<p>Open \/etc\/named.conf again and:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># vim \/etc\/named.conf\n....\nzone \"0.168.192.in-addr.arpa\" {\n    type master;\n    file \"0.168.192.in-addr.arpa.zone\";\n};\n....<\/code><\/pre>\n\n\n\n<p>Save and close the file.<\/p>\n\n\n\n<p>This will add a reverse lookup entry for addresses starting with 192.168.0.*.<\/p>\n\n\n\n<p>Now just like our forward zone, we need to make a zone record file for our reverse lookups:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># vim \/var\/named\/0.168.192.in-addr.arpa.zone\n....\n$TTL 8h\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n                          2022070601 ; serial number\n                          1d         ; refresh period\n                          3h         ; retry period\n                          3d         ; expire time\n                          3h )       ; minimum TTL\n\n                  IN NS   ns1.fakedomain.dev.\n\n66                IN PTR  ns1.fakedomain.dev.\n66                IN PTR  rhel92.fakedomain.dev.\n63                IN PTR  rhel89.fakedomain.dev.\n63                IN PTR  webapp.fakedomain.dev.\n67                IN PTR  rhel88.fakedomain.dev.\n....<\/code><\/pre>\n\n\n\n<p>Again, save and reload named.service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># systemctl reload named.service<\/code><\/pre>\n\n\n\n<p>Voila, now any of our servers can do reverse lookups via IP:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# nslookup 192.168.0.63\n63.0.168.192.in-addr.arpa       name = webapp.fakedomain.dev.\n63.0.168.192.in-addr.arpa       name = rhel89.fakedomain.dev.\n\n&#91;root@rhel92 ~]# nslookup 192.168.0.67\n67.0.168.192.in-addr.arpa       name = rhel88.fakedomain.dev.\n\n&#91;root@rhel92 ~]# nslookup 192.168.0.66\n66.0.168.192.in-addr.arpa       name = ns1.fakedomain.dev.\n66.0.168.192.in-addr.arpa       name = rhel92.fakedomain.dev.<\/code><\/pre>\n\n\n\n<p>These are now covered:<br><strong>\u2611<\/strong> <strong>Need 1<\/strong>: (<strong>resolve local network hostnames within the internal business domain both forward and reverse<\/strong>)<br><strong>\u2611<\/strong> <strong>Need 2:<\/strong> (<strong>resolve web application subdomain within the internal business domain both forward and reverse<\/strong>)<br><br>4. Ok, we&#8217;ve walked through and completed Needs 1,2,3 and 4, now we&#8217;re on the final &#8220;<strong>Need 5<\/strong>&#8220;.  We need bind to run in a chroot environment. This is simple.<br><br>Shut down and disable named.service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# systemctl stop named\n&#91;root@rhel92 ~]# systemctl disable named<\/code><\/pre>\n\n\n\n<p>Start and enable named-chroot.service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;root@rhel92 ~]# systemctl enable --now named-chroot.service<\/code><\/pre>\n\n\n\n<p>Finally, our last requirement has now been fulfilled:<br><strong>\u2611<\/strong> <strong>Need 5:<\/strong> (<strong>run our DNS server in a chrooted environment<\/strong>)<br><br><strong>IMPORTANT THING TO REMEMBER<\/strong>:<\/p>\n\n\n\n<p><strong>With named-chroot.service a chroot is created at \/var\/named\/chroot\/<\/strong><\/p>\n\n\n\n<p><strong>Inside this chroot is the new &#8216;var\/named&#8217; directory. Our zone records from the standard named instance get copied here upon the first startup AND\/OR reload of the named-chroot service.<\/strong><\/p>\n\n\n\n<p><strong>Some customers will have different copies in \/var\/named\/ from \/var\/named\/chroot\/var\/named\/ so it&#8217;s important to determine if they are using named-chroot or not and get copies from BOTH directories.<\/strong><\/p>\n\n\n\n<p><br><\/p>\n","protected":false},"featured_media":0,"parent":101,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","doc_tag":[],"_links":{"self":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/180"}],"collection":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/types\/docs"}],"replies":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=180"}],"version-history":[{"count":4,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/180\/revisions"}],"predecessor-version":[{"id":195,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/180\/revisions\/195"}],"up":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/101"}],"next":[{"title":"Master\/Slave server configurations for redundancy","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-connection-interruptions\/master-slave-server-configurations-for-redundancy","href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/185"}],"wp:attachment":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=180"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fdoc_tag&post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}