Linux dns server administration

Install, Configure, and Maintain Linux DNS Server

The DNS (Domain Name System) is a naming system for computers, the service that does that is the DNS server which translates an IP address to a human-readable address.

This process is the backbone of the internet and a very important service in your server, so from that point, we will discuss DNS server or specifically Linux DNS server and how to install, configure and maintain it.

Table of Contents

The /etc/hosts file

Every system will have to keep its copy of the table of the hostnames and their IP addresses. This file is responsible for IP addresses.

On Linux systems, this table is the /etc/hosts file.

So even if you don’t have a DNS server or DNS server is unavailable, this file can translate IP addresses to names using /etc/hosts file.

That means the system query this file first before going to the DNS server, and if it finds the domain, it will translate it without going to any DNS servers.

Try to edit /etc/hosts and type the following:

Then go to your browser and type google.com and see the results. If you have Apache server installed on your system and your localhost is running, it will show the index page of the localhost instead of the google page.

You can translate google.com to any other IP address of any site and see the result to ensure that.

So what this file is doing is translating IP addresses to names, but this for the same connected network. So what about the outside networks and how to maintain all those records for all systems?

Will everybody manages his own /etc/hosts file and update it himself? Of course not.

Domain names

When you visit a website, you type the FQDN (Fully Qualified Domain Name) or the domain name like this: likegeeks.com or www.google.com

Each domain consists of domain components; the dot separates these components.

The text com is the top-level domain component, and google is the second-level domain component, and www is the third-level domain component

When you visit any website, the browser silently adds a dot at the end, but not visible to you, so the domain will be like www.google.com. Notice the dot after .com; this dot is called the root domain.

But why we added this root domain or the dot?

Because this dot is served by the root name servers, at the time of this post, there are 13 root name servers in the world, you can think of them as the brain of the internet, if they go OFF the world will be without the internet.

Because maybe an earthquake or a natural disaster happens in one place in the world may destroy a root server, so the others serve until the damaged server returns online.

Those root name servers have names like this: a.root-server.net, b.root-server.net, and so on.

Top Level domain names (TLDs)

We saw a top-level domain component, such as com domains.

Top-level domains (TLDs) are divided into categories based on geographical or functional aspects.

There are more than 800 top-level domains on the web at the time of writing this post.

The top-level domains categories are:

• Generic top-level domain like (.org, .com, .net, .gov, .edu and so on).
• Country-code top-level domains like (.us, .ca, and so on) corresponding to the country codes for the United States and Canada, respectively.
• New branded top-level domains like (.linux, .microsoft, .companyname and so on).
• Infrastructure top-level domains like the .arpa domain.

Subdomains

When you visit a website like mail.google.com, the mail here is a subdomain of google.com.

Only the name servers for mail.google.com know all the hosts existing beneath it, so google answers if there is mail subdomain or not, the root name servers have no clue about that.

Types of DNS servers

There are three types of DNS servers:

• Primary DNS servers: They contain the domain’s configuration files, and they respond to the DNS queries.
• Secondary DNS server: They work as a backup and load distribution. Primary servers know the existence of the secondary name servers and send updates to them.
• Caching DNS server: All they do is caching the DNS responses, so you don’t need to ask the primary or secondary DNS server again. You can make your system work as a caching server easily, as we will see later on this post.

Setting up Linux DNS server

There are many packages on Linux that implement DNS functionality, but we will focus on the BIND DNS server. Many servers around the world use it.

If you are using Red Hat based distro like CentOS, you can install it like this:

Or on Debian based systems like Ubuntu:

Once the installation completed, you can start it and enable it to run at boot time.

Configuring BIND

The service configuration is /etc/named.conf file.

There are some statements that BIND uses in that file like:

options	used for global BIND configuration.
logging	what can be logged and what can be ignored. I recommend you review the Linux syslog server.
zone	define DNS zone.
include	to include another file in named.conf.

From the options statement, you can see that the working directory for BIND is /var/named directory.

The zone statement enables you to define a DNS zone.

Like the domain google.com which also has subdomains like mail.google.com and analytics.google.com and other subdomains.

Every one of these three (the domain and subdomains) has a zone defined by the zone statement.

Defining a primary zone

We know from the DNS server types that there are primary, secondary, and cache DNS servers.

Primary and secondary are equally authoritative in their answers, unlike the caching server.

To define a primary zone, you can use the following syntax:

