DNS Sample BIND Configurations - Об ОС *Nix - Системное администрирование - Каталог статей - Архив документации и мануалов для админов

Вторник, 06.12.2016, 02:47
Приветствую Вас Гость | RSS
Мой сайт
Главная
Регистрация
Вход
Форма входа

Меню сайта

Категории раздела
Об ОС Windows [137]
В категории размещаются статьи, касающщиеся операционных систем от Microsoft.
Об ОС *Nix [198]
В данной категории собраны статьи об ОС семейства Unix/Linux/FreeBSD/...
Справочные материалы [351]
Справка по всему разделу.
Виртуализация и Облака [46]
Networks & Routing [86]
DataBases [22]

Наш опрос
Оцените мой сайт
Всего ответов: 193

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Главная » Статьи » Системное администрирование » Об ОС *Nix

DNS Sample BIND Configurations

6. DNS Sample BIND Configurations

This chapter provides a number of BIND configuration samples.

Running any DNS server that does not require to support recursive queries for external users (an Open DNS) is a bad idea. While it may look like a friendly and neighbourly thing to do it carries with it a possible threat from DDoS attacks and an increased risk of cache poisoning. The various configurations have been modified to reflect this.

6.1 Sample BIND Configuration Overview

This chapter provides sample configurations and descriptions for each of the DNS types previously described. A BIND systems consists of the following parts:

  1. A named.conf file describing the functionality of the BIND system. The entries in this file are fully described.
  2. Depending on the configuration one or more zone files describing the domains being managed. The entries in zone files are fully described. Zone files contain Resource Records which are fully described.
  3. Depending on the configuration one or more required zone files describing the 'localhost' and root name servers.

Many BIND/DNS configurations are schizophrenic in nature - they may be 'masters' for some zones, 'slaves' for others, forward others and provide caching services for all comers. Where possible we cover alternate configurations or at least note the alternate configurations.

There are many in the DNS world who say that mixing DNS functionality in a single instance of BIND is a Very Bad Idea™ and leads to increased security risks. Such folks tend to get especially vocal about mixing ANY master or slave zones with caching (recursive) services. Such blanket advice overlooks pragmatic considerations. In a high volume DNS scenario it is both crazy and dangerous to run anything other than an authoritative only server (with no caching/recursive support). When small or modest volume DNS servers are used, and provided that the DNS is CLOSED, the modest increase in security threat is usually more than offset by operational benefits.

All the configuration files are deliberately kept simple - links are provided to the various sections that will describe more advanced parameters as appropriate. Comments are included in the files to describe functionality. The configuration used throughout is:

  1. Two name servers are used one internal (ns1) and one external (ns2) to the domain
  2. The mail service is external to the domain (provided by a third party)
  3. FTP and WWW services are provided by the same host
  4. There are two hosts named bill and fred
  5. The host address are all in the class C private address range 192.168.0.0 (a slightly artificial case)

up icon

6.1.1 Zone File Naming Convention

Everyone has their own ideas on a good naming convention and thus something that is supposed to be useful becomes contentious.

Here is a convention that is in daily use. Its sole merits are; it is a convention; it makes sense to its authors.

  1. All zone files are placed in /var/named/ (for Windows users this would be %systemroot%\system32\drivers\etc). The base directory contains all the housekeeping zone files (e.g. localhost, reverse-mapping, root.servers etc.) with a subdirectory structure used as follows:

    1. /var/named/master - master zone files
    2. /var/named/slave - slave zones files
    3. /var/named/views - where views are used
  2. master files are named master.example.com (or master.example.net etc.) if its a sub-domain it will be master.sub-domain.example.com etc.

  3. slave zone files are named slave.example.com (or slave.example.ca etc.) if its a sub-domain it will be slave.sub-domain.example.com etc.

  4. The root server zone file is called root.servers (typically called named.ca or named.root in BIND distributions).

  5. The reverse mapping file name uses the subnet number and .rev i.e.. if the zone is '23.168.192.IN-ADDR.ARPA' the file is called 192.168.23.rev to save having to reverse the digits at 3AM in a blind panic.

  6. The 'localhost' zone file is called master.localhost (typically called localhost.zone on BIND distributions). The reverse mapping file is called localhost.rev (typically called named.local in BIND distributions).

