DNS Bind cheat sheet

All references on the system, i.e. starting, stopping, all reference named and not 'bind'.

Main configuration file is in /etc/named.conf this file does not change very much.

They are stored in /var/named These get edited quite often, with errors going to /var/log/messages unless specified otherwise. In a production environment errors should got to /var/log/named.log (or something similar)

With these requests your server will attempt to find the website in question in its local cache. If it cannot find an answer it will query other DNS servers on your behalf until it finds the address. It will then respond to the original request with the results from each server's query.

With these requests the DNS server will attempt to find the website in question in its local cache. If it cannot find an answer it will not ask other DNS servers but will reply back to the original request with a single “I don't know, but you could try asking this server” message.

By passing the buck you are in less danger of your dns server from being overwhelmed by "amplifier" attacks. Use recursion=yes with caution.

Home routers typically use forwarding to the ISP DNS server.

Normal internet browsing works with the end client computer by sending its local configured DNS server a recursive query. That local server then sends an iterative query to the configured root name servers. What follows is the usual iterative bunch of queries, all carried out by the local server to the next tld server, until the local server queries the authoritative name server that returns the final answer to the local server.

Finally the local server replies to the original recursive query back to the client that wants to browse it that website.

specify the directory where zone files are stored, usually /var/named

directory "/var/named"; // the default

all references to directories in the options section prepend this directory automatically, so the options config section may look odd for the remaining files

Other options that are not being used in OPS335

options
{
dump-file           "data/cache_demp.db";
statistics-file     "data/named_stats.txt";
memstatistics-file  "data/named_mem_stats.txt";

};

This feature was not availble in bind version 4. bind version 9 though uses it, and it is the recommended approach. Also, if there is at least one zone in a "view" section, then ALL zones must be "view" sections.

If named.conf contains no "view" clauses, then all zones are in the default "view" which matches all clients.

This allows for options to be set for groups of zones, as well as different zones to be served to different types of client addressess.

The followin example has three "views", a local host, internal host view, and and external host view.