The file that contains the zone information is located in /var/named directory since this is the working directory, as we know from the options.

Note that the server software or the hosting panel you’re using creates this file with this name automatically for you, so if your domain is example.org, the file will be /var/named/example.org.db.

The type is master, which means this is a primary zone.

Defining a secondary zone

The same as the primary zone definition with little change.

In the secondary zone, the domain is the same as the primary zone, and the type slave here means this is a secondary zone, and the masters option to list the IP addresses of the primary nameserver and finally, the file is the path of the primary’s zone files.

Defining a caching zone

It is necessary to have a caching zone, so you decrease the queries on the DNS server.

To define a caching zone, you need to define three-zone sections the first one:

The first line contains a dot, which is the root name servers. The type hint, which means a caching zone entry, and the file “root.hints”; specifies the file that contains the root servers ( the 13 root name server). You can get the latest root name server from http://www.internic.net/zones/named.root

The second zone defined in the /etc/named.rfc1912.zones file and included in /etc/named.conf via include directive, which is already included by default.

The third zone defines the reverse lookup for the localhost.

Putting these three zones on /etc/named.conf will make your system work as a caching DNS server. Now you should type the content of the files referenced like likegeeks.com.db, localhost.db, and 127.0.0.rev.

These files contain the DNS record types for each zone with some options. So what are those DNS record types and how to write them?

DNS records types

The database files consist of record types like SOA, NS, A, PTR, MX, CNAME, and TXT.

So let’s start with each record type and see how we can configure it.

SOA: Start of Authority Record

The SOA record describes the site’s DNS entries with the following format:

The first line starts with the domain example.com. and ends with a period. Which is the same as the zone definition in /etc/named.conf file.

Keep in mind that DNS configuration files are extremely picky.

The IN word means Internet record.

The SOA word means Start of Authority record.

The ns1. example.com. is the domain’s name server.

The mail.host.com. is the domain administrator email. You may notice there is no @ sign, and we replaced it with the period, and there is a trailing period.

Line 2 is the serial number, we use it to tell the name server about the file update time, so if you make a change to the zone data, you have to increment this number. The serial number has the format YYYYMMDDxx where xx is starting from 00.

Line 3 is the refresh rate in seconds. How often secondary DNS servers should query the primary server to check for updates.

Line 4 is the retry rate in seconds. This is the time that the secondary DNS server takes for waiting after trying to connect to the primary DNS server and cannot reach it. The specified number of retry seconds.

Line 5 is the expire directive. If the secondary server cannot connect to the primary server for an update, it should discard the value after the specified number of seconds.

Line 6 tells the caching servers can’t connect to the primary DNS server; they wait before expiring an entry, this line defines the wait time.

NS: Name Server records

You can use the NS record to specify the name servers for a zone. The NS records are like this:

You don’t have to create two NS records, but we prefer to have backup name servers.

A and AAAA: address records

The A record maps the hostname to an IP address:

If you have a host at support.example.com on address 192.168.1.5, you can type like the above example.

Note: we wrote the host without a period.

PTR: pointer records

The PTR record is for doing the reverse name resolution, you give an IP address, and it returns the hostname.

This is the opposite of what A record does.

Here we type the full hostname with the trailing period.

MX: Mail exchange records

The MX record tells about the mail server records.

The domain ends with a period; the number 10 is the importance of the mail server, if you have multiple mail servers, the lower number is the less important.

CNAME: Canonical Name Records

CNAME records are like shortcuts for hostnames.

Suppose you have a site that has a hostname of whatever-bignameis.example.com, and since the system is a web server, an alias of www or CNAME record can be created for the host.

So you can create a CNAME record to make the name www.example.com:

The first line tells the DNS server about the location of the alias; the second line creates the alias that points to www.

TXT records

You can put any text on TXT records like your contact information or any other information you want the people to know when they query your DNS server.

You can write TXT records like this:

Also, you can use the RP record to put the contact information.

DNS TTL value

In /etc/named.conf on the top there is $TTL entry.

This entry informs BIND about the time to live value for each individual record.

It takes a value in seconds like 14400 seconds (4 hours), so the DNS servers will cache your zone up to four hours then will query your DNS server again.

You can lower the value, but the default value is fair unless you know what you are doing.

Catching configuration errors

When you write your zone files, maybe you forget a period or space or any other error.

You can diagnose your Linux DNS server errors from the log. The BIND service through errors in /var/log/messages, you can use the tail command to view real-time error log using -f option.