Note: For most Linux distributions you have a small overhead at the beginning to rename the supplied files but the author considers it worthwhile in the long run to avoid confusion.

Final point on this topic: Whatever your convention be rigorous in its application!

up icon

6.2 Master (Primary) DNS Server

The functionality of the master name server was previously described.

Master Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. 'master' DNS for example.com
  2. provides 'caching' services for all other domains
  3. provides recursive query services to local resolvers only (a closed DNS - note in configuration file shows how to Open the server if required)

The BIND 'named.conf' is as follows (click to look at any file):

// MASTER & CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "get lost";
 // optional - disables all transfers 
 // slaves allowed in zone clauses
 allow-transfer {"none";};
 // Closed DNS - permits only local IPs to issue recursive queries 
 // remove if an Open DNS required to support all users 
 // or add additional ranges 
 allow-recursion {192.168.3.0/24;};
};
//
// log to /var/log/named/example.log all events from 
// info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog) 
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// required zone for recursive queries
zone "." {
 type hint;
 file "root.servers";
};
zone "example.com" in{
 type master;
 file "master/master.example.com";
 // enable slaves only
 allow-transfer {192.168.23.1;192.168.23.2;);
};
// required local host domain
zone "localhost" in{
 type master;
 file "master.localhost";
 allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
};
// reverse map for class C 192.168.0.0
zone "0.168.192.IN-ADDR.ARPA" in{
 type master;
 file "192.168.0.rev";
};

up icon

6.3 Slave (Secondary) DNS Server

The functionality of the slave name server was previously described.

Slave Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. 'slave' DNS for example.com
  2. provides 'caching' services for all other domains
  3. provides recursive query services to local resolvers only (a closed DNS - note in configuration file shows how to Open the server if required)

Note: Since we are defining the slave the alternate sample file is used throughout this example configuration with all servers being internal to the domain.

The BIND 'named.conf' is as follows (click to look at any file):

// SLAVE & CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "not currently available";
 // allows notifies only from master
 allow-notify {192.168.0.1};
 // disables all zone transfer requests
 allow-transfer{"none"};
 // Closed DNS - permits only local IPs to issue recursive queries 
 // remove if an Open DNS required to support all users 
 // or add additional ranges 
 allow-recursion {192.168.3.0/24;};
};
//
// log to /var/log//named/example.log all events 
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// required zone for recursive queries
zone "." {
 type hint;
 file "root.servers";
};
// see notes below
zone "example.com" in{
 type slave;
 file "slave/slave.example.com";
 masters {192.168.0.1;};
};
// required local host domain
zone "localhost" in{
 type master;
 file "pri.localhost";
 allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
};
// reverse map for class C 192.168.0.0 (see notes)
zone "0.168.192.IN-ADDR.ARPA" IN {
 type slave;
 file "sec.192.168.0.rev";
 masters {192.168.0.1;};
};

Notes:

  1. The slave zone file 'slave/slave.example.com' is optional and allows storage of the current records - minimising load when named is restarted. To create this file initially just open and save an empty file. BIND will complain the first time it loads but not thereafter.
  2. The reverse map for the network (zone 0.168.192.IN-ADDR.ARPA) is defined as a slave for administrative convenience - you need to maintain only one copy - but it could be defined as a 'master' with a standard reverse map format.
  3. A single 'masters' IP address is used specifying ns1.example.com.

up icon

6.4 Caching Only DNS Server

The functionality of the Caching Only name server was previously described.

Caching Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. The name server is not a 'master' or 'slave' for any domain
  2. provides 'caching' services for all domains
  3. provides query services to local resolvers only (a closed DNS - note in configuration file shows how to Open the server if required)

The BIND 'named.conf' is as follows (click to look at any file):

// CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "not currently available";
 // disables all zone transfer requests
 allow-transfer{"none";};
 // Closed DNS - permits only local IPs to issue queries 
 // remove if an Open DNS required to support all users 
 // or add additional IP ranges 
 // in this case either allow-query or allow-recursion can be used
 allow-query {192.168.3.0/24;};
};
//
// log to /var/log/example.log all events 
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// required zone for recursive queries
zone "." {
 type hint;
 file "root.servers";
};
// required local host domain
zone "localhost" in{
 type master;
 file "master.localhost";
 allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
};

Notes:

  1. The Caching only name server contains no zones (other than 'localhost') with 'master' or 'slave' types.
  2. The reverse map zone has been omitted since it assumed that an external body (ISP etc) has the master domain DNS and is therefore also responsible for the reverse map. It could be added if required for local operational reasons.

up icon

6.5 Forwarding (a.k.a. Proxy, Client, Remote) DNS Server

The functionality of the Forwarding name server was previously described.

Forwarding Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. The name server is not a 'master' or 'slave' for any domain
  2. provides 'caching' services for all domains
  3. forwards all queries to a remote DNS from all local resolvers (Global forwarding)
  4. limits query services to local resolvers only - this statement is designed to limit forwarding which both negates the effect of the forwarding server by increasing traffic loads and passes the bogus requests to the remote DNS potentially causing a DoS/DDos attack.

The BIND 'named.conf' is as follows (click to look at any file):

// FORWARDING & CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "not currently available";
 forwarders {10.0.0.1; 10.0.0.2;};
 forward only;
 // disables all zone transfer requests
 allow-transfer{"none";};
 // Closed DNS - permits only local IPs to issue queries 
 // remove if an Open DNS required to support all users 
 // or add additional IP ranges 
 // in this case either allow-query or allow-recursion can be used
 allow-query {192.168.3.0/24;};
};
// log to /var/log/example.log all events from
// info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// required local host domain
zone "localhost" in{
 type master;
 file "pri.localhost";
 allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
};

Notes:

  1. The Forwarding name server typically contains no zones (other than 'localhost') with 'master' or 'slave' types.
  2. The reverse map zone has been omitted since it assumed that an external body (ISP etc) has the master domain DNS and is therefore also responsible for the reverse map. It could be added if required for local operational reasons.
  3. The forward option must be used in conjunction with a forwarders option. The value 'only' will override 'recursive query' behaviour.
  4. Since all queries are forwarded the root servers zone ('type hint') can be omitted.
  5. Forwarding can be done on a zone basis in which case the values defined override the global options.

up icon

6.6 Stealth (a.k.a. Split or DMZ) DNS Server

The functionality of the Stealth name server was previously described. The following diagram illustrates the conceptual view of a Stealth (a.k.a. Split) DNS server system.

Split (Stealth) Server configuration

Figure 6.1 Split/Stealth Server configuration

The key issue in a 'Stealth' (a.k.a. Split) DNS system is that there is a clear line of demarcation between the 'Internal' Stealth server(s) and the 'External' or Public DNS servers(s). The primary difference in configuration is the 'Stealth' Servers will provide a comprehensive set of services to internal users to include caching and recursive queries and would be configured as a typical Master DNS, while the External server may provide limited services and would typically be configured as an Authoritative Only DNS server.

There are two critical points:

  1. The zone file for the 'Stealth' server will contain both public and private hosts, whereas the 'Public' server's master zone file will contain only public hosts.

  2. To preserve the 'Stealth' nature it is vital that the PUBLIC DNS configuration does not include options such as 'master', 'allow-notify','allow-transfer', etc. with references to the IP of the 'Stealth' server. If the Stealth servers IP where to appear in the Public DNS server and its file system were to be compromised the attacker could gain more knowledge about the organisation - they can penetrated the 'veil of privacy' by simply inspecting the 'named.conf file.

    There are a number of articles which suggest that the view statement may be used to provide similar functionality using a single server. This does not address the problem of the DNS host system being compromised and by simple 'named.conf' file inspection additional data about the organisation being discovered. In a secure environment 'view' does not provide a 'Stealth DNS' solution if there is any possibility that a filesystem compromise can happen.

up icon

6.7 Authoritative Only DNS Server

The functionality of the Authoritative name server was previously described. If security is not the primary requirement then the view statement may be used to provide 'Authoritative only' services to external users and more comprehensive services to internal users.

