{"id":4562,"date":"2018-09-27T23:47:58","date_gmt":"2018-09-28T02:47:58","guid":{"rendered":"https:\/\/blog.clusterweb.com.br\/?p=4562"},"modified":"2018-09-27T23:47:58","modified_gmt":"2018-09-28T02:47:58","slug":"how-to-configure-bind-as-a-caching-or-forwarding-dns-server","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=4562","title":{"rendered":"How To Configure Bind as a Caching or Forwarding DNS Server"},"content":{"rendered":"

Introduction<\/h3>\n

DNS, or the Domain Name System, is often a difficult component to get right when learning how to configure websites and servers. While most people will probably choose to use the DNS servers provided by their hosting company or their domain registrar, there are some advantages to creating your own DNS servers.<\/p>\n

In this guide, we will discuss how to install and configure the Bind9 DNS server as a caching or forwarding DNS server on Ubuntu 14.04 machines. These two configurations both have advantages when serving networks of machines.<\/p>\n

<\/div>\n

<\/p>\n

Prerequisites and Goals<\/h2>\n

To complete this guide, you will first need to be familiar with some common DNS terminology. Check out\u00a0this guide\u00a0to learn about some of the concepts we will be implementing in this guide.<\/p>\n

We will be demonstrating two separate configurations that accomplish similar goals: a caching and a forwarding DNS server.<\/p>\n

To follow along, you will need to have access to two computers (at least one of which should be an Ubuntu 14.04 server). One will function as the client and the other will be configured as the DNS server. The details of our example configuration are:<\/p>\n\n\n\n\n\n\n
Role<\/th>\nIP Address<\/th>\n<\/tr>\n<\/thead>\n
DNS Server<\/td>\n192.0.2.1<\/td>\n<\/tr>\n
Client<\/td>\n192.0.2.100<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

We will show you how to configure the client machine to use the DNS server for queries. We will show you how to configure the DNS server in two different configurations, depending on your needs.<\/p>\n

Caching DNS Server<\/h3>\n

The first configuration will be for a\u00a0caching<\/strong>\u00a0DNS server. This type of server is also known as a resolver because it handles recursive queries and generally can handle the grunt work of tracking down DNS data from other servers.<\/p>\n

When a caching DNS server tracks down the answer to a client’s query, it returns the answer to the client. But it also stores the answer in its cache for the period of time allowed by the records’ TTL value. The cache can then be used as a source for subsequent requests in order to speed up the total round-trip time.<\/p>\n

Almost all DNS servers that you might have in your network configuration will be caching DNS servers. These make up for the lack of adequate DNS resolver libraries implemented on most client machines. A caching DNS server is a good choice for many situations. If you do not wish to rely on your ISPs DNS or other publicly available DNS servers, making your own caching server is a good choice. If it is in close physical proximity to the client machines, it is also very likely to improve the DNS query times.<\/p>\n

Forwarding DNS Server<\/h3>\n

The second configuration that we will be demonstrating is a\u00a0forwarding<\/strong>\u00a0DNS server. A forwarding DNS server will look almost identical to a caching server from a client’s perspective, but the mechanisms and work load are quite different.<\/p>\n

A forwarding DNS server offers the same advantage of maintaining a cache to improve DNS resolution times for clients. However, it actually does none of the recursive querying itself. Instead, it forwards all requests to an outside resolving server and then caches the results to use for later queries.<\/p>\n

This lets the forwarding server respond from its cache, while not requiring it to do all of the work of recursive queries. This allows the server to only make single requests (the forwarded client request) instead of having to go through the entire recursion routine. This may be an advantage in environments where external bandwidth transfer is costly, where your caching servers might need to be changed often, or when you wish to forward local queries to one server and external queries to another server.<\/p>\n

<\/div>\n

Install Bind on the DNS Server<\/h2>\n

Regardless of which configuration choice you wish to use, the first step in implementing a Bind DNS server is to install the actual software.<\/p>\n

The Bind software is available within Ubuntu’s default repositories, so we just need to update our local package index and install the software using\u00a0apt<\/code>. We will also include the documentation and some common utilities:<\/p>\n

sudo apt-get update\r\nsudo apt-get install bind9 bind9utils bind9-doc\r\n<\/code><\/pre>\n
Now that the Bind components are installed, we can begin to configure the server. The forwarding server will use the caching server configuration as a jumping off point, so regardless of your end goal, configure the server as a Caching server first.<\/p>\n
<\/div>\n
Configure as a Caching DNS Server<\/h2>\n
First, we will cover how to configure Bind to act as a caching DNS server. This configuration will force the server to recursively seek answers from other DNS servers when a client issues a query. This means that it is doing the work of querying each related DNS server in turn until it finds the entire response.<\/p>\n
The Bind configuration files are kept by default in a directory at\u00a0\/etc\/bind<\/code>. Move into that directory now:<\/p>\n
cd \/etc\/bind\r\n<\/code><\/pre>\n
We are not going to be concerned with the majority of the files in this directory. The main configuration file is called\u00a0named.conf<\/code>\u00a0(named<\/code>\u00a0and\u00a0bind<\/code>\u00a0are two names for the same application). This file simply sources the\u00a0named.conf.options<\/code>\u00a0file, the\u00a0named.conf.local<\/code>\u00a0file, and the\u00a0named.conf.default-zones<\/code>\u00a0file.<\/p>\n
For a caching DNS server, we will only be modifying the\u00a0named.conf.options<\/code>\u00a0file. Open this in your text editor with sudo privileges:<\/p>\n
sudo nano named.conf.options\r\n<\/code><\/pre>\n
With the comments stripped out for readability, the file looks like this:<\/p>\n
options {\r\n        directory \"\/var\/cache\/bind\";\r\n\r\n        dnssec-validation auto;\r\n\r\n        auth-nxdomain no;    # conform to RFC1035\r\n        listen-on-v6 { any; };\r\n};\r\n<\/code><\/pre>\n
To configure caching, the first step is to set up an access control list, or ACL.<\/p>\n
As a DNS server that will be used to resolve recursive queries, we do not want the DNS server to be abused by malicious users. An attack called a\u00a0DNS amplification attack<\/strong>\u00a0is especially troublesome because it can cause your server to participate in distributed denial of service attacks.<\/p>\n
A DNS amplification attack is one way that malicious users try to take down servers or sites on the internet. To do so, they try to find public DNS servers that will resolve recursive queries. They spoof the victim’s IP address and send a query that will return a large response to the DNS server. In doing so, the DNS server responds to a small request with a large payload directed at the victims server, effectively amplifying the available bandwidth of the attacker.<\/p>\n
Hosting a public, recursive DNS server requires a great deal of special configuration and administration. To avoid the possibility of your server being used for malicious purposes, we will configure a list of IP addresses or network ranges that we trust.<\/p>\n
Above the\u00a0options<\/code>\u00a0block, we will create a new block called\u00a0acl<\/code>. Create a label for the ACL group that you are configuring. In this guide, we will call the group\u00a0goodclients<\/code>.<\/p>\n
acl goodclients {\r\n};\r\n\r\noptions {\r\n    . . .\r\n<\/code><\/pre>\n
Within this block, list the IP addresses or networks that should be allowed to use this DNS server. Since both our server and client are operating within the same \/24 subnet, we will restrict the example to this network. We will also add\u00a0localhost<\/code>\u00a0and\u00a0localnets<\/code>\u00a0which will attempt to do this automatically:<\/p>\n
acl goodclients {\r\n    192.0.2.0\/24;\r\n    localhost;\r\n    localnets;\r\n};\r\n\r\noptions {\r\n    . . .\r\n<\/code><\/pre>\n
Now that we have an ACL of clients that we want to resolve request for, we can configure those capabilities in the\u00a0options<\/code>\u00a0block. Within this block, add the following lines:<\/p>\n
options {\r\n    directory \"\/var\/cache\/bind\";\r\n\r\n    recursion yes;<\/span>\r\n    allow-query { goodclients; };<\/span>\r\n    . . .\r\n<\/code><\/pre>\n
We explicitly turned recursion on, and then configured the\u00a0allow-query<\/code>\u00a0parameter to use our ACL specification. We could have used a different parameter, like\u00a0allow-recursion<\/code>\u00a0to reference our ACL group. If present and recursion is on,\u00a0allow-recursion<\/code>\u00a0will dictate the list of clients that can use recursive services.<\/p>\n
However, if\u00a0allow-recursion<\/code>\u00a0is not set, then Bind falls back on the\u00a0allow-query-cache<\/code>\u00a0list, then the\u00a0allow-query<\/code>\u00a0list, and finally a default of\u00a0localnets<\/code>\u00a0and\u00a0localhost<\/code>\u00a0only. Since we are configuring a caching only server (it has no authoritative zones of its own and doesn’t forward requests), the\u00a0allow-query<\/code>\u00a0list will always apply only to recursion. We are using it because it is the most general way of specifying the ACL.<\/p>\n
When you are finished making these changes, save and close the file.<\/p>\n
This is actually all that is required for a caching DNS server. If you decided that this is the server type you wish to use, feel free to skip ahead to learn how to check your configuration files, restart the service, and implement client configurations.<\/p>\n
Otherwise, continue reading to learn how to set up a forwarding DNS server instead.<\/p>\n
<\/div>\n
Configure as a Forwarding DNS Server<\/h2>\n
If a forwarding DNS server is a better fit for your infrastructure, we can easily set that up instead.<\/p>\n
We will start with the configuration that we left off in the caching server configuration. The\u00a0named.conf.options<\/code>\u00a0file should look like this:<\/p>\n
acl goodclients {\r\n        192.0.2.0\/24;\r\n        localhost;\r\n        localnets;\r\n};\r\n\r\noptions {\r\n        directory \"\/var\/cache\/bind\";\r\n\r\n        recursion yes;\r\n        allow-query { goodclients; };\r\n\r\n        dnssec-validation auto;\r\n\r\n        auth-nxdomain no;    # conform to RFC1035\r\n        listen-on-v6 { any; };\r\n};\r\n<\/code><\/pre>\n
We will be using the same ACL list to restrict our DNS server to a specific list of clients. However, we need to change the configuration so that the server no longer attempts to perform recursive queries itself.<\/p>\n
To do this, we do\u00a0not<\/em>\u00a0change\u00a0recursion<\/code>\u00a0to no. The forwarding server is still providing recursive services by answering queries for zones it is not authoritative for. Instead, we need to set up a list of caching servers to forward our requests to.<\/p>\n
This will be done within the\u00a0options {}<\/code>\u00a0block. First, we create a block inside called\u00a0forwarders<\/code>\u00a0that contains the IP addresses of the recursive name servers that we want to forward requests to. In our guide, we will use Google’s public DNS servers (8.8.8.8<\/code>\u00a0and\u00a08.8.4.4<\/code>):<\/p>\n
. . .\r\noptions {\r\n        directory \"\/var\/cache\/bind\";\r\n\r\n        recursion yes;\r\n        allow-query { goodclients; };\r\n\r\n        forwarders {<\/span>\r\n                8.8.8.8;<\/span>\r\n                8.8.4.4;<\/span>\r\n        };<\/span>\r\n        . . .\r\n<\/code><\/pre>\n
Afterward, we should set the\u00a0forward<\/code>\u00a0directive to “only” since this server will forward all requests and should not attempt to resolve requests on its own.<\/p>\n
The configuration file will look like this when you are finished:<\/p>\n
acl goodclients {\r\n        192.0.2.0\/24;\r\n        localhost;\r\n        localnets;\r\n};\r\n\r\noptions {\r\n        directory \"\/var\/cache\/bind\";\r\n\r\n        recursion yes;\r\n        allow-query { goodclients; };\r\n\r\n        forwarders {\r\n                8.8.8.8;\r\n                8.8.4.4;\r\n        };\r\n        forward only;<\/span>\r\n\r\n        dnssec-validation auto;\r\n\r\n        auth-nxdomain no;    # conform to RFC1035\r\n        listen-on-v6 { any; };\r\n};\r\n<\/code><\/pre>\n
One final change we should make is to the\u00a0dnssec<\/code>\u00a0parameters. With the current configuration, depending on the configuration of forwarded DNS servers, you may see some errors that look like this in the logs:<\/p>\n
Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa\/DS\/IN': 8.8.8.8#53\r\nJun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa\/PTR\/IN': 8.8.4.4#53\r\n<\/code><\/pre>\n
To avoid this, change the\u00a0dnssec-validation<\/code>\u00a0setting to “yes” and explicitly enable dnssec:<\/p>\n
. . .\r\nforward only;\r\n\r\ndnssec-enable yes;<\/span>\r\ndnssec-validation yes<\/span>;\r\n\r\nauth-nxdomain no;    # conform to RFC1035\r\n. . .\r\n<\/code><\/pre>\n
Save and close the file when you are finished. You should now have a forwarding DNS server in place. Continue to the next section to validate your configuration files and restart the daemon.<\/p>\n
<\/div>\n
Test your Configuration and Restart Bind<\/h2>\n
Now that you have your Bind server configured as either a caching DNS server or a forwarding DNS server, we are ready to implement our changes.<\/p>\n
Before we take the plunge and restart the Bind server on our system, we should use Bind’s included tools to check the syntax of our configuration files.<\/p>\n
We can do this easily by typing:<\/p>\n
sudo named-checkconf\r\n<\/code><\/pre>\n
If there are no syntax errors in your configuration, the shell prompt will return immediately without displaying any output.<\/p>\n
If you have syntax errors in your configuration files, you will be alerted to the error and line number where it occurs. If this happens, go back and check your files for errors.<\/p>\n
When you have verified that your configuration files do not have any syntax errors, restart the Bind daemon to implement your changes:<\/p>\n
sudo service bind9 restart\r\n<\/code><\/pre>\n
Afterwards, keep an eye on the server logs while you set up your client machine to make sure that everything goes smoothly. Leave this running on the server:<\/p>\n
sudo tail -f \/var\/log\/syslog\r\n<\/code><\/pre>\n
Now, open a new terminal window to configure your client machines.<\/p>\n
<\/div>\n
Configure the Client Machine<\/h2>\n
Now that you have your server up and running, you can configure your client machine to use this DNS server for queries.<\/p>\n
Log into your client machine. Make sure that the client you are using was specified in the ACL group you set for your DNS server. Otherwise the DNS server will refuse to serve requests for the client.<\/p>\n
We need to edit the\u00a0\/etc\/resolv.conf<\/code>\u00a0file to point our server to the name server. Changes made here will only last until reboot, which is great for testing. If we are satisfied with the results of our tests, we can make these changes permanent.<\/p>\n
Open the file with sudo privileges in your text editor:<\/p>\n
sudo nano \/etc\/resolv.conf\r\n<\/code><\/pre>\n
The file will list the DNS servers to use to resolve queries by setting the\u00a0nameserver<\/code>\u00a0directives. Comment out all of the current entries and add a\u00a0nameserver<\/code>\u00a0line that points to your DNS server:<\/p>\n
nameserver 192.0.2.1<\/span>\r\n# nameserver 8.8.4.4\r\n# nameserver 8.8.8.8\r\n# nameserver 209.244.0.3\r\n<\/code><\/pre>\n
Save and close the file.<\/p>\n
Now, you can test to make sure queries can resolve correctly by using some common tools.<\/p>\n
You can use\u00a0ping<\/code>\u00a0to test that connections can be made to domains:<\/p>\n
ping -c 1 google.com\r\n<\/code><\/pre>\n
PING google.com (173.194.33.1) 56(84) bytes of data.\r\n64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms\r\n\r\n--- google.com ping statistics ---\r\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\r\nrtt min\/avg\/max\/mdev = 63.807\/63.807\/63.807\/0.000 ms\r\n<\/code><\/pre>\n
This means that our client can connect with\u00a0google.com<\/code>\u00a0using our DNS server.<\/p>\n
We can get more detailed information by using DNS specific tools like\u00a0dig<\/code>. Try a different domain this time:<\/p>\n
dig linuxfoundation.org\r\n<\/code><\/pre>\n
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org\r\n;; global options: +cmd\r\n;; Got answer:\r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417\r\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1\r\n\r\n;; OPT PSEUDOSECTION:\r\n; EDNS: version: 0, flags:; udp: 4096\r\n;; QUESTION SECTION:\r\n;linuxfoundation.org.       IN  A\r\n\r\n;; ANSWER SECTION:\r\nlinuxfoundation.org.    6017    IN  A   140.211.169.4\r\n\r\n;; Query time: 36 msec<\/span>\r\n;; SERVER: 192.0.2.1#53(192.0.2.1)\r\n;; WHEN: Wed Jun 25 15:45:57 EDT 2014\r\n;; MSG SIZE  rcvd: 64\r\n<\/code><\/pre>\n
You can see that the query took 36 milliseconds. If we make the request again, the server should pull the data from its cache, decreasing the response time:<\/p>\n
dig linuxfoundation.org\r\n<\/code><\/pre>\n
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org\r\n;; global options: +cmd\r\n;; Got answer:\r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275\r\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1\r\n\r\n;; OPT PSEUDOSECTION:\r\n; EDNS: version: 0, flags:; udp: 4096\r\n;; QUESTION SECTION:\r\n;linuxfoundation.org.       IN  A\r\n\r\n;; ANSWER SECTION:\r\nlinuxfoundation.org.    6012    IN  A   140.211.169.4\r\n\r\n;; Query time: 1 msec<\/span>\r\n;; SERVER: 192.0.2.1#53(192.0.2.1)\r\n;; WHEN: Wed Jun 25 15:46:02 EDT 2014\r\n;; MSG SIZE  rcvd: 64\r\n<\/code><\/pre>\n
As you can see, the cached response is significantly faster.<\/p>\n
We can also test the reverse lookup by using the IP address that we found (140.211.169.4<\/code>\u00a0in our case) with dig’s\u00a0-x<\/code>\u00a0option:<\/p>\n
dig -x 140.211.169.4\r\n<\/code><\/pre>\n
; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4\r\n;; global options: +cmd\r\n;; Got answer:\r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516\r\n;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1\r\n\r\n;; OPT PSEUDOSECTION:\r\n; EDNS: version: 0, flags:; udp: 4096\r\n;; QUESTION SECTION:\r\n;4.169.211.140.in-addr.arpa.    IN  PTR\r\n\r\n;; ANSWER SECTION:\r\n4.169.211.140.in-addr.arpa. 3402 IN CNAME   4.0-63.169.211.140.in-addr.arpa.\r\n4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.\r\n\r\n;; Query time: 31 msec\r\n;; SERVER: 192.0.2.1#53(192.0.2.1)\r\n;; WHEN: Wed Jun 25 15:51:23 EDT 2014\r\n;; MSG SIZE  rcvd: 117\r\n<\/code><\/pre>\n
As you can see, the reverse lookup also succeeds.<\/p>\n
Back on your DNS server, you should see if any errors have been recorded during your tests. One common error that may show up looks like this:<\/p>\n
. . .\r\nJun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net\/A\/IN': 2001:dc0:4001:1:0:1836:0:140#53\r\nJun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com\/A\/IN': 2001:503:a83e::2:30#53\r\nJun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org\/AAAA\/IN': 2001:500:f::1#53\r\nJun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr\/A\/IN': 2a00:d78:0:102:193:176:144:22#53\r\n<\/code><\/pre>\n
These indicate that the server is trying to resolve IPv6 information but that the server is not configured for IPv6. You can fix this issue by telling Bind to only use IPv4.<\/p>\n
To do this, open the\u00a0\/etc\/default\/bind9<\/code>\u00a0file with sudo privileges:<\/p>\n
sudo nano \/etc\/default\/bind9\r\n<\/code><\/pre>\n
Inside, modify the\u00a0OPTIONS<\/code>\u00a0parameter to include the\u00a0-4<\/code>\u00a0flag to force IPv4 only behavior:<\/p>\n
OPTIONS=\"-u bind -4<\/span>\"\r\n<\/code><\/pre>\n
Save and close the file.<\/p>\n
Restart the server:<\/p>\n
sudo service bind9 restart\r\n<\/code><\/pre>\n
You should not see these errors in the logs again.<\/p>\n
Making Client DNS Settings Permanent<\/h3>\n
As mentioned before, the\u00a0\/etc\/resolv.conf<\/code>\u00a0settings that point the client machine to our DNS server will not survive a reboot. To make the changes last, we need to modify the files that are used to generate this file.<\/p>\n
If the client machine is running Debian or Ubuntu, open the\u00a0\/etc\/network\/interfaces<\/code>\u00a0file with sudo privileges:<\/p>\n
sudo nano \/etc\/network\/interfaces\r\n<\/code><\/pre>\n
Look for the\u00a0dns-nameservers<\/code>\u00a0parameter. You can remove the existing entries and replace them with your DNS server or just add your DNS server as one of the options:<\/p>\n
. . .\r\niface eth0 inet static\r\n        address 111.111.111.111\r\n        netmask 255.255.255.0\r\n        gateway 111.111.0.1\r\n        dns-nameservers 192.0.2.1<\/span>\r\n. . .\r\n<\/code><\/pre>\n
Save and close the file when you are finished. Next time you boot up, your settings will be applied.<\/p>\n
If the client is running CentOS or Fedora, you need to open the\u00a0\/etc\/sysconfig\/network\/network-scripts\/ifcfg-eth0<\/code>\u00a0file instead:<\/p>\n
sudo nano \/etc\/sysconfig\/network-scripts\/ifcfg-eth0\r\n<\/code><\/pre>\n
Inside, look for the lines that begin with\u00a0DNS<\/code>. Change\u00a0DNS1<\/code>\u00a0to your DNS server. If you don’t want to use the other DNS servers as a fallback, remove the other entries:<\/p>\n
DNS1=192.0.2.1<\/span>\r\n<\/code><\/pre>\n
Save and close the file when you are finished. Your client should use those settings at next boot.<\/p>\n
<\/div>\n
Conclusion<\/h2>\n
You should now have either a caching or forwarding DNS server configured to serve your clients. This can be a great way to speed up DNS queries for the machines you are managing.<\/p>\n
If you want to create a DNS server that is authoritative for your own domain zones, you can configure an\u00a0authoritative-only DNS server\u00a0or combine these solutions.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction DNS, or the Domain Name System, is often a difficult component to get right when learning how to configure websites and servers. While most people will probably choose to use the DNS servers provided by their hosting company or their domain registrar, there are some advantages to creating your own DNS servers. In this […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1082,1,730,830,772,42,51,495,68,271,548],"tags":[773,915,771,783,292,215,1234,920,1233,759,921],"class_list":["post-4562","post","type-post","status-publish","format-standard","hentry","category-centos-7-rhel-7","category-viazap","category-clusterweb","category-debian","category-dns-2","category-leitura-recomendada","category-linux-linuxrs","category-profissional-de-ti","category-redes-2","category-seguranca-2","category-ubuntu-2","tag-a","tag-as","tag-bind","tag-caching","tag-configure","tag-dns","tag-forwarding","tag-how","tag-or","tag-server","tag-to"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4562","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4562"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4562\/revisions"}],"predecessor-version":[{"id":4563,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/4562\/revisions\/4563"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4562"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4562"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4562"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}