So when you write a zone file or modify /etc/named.config and restart your service and it shows an error, you can easily identify the error from the log.

Host command

After you have successfully added or modified your records, you can use the host command to see if your host if resolved correctly.

If you give it a hostname, it will answer with the corresponding IP addresses.

Also, you can perform reverse lookups.

Whois command

You can use the whois command to get the domain owner’s details.

Also, the owner’s email addresses, and contact phone numbers.

The rndc command

You can use the rndc tool to manage the name server securely.

You can check the status of the Linux DNS server like this:

Also, if you make a change to any of the zone files, you can reload the service without restart the named service.

Here we reload the example.com zone file.

You can reload all zones like this:

Or maybe you add new zones or change the configuration of the service; you can reload the configuration like this:

Linux DNS resolver

We’ve seen how a Linux DNS server works and how to configure it. The other part is the client who is contacting the DNS server.

The client is the resolver; you can check the configuration file /etc/resolv.conf

On Debian based distros, you can check /etc/resolvconf/resolv.conf.d/ directory.

The /etc/resolv.conf file contains the local DNS servers that the system uses.

The first line is for the default search domain, and the second line indicates the IP address of the name server.

You can use your own DNS server once your BIND service running, just type them in the resolver.conf file.

Working with the Linux DNS server is pretty easy. I hope you find the post useful and easy.

Источник

Linux dns server administration

DNS (domain name system) is needed to resolve the domain names and host names into IP addresses. In this way, the IP address 192.168.2.100 is assigned to the host name jupiter , for example. Before setting up your own name server, read the general information about DNS in Section 19.3, “Name Resolution”. The following configuration examples refer to BIND, the default DNS server.

32.1 DNS Terminology #Edit source

The domain name space is divided into regions called zones. For example, if you have example.com , you have the example section (or zone) of the com domain.

The DNS server is a server that maintains the name and IP information for a domain. You can have a primary DNS server for master zone, a secondary server for slave zone, or a slave server without any zones for caching.

The master zone includes all hosts from your network and a DNS server master zone stores up-to-date records for all the hosts in your domain.

Slave zone DNS server

A slave zone is a copy of the master zone. The slave zone DNS server obtains its zone data with zone transfer operations from its master server. The slave zone DNS server responds authoritatively for the zone as long as it has valid (not expired) zone data. If the slave cannot obtain a new copy of the zone data, it stops responding for the zone.

Forwarders are DNS servers to which your DNS server should send queries it cannot answer. To enable different configuration sources in one configuration, netconfig is used (see also man 8 netconfig ).

The record is information about name and IP address. Supported records and their syntax are described in BIND documentation. Some special records are:

An NS record tells name servers which machines are in charge of a given domain zone.

The MX (mail exchange) records describe the machines to contact for directing mail across the Internet.

SOA (Start of Authority) record is the first record in a zone file. The SOA record is used when using DNS to synchronize data between multiple computers.

32.2 Installation #Edit source

To install a DNS server, start YaST and select Software  › Software Management . Choose View  › Patterns and select DHCP and DNS Server . Confirm the installation of the dependent packages to finish the installation process.

Alternatively use the following command on the command line:

32.3 Configuration with YaST #Edit source

Use the YaST DNS module to configure a DNS server for the local network. When starting the module for the first time, a wizard starts, prompting you to make a few decisions concerning administration of the server. Completing this initial setup produces a basic server configuration. Use the expert mode to deal with more advanced configuration tasks, such as setting up ACLs, logging, TSIG keys, and other options.

32.3.1 Wizard Configuration #Edit source

The wizard consists of three steps or dialogs. At the appropriate places in the dialogs, you can enter the expert configuration mode.

When starting the module for the first time, the Forwarder Settings dialog, shown in Figure 32.1, “DNS Server Installation: Forwarder Settings”, opens. The Local DNS Resolution Policy allows to set the following options:

Merging forwarders is disabled

Merging forwarders is enabled

Custom configuration —If Custom configuration is selected, Custom policy can be specified; by default (with Automatic merging selected), Custom policy is set to auto , but here you can either set interface names or select from the two special policy names STATIC and STATIC_FALLBACK .

In Local DNS Resolution Forwarder , specify which service to use: Using system name servers , This name server (bind) , or Local dnsmasq server .

For more information about all these settings, see man 8 netconfig .

FigureВ 32.1: DNS Server Installation: Forwarder Settings #