The configuration examples shown for authoritative only DNS servers all show the zones as being type master;. Thus if two (or more) DNS servers are being used the master zone files would have to be made available separately to all the servers by an out-of-band process (using, say, SFTP). In general this is the safest configuration. In situations where the zone files are highly dynamic, practical considerations may require that one or all of the zones be slaved from a single source. Zone transfer operations use TCP and are thus vulnerable to a new set of security and DoS threats. Avoid this configuration if possible, if not, as minimum secure the transfers with allow-transfer statements in the master zone clause and it may be worth considering use of TSIG to authenticate zone transfers.

An example configuration is shown below.

Authoritative Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. 'master' DNS for example.com
  2. does NOT provide 'caching' services for any other domains
  3. does NOT provide recursive query services for all resolvers (Iterative only)
  4. optimised for maximum performance

The BIND 'named.conf' is as follows (click to look at any file):

// AUTHORITATIVE ONLY NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "not currently available";
 // disable all recursion - authoritative only
 recursion no;
 // disables all zone transfer requests in this case 
 // for performance not security reasons
 allow-transfer{none;};
};
//
// log to /var/log/example.log all events
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
zone "example.com" in{
 type master;
 file "master/master.example.com";
};
// reverse map for class C 192.168.0.0
zone "0.168.192.IN-ADDR.ARPA" in{
 type master;
 file "192.168.0.rev";
};
// required local host domain
zone "localhost" in{
 type master;
 file "master.localhost";
 allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
};

Notes:

  1. The reverse mapping zone (zone "0.168.192.IN-ADDR.ARPA" ) was originally omitted from this server - given the use of reverse look-up by anti-spam systems we have restored the reverse look-up zone. It would - in a perfect world without spam - typically not be present on a performance oriented server.

BIND provides three more parameters to control caching ,max-cache-size and max-cache-ttl neither of which will have much effect on performance in the above case and allow-recursion which uses a list of hosts that are permitted to use recursion (all others are not) - a kind of poor man's 'view'.

up icon

6.8 View based Authoritative Only DNS Server

The functionality of the Authoritative name server was previously described. If security is not the primary requirement then the view clause may be used to provide 'Authoritative only' services to external users and more comprehensive services to internal users.

View based Authoritative Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

  1. 'master' DNS for example.com
  2. does NOT provide 'caching' services for any external users
  3. does NOT provide recursive query services for any external resolvers (Iterative only)
  4. provides 'caching' services for internal users
  5. provides recursive query services for internal users

The BIND 'named.conf' is as follows (click to look at any file):

// VIEW BASED AUTHORITATIVE ONLY NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
// global options
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "not currently available";
};
//
// log to /var/log/example.log all events
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// provide recursive queries and caching for internal users
view "goodguys" {
 match-clients { 192.168.0.0/24; }; // our network
 recursion yes;
 // required zone for recursive queries
 zone "." {
 type hint;
 file "root.servers";
 };
 zone "example.com" {
 type master;
 // private zone file including local hosts
 file "view/master.example.com.internal";
 };
 // required local host domain
 zone "localhost" in{
 type master;
 file "master.localhost";
 allow-update{none;};
 };
 // localhost reverse map
 zone "0.0.127.in-addr.arpa" in{
 type master;
 file "localhost.rev";
 allow-update{none;};
 };
}; // end view

// external hosts view
view "badguys" {
 match-clients {"any"; }; // all other hosts
 // recursion not supported
 recursion no;
 zone "example.com" {
 type master;
 // only public hosts
 file "view/master.example.com.external";
 };
}; // end view

Notes:

  1. All the required zones must be declared in each view.
  2. The 'goodguys' view contains the root.servers, 'localhost' and reverse mapping file.
  3. The 'badguys' view contains only the required zone files for which we will answer authoritatively.
  4. The 'badguys' view may contain an edited version of the reverse map file.

up icon

6.9 Split Horizon using view clause

The functionality of the Split Horizon DNS was previously described. The view clause may be used to return different IP addresses to provide, say, geographically dispersed users with minimum access latency or even a level of load-balancing if you understand the service source-ip access profile (in this case the source-ip ranges in the example would be based on some analysis of incoming traffic not just geographic location).

