The purpose of DNS is to translate domain names easily remembered by humans into IP addresses that computers understand, a process called name resolution. What will the installation of our own caching DNS server give us? This will speed up the response of sites a little + Linux does not take NetBios names very well, and sometimes you have to find computers or printers inside local network, but I want to do it by name.
Remembering IP addresses is not convenient, but constantly climbing to the DHCP server log is also not our method. For such cases, DNS is needed in the local network. The installation of the bind9 package itself is not difficult, plugs usually arise at the stage of its configuration, because after easy-to-read configuration files of the system, an incomprehensible syntax falls on a person, by the way, very similar to the C programming language. the server will work inside the local network, then it does not make sense to transfer it to a chroot environment and the whole setup takes very little time. On this, the lyrical part can be completed, we proceed to installation and configuration.
Install the Bind9 DNS server:
# apt - get install bind9Once completed, downloaded and installed, we need to edit its configuration file:
# vim / etc / bind / named . conf. optionsWe find the section, it is at the very beginning configuration file besides her, there is nothing else ...
options ( directory "/var/cache/bind" ; // If there is a firewall between you and nameservers you want// to talk to, you may need to fix the firewall to allow multiple// ports to talk. See http://www.kb.cert.org/vuls/id/800113// If your ISP provided one or more IP addresses for stable// nameservers, you probably want to use them as forwarders.// Uncomment the following block, and insert the addresses replacing// the all-0"s placeholder. // forwarders ( // 0.0.0.0; // ); auth - nxdomain no ; # conform to RFC1035 listen - on - v6 ( any ; ); );The forwarders section is responsible for where the DNS request for name resolution will be sent if it is not in its own database. Lately, I’m not at all happy, the work of these servers at the provider can be connected to third-party ones, for example, Google ones, it’s very easy to remember the IP 8.8.
We edit the section, first you need to remove comments from it and add third-party DNS, if there is a need to add several servers, for example, in case the google server does not withstand your requests and breaks :), then the IP of other servers can be written in a column, then you can achieve greater resiliency.
forwarders ( 8.8.8.8 ; 193.58.251.251 ; //Russian DNS service -SkyDNS};In this section, it is better to enter the IP of the server that you have specified in the file /etc/resolv.conf or enter there in the section nameserver this IP. We save the changes and exit. Restart the server and check. Recruiting in command line nslookup mail.ru
Should issue:
This suggests that our server is not the main one in servicing this zone (mail.ru), but the requests have been added to the cache!
Now we need to create a DNS zone for our network so that machines can find various network services - there can be, for example, network printers, they can be either independent or shared on other workstations.
Our zone can be called orgname -i.e. Name of the organization.
First of all, we create a zone, for this we edit named.conf.local
and add the following to it:
zone "orgname" ( type master ; file "/etc/bind/db.orgname" ; );Save and exit
Now we need to create a zone configuration file
and paste the following into it:
(Please pay attention to the syntax of the configuration file, even dots matter)
Now, when adding a new network device, you need to do 2 things:
1) Reserve an IP address for DHCP server, how to do this, you can read in the article - Setting up a DHCP server
2) Create DNS zone for this IP, devicename IN A XXX.XXX.XXX.XXX. Where: devicename - network name of the device; XXX.XXX.XXX.XXX is its IP address which is reserved on the DHCP server.
now we need to edit the resolv.conf file
# vim / etc / resolv . confand enter there:
nameserver 127.0.0.1everything that was there could be commented out by putting #
server restarts
# reboot
This is done so that the server looks for everything in its own database, and only then BIND will redirect requests to the server 8.8.8.8 whose IP is entered in the directive forwarders.
Now you can check if it works:
If testing is done from under Windows:
If we test from under Linux:
ping devicename . orgname - c 4Pings should go to the IP that you specified instead of XXX.XXX.XXX.XXX
You can also check the speed of processing requests with the command dig
# dig @127.0.0.1 tut.by ;<<>> DiG 9.9.5-9+deb8u6-Debian<<>> @127.0.0.1 tut.by ; (1 server found) ;; global options: +cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310
DNS (Domain Name System) is an important and rather difficult to configure component necessary for the operation of websites and servers. Many users use DNS servers provided by their hosting provider, however, having your own DNS servers has some advantages.
In this tutorial, you will learn how to install Bind9 and configure it as a caching or forwarding DNS server on an Ubuntu 14.04 server.
You will learn how to configure a client machine to send queries through a DNS server.
Servers of this type are also called resolvers because they process recursive queries and can usually look up DNS data on other servers.
When a caching DNS server monitors a response to a client query, it returns the response to the client and also stores it in the cache for a period of time allowed by the TTL value of the corresponding DNS records. The cache can then be used as a source of responses to subsequent requests to speed up the overall request processing time.
Almost all DNS servers in your network configuration will be caching. A caching DNS server is a good choice for many situations. If you don't want to rely on your hosting provider's DNS servers or other public DNS servers, set up your own caching DNS server. The shorter the distance from the DNS server to the client machines, the shorter the time it takes to service DNS queries.
From the client's point of view, a forwarding DNS server will look almost identical to a caching server, but the mechanisms and workload are completely different.
A forwarding DNS server has the same benefits as a caching server. However, it doesn't actually execute any recursive query. Instead, it redirects all requests to an external resolver and then caches the results for subsequent requests.
This allows the forwarding server to serve requests from its cache without having to process recursive requests. Thus, this server only handles single requests (redirected client requests) and not the entire recursion procedure. This can be an advantage in environments with limited external bandwidth, where you need to frequently change caching servers, and in situations where you need to redirect local requests to one server and external requests to another.
The Bind package can be found in the official Ubuntu repository. Update the package index and install Bind using the apt manager. You also need to install a couple of dependencies.
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
After that, you can start configuring the server. The caching server configuration can be used as a template for configuring a forwarding server, so the caching DNS server needs to be configured first.
First you need to configure Bind as a caching DNS server. This configuration will cause the server to recursively look up answers to client queries on other DNS servers. It will sequentially query all relevant DNS servers until it finds an answer.
Bind configuration files are stored in the /etc/bind directory.
Most of the files do not need to be edited. The main configuration file is called named.conf (named and bind are two names for the same application). This file references the named.conf.options, named.conf.local, and named.conf.default-zones files.
To configure a caching DNS server, you only need to edit named.conf.options.
sudo nano named.conf.options
This file looks like this (comments omitted for simplicity):
options (
directory "/var/cache/bind";
dnssec-validation auto;
listen-on-v6 ( any; );
};
To set up a caching server, you need to create an access control list, or ACL.
You need to protect the DNS server that processes recursive queries from intruders. DNS amplification attacks are especially dangerous because they can involve a server in distributed denial of service attacks.
DNS amplification attacks are one way to bring down servers and sites. To do this, attackers try to find public DNS servers that process recursive queries. They forge the victim's IP address and send a query that will return a very large response to the DNS server. In this case, the DNS server returns too much data to the victim's server in response to a small request, increasing the attacker's available bandwidth.
Hosting a public recursive DNS server requires careful configuration and administration. To prevent the server from being hacked, configure a list of IP addresses or network ranges that the server can trust.
Before the options block, add an acl block. Create a label for the ACL group (in this manual, the group is called goodclients).
acl goodclients(
};
options (
. . .
In this block, list the IP addresses or networks that will have access to this DNS server. Because the server and client are running on the /24 subnet, you can restrict access to that subnet. You also need to unblock localhost and localnets, which connect automatically.
acl goodclients(
192.0.2.0/24;
localhost;
local nets;
};
options (
. . .
You now have secure client ACLs. You can start setting the request resolution in the options block. Add the following lines to it:
options (
directory "/var/cache/bind";
recursion yes;
. . .
The options block explicitly enables recursion and then sets the allow-query option to use the ACL. You can also use another option to refer to an ACL group, such as allow-recursion. With recursion enabled, allow-recursion will define a list of clients that can use recursive services.
However, if the allow-recursion option is not set, Bind falls back to the allow-query-cache list, then to the allow-query list, and finally to the default localnets and localhost lists. Since we are only setting up a caching server (it does not have its own zones and does not forward requests), the allow-query list will always only apply to recursion. This is the most general way to define an ACL.
Save and close the file.
These are all the settings that need to be added to the caching DNS server configuration file.
Note A: If you only want to use this type of DNS, proceed to check the configurations, restart the service and configure your client.
If your infrastructure is more suited to a forwarding DNS server, you can tweak the setting a bit.
At the moment, the named.conf.options file looks like this:
acl goodclients(
192.0.2.0/24;
localhost;
local nets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};
You can use the same ACL to restrict a DNS server to a specific list of clients. However, this requires a slight configuration change so that the server no longer tries to execute recursive queries.
Do not change recursion to no. The forwarding server does support recursive services. To set up a redirect server, you need to create a list of caching servers to which it will redirect requests.
This is done in the options() block. First, you need to create a new forwarders block in it, which will store the IP addresses of the recursive name servers to which you want to forward requests. In this case, these will be the Google DNS servers (8.8.8.8 and 8.8.4.4):
. . .
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (
8.8.8.8;
8.8.4.4;
};
. . .
The resulting configuration looks like this:
acl goodclients(
192.0.2.0/24;
localhost;
local nets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};
The last change concerns the dnssec parameter. With the current configuration and depending on the settings of the DNS servers to which requests are redirected, the following errors may appear in the logs:
Jun 25 15:03:29 cache named: error (chase DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 cache named: error (no valid DS) resolving "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53
To avoid them, you need to change the value of the dnssec-validation parameter to yes and explicitly enable dnssec.
. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .
Save and close the file. The forwarding DNS server setup is complete.
Now we need to make sure that the settings work as expected.
To check the syntax of configuration files, type:
sudo named-checkconf
If there are no errors in the files, the command line will not display any output.
If you receive an error message, correct it and recheck.
You can then restart the Bind daemon to update the settings.
sudo service bind9 restart
After you need to check the server logs. Run the command on the server:
sudo tail -f /var/log/syslog
Now open a new terminal and start setting up the client machine.
Log in to the client machine. Verify that the client was listed in the ACL group of the configured DNS server. Otherwise, the DNS server will refuse to serve queries from this client.
Edit the /etc/resolv.conf file to point the server to the nameserver.
Changes made here will only persist until a reboot, which is great for testing. If you are satisfied with the results of the test setup, you can make these settings permanent.
Open the file with sudo in a text editor:
sudo nano /etc/resolv.conf
The file must list the DNS servers that will be used to resolve queries. To do this, use the nameserver directive. Comment out all current entries and add the line nameserver pointing to your DNS server:
nameserver 192.0.2.1
#nameserver 8.8.4.4
#nameserver 8.8.8.8
# nameserver 209.244.0.3
Save and close the file.
Now you can send a test request to make sure it resolves correctly.
You can use ping for this:
ping -c 1
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000ms
To speed up web browsing, the Windows operating system caches DNS server responses. Immediately after the arrival of a response to the definition of a numeric value from the DNS server, Windows automatically places this address in local storage. When a browser requests an address from a URL, Windows first looks it up in the store, and if it finds it, it immediately returns the result without going to the ISP's DNS servers. Local cache increases speed and saves bandwidth.
If the information is corrupted or the IP address changes while storing the address in local storage, the browser will not be able to open the site. This doesn't happen very often. Luckily, there is a way to clear the local cache to fix the problem instantly.
Windows has a tool ipconfig, which has the option /flushdns to clear all cached entries. If you want to clear the local cache, then in the command line window ( Start — Programs(All programs) - Standard — Command line) you should enter the command ipconfig /flushdns and press the Enter key.
To view all DNS records in local storage, you can use the option /displaydns teams ipconfig. To do this, in the command line window, enter the command ipconfig / displaydns and press the Enter key. All records of cached DNS responses will appear in the window.
Typically, Windows stores addresses for no more than 86400 seconds (1 day), but you can limit the storage time to another limit. To do this, open the registry editor (at the command prompt, type regedit and press Enter). In the left pane of the editor, there is a tree of registry keys that looks like folders on a hard drive. In this tree, clicking on the corresponding folder expansion icons (plus sign) should open the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters, then set the cursor on the folder in this tree Parameters. The contents of this key (folder) will appear in the right area of the registry editor.
DWORD value of the parameter MaxCacheTtl Specifies the time limits for storing responses in seconds. It can be changed to anything else. If parameter MaxCacheTtl no, it means that the standard limit is set to 86400 seconds. To change it, create a parameter MaxCacheTtl DWORD type with a value equal to the required limit. Parameter MaxCacheTtl limits only the storage time of positive responses, i.e. when it was possible to determine the ip-address by the domain name.
If the provider's DNS server returned a negative response (could not determine the address), it is also stored in local storage. Typically, such a response is stored for 15 minutes. This means that if during the visit to the site, it was not possible to determine its ip-address, the site will be impossible to visit within 15 minutes, even if it becomes available during this time. To avoid this, you should reduce the storage time for negative answers or disable their storage altogether. To set the retention time, you must adjust (or create if missing) the DWORD parameter MaxNegativeCacheTtl, which limits the time limit for storing negative responses. To disable their storage, it is enough to set the storage time to zero.
If you want to temporarily disable address caching in local storage, you must enter the command in the command line net stop dnscache(or sc stop dnscache) and press Enter. To turn it back on, enter the command in the command line net start dnscache(or scstart dnscache) and press Enter, or restart the computer.
A DNS cache is a temporary database that stores information about previous DNS lookups. In other words, whenever you visit a website, your OS and web browser will keep a record of the domain and the corresponding IP address. This eliminates the need for repeated queries to remote DNS servers and allows your OS or browser to quickly resolve website URLs.
However, in some situations, such as network troubleshooting or after changing DNS resolvers, you need to flush the DNS cache. This will clear the cached DNS records and perform a subsequent lookup to resolve the domain based on the newly configured DNS settings.
This article provides instructions on how to clear the DNS cache in different operating systems and web browsers.
The process for clearing the DNS cache is the same for all versions of Windows. You need to open a command prompt with administrator rights and run ipconfig /flushdns.
To clear the DNS cache in Windows 10 and 8, follow these steps:
ipconfig /flushdns
To clear the DNS cache in Windows 7, follow these steps:
ipconfig /flushdns
If successful, the system will return the following message:
Windows IP Configuration Successfully flushed the DNS Resolver Cache.
Linux lacks OS-level DNS caching unless a caching service such as Systemd-Resolved, DNSMasq, or Nscd is installed and running. The process for clearing the DNS cache differs depending on the distribution and caching service you are using.
Most modern Linux distributions, such as , use a system enabled service to cache DNS records.
To find out if the service is running, run:
sudo systemctl is-active systemd-resolved.service
If the service is running, the command will print active, otherwise you will see inactive.
To flush the Systemd Resolved DNS cache, you must enter the following command.
sudo systemd-resolve --flush-caches
If successful, the command does not return any message.
Dnsmasq is a lightweight DHCP and DNS name caching server.
If your system is using DNSMasq as a cache server, you need to restart the Dnsmasq service to clear the DNS cache:
sudo systemctl restart dnsmasq.service
sudo service dnsmasq restart
Nscd is a caching daemon and is the preferred DNS caching system for most RedHat based distributions.
If your system is using Nscd, you need to restart the Nscd service to clear the DNS cache:
sudo systemctl restart nscd.service
sudo service nscd restart
The command to clear the cache in MacOS is slightly different depending on the version you are using. The command must be run as a user with system administrator rights (sudo user).
To clear the DNS cache on MacOS, follow these steps:
sudo killall -HUP mDNSResponder
Type in your sudo password and press Enter again. If successful, the system does not return any messages.
For more early versions The MacOS command to clear the cache is different.
MacOS versions 10.11 and 10.9
sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
macOS version 10.10
sudo discoveryutil mdnsflushcache sudo discoveryutil udnsflushcaches
MacOS versions 10.6 and 10.5
sudo dscacheutil -flushcache
Most modern web browsers have a built-in DNS client that prevents duplicate queries every time you visit a website.
To clear the DNS cache Google Chrome, do the following:
If this doesn't work for you, try clearing your cache and cookies.
This method should work for all Chrome based browsers including Chromium, Vivaldi and Opera.
To clear the Firefox DNS cache, follow these steps:
If this doesn't work for you, try the next method and temporarily disable the DNS cache.
Have you learned how to clear or clear the DNS cache in the operating Windows systems, Linux and macOS.
Linux and MacOS can use the dig command to query DNS and troubleshoot DNS issues.
If you have any questions or feedback feel free to leave a comment.
artem
30.10.2013
10379
The Asterisk SIP module resolves DNS names synchronously, if the DNS server stops responding for any reason, the SIP module code stops executing before the DNS query times out. The result of this is the inoperability of all clients and providers connected via SIP, clients cannot register and make calls.
Ways to solve the problem:
1. Do not specify DNS names in the 'host' parameter of SIP peers and in SIP registration lines, specify only IP addresses (allows you to completely eliminate the possibility of a problem, but is not possible with some providers).
2. Set up a caching DNS server on the Asterisk host.
This article will describe how to solve the problem using the BIND DNS server (the instruction is correct for CentOS 5-6)
1. Install BIND, copy settings templates and standard zone files
yum install bind bind-chroot
cp /etc/localtime /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.root.hints /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.rfc1912.zones /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.conf /var/named/chroot/etc
cp /usr/share/bind-*/sample/var/named/localdomain.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/localhost.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.broadcast /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.ip6.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.root /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.zero /var/named/chroot/var/named
2. Edit BIND config /var/named/chroot/etc/named.conf
You need to make the following changes to the config:
> Add a line to the options section:
You can specify your DNS servers. If you do not specify this line, then BIND will query the root DNS servers, which is slower
> Allow recursive queries for view-zone 'localhost_resolver' (replace 'recursion no' with 'recursion yes', if this is not done, then the host itself will not be able to make recursive queries through the DNS server). Recursive queries and cache queries for other zones can be disabled
> Comment out or delete the sections responsible for setting up internal zones and DDNS, because they just won't be
Listing of the resulting config:
//
// Sample named.conf BIND DNS server 'named' configuration file
// for the Red Hat BIND distribution.
// See the BIND Administrator's Reference Manual (ARM) for details, in:
// file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Also see the BIND Configuration GUI: /usr/bin/system-config-bind and
// its manual.
options
{
// Those options should be used carefully because they disable port
// randomization
// query-source port 53;
// query-source-v6 port 53;
// Put files that named is allowed to write in the data/ directory:
directory “/var/named”; // default
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file “data/named_mem_stats.txt”;
max-cache-size 2097152;
forwarders ( 8.8.8.8; 8.8.4.4; );
};
//logging
//{
/* If you want to enable debugging, eg. using the 'rndc trace' command,
* named will try to write the 'named.run' file in the $directory (/var/named).
* By default, SELinux policy does not allow named to modify the /var/named directory,
* so put the default debug log file in data/ :
*/
// channel default_debug(
// file "data/named.run";
// severity dynamic;
// };
//};
// All BIND 9 zones are in a "view", which allow different zones to be served
// to different types of client addresses, and for options to be set for groups
// zones.
// By default, if named.conf contains no "view" clauses, all zones are in the
// "default" view, which matches all clients.
// If named.conf contains any "view" clause, then all zones MUST be in a view;
// so it is recommended to start off using views to avoid having to restructure
// your configuration files in the future.
view "localhost_resolver"
{
/* This view sets up named to be a localhost resolver (caching only nameserver).
* If all you want is a caching-only nameserver, then you need only define this view:
*/
match-clients ( localhost; );
match-destinations ( localhost; );
recursion yes;
/* these are zones that contain definitions for all the localhost
* names and addresses, as recommended in RFC1912 – these names should
* ONLY be served to localhost clients:
*/
include "/etc/named.rfc1912.zones";
};
view “internal”
{
/* This view will contain zones you want to serve only to "internal" clients
that connect via your directly attached LAN interfaces – “localnets” .
*/
match-clients ( localnets; );
match-destinations ( localnets; );
recursion no;
Allow-query-cache ( none; );
// all views must contain the root hints zone:
include "/etc/named.root.hints";
// include "named.rfc1912.zones";
// you should not serve your rfc1912 names to non-localhost clients.
// These are your "authoritative" internal zones, and would probably
// also be included in the “localhost_resolver” view above:
//zone "my.internal.zone" (
// typemaster;
// file "my.internal.zone.db";
//};
//zone “my.slave.internal.zone” (
// type slave;
// file “slaves/my.slave.internal.zone.db”;
// masters ( /* put master nameserver IPs here */ 127.0.0.1; ) ;
// // put slave zones in the slaves/ directory so named can update them
//};
//zone “my.ddns.internal.zone” (
// typemaster;
// allow-update ( key ddns_key; );
// file “slaves/my.ddns.internal.zone.db”;
// // put dynamically updateable zones in the slaves/ directory so named can update them
//};
};
//key ddns_key
//{
// algorithm hmac-md5;
// secret "use /usr/sbin/dns-keygen to generate TSIG keys";
//};
view "external"
{
/* This view will contain zones you want to serve only to "external" clients
* that have addresses that are not on your directly attached LAN interface subnets:
*/
match-clients ( any; );
match-destinations ( any; );
recursion no;
// you'd probably want to deny recursion to external clients, so you don't
// end up providing free DNS service to all takers
allow-query-cache ( none; );
// Disable lookups for any cached data and root hints
// all views must contain the root hints zone:
include "/etc/named.root.hints";
// These are your "authoritative" external zones, and would probably
// contain entries for just your web and mail servers:
//zone "my.external.zone" (
// typemaster;
// file "my.external.zone.db";
//};
};
3. Run BIND, turn on startup at system startup
service named start
If errors are made in the config syntax or any files are missing, an error message will be printed to the console and written to the /var/log/messages log