Forwarders are DNS servers to which your DNS server sends queries it cannot answer itself. Enter their IP address and click Add .

The DNS Zones dialog consists of several parts and is responsible for the management of zone files, described in Section 32.6, “Zone Files”. For a new zone, provide a name for it in Name . To add a reverse zone, the name must end in .in-addr.arpa . Finally, select the Type (master, slave, or forward). See Figure 32.2, “DNS Server Installation: DNS Zones”. Click Edit to configure other settings of an existing zone. To remove a zone, click Delete .

FigureВ 32.2: DNS Server Installation: DNS Zones #

In the final dialog, you can open the DNS port in the firewall by clicking Open Port in Firewall . Then decide whether to start the DNS server when booting ( On or Off ). You can also activate LDAP support. See Figure 32.3, “DNS Server Installation: Finish Wizard”.

FigureВ 32.3: DNS Server Installation: Finish Wizard #

32.3.2 Expert Configuration #Edit source

After starting the module, YaST opens a window displaying several configuration options. Completing it results in a DNS server configuration with the basic functions in place:

32.3.2.1 Start-Up #Edit source

Under Start-Up , define whether the DNS server should be started when the booting the system or manually. To start the DNS server immediately, click Start DNS Server Now . To stop the DNS server, click Stop DNS Server Now . To save the current settings, select Save Settings and Reload DNS Server Now . You can open the DNS port in the firewall with Open Port in Firewall and modify the firewall settings with Firewall Details .

By selecting LDAP Support Active , the zone files are managed by an LDAP database. Any changes to zone data written to the LDAP database are picked up by the DNS server when it is restarted or prompted to reload its configuration.

32.3.2.2 Forwarders #Edit source

If your local DNS server cannot answer a request, it tries to forward the request to a Forwarder , if configured so. This forwarder may be added manually to the Forwarder List . If the forwarder is not static like in dial-up connections, netconfig handles the configuration. For more information about netconfig, see man 8 netconfig .

32.3.2.3 Basic Options #Edit source

In this section, set basic server options. From the Option menu, select the desired item then specify the value in the corresponding text box. Include the new entry by selecting Add .

32.3.2.4 Logging #Edit source

To set what the DNS server should log and how, select Logging . Under Log Type , specify where the DNS server should write the log data. Use the system-wide log by selecting System Log or specify a different file by selecting File . In the latter case, additionally specify a name, the maximum file size in megabytes and the number of log file versions to store.

Further options are available under Additional Logging . Enabling Log All DNS Queries causes every query to be logged, in which case the log file could grow extremely large. For this reason, it is not a good idea to enable this option for other than debugging purposes. To log the data traffic during zone updates between DHCP and DNS server, enable Log Zone Updates . To log the data traffic during a zone transfer from master to slave, enable Log Zone Transfer . See Figure 32.4, “DNS Server: Logging”.

FigureВ 32.4: DNS Server: Logging #

32.3.2.5 ACLs #Edit source

Use this dialog to define ACLs (access control lists) to enforce access restrictions. After providing a distinct name under Name , specify an IP address (with or without netmask) under Value in the following fashion:

The syntax of the configuration file requires that the address ends with a semicolon and is put into curly braces.

32.3.2.6 TSIG Keys #Edit source

The main purpose of TSIGs (transaction signatures) is to secure communications between DHCP and DNS servers. They are described in Section 32.8, “Secure Transactions”.

To generate a TSIG key, enter a distinctive name in the field labeled Key ID and specify the file where the key should be stored ( Filename ). Confirm your choices with Generate .

To use a previously created key, leave the Key ID field blank and select the file where it is stored under Filename . After that, confirm with Add .

32.3.2.7 DNS Zones (Adding a Slave Zone) #Edit source

To add a slave zone, select DNS Zones , choose the zone type Slave , write the name of the new zone, and click Add .

In the Zone Editor sub-dialog under Master DNS Server IP , specify the master from which the slave should pull its data. To limit access to the server, select one of the ACLs from the list.

32.3.2.8 DNS Zones (Adding a Master Zone) #Edit source

To add a master zone, select DNS Zones , choose the zone type Master , write the name of the new zone, and click Add . When adding a master zone, a reverse zone is also needed. For example, when adding the zone example.com that points to hosts in a subnet 192.168.1.0/24 , you should also add a reverse zone for the IP-address range covered. By definition, this should be named 1.168.192.in-addr.arpa .