View based Split Horizon

The BIND DNS configuration provides the following functionality:

  1. Assume we want geographic users to get the lowest possible latency from a web service with a name of www.example.com
  2. Assume we have a single worldwide email server called mail.example.com
  3. Assume addresses 172.16.x.x originate in Mordor and we want them to be serviced by a local web server (172.16.1.1) we have installed in that land.
  4. Assume addresses 172.15.x.x and 172.14.x.x originate in Gondor and we want them to be serviced by a local web server (17.15.1.1) we have installed in that land.
  5. All other originations will default to a www.example.com at 192.168.1.2
  6. For simplicity we assume an authoritative only server is being configured.

The BIND 'named.conf' is as follows (click to look at any file):

// VIEW BASED GEOGRAPHIC DNS SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2009 - did something
// 2. 16 july 2009 - did something else
// 3. 23 july 2009 - did something more
//
// global options
options {
 directory "/var/named";
 // version statement - inhibited for security
 // (avoids hacking any known weaknesses) 
 version "Name is Bind, James Bind";
 // authors note: No idea who came up with the clever text but if you email 
 // we'd be more than happy to credit it you - you deserve it
 allow-update{none;}; // defaulted if not present
 recursion no; // authoritative only
};
//
// log to /var/log/example.log all events
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
 logging{
 channel example_log{
 file "/var/log/named/example.log" versions 3 size 2m;
 severity info;
 print-severity yes;
 print-time yes;
 print-category yes;
 };
 category default{
 example_log;
 };
};
// map service to geographic origination
view "gondor" {
 match-clients { 172.15/16; 172.14/16; }; // originate in gondor
 zone "example.com" {
 type master;
 // zone file will return www.example.com = 172.15.1.1
 file "view/master.example.com.gondor";
 };
}; // end view

view "mordor" {
 match-clients { 172.16/16; }; // originate in mordor
 zone "example.com" {
 type master;
 // zone file will return www.example.com = 172.16.1.1
 file "view/master.example.com.mordor";
 };
}; // end view

// default for everything else lies outside views
 zone "example.com" {
 type master;
 // zone file will return www.example.com with default (worldwide) IP
 file "view/master.example.com.default";
 };

Notes:

  1. All the required zones must be declared in each view.
  2. For simplicity of configuration an authoritative only server is assumed and therefore contains no root.servers, 'localhost' or reverse mapping files.
  3. The 'mordor' and 'gondor' view zone files map to a geographically local server.
  4. Queries that do not satisfy the match-clients statements fall through to use the default (outside views clause) zone file. If it is more understandable the default zone could have been wrapped in a view clause with a name of, say, "default" using a match-clients { any; }; statement as shown:
    // default for everything else lies in a default view
    view "default"
     match-clients { "any"; }; // must be in the last clause
     zone "example.com" {
     type master;
     // zone file will return www.example.com with default (worldwide) IP
     file "view/master.example.com.default";
     };
    };
    
  5. The configuration uses the only the match-clients statement. Two other statements, match-destination and match-recursive-only, neither of which is applicable in the example, may also be used to select which view is used.


DNS Sample External Domain Zone file

This file shows only hosts (services) which are externally (publicly) visible and may be used with a views 'View based Authoritative Only' server or in a 'public' server in a Stealth configuration - all internal hosts are excluded. The internal view version is here. The configuration provides:

  1. Two name servers are used one internal (ns1) and one external (ns2) to the domain
  2. The mail service is external to the domain (provided by a third party)
  3. FTP and WWW services are provided by the same host
  4. The host addresses are all in the class C private address range 192.168.0.0 (a slightly artificial case)

The Resource Records are all defined separately.

$TTL 86400 ; 24 hours could have been written as 24h or 1d
$ORIGIN example.com.
@ 1D IN SOA ns1.example.com. hostmaster.example.com. (
 2002022401 ; serial
 3H ; refresh
 15 ; retry
 1w ; expire
 3h ; minimum
 )
 IN NS ns1.example.com. ; in the domain
 IN NS ns2.smokeyjoe.com. ; external to domain
 IN MX 10 mail.another.com. ; external mail provider