view "localhost_resolver"     //this sets up named to be a localhost resolver
                              //i.e. caching only nameserver.
{
/* this view sets up named to be a localhost resolver, and any zone
placed in this view will only be seen by the local machine.
*/
          match-clients        {localhost; };
          match-destinations   {localhost; };
          recursion yes;

          # all views must contain the root hints zone:
          include "/etc/named.root.hints";
          include "/etc/named.rfc1912.zones"

rfc1912

these are the root "dots" data, and why all FQDN must end in a dot.

acme.com.      IN  SOA    coyote.acme.com.  admin.coyote.acme.com.  (
@              IN  SOA    coyote.acme.com.  admin.coyote.acme.com.  (

• acme.com. could be shortened to "@"

  More specifically, the @ gets replaced with the $ORIGIN, and the $ORIGIN is deteremined by the second field in the named.conf file, right after "zone"

  For example if the named.conf file has zone "acme.com" then $ORIGIN becomes "acme.com." and @ will be replaced with "acme.com."

• coyote.acme.com. = name of primary (authoritative) name server for acme.com. you could also say coyote.acme.com. if coyote.acme.com. is the authoritative name server for the acme.com. domain
• the root above is the mail address to receive queries about this domain i.e root@acme.com

They allow the DNS server (named) to treat dns queries differently to different DNS requesters. Typically done to differantiate between inside dns queries, where you would want to allow all inside hosts to get the addresses of all other inside hosts, and outside dns queries, where you might only allows MX records, and your web server records, or maybe load balancer. Or maybe not allow any queries at all.

So view clauses are like iptable filters. They define match parameters and a subsequent action. The match parameters are defined for a view. Different match parameters are for different views.

Then within each view section, you can configure named to server up the resource records appropriate for that view. (i.e. those clients that matched)

A view clause matches (is invoked) when either or both of its match-clients and match-destinations statements match and when the match-recursive-only condition is met. If either or both of match-clients and match-destinations are missing they default to any (all hosts match).

All zones supported by each view clause must be defined with the view clause allowing a view to respond uniquely for each zone if required.

The syntax of a view clause is as follows:

view "view_name" [class] {
[ match-clients {  address_match_list } ; ]
[ match-destinations { address_match_list } ; ]
[ match-recursive-only { yes | no } ; ]
// view statements
// zone clauses
};

This is for the machine itself. The host that is running named. It is needed for caching-only nameservers, and caching-only nameserver have ONLY this view. entries in this view include: localhost.localdomain 127.0.0.1

Keep the internal host information secret to the outside wild-west of the internet. It makes it much harder for outside attacks.

view "internal"  
{ 
/*
      this view contains zones to serve to internal clients
      only that connect via direct attached LAN interfaces
      or 'localnets'
*/
          match-clients        {localnets; };
	  match-destinations   {localhost; };
	  recursion yes;
	  // all views must contain the root hints zone:
	  include "/etc/named.root.hints";

	  // include "/etc/named.rfc1912.zones" do NOT server
	  // these to local clients.

       // these are the "authoritative  internal zones, and would
       // probably also be included in the "localhost_resolver" 
       // view above.   That's because it would be odd to resolve
       // requests for the rest of your network, or external hosts,
       // but not be able to resolve them yourself.  therefore
       // whatever domains are listed here should also be listed
       // in localhost_resolver

       zone "my.internal.zone" {   
	     type master;
	     file "my.internal.zone.db";
       };
       zone "my.slave.internal.zone" {
	     type slave;
	     file "slaves/my.slave.intern
	     masters { /* put master names here
       ;
	     // put slave zones in the slaves/ directory so 
	     //named can update them
       };

       zone3 "my.ddns.internal.zone" {
	      type master;
	      allow-update { key ddns_key; };
	      file "slaves/my.ddns.internal.zone.db";
	      // put dynamically updateable zones in the slaves/

       key ddns_key
       {
	      algorithm hmac-md5;
	      secret "use /usr/sbin/dns-keygin to generate TSIG keys";
       };

Note that CentOS sets up the dynamic dns keys in the "internal" view

Host addresess served up here are for outside lookups. Any resource record offered up in responses should be for hardened internet safe servers, or firewalls, or name servers.

view "external"  
{ 
/*
      this view contains zones to serve to external clients
      that have addresses that are NOT on attached LAN interfaces
      or 'localnets'
*/
          match-clients        {any; };
	  match-destinations   {any; };

	  recursion no;
	  // set to no so you do not provide free DNS recursive lookups for
	  // external clients.

	  // 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" {
	        type master;
		file "my.external.zone.db";
	  };
};

   'split' DNS using views
view "trusted" {
 match-clients { 192.168.23.0/24; }; // our network
  recursion yes;
  // other view statements as required
  zone "example.com" {
   type master;
   // private zone file including local hosts
   file "internal/master.example.com";
  };
  // add required zones
 };
view "badguys" {
 match-clients {"any"; }; // all other hosts
 // recursion not supported
 recursion no;
 // other view statements as required
 zone "example.com" {
   type master;
   // public only hosts
   file "external/master.example.com";
  };
  // add required zones
};

One last succinct example:

view "sitea" {
    match-clients {192.168.1.0/24;};
    zone "mydomain.com." IN {
       type slave;
       masters { 192.168.1.100;};
       file "sitea_mydomain.com.db";
    };
    include "/etc/common_zones.conf";
 };

 view "siteb" {
    match-clients {any; };
    zone "mydomain.com." IN {
       type slave;
       masters {192.168.1.100; };
       file "mydomain.com.db";
    };
    include "/etc/common_zones.conf";
 };

Split zones with tsig keys. Slave servers sometimes get the first zone database from the first view. To enusre each view gets the right database transfered, you can use tsig keys?

view viewa {
allow-transfer { key viewa-tsig; }
...
};

view viewb {
allow-transfer { key viewb-tsig; }
...
};

for the master name server, setting up views is not very complicated. for slave servers though things can get dicey. jensd.be has a good explanation:

For a view that has recursion enabled, default is "empty-zones-enable yes;" Recursion enabled is the "buck stops here" mentality. So if the server will takes on the responsibility of answering the query to the end, it is better to have empty zones available to lookup and respond immediately.

For a view that has recursion disabled, default is "empty-zones-enable no;" Recursion disabled is the "pass the buck" mentality. i.e. let the up-wind server decide to answer with its empty zone, or also pass the buck.

But what are empty zones and why is my dns server creating them? They are automatically configured and loaded (for each view) when named starts. The purpose of these zones is to prevent recursive servers from sending meaningless queries to Internet servers that cannot handle them (thus creating delays and SERVFAIL responses to clients who query for them). These empty zones ensure that immediate and authoritative NXDOMAIN responses are returned instead.

The configuration option empty-zones-enable controls whether or not empty zones are created, whilst the option disable-empty-zone can be used in addition to disable one or more empty zones from the list of default prefixes that would be used.

This NS contains the complete data for the zone. To make the DNS tolerant of server and network failures, most zones have two or more authoritative servers, on different networks.

Defines a named IP address match list used for access control. The address match list designates one or more IP addresses (dotted-decimal notation) or IP prefixes (dotted-decimal notation followed with a slash and the number of bits in the netmask). The named IP address match list must be defined by an acl statement before it can be used elsewhere. No forward references are allowed.

Inserts an include file at the point where the include statement is encountered. Use include to break up the configuration into more easily managed chunks.

Specifies a key ID used for authentication and authorization on a particular name server. See the server statement.

Specifies what information the server logs and the destination of log messages

Controls global server configuration options and sets default values for other statements.

Sets designated configuration options associated with a remote name server. Selectively applies options on a per-server basis, rather than to all servers.

Defines a zone. Selectively applies options on a per-zone basis, rather than to all zones.

zone "acme.com" IN { type master; file "acme.com.zone"; allow-update{none; }; };

So acme.com is the domain that needs to be resolved.

There are three types: master these are updated directly. Can be queried slave these are not updated directly, but through zone transfers. Can be queried. hints a very specific thing: "go find me the root servers"

Traditionally can be defined directly in /etc/named.conf The problem is that the zone must be listed in every view that you want the zone to be visible in.

That means if you adminsiter 10 zones, you must list them each at least twice in /etc/named, and make sure that they are both consistent with each other.

Solution: put the zones that you define yourself into a separate file and use the "include" statement

cat /etc/more.zones

   zone "acme.com IN {
     type master;
     file "acme.com.zone";
     allow-update { none; };
};

zone "dude.com" IN {
     type master;
     file "dude.com.zone";
     allow-update { none; };
     allow-transfer { <ipaddr of slave NS>;   };
};


This is a list of additional zones that I administer
Then, still in named.conf you can:

view "localhosts_resolver"
{
xxxxxxxx
xxxxxxxx
   include "/etc/named.root.hints";
   include "/etc/more.zones";
xxxxxxxx
xxxxxxxx
};

view "internal"
{
xxxxxxxx
xxxxxxxx
   include "/etc/named.root.hints";
   include "/etc/more.zones";
xxxxxxxx
xxxxxxxx
};


{

};  

First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:

 [...]

 zone "example.com" {
      type master;
      file "/etc/bind/db.example.com";
      allow-transfer { localhost; ip_secondary; };
 };

 [...]

 zone "1.168.192.in-addr.arpa" {
      type master;
      notify no;
      file "/etc/bind/db.192";
      allow-transfer { localhost;  ip_secondary; };
 };

[...]

Most everthing is the same as the primary, except a few key points. That means we install and run bind and bind-utils, We configure /etc/named.conf and /var/named/zonefiles

Actually for localhost and 0.0.127.in-addr.arpa. it is a primary, so you can just copy those sections from /etc/named.conf from the primary.

The zone files for these are also the same, so just copy those too from the primary.

db.cache should also just be copied. So that is three files:

1. /etc/named.conf
2. /var/named/db-127-0-0
3. /var/named/named.localhost # or whatever your implementation calls this.

Now, edit :

Change every occurance of primary to secondary, except for 0.0.127.in-addr.arpa.

Before the filename on each of these lines, add the ip address of the primary.

You should only have two zone files in var/named db-local-host and db-127-0-0 You have to add a subdirectory for every primary dns server

// We are the master server for example.com
zone "example.com" {
  type master;
  file "example.com.db";
  // IP addresses of slave servers allowed to
  // transfer example.com
  allow-transfer {
   192.168.4.14;
   192.168.5.53;
  };
};
// We are a slave server for eng.example.com
zone "eng.example.com" {
  type slave;
  file "eng.example.com.bk";
  // IP address of eng.example.com master server
  masters { 192.168.4.12; }; 
};

• RRSIG digital resource record signature
• DNSKEY public key
• DS parent-child
• NSEC proof of non-existence
• NSEC3 proof of non-existence
• NSEC3PARAM proof of non-existence
• CDS child-parent signalling
• CDNSKEY child-parent signalling

The details can be read from the docs at this link: bind9.readthedocs.io

Reminding you that a local server will receive a recursive dns query from its clients, then repeatedly issue iterative dns queries to root, tld and authoritative dns servers. The recursive server handles all subsequent queries until the authoritative answer is found. The recursive server is also known as validating resolver

Each iterative query is signed using the private key of the sending server and is checked using its public key by the receiver.

These DNS responses signatures are sent using the RRSIG resource record.

The signatures are created in the following way.

1. Every dns record of message has a hash function applied to get a hash value for the message.
2. This hash is then encrypted using the server's private key.
3. The encrypted hash is the signature.

Checking validity occurs as follows:

1. the message is run through the same hash function by the receiver and the new hash is recorded.
2. the accompanying signature is decrypted using the public key of the sending server.
3. the resulting decrypted hash (signature) is compared to the hash of the computed by the receiver. The hash should match if data has not changed, (integrity intact) and the sender validated (authenticity validated).

Here too the servers involved will sign the data about to be transmitted by the primary dns server for the zone data, before the transfer happens. Then the secondary dns server will confirm that the signature checks out using the primary servers public key.

The public keys are published as part of the zone data and stored in the DNSKEY resource records. The DNSKEY records store the keys. There are the Zone Signing Keys, ZSK, used to protect the zone data, and Key Signing Keys used to sign the zone's keys. If the same key is used for both roles that key is called a Combined Signing Key, CSK.

For the parent-child relationship (primary-secondary dns servers) there are several other records used between them. The DS, CDS, and CDSKEY records. They all use public-private key cryptography to sign and verify signatures between server that do zone transfers.

Spoofed DNS servers could attempt to add bogus DNS responses to queries. So it is important to not just say this data is correct, but also to say, that data does not exist. The resource records NSEC, NSEC3, and NSEC3PARAM records are created for these reasons.

named-checkzone -i full 105.28.172.in-addr.arpa /var/named/slaves/mydb-for-172-28-105

named-checkzone 105.28.172.in-addr.arpa /var/named/slaves/mydb-for-172-28-105

/etc/init.d/named configtest

named-checkconf named-checkconf /etc/named.conf

named-checkzone ZONE_NAME FILE named-checkzone continents.earth.ops /var/named/continents.example.com named-checkzone 10.in-addr.arpa /var/named/named.rev

All zone contents: rndc reload Update earth.ops zone contents rndc reload earth.ops Add new zone file: rdnc reconfig

[user01@centos7 ~]$ while : ; do  echo -n "`date ` : " ; dig google.com | grep ^google.com ; sleep 1 ; done
Wed May 24 20:12:16 JST 2017 : google.com.              164     IN      A       172.217.26.46
Wed May 24 20:12:17 JST 2017 : google.com.              163     IN      A       172.217.26.46
Wed May 24 20:12:18 JST 2017 : google.com.              161     IN      A       172.217.26.46
Wed May 24 20:12:19 JST 2017 : google.com.              160     IN      A       172.217.26.46
Wed May 24 20:12:20 JST 2017 : google.com.              159     IN      A       172.217.26.46
Wed May 24 20:12:21 JST 2017 : google.com. 

Use dig @server lookupthishost

• dig -x 172.28.105.100
• dig vm1.zintis.ops
• dig vm2.zintis.ops
• dig -x +noall +answer 172.28.105.101

for following through non-recursive lookups for each stage (You will see the response from the root servers, . , the .com. servers, and cisco.com. servers. )

• check the fireall (iptables) rules. My VMs did not allow this (host was fine)

But if you are solely looking for the A record, it is simpler to use:

• host vm1.zintis.ops
• host vm2.zintis.ops antarctica
• host vm3.zintis.ops c8
• host vm4.zintis.ops aus
• host c8host.zintis.ops
• host google.com aus
• host 139.177.192.45
• host vm1
• host vm2
• host vm3
• host vm4
• host c8host
• host google.com

man host to see other options, including PTR resource records, and SOA records eg host -t soa zintsi.ops or also, host -t PTR 192.168.111.5

host -t axfr continents.earth.ops or host -t axfr continents.earth.ops australinea

oldest of the three but improved over the years. See man pages for details, or just try nslookup -t SOA continents.earth.ops or just nslookup vm3

• nslookup -querytype=SOA zintis.ops
• nslookup -querytype=PTR 192.168.111.11
• nslookup vm1.zintis.ops
• nslookup vm1.zintis.ops australilnea
• nslookup vm1.zintis.ops australilnea.continents.earth.ops
• nslookup vm2.zinti.ops c8
• nslookup eu c8
• nslookup eu aus
• nslookup eu ant

in /etc/rndc.conf

I took the following right out of interserver.net

If the rndc configuration file /etc/rndc.conf does not exist, the utility will use the key located in /etc/rndc.key, which was generated automatically during the installation process using the rndc-confgen -a command. Rndc configuration file specifies which server controls and what algorithm the server should use. To prevent unauthorized users to the named daemon, BIND uses a shared secret key authentication method to grant privileges to particular hosts. It means that an identical key must be present in the configuration file of bind, /etc/named.conf and configuration file, /etc/rndc.conf.

Rndc uses a TCP connection to communicate with the name server. It sends commands authenticated with digital signatures over a TCP connection. HMAC-MD5 is the authentication algorithm supported in the current versions of rndc and named. This uses a shared secret on each end of the TCP connection. This provides a TSIG-style authentication for the command request and the name servers response.

The rndc configuration file consists of three statements:

1. Option statement
2. Server Statement
3. Key statement

The option statement consists of three clauses default-server clause, default-key clause and default-port clause. The default-server clause is followed by the name or address of the name server. This host is used when a no name server is given as an rndc argument. The default-key clause is followed by the name of a key which is identified by a key statement. This default key will be used for authenticating a server when there is no key clause found in a matching server statement, and no keyid is provided in the rndc command line. The default port clause is followed by the port to connect to the remote name server. This default port will be used when no port option is provided on the rndc command line and no port clause is found in a matching server environment.

The server statement includes two clauses, the key and port. The key name must match the name of a key statement in the file. The server statement consists of a string which is the name server address or the host name of name server.

The key statement starts with the name of the key. It consists of two clauses algorithm and a secret clause. Algorithm identifies the encryption algorithm for rndc, currently HMAC-MD5 is used. Secret clause contains the base-64 encoding of the algorithm encryption key.

Rndc reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.

syntax of rndc takes the following form: –

rndc [option…] command [command-option]

If rndc is invoked with no command-options or arguments, it prints a short summary of the supported commands and the available options and arguments. To display options of rndc command use #rndc

Commands used in rndc are: –

.halt -It is used to stop the named service.

.querylog -logs all queries made to the name server.

.refresh -used to refreshes name server database.

.reload -reloades the zone file.

.stats -dumps the current named stats to the /var/named/named.stats file

.stop -stops the server gracefully.

Options of rndc includes: –

-c <configuration file> -specifies the alternate location of a configuration file.

-p <port number> -Specifies a port number to use rndc other than port 953.

-s <server> -specifies a server other than default- server listed in /etc/rndc.conf file.

-y <key name> -specifies a key other than default-key option in the /etc/rndc.conf file.

To reload the server, use command

#rndc reload

Limitations of rndc: –

1. rndc does not yet support all the commands of the BIND 8 ndc utility.
2. There is currently no way to provide the shared secret for a key_id without using the configuration file.
3. Several error messages could be clearer.