32.3.2.9 DNS Zones (Editing a Master Zone) #Edit source

To edit a master zone, select DNS Zones , select the master zone from the table, and click Edit . The dialog consists of several pages: Basics (the one opened first), NS Records , MX Records , SOA , and Records .

The basic dialog, shown in Figure 32.5, “DNS Server: Zone Editor (Basics)”, lets you define settings for dynamic DNS and access options for zone transfers to clients and slave name servers. To permit the dynamic updating of zones, select Allow Dynamic Updates and the corresponding TSIG key. The key must have been defined before the update action starts. To enable zone transfers, select the corresponding ACLs. ACLs must have been defined already.

In the Basics dialog, select whether to enable zone transfers. Use the listed ACLs to define who can download zones.

FigureВ 32.5: DNS Server: Zone Editor (Basics) #

The NS Records dialog allows you to define alternative name servers for the zones specified. Make sure that your own name server is included in the list. To add a record, enter its name under Name Server to Add then confirm with Add . See Figure 32.6, “DNS Server: Zone Editor (NS Records)”.

FigureВ 32.6: DNS Server: Zone Editor (NS Records) #

To add a mail server for the current zone to the existing list, enter the corresponding address and priority value. After doing so, confirm by selecting Add . See Figure 32.7, “DNS Server: Zone Editor (MX Records)”.

FigureВ 32.7: DNS Server: Zone Editor (MX Records) #

This page allows you to create SOA (start of authority) records. For an explanation of the individual options, refer to Example 32.6, “The /var/lib/named/example.com.zone File”. Changing SOA records is not supported for dynamic zones managed via LDAP.

FigureВ 32.8: DNS Server: Zone Editor (SOA) #

This dialog manages name resolution. In Record Key , enter the host name then select its type. The A type represents the main entry. The value for this should be an IP address (IPv4). Use AAAA for IPv6 addresses. CNAME is an alias. Use the types NS and MX for detailed or partial records that expand on the information provided in the NS Records and MX Records tabs. These three types resolve to an existing A record. PTR is for reverse zones. It is the opposite of an A record, for example:

32.3.2.9.1 Adding Reverse Zones #Edit source

To add a reverse zone, follow this procedure:

Start YaST  › DNS Server  › DNS Zones .

If you have not added a master forward zone, add it and Edit it.

In the Records tab, fill the corresponding Record Key and Value , then add the record with Add and confirm with OK . If YaST complains about a non-existing record for a name server, add it in the NS Records tab.

FigureВ 32.9: Adding a Record for a Master Zone #

Back in the DNS Zones window, add a reverse master zone.

FigureВ 32.10: Adding a Reverse Zone #

Edit the reverse zone, and in the Records tab, you can see the PTR: Reverse translation record type. Add the corresponding Record Key and Value , then click Add and confirm with OK .

FigureВ 32.11: Adding a Reverse Record #

Add a name server record if needed.

Tip: Editing the Reverse Zone

After adding a forward zone, go back to the main menu and select the reverse zone for editing. There in the tab Basics activate the check box Automatically Generate Records From and select your forward zone. That way, all changes to the forward zone are automatically updated in the reverse zone.

32.4 Starting the BIND Name Server #Edit source

On a SUSEВ® Linux Enterprise Server system, the name server BIND ( Berkeley Internet Name Domain ) comes preconfigured, so it can be started right after installation without any problems. Normally, if you already have an Internet connection and entered 127.0.0.1 as the name server address for localhost in /var/run/netconfig/resolv.conf , you already have a working name resolution without needing to know the DNS of the provider. BIND carries out name resolution via the root name server, a notably slower process. Normally, the DNS of the provider should be entered with its IP address in the configuration file /etc/named.conf under forwarders to ensure effective and secure name resolution. If this works so far, the name server runs as a pure caching-only name server. Only when you configure its own zones it becomes a proper DNS. Find a simple example documented in /usr/share/doc/packages/bind/config .

Tip: Automatic Adaptation of the Name Server Information

Depending on the type of Internet connection or the network connection, the name server information can automatically be adapted to the current conditions. To do this, set the NETCONFIG_DNS_POLICY variable in the /etc/sysconfig/network/config file to auto .

However, do not set up an official domain until one is assigned to you by the responsible institution. Even if you have your own domain and it is managed by the provider, you are better off not using it, because BIND would otherwise not forward requests for this domain. The Web server at the provider, for example, would not be accessible for this domain.

To start the name server, enter the command systemctl start named as root . Check with systemctl status named whether named (as the name server process is called) has been started successfully. Test the name server immediately on the local system with the host or dig programs, which should return localhost as the default server with the address 127.0.0.1 . If this is not the case, /var/run/netconfig/resolv.conf probably contains an incorrect name server entry or the file does not exist. For the first test, enter host В 127.0.0.1 , which should always work. If you get an error message, use systemctl status named to see whether the server is actually running. If the name server does not start or behaves unexpectedly, check the output of journalctl -e .

To use the name server of the provider (or one already running on your network) as the forwarder, enter the corresponding IP address or addresses in the options section under forwarders . The addresses included in Example 32.1, “Forwarding Options in named.conf” are examples only. Adjust these entries to your own setup.

ExampleВ 32.1: Forwarding Options in named.conf #

The options entry is followed by entries for the zone, localhost , and 0.0.127.in-addr.arpa . The type hint entry under “ . ” should always be present. The corresponding files do not need to be modified and should work as they are. Also make sure that each entry is closed with a “ ; ” and that the curly braces are in the correct places. After changing the configuration file /etc/named.conf or the zone files, tell BIND to reread them with systemctl reload named . Achieve the same by stopping and restarting the name server with systemctl restart named . Stop the server at any time by entering systemctl stop named .

32.5 The /etc/named.conf Configuration File #Edit source

All the settings for the BIND name server itself are stored in the /etc/named.conf file. However, the zone data for the domains to handle (consisting of the host names, IP addresses, and so on) are stored in separate files in the /var/lib/named directory. The details of this are described later.

/etc/named.conf is roughly divided into two areas. One is the options section for general settings and the other consists of zone entries for the individual domains. A logging section and acl (access control list) entries are optional. Comment lines begin with a # sign or // . A minimal /etc/named.conf is shown in Example 32.2, “A Basic /etc/named.conf”.

ExampleВ 32.2: A Basic /etc/named.conf #

32.5.1 Important Configuration Options #Edit source

Specifies the directory in which BIND can find the files containing the zone data. Usually, this is /var/lib/named .

Specifies the name servers (mostly of the provider) to which DNS requests should be forwarded if they cannot be resolved directly. Replace IP-ADDRESS with an IP address like 192.168.1.116 .

Causes DNS requests to be forwarded before an attempt is made to resolve them via the root name servers. Instead of forward first , forward only can be written to have all requests forwarded and none sent to the root name servers. This makes sense for firewall configurations.

Tells BIND on which network interfaces and port to accept client queries. port 53 does not need to be specified explicitly, because 53 is the default port. Enter 127.0.0.1 to permit requests from the local host. If you omit this entry entirely, all interfaces are used by default.

listen-on-v6 port 53 ;

Tells BIND on which port it should listen for IPv6 client requests. The only alternative to any is none . As far as IPv6 is concerned, the server only accepts wild card addresses.

query-source address * port 53;

This entry is necessary if a firewall is blocking outgoing DNS requests. This tells BIND to post requests externally from port 53 and not from any of the high ports above 1024.

query-source-v6 address * port 53;

Tells BIND which port to use for IPv6 queries.

Defines the networks from which clients can post DNS requests. Replace NET with address information like 192.168.2.0/24 . The /24 at the end is an abbreviated expression for the netmask (in this case 255.255.255.0 ).

Controls which hosts can request zone transfers. In the example, such requests are completely denied with ! * . Without this entry, zone transfers can be requested from anywhere without restrictions.

In the absence of this entry, BIND generates several lines of statistical information per hour in the system’s journal. Set it to 0 to suppress these statistics completely or set an interval in minutes.

This option defines at which time intervals BIND clears its cache. This triggers an entry in the system’s journal each time it occurs. The time specification is in minutes. The default is 60 minutes.

BIND regularly searches the network interfaces for new or nonexistent interfaces. If this value is set to 0 , this is not done and BIND only listens at the interfaces detected at start-up. Otherwise, the interval can be defined in minutes. The default is sixty minutes.

no prevents other name servers from being informed when changes are made to the zone data or when the name server is restarted.

For a list of available options, read the manual page man 5 named.conf .

32.5.2 Logging #Edit source

What, how, and where logging takes place can be extensively configured in BIND. Normally, the default settings should be sufficient. Example 32.3, “Entry to Disable Logging”, shows the simplest form of such an entry and completely suppresses any logging.

Источник