; server host definitions
ns1 IN A 192.168.0.1 ;name server definition 
www IN A 192.168.0.2 ;web server definition
ftp IN CNAME www.example.com. ;ftp server definition


source: http://www.zytrax.com/books/dns/ch6/mydomain-external.html


Chapter 8. DNS Resource Records

DNS resource records (RRs) describe the characteristics of a zone (or domain) and have a binary or wire-format, which is used in queries and responses, and a text format used in zone files and which is described in this chapter.

Contents

Zone File Format
DNS Generic Record Formats

DNS Record Types

A full list of DNS Record Types may be obtained from IANA DNS Parameters.

RR Value RFC Description
A 1 RFC 1035 IPv4 Address record. An IPv4 address for a host.
AAAA 28 RFC 3596 IPv6 Address record. An IPv6 address for a host. Current IETF recommendation for IPv6 forward-mapped zones.
A6 38 RFC 2874 Experimental. Forward mapping of IPv6 addresses. An IP address for a host within the zone.
AFSDB 18 RFC 1183 Location of AFS servers. Experimental - special apps only.
CNAME 5 RFC 1035 Canonical Name. An alias name for a host.
DNAME 39 RFC 2672 Experimental. Delegation of reverse addresses (primarily IPv6).
DNSKEY 48 RFC 4034 DNSSEC.bis. DNS public key RR.
DS 43 RFC 4034 DNSSEC.bis. Delegated Signer RR.
HINFO 13 RFC 1035 Host Information - optional text data about a host.
ISDN 20 RFC 1183 ISDN address. Experimental = special applications only.
KEY 25 RFC 2535 Public key associated with a DNS name.
LOC 29 RFC 1876 Stores GPS data. Experimental - widely used.
MX 15 RFC 1035 Mail Exchanger. A preference value and the host name for a mail server/exchanger that will service this zone. RFC 974 defines valid names.
NAPTR 35 RFC 3403 Naming Authority Pointer Record. Gross misnomer. General purpose definition of rule set to be used by applications e.g. VoIP
NS 2 RFC 1035 Name Server. Defines the authoritative name server(s) for the domain (defined by the SOA record) or the subdomain.
NSEC 47 RFC 4034 DNSSEC.bis. Next Secure record. Ssed to provide proof of non-existence of a name.
NXT 30
DNSSEC Next Domain record type. Obsolete use NSEC.
PTR 12 RFC 1035 IP address (IPv4 or IPv6) to host. Used in reverse maps.
RP 17 RFC 1183 Information about responsible person. Experimental - special apps only.
RRSIG 46 RFC 4034 DNSSEC.bis. Signed RRset.
RT 21 RFC 1183 Through-route binding. Experimental - special apps only.
SIG 24 RFC 2931//2535 DNSSEC. Obsolete use RRSIG. SIG(0) is used as a special meta RR in DDNS and zone transfer security.
SOA 6 RFC 1035 Start of Authority. Defines the zone name, an e-mail contact and various time and refresh values applicable to the zone.
SPF 99 RFC 4408 Sender Policy Framework (v1). Defines the servers which are authorized to send mail for a domain. Its primary function is to prevent identity theft by spammers.
SRV 33 RFC 2872 Defines services available in the zone, for example, ldap, http etc..
TXT 16 RFC 1035 Text information associated with a name. The SPF record should be defined using a TXT record and may (as of April 2006) be defined using an SPF RR. DKIM (RFC 4871 also makes use of the TXT RR for authenticaing email. How to define DKIM/ADSP RRs.
WKS 11 RFC 1035 Well Known Services. Deprecated in favour of SRV.
X25 19 RFC 1183 X.25 address. Experimental - special apps only.

Zone File Directives

$ORIGIN
$INCLUDE
$TTL
$GENERATE (non-standard BIND only)

Zone File Format

The DNS system defines a number of Resource Records (RRs). The text representation of these records are stored in zone files.

Zone file example

; zone file for example.com
$TTL 2d ; 172800 secs default TTL for zone
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
 2003080800 ; se = serial number
 12h ; ref = refresh
 15m ; ret = update retry
 3w ; ex = expiry
 3h ; min = minimum
 )
 IN NS ns1.example.com.
 IN MX 10 mail.example.net.
joe IN A 192.168.254.3
www IN CNAME joe 

The above example shows a very simple but fairly normal zone file. The following notes apply to zone files:

  1. Zone files consist of Comments, Directives and Resource Records
  2. Comments start with ';' (semicolon) and are assumed to continue to the end of the line. Comments can occupy a whole line or part of a line as shown in the above example.
  3. Directives start with '$' and are standardized - $ORIGIN and $INCLUDE (defined in RFC 1035) and $TTL (defined in RFC 2308). BIND additionally provides the non-standard $GENERATE directive.
  4. There are a number of Resource Record (RR) types defined in RFC 1035 and augmented by subsequent RFCs.
  5. The $TTL directive should be present and appear before the first RR (RFC 2308 implemented in BIND 9).
  6. The first Resource Record must be the SOA (Start of Authority) record. The generic format is described below.

up icon

DNS Generic Record Format

Resource Records have two representations. A textual format described in this chapter and a binary or wire-format described in Chapter 15.

The textual format has the following generic form:

name ttl class type type-specific-data

Where:

name The name (or label) of the node in the zone file to which this record belongs. The name field may also take one of the following values:
@
; replace with the current value of $ORIGIN
 
; blank/space or tab in which case the last name used or the value of $ORIGIN (or its default value) is substituted
ttl 32 bit value. The Time to Live in seconds (range is 1 to 2147483647) and indicates how long the RR may be cached. The value zero indicates the data should not be cached.
class A 16 bit value which defines the protocol family or an instance of the protocol. The normal value is IN = Internet protocol (other values are HS and CH both historic MIT protocols).
types The resource record type which determines the value(s) of the type-specific-data field. Type takes one of the values below.
type-specific-data Data content of each record is defined by the type and class values.

The generic binary or wire-format is:

name ttl class type rdlen rdata

The binary format is described in chapter 15 RR format

up icon

DNS Zone File Directives

Directives start with '$' and are standardized - $ORIGIN and $INCLUDE (defined in RFC 1305) and $TTL (defined in RFC 2308). BIND additionally provides the non-standard $GENERATE directive.

Directive Description
$INCLUDE Includes the defined file in-line.
$ORIGIN Defines the base name (aka label) to be used for 'unqualified' name substitution.
$TTL Defines the default Resource Record TTL value, used if no TTL is defined in a resource record.

DNS Sample Domain Zone file

This file (pri.example.com) is the standard sample zone file used throughout this Chapter and has the following characteristics. NOTE: Both externally visible (public) services and internal hosts are defined in this file.

  1. Two name servers are used one internal (ns1) and one external (ns2) to the domain
  2. The mail service is external to the domain (provided by a third party)
  3. FTP and WWW services are provided by the same host
  4. There are two hosts named bill and fred
  5. The host addresses are all in the class C private address range 192.168.0.0 (a slightly artificial case)

The Resource Records are all defined separately.

$TTL 86400 ; 24 hours could have been written as 24h or 1d $ORIGIN example.com. @ 1D IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 ; serial 3H ; refresh 15 ; retry 1w ; expire 3h ; minimum ) IN NS ns1.example.com. ; in the domain IN NS ns2.smokeyjoe.com. ; external to domain IN MX 10 mail.another.com. ; external mail provider ; server host definitions ns1 IN A 192.168.0.1 ;name server definition www IN A 192.168.0.2 ;web server definition ftp IN CNAME www.example.com. ;ftp server definition ; non server domain hosts bill IN A 192.168.0.3 fred IN A 192.168.0.4

An alternate file including only hosts externally visible to the domain is also provided. The CNAME Resource Record allow the 'www' server to provide additional services. The associated reverse map zone file is provided.



Источник: http://www.zytrax.com/books/dns/ch6/
Категория: Об ОС *Nix | Добавил: admin (08.08.2011)
Просмотров: 1166 | Комментарии: 1 | Теги: configurations, dns, config, bind | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2016