DNS是什麼大家已經很清楚了，就不多做累述了。
一、DNS解析過程
1.1 DNS解析的順序
linux進行DNS解析的順序，先查找/etc/hosts檔案，如果沒有再通過配置/etc/resolv.conf裡面設定的DNS伺服器進行DNS解析。
Centos6的檔案設定：
# cat /etc/nsswitch.conf |grep hosts #在Centos6裡/etc/nsswitch.conf裡面指定本地解析順序的，這裡隻有兩個files指本地的/etc/hosts檔案，然後是/etc/resolv.conf裡面定義的dns服務進行解析。
#hosts: db files nisplus nis dns
hosts: files dns
Centos7的檔案設定：
# cat /etc/nsswitch.conf |grep hosts #在Centos7裡/etc/nsswitch.conf裡多了一個myhostname，就是多了一個本地主機名的解析，如果你的主機名是自定義的，你直接ping自己的主機名是可以通過。
#hosts: db files nisplus nis dns
hosts: files dns myhostname
1.2 /etc/resolv.conf裡面的設定
首先介紹一下DNS解析的逾時時間：
# cat /etc/resolv.conf
nameserver 114.114.114.114
nameserver 223.6.6.6
#我們一般都會設定兩個DNS解析伺服器，預設情況下當第一個解析出現問題的時候會讓第二個DNS解析伺服器負責解析。第一次預設是五秒。
#由上圖可以看出，就以三個DNS來解釋一下公式，第一次都是5S按順序嘗試下次，然後第二次就是逾時時間會增加到10秒,公式是10（這個是第二次是10秒）/3（這個DNS伺服器設定的數量）=3(取整，後面的小數部分不要)。
然後就是5*3+3*3=24秒。兩台DNS伺服器設定就是5*2+5*2=20秒，一台就是5*1+10*1=15秒。這個可以将自己/etc/resolv.conf裡面設定兩個錯誤不能進行DNS解析的namserver，然後# time dig www.baidu.com測試一下。
然後就引出了options指令：
# cat /etc/resolv.conf #一般一個正常的DNS解析過程應該是在一秒之内，然後你可能覺得設定兩個DNS解析伺服器結果出問題了等待回報的時間有點長，可以用options timeout:2将預設逾時時間從5秒改為2秒。
nameserver 114.114.114.114
nameserver 223.5.5.5
options timeout:2
1.3 域的劃分
DQDN(完全合格域名)：根域+頂級域+二級域+子域+主機名，例如:www.baidu.com.，整個域名空間是一個倒置的樹形結構。
根域：所有域的最頂端，管理者頂級域，現在全球有十三個根域。域名就是一個點号“.”。
頂級域：也稱為一級域：.com（商業組織）、mil（軍事部門）、.net（通常是提供網絡基礎設施的組織）、org（通常是非盈利組織）、.edu（教育）、.gov（政府）等常見的國際頂級域。還有國家頂級域：.cn、.ck等。
二級域或者次級域：網站使用者在頂級域中注冊使用的域名，如baidu.com、sina.cn
子域：在二級域中可以授權多個子域并且可以設定多級子域，如:www.baidu.com這就是一級子域。如：web.mail.51niux.com，這就是一個二級子域，是mail.51niux.com的子域。（web就類似于主機名加上後面的mail.51niux.com域就是一個完整的域名，指向了此域名主機所在的位置。）
反向域：arpa，FQDN<--IP，通過IP反向解析出域名，這也算一個頂級域。
1.4 DNS伺服器解析過程
# dig +trace www.baidu.com #dig指令是我們經常用到的一個指令，這是追蹤一個域名的解析過程
Bash
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> +trace #dig的版本然後後面是跟的指令參數，追蹤www.baidu.com的解析過程 ;; global options: +cmd #下面可以看到第一列都是.，下面就是獲得了13個根域的IP和主機名。. 18113 IN NS e.root-servers.net.. 18113 IN NS g.root-servers.net.. 18113 IN NS m.root-servers.net.. 18113 IN NS j.root-servers.net.. 18113 IN NS l.root-servers.net.. 18113 IN NS c.root-servers.net.. 18113 IN NS b.root-servers.net.. 18113 IN NS k.root-servers.net.. 18113 IN NS a.root-servers.net.. 18113 IN NS d.root-servers.net.. 18113 IN NS h.root-servers.net.. 18113 IN NS f.root-servers.net.. 18113 IN NS i.root-servers.net.;; Received 811 bytes from 114.114.114.114#53(114.114.114.114) in 39 ms #114.114.114.114就是我們設定的DNS伺服器，為我們傳回來13個根域所在的位置。com. 172800 IN NS a.gtld-servers.net. #這裡就是向其中一台根域伺服器發送www.baidu.com的解析請求，根域将.com頂級域的IP（未顯示）和名稱告訴了我們。com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20170618050000 20170605040000 14796 . GkB03B/beJHmV1RNk7C+cWtEK4kHex9DQ/yFdB+N0RRu1KdPL/fGCHon eeQInXxzSiF10WPv+w+BYIJXzN5zULaP8M6SieW+59aZbDcDVqxh7BNB Z1yBZRlvJHu5ILnkcfaZM8HrGj6tZRd3ozygjoR7M9lSFV55aNiYMWyR hfL2cMfN1w7+149wWjngFkNgSopOVCBvM6nUlxuDjw2GQktW8R8JThJQ RRN9VZ0WLeTAY9o0KzCXmoax2GSkb1PDLOYdS8G0nnaRs+Btrbk6u4cf oBXJdx770EckaxhIWA8goAMT/rmOyCAparYQwDmq1exU/vWFDfb1fiRn 4NXj+Q==;; Received 865 bytes from 198.97.190.53#53(h.root-servers.net) in 291 ms #h.root-servers.net這個主機為我們傳回了上面的com.域的主機位置baidu.com. 172800 IN NS dns.baidu.com. #第三步，向com.域的一台伺服器請求www.baidu.com的解析，它為我們傳回了百度的五台SOA域伺服器，也就是百度自己的DNS伺服器。baidu.com. 172800 IN NS ns2.baidu.com.
baidu.com. 172800 IN NS ns3.baidu.com.
baidu.com. 172800 IN NS ns4.baidu.com.
baidu.com. 172800 IN NS ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20170610044750 20170603033750 27302 com. qtstB1qc43bHTc7TaTpoQf+0utzHITmvowD2CchY6qd546A00m3bnJf0 jof3C9kARs52DjVlJinbVbDL1eIa2UO/UVt0WOf9gyBkKbG3qRGWGu6N d6Y4GbgoSb/vRcyohpD15lqVcnFdhDPNVe9wsHBmFICe/lJG3d0RInbr RME=HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HQ01I3PFSK4TG3Q31LT3RIMHGBFQU42T NS DS RRSIG
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20170612044853 20170605033853 27302 com. iwBbO4jBbQE91G75HiBDuMChoQbYKugUF1SGTbRxmgUYdfm7GHyhhM7e 4MpiGF+3mXDrbg8AcyeIu8qE+OV5ir5ytKw7/r2gJj7E4s/780brQSLW owNK4jifzcbMFXyoMrR1xC6bnzCQyeEJ1nObglzLMA8R1Ime4gpyPCDh 4pw=;; Received 697 bytes from 192.48.79.30#53(j.gtld-servers.net) in 301 ms #j.gtld-servers.net這個com.域主機為我們傳回了上面五個百度SOA域伺服器所在的位置。www.baidu.com. 1200 IN CNAME www.a.shifen.com. #向上面提供的域主機發起了www.baidu.com的解析請求，為我們傳回了一個www的CNAME别名，别名是www.a.shifen.com。按照一般邏輯，當DNS請求到别名的時候查詢會終止，而是重新發起查詢别名的請求。 a.shifen.com. 1200 IN NS ns2.a.shifen.com.
a.shifen.com. 1200 IN NS ns4.a.shifen.com.
a.shifen.com. 1200 IN NS ns5.a.shifen.com.
a.shifen.com. 1200 IN NS ns3.a.shifen.com.
a.shifen.com. 1200 IN NS ns1.a.shifen.com.;; Received 239 bytes from 180.76.76.92#53(ns7.baidu.com) in 3 ms #ns7.baidu.com域主機為我們提供了解析服務，為我們傳回了上面6個域名解析記錄。 #如果你搭建了本地的DNS解析伺服器在跟蹤解析過程的話，會發現當解析到www.baidu.com. 1200 IN CNAME www.a.shifen.com.的時候，會向.com域再次對www.a.shifen.com.進行解析請求。
DNS輪詢機制：如果你多對www.baidu.com進行dig查詢的話，會發現并不是同一個IP,這就是一個名稱對應多個IP，這是為了伺服器不斷地被輪詢詢問，防止一台主機接收通路量過大，進而做的負載均衡。
DNS查詢分類：遞歸查詢（一直問直到問出最終結果,DNS伺服器做的事情）和疊代（反複）查詢（隻告訴你下一步怎麼做或者是招那個域主機去詢問，根域啊，com.域啊這些主機做的事情）。
1.5 DNS名字伺服器的類型
DNS規範定義了兩種類型的名字伺服器：primary master（主名字伺服器）和secondary master（輔名字伺服器）。當然除此之外還有擴充出緩存域名伺服器和轉發域名伺服器。
主名字伺服器：也稱為主域名伺服器,負責維護這個域名區域的所有域名資訊，是特定的所有資訊的權威資訊源。可以對域名進行修改添加管理。從本機中加載資料的檔案叫做資料檔案。
輔名字伺服器：從主名字伺服器傳送過來的區資料備份到本機的資料檔案當中，資料是從另一台域伺服器複制過來的，是以資料無法修改隻是一個區域檔案的副本。如果輔名字伺服器被殺死再重新開機時，它會先讀取備份的資料檔案，然後檢查它的取資料是否是最新的。如果主域名伺服器出現故障，輔域名伺服器再自殺前還可以提供一段時間的解析服務。
緩存域名伺服器：運作域名伺服器軟體但是沒有域名資料庫，如果收到域名服務的查詢操作，它從某個遠端伺服器獲得域名伺服器的查詢結果，會放到緩存中，以後再有相同的查詢會給予回答。是以緩存域名伺服器不是權威性的伺服器，因為提供的所有資訊都是間接資訊。
轉發域名伺服器：負責所有非本地域名的本地查詢。轉發域名伺服器接到查詢請求時，在其緩存中查找，如果找不到請求的結果就以此轉發到指定的域名伺服器，直到查詢到結果為止，否則傳回無法映射的結果。名字伺服器不能把資料永遠的放到緩存中，這些域名的管理者為資料設定一個生存期簡稱TTL，生存期一過，名字伺服器就必須丢棄緩存的資料，并從權威名字伺服器上擷取新的資料。對于否定緩存資料（也就是之前解析發現不存在的域名）也一樣。
1.6 DNS按功能（角色）的分類
權威DNS：權威DNS是經過上一級授權對域名進行解析的伺服器，同時它可以把解析授權轉授給其他人，如com頂級伺服器可以授權51niux.com這個域名的的權威伺服器為ns.51niux.com，當然也可以指定别的域名權威伺服器。平時我們解析域名的結果都源自權威DNS。比如51niux.com的權威DNS伺服器就是萬網的dns13.hichina.com和dns14.hichina.com。
遞歸DNS : 負責接受使用者對任意域名查詢，并傳回結果給使用者。遞歸DNS可以緩存結果以避免重複向上查詢。我們平時使用最多的就是這類DNS，他對公衆開放服務，一般由網絡營運商提供，大家都自己可以架遞歸DNS提供服務。遞歸DNS一定要有可靠的網際網路連接配接方可使用。比如谷歌的8.8.8.8和8.8.4.4以及114的114.114.114.114和114.114.115.115都屬于這一類DNS。你本地電腦上設定的DNS就是這類DNS。
轉發DNS : 負責接受使用者查詢，并傳回結果給使用者。但這個結果不是按标準的域名解析過程得到的，而是直接把遞歸DNS的結果轉發給使用者。它也具備緩存功能。他主要使用在沒有直接的網際網路連接配接，但可以連接配接到一個遞歸DNS那裡，這時使用轉發DNS就比較合适。其缺陷是：直接受遞歸DNS的影響，服務品質較差。比如我們用的路由器裡面的DNS就是這一類，用路由器的朋友可以看下本地電腦的DNS一般都是192.168.1.1。
1.7 DNS常用記錄類型
A記錄：用來指定域名（或主機名）對應的IP位址記錄。
CNAME記錄：别名記錄，允許将多個名字映射到同一台計算機。
MX記錄：郵件交換記錄，它指向一個郵件伺服器，用于點子郵件系統發郵件時根據收件人的位址字尾來定位郵件伺服器。
NS記錄：域名伺服器記錄，用來指定該域名由哪個DNS伺服器進行解析，指定負責此DNS區域的權威名稱伺服器。
PTR記錄：指針記錄，将一個IP位址映射到對應的域名，也可以看成是A記錄的反向，IP位址的反向解析。PTR主要用于郵件伺服器，對端的郵件伺服器根據發件IP進行反向解析，如果解析結果對應發件人的域名稱就接收這封郵件，否則拒絕接收這封郵件。
SOA記錄：權威記錄的起始，指定有關的DNS區域的權威性資訊，包含主要名稱伺服器、域名管理者的郵箱位址、域名的流水式編号和幾個有關重新整理區域的定時器。
SPF記錄：是為了防範垃圾郵件而提出來的一種DNS記錄類型，它是一種TXT類型的記錄，它用于登記某個域名擁有的用來外發郵件的所有IP位址。當你定義了你的domain name的SPF記錄之後，接收郵件方會根據你的SPF記錄來确定連接配接過來的IP位址是否被包含在SPF記錄裡面，如果在，則認為是一封正确的郵件，否則則認為是一封僞造的郵件。
TSIG記錄：交易證書，用以認證動态更新（Dynamic DNS）是來自合法的用戶端，或與 DNSSEC 一樣是驗證回應是否來自合法的遞歸名稱伺服器。
TXT記錄：文本記錄。一般指某個主機名或域名的說明，TXT的應用之一，SPF（Sender Policy Framework）反垃圾郵件。
博文來自：www.51niux.com
二、DNS伺服器搭建
2.1 DNS伺服器基本搭建
第一步：安裝相關件軟體
# yum install bind bind-libs -y #dns服務軟體安裝。提供域名服務的主要程式及相關檔案。
# yum install bind-utils -y #提供了對DNS伺服器的測試工具（如nslookup,dig等）
第二步：修改位置檔案
# vim /etc/named.conf #修改主配置檔案，我們先做很小的修改讓結果顯示出來
Bash
options {
//listen-on port 53 { 127.0.0.1; }; #我們将預設的127.0.0.1用//注釋掉
listen-on port 53 { 192.168.1.101; }; #這是新添加的一行，讓其監聽再192.168.1.101的53端口上面，注意每一行都要以;結尾。
//listen-on-v6 port 53 { ::1; }; #我們将ipv6的注釋掉如果不需要
directory "/var/named"; #這就是我們區資料檔案的存放位置。
dump-file "/var/named/data/cache_dump.db"; #轉儲名稱伺服器資料庫時存儲檔案的位置
statistics-file "/var/named/data/named_stats.txt"; #轉儲其統計資料，存儲檔案的位置
memstatistics-file "/var/named/data/named_mem_stats.txt";
//allow-query { localhost; }; #将原來的隻允許本地通路注釋掉
allow-query { any; }; #新添加一行允許任何位址來通路
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes; #預設是開啟遞歸設定。如果是yes，并且一個DNS詢問要求遞歸，那麼伺服器将會做所有能夠回答查詢請求的工作。如果recursion是off的，并且伺服器不知道答案，它将會傳回一個推薦（referral）響應。預設值是yes。注意把recursion設為no，不會阻止使用者從伺服器的緩存中得到資料，它僅僅阻止新資料作為查詢的結果被緩存。伺服器的内部操作還是可以影響本地的緩存内容，如NOTIFY位址查詢。
dnssec-enable yes; #是否支援DNSSEC開關,預設為yes。 (DNSSEC)DNS安全擴充，是由IETF提供的一系列DNS安全認證的機制（可參考RFC2535）。它提供了一種來源鑒定和資料完整性的擴充，但不去保障可用性、加密性和證明域名不存在。DNSSEC是為解決DNS欺騙和緩存污染而設計的一種安全機制。
dnssec-validation yes; # 是否進行DNSSEC确認開關。
//dnssec-lookaside auto; #該選項的文法格式為：[ (dnssec-lookaside auto| no| domain trust-anchor daomain); ]，dnssec-lookside為驗證器提供另外一個能在網絡區域的頂層驗證DNSKEY的方法。當使用dnssec-lookaside指定一個DNSKEY是等于或低于指定域時，正常DNSSEC驗證已經忽略了不信任的密鑰。如果它能夠驗證密鑰，trust-anchor将被追加到密鑰名和DLV記錄被檢視。如果DLV記錄驗證一個DNSKEY，這個DNSKEY RRset可以被視為可信任的。如果dnssec-lookside設定為auto，那麼内置的預設值DLV域和信任錨定将被使用，随着一個内置的驗證密鑰。如果設定為no，那麼不使用dnssec-lookside，将加載預設DLV密鑰存儲在檔案bind.keys中。預設的DLV密鑰存儲在檔案bind.keys中，如果dnssec-lookaside設定為auto，named在啟動時将被加載。
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key"; #内置信任的密鑰檔案。當dnssec-validation和dnssec-lookaside都被設為auto時，這個密鑰檔案生效。
managed-keys-directory "/var/named/dynamic"; #指定目錄中的檔案存儲，跟蹤管理DNSSEC密鑰。預設情況下，儲存在/var/named/dynamic目錄中。如果named配置不使用視圖，然後在管理伺服器中的密鑰将被跟蹤單個檔案稱為managed-keys.bind；否則将單獨跟蹤管理的密鑰檔案。
pid-file "/run/named/named.pid"; #pid檔案的位置
session-keyfile "/run/named/session.key"; #寫入由nsupdate -l使用的命名生成的TSIG會話密鑰的檔案的路徑名。 如果未指定，則預設值為/var/run/named/session.key。};logging { #定義bind服務的日志
channel default_debug { #定義通道，default_debug隻有當伺服器的debug級别非0時，才産生輸出
file "data/named.run"; #預設日志儲存位置
severity dynamic; #severity按照伺服器目前的debug級别記錄日志。everity語句用于指定消息的嚴重性等級。log_severity的取值為（按照嚴重性遞減的順序）：critical、error、warning、notice、info、debug [level]、dynamin。dynamic是一個特殊的值，系統會記錄包括該級别以及比該級别更嚴重的級别的所有消息。比如定義級别為error，則會記錄critical和error兩個級别的消息。對于系統管理來說，一般記錄到info級别就可以了。
};};zone "." IN { #這是定義了根域。zone用來定義一個區域。每個zone區域都是可選的（包括根域、回環域、反向域），具體根據實際需要而定，zone配置部分的IN關鍵子可以省略。
type hint; #指定區域類型為根域，可以設定的區域類型有“根域”、“主域”和“從域”3種類型，在配置檔案中分别使用hint、master和slave表示這3種類型。
file "named.ca"; #定義了根域資料庫檔案位置，預設是在/var/named/named.ca，設定區域位址資料庫檔案，該檔案名由使用者自行設定，隻要實際的位址資料庫檔案名與其保持一緻即可。};include "/etc/named.rfc1912.zones"; #這兩個就是加載哪些檔案include "/etc/named.root.key"; 第三步：修改/etc/named.rfc1912.zones區域檔案,此檔案裡面原來的内容可以全删除掉，那就相當于例子供你參考。
Bash
zone "51niux.in" IN { #定義了一個51niux.in的域
type master; #類型為主域
file "51niux.in.zone"; #檔案是51niux.in.zone，預設是在/vat/named/目錄下面};zone "1.168.192.in-addr.arpa" IN { #定義了一個反向域，這個你要從右向左來看，arpa.addr-in.192.168.1
type master; #類型為主域
file "1.168.192.zone"; #檔案位置}; 第四步：添加51niux.in.zone域檔案并修改
# cat /var/named/51niux.in.zone
Bash
$TTL 86400 //設定位址解析記錄的預設存儲時間，機關是秒。當然也可以用3h（3小時）或者1D（一天）來表示，大小寫沒影響不過一般用大寫。H(時)、M（分）、S（秒）、W（周）、D（天）
@ IN SOA ns1.51niux.in. csp ( //定義了一條SOA記錄，現在是一種縮寫，@代表51niux.in.，這是很常見的一種寫法。這裡定義了SOA标記、SOA域名是ns1.51niux.com,域管理郵箱是[email protected]（也可以寫成csp.51niux.in.，這裡第一個.就相當于@）
2017060616 //更新序列号，10位以内的證書，用于标記位址資料庫的變化，這裡是以2017年6月6日16時來定義的序列号。
3H //重新整理時間，從域名伺服器更新該位址資料庫檔案的間隔時間
1H //重試延時，從域命伺服器更新位址資料庫失敗以後，等待多長時間再次嘗試
1W //失效時間，超過該時間仍無法更新位址資料庫，則不再嘗試并且殺死自己。
1H ) //設定無效位址解析記錄（該資料庫中不存在的位址也就是域名）的預設緩存時間
@ IN NS ns1.51niux.in. //域名伺服器記錄，用于設定目前域的DNS伺服器的域名位址
@ IN NS ns2.51niux.in.
@ IN MX 5 mail.51niux.in. //設定郵件伺服器的MX記錄，前面的@就表示51niux.in.
@ IN MX 10 mail2.51niux.in. //這裡設定了兩個MX記錄。優先級越高的郵件交換器的優先級值就小，如果上面的MX出問題了，才會解析到現在這台機器。
ns1 IN A 192.168.1.101 //這些就是A記錄了
ns2 IN A 192.168.1.102 //因為是縮寫了，是以ns2.51niux.in.可以直接縮寫成ns2
www IN A 192.168.1.103
mail IN A 192.168.1.104
mail2 IN A 192.168.1.105
pop3 IN CNAME mail.51niux.in. //這些就是CNAME記錄了
imap IN CNAME mail.51niux.in. 第五步：1.168.192.zone反向域檔案的添加并修改
Bash
$TTL 86400
@ IN SOA ns1.51niux.in. csp (
2017060616
3H
1H
1W
1H )@ IN NS ns1.51niux.in.
@ IN NS ns2.51niux.in.
104 IN PTR mail.51niux.in. //這是也縮寫，标準格式是104.1.168.192.in-addr.arpa，指定了192.168.1.104的反向域名是mail.51niux.in 第六步：重新開機DNS服務
# named-checkconf /etc/named.conf #可以檢測下配置檔案，沒輸出就說明沒問題
# named-checkzone 51niux.in /var/named/51niux.in.zone #檢查下zone檔案，
Bash
zone 51niux.in/IN: loaded serial 2017060616
OK # service named restart #重新開機bind服務，也可以檢視日志是否報錯# tail -f /var/log/messages
# netstat -lntup|grep :53 #檢視53端口已經啟動
tcp 0 0 192.168.1.101:53 0.0.0.0:* LISTEN 124313/named
udp 0 0 192.168.1.101:53 0.0.0.0:* 124313/named
第七步：測試
# cat /etc/resolv.conf #找一台機器将dns伺服器設定成我們的測試DNS伺服器
nameserver 192.168.1.101
# ping www.51niux.in #ping檢測一下
# nslookup www.baidu.com #抓下外網
# dig -x 192.168.1.104 @192.168.1.101 #指定通過192.168.1.101去檢視192.168.1.104的反向解析。
#經過測試我們設定的域名可以解析，外網也可以解析，反向解析也是可以的。
第八步：解決ipv6相關報錯
通過上面的配置啟用後雖然可以正常使用，不過在/var/log/message 和 /var/named/data/named.run 日志中會出現相關報錯。
Bash
Jun 6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:500:3::42#53Jun 6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:7fe::53#53Jun 6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:dc3::35#53Jun 6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:500:2f::f#53 該報錯是由于啟用了ipv6的原因導緻的，雖然我們在/etc/named.conf中将listen項的IPv6配置已禁用，但是在named.ca配置中還有13台根域的ipv6配置。是以還需要如下兩種方法中的任一種來關閉ipv6的使用。
方法1：修改/etc/sysconfig/named配置
直接編輯配置檔案/etc/sysconfig/named：
Bash
OPTIONS="whatever" 改為 OPTIONS="-4"# 注意OPTIONS選項的值可以是：whatever、-4、-6中的一個 方法2：完全禁用IPv6
配置檔案/etc/sysconfig/network，然後 将NETWORKING_IPV6=YES改為NETWORKING=no；
關閉ip6tables這個服務；向/etc/modprobe.conf檔案中，添加如下内容：
Bash
alias ipv6 offalias net-pf-10 off 博文來自：www.51niux.com
三、DNS主輔同步部署
增量區傳送（IXFR）：區很大的話，區傳送需要一定的時間，IXFR是為了解決這個問題，它允許輔名字伺服器告訴主名字伺服器目前使用的區的版本，并僅僅請求傳送它使用的版本和目前版本之間改動過的部分。這樣就大大減少了區傳送的大小和所需的時間。但是存在的問題比較多，如果最大限度的利用IXFR，最好動态更新修改區而不是手工編輯區資料檔案。
全量區傳送（AXFR）：預設的是這種形式，進行整個區傳送的查詢類型。
3.1 dns主伺服器端（192.168.1.101）的設定
# cat /etc/named.rfc1912.zones
Bash
zone "51niux.in" IN {
type master;
file "51niux.in.zone";
allow-transfer { 192.168.1.104;}; //輔助DNS的位址，也就是隻允許此服務複制51niux.in.zone的資訊的資訊
allow-update { none;}; //設定允許動态更新的用戶端位址（none為禁止）
also-notify { 192.168.1.104;}; //當zone資訊發送改變時，主DNS會主動給輔助DNS發送資訊通知自己更新了};zone "1.168.192.in-addr.arpa" IN {
type master;
file "1.168.192.zone";
allow-transfer { 192.168.1.104;};
allow-update { none;};
also-notify { 192.168.1.104;}; //BIND8和BIND9是不允許關掉伺服器對伺服器的NOTIFY聲明的，是以notify yes;加不加都行，預設就是開啟的。}; notify: 預設為yes,當伺服器的一個域授權發生改變,将發送DNS NOTIFY資訊給域NS記錄的伺服器清單,和一些列在also-notify選項中的伺服器.如果選master-only,資訊隻發給主域,如果是explicit,通知隻發給also-notify的清單,no不發通知.這裡需要注意：如果我們also-notify沒有進行設定的話，那麼會造成當主dns記錄發生改變後，輔dns并沒有同步更改相應的記錄。也許有人會說我們可以更改SOA中的Refresh值，把它改小點也一樣，這樣說到也是可以的，但問題是我們的主DNS修改完重新開機服務後，它是會主動發送一個notify值，如果輔助DNS伺服器沒有收到才參考Refresh，Refresh 不成功,則參考Retry ，Retry 一直不成功,則參考 Expire，如果Expire也不成功，則選擇放棄zone transfer的過程。是以為了主輔更好的同步，建議大家在這裡設定also-notify。
# service named restart #重新開機主DNS的服務
3.2 dns從伺服器端（192.168.1.104）的設定
# cat /etc/named.conf #隻改變一出，上面講述了這裡設定個IP的形式，改成下面的形式就是監聽0.0.0.0，主從這樣設定的話，主從的named.conf就都不用更改了保持一緻了。
listen-on port 53 { any; };
# cat /etc/named.rfc1912.zones
Bash
zone "51niux.in" IN {
type slave; //類型是不一樣，指定自己的DNS類型是slave也就是指定自己是輔助DNS伺服器 file "slaves/51niux.in.zone";
masters{ //這裡指定從哪個master伺服器同步zone檔案
192.168.1.101; //192.168.1.101從這個主伺服器同步zone資料 };};zone "1.168.192.in-addr.arpa" IN {
type slave;
file "slaves/1.168.192.zone";
masters{
192.168.1.101;
};}; # service named restart #重新開機輔助DNS伺服器的服務。
# chmod 700 /var/named/slaves
# tail -f /var/log/messages #當你上面進行重新開機的時候，檢視日志已經有資料同步過來了，如果設定是成功的話。
Bash
Jun 6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: Transfer started.
Jun 6 18:17:13 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: connected using 192.168.1.104#21228Jun 6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: transferred serial 2017060619 #注意我們設定的這個ID号等會同步的時候就知道它的重要性了。Jun 6 18:17:13 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 17 records, 391 bytes, 0.001 secs (391000 bytes/sec)Jun 6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: sending notifies (serial 2017060619)Jun 6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: Transfer started.
Jun 6 18:17:13 agent3 named[3399]: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.101#53: connected using 192.168.1.104#10660Jun 6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: transferred serial 2017060616
Jun 6 18:17:13 agent3 named[3399]: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 5 records, 184 bytes, 0.003 secs (61333 bytes/sec)Jun 6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2017060616) 3.3 進行測試
主DNS上面的操作：
現在我們在192.168.1.101上面添加一條DNS，并且檢視日志：
# vim /var/named/51niux.in.zone #添加下面一條記錄
dnstest IN A 192.168.1.101
# service named reload #不可能總是重新開機服務，讓named重新加載一下配置檔案
# tail -f /var/log/messages #下面是最後的資訊
Bash
Jun 6 18:22:30 master named[125967]: reloading zones succeeded
Jun 6 18:22:30 master named[125967]: zone 51niux.in/IN: zone serial (2017060619) unchanged. zone may fail to transfer to slaves. #區序（2017060619）不變。區域可能無法轉移到salves伺服器。Jun 6 18:22:30 master named[125967]: zone 51niux.in/IN: loaded serial 2017060619
Jun 6 18:22:30 master named[125967]: zone 51niux.in/IN: sending notifies (serial 2017060619) #發送通知（系列2017060619）,說明已經通知出去，通知slaves來更新了。 #用戶端本地測試已經生效了。
輔助DNS上面進行的操作：
# tail -f /var/log/messages #下面是最後的資訊
Bash
Jun 6 18:22:31 agent3 named[3399]: client 192.168.1.101#43642: received notify for zone '51niux.in' #用戶端收到了通知51niux.in的更新Jun 6 18:22:31 agent3 named[3399]: zone 51niux.in/IN: notify from 192.168.1.101#43642: zone is up to date #從192.168.1.101去更新最新的51nux.in的zone檔案 注意：
差就差在了主DNS伺服器再更改zone檔案的時候，serial号沒有進行更改。每次更改zone檔案，serial号都要進行更改可以按天加或者按小時加，要增大，一定要比輔助DNS的serial号大，這樣輔助DNS一檢視自己的serial号變小了，就會同步資料了。
如現在我們将主DNS上面的号加大一下再重新加載配置檔案：
再檢視輔助DNS上面的日志：
# tail -f /var/log/messages
Bash
Jun 6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: Transfer started. #zone 51niux.in轉移開始Jun 6 18:35:09 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: connected using 192.168.1.104#36323 #192.168.1.104連接配接上來了Jun 6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: transferred serial 2017060620 #發現号已經發生了變化已經不是2017060619了。Jun 6 18:35:09 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 18 records, 415 bytes, 0.001 secs (415000 bytes/sec) #從192.168.1.101傳送51niux.in完成，1條資訊，18條記錄，415位元組，0.001秒。Jun 6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: sending notifies (serial 2017060620) 博文來自：www.51niux.com
四、BIND配置文法介紹
acl ： 定義IP位址通路控制清單
controls : 定義 rndc 指令使用的控制通道，若省略此句，則隻允許經過 rndc.key 認證的 127.0.0.1 的 rndc 控制
include : 加載檔案，檔案裡面可以有一些配置。
key：定義用于 TSIG 的授權密鑰
logging : 定義日志的記錄規範，隻能在配置中出現一次。
options : 定義全局配置選項，隻能在配置中出現一次。
server : 設定每個伺服器的特有的選項
trusted-keys : 定義信任的DNSSED秘鑰
view : 定義域名空間的一個視圖，用來做智能DNS解析
zone : 定義一個域
4.1 options語句
以下内容來源于網絡，我也不知道具體原位址是哪？
options語句的定義和使用：
options語句用來設定可以被整個BIND使用的全局選項。這個語句在每個配置檔案中隻有一處。如果出現多個options語句，則第一個options的配置有效，并且會産生一個警告資訊。
如果沒有options語句，則每個選項使用預設值。
options {
[ version version_string; ]
[ directory path_name; ]
[ named-xfer path_name; ]
[ tkey-domain domainname; ]
[ tkey-dhkey key_name key_tag; ]
[ dump-file path_name; ]
[ memstatistics-file path_name; ]
[ pid-file path_name; ]
[ statistics-file path_name; ]
[ zone-statistics yes_or_no; ]
[ auth-nxdomain yes_or_no; ]
[ deallocate-on-exit yes_or_no; ]
[ dialup dialup_option; ]
[ fake-iquery yes_or_no; ]
[ fetch-glue yes_or_no; ]
[ has-old-clients yes_or_no; ]
[ host-statistics yes_or_no; ]
[ minimal-responses yes_or_no; ]
[ multiple-cnames yes_or_no; ]
[ notify yes_or_no | explicit; ]
[ recursion yes_or_no; ]
[ rfc2308-type1 yes_or_no; ]
[ use-id-pool yes_or_no; ]
[ maintain-ixfr-base yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ check-names ( master | slave | response )( warn | fail | ignore ); ]
[ allow-notify { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ allow-recursion { address_match_list }; ]
[ allow-v6-synthesis { address_match_list }; ]
[ blackhole { address_match_list }; ]
[ listen-on [ port ip_port ] { address_match_list }; ]
[ listen-on-v6 [ port ip_port ] { address_match_list }; ]
[ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
[ max-transfer-time-in number; ]
[ max-transfer-time-out number; ]
[ max-transfer-idle-in number; ]
[ max-transfer-idle-out number; ]
[ tcp-clients number; ]
[ recursive-clients number; ]
[ serial-query-rate number; ]
[ serial-queries number; ]
[ transfer-format ( one-answer | many-answers ); ]
[ transfers-in number; ]
[ transfers-out number; ]
[ transfers-per-ns number; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ notify-source (ip4_addr | *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ alsonotify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
[ max-ixfr-log-size number; ]
[ coresize size_spec ; ]
[ datasize size_spec ; ]
[ files size_spec ; ]
[ stacksize size_spec ; ]
[ cleaning-interval number; ]
[ heartbeat-interval number; ]
[ interface-interval number; ]
[ statistics-interval number; ]
[ topology { address_match_list }];
[ sortlist { address_match_list }];
[ rrset-order { order_spec ; [ order_spec ; ... ] } };
[ lame-ttl number; ]
[ max-ncache-ttl number; ]
[ max-cache-ttl number; ]
[ sig-validity-interval number ; ]
[ min-roots number; ]
[ use-ixfr yes_or_no ; ]
[ provide-ixfr yes_or_no; ]
[ request-ixfr yes_or_no; ]
[ treat-cr-as-space yes_or_no ; ]
[ min-refresh-time number ; ]
[ max-refresh-time number ; ]
[ min-retry-time number ; ]
[ max-retry-time number ; ]
[ port ip_port; ]
[ additional-from-auth yes_or_no ; ]
[ additional-from-cache yes_or_no ; ]
[ random-device path_name ; ]
[ max-cache-size size_spec ; ]
[ match-mapped-addresses yes_or_no; ]
};
version
回答針對伺服器版本的請求時的内容。預設傳回的是伺服器的真實版本。
directory
伺服器的工作目錄。配置檔案中所有使用的相對路徑，指的都是在這裡配置的目錄下。大多數伺服器的輸出檔案（如named.run）都預設生成在這個目錄下。如果沒有設定目錄，工作目錄預設設定為伺服器啟動時的目錄‘.’。指定的目錄應該是一個絕對路徑。
named-xfer
這個選項已經被廢棄了。它在BIND8 中，它用來給named-xfer程式設定路徑名。在BIND9中，不需要單獨的named-xfer程式；它的功能已經内置在域名伺服器中。
tkey-domain
這個域名将會附帶在由TKEY 生成的所有共享密匙名字的後面。當使用者請求進行TKEY交換時，它會為密匙設定或不設定所要求的名稱。如果設定了tkey_domain，共享密匙的名字将會是"client specified part"（使用者設定的部分）+ "tkey-domain"。否則，共享密匙的名字将是"random hex digits"（随機的16 進制數）+ "tkey-domain"。在大多數情況下，domainname應該是伺服器的域名。
tkey-dhkey
針對使用Diffie-Hellman 的TKEY模式的使用者，伺服器用來生成共享密匙的Diffie-Hellman 密匙。伺服器必須可以從工作目錄中調入公共和私人密匙。大多數情況下，密匙的名稱應該是伺服器的主機名。
dump-file
當執行rndc dumpdb指令時，伺服器存放資料庫檔案的路徑名。如果沒有指定，預設名字是named_dump.db。
memstatistics-file
伺服器輸出的記憶體使用統計檔案的路徑名。如果沒有指定，預設值為named.memstats。
注意：還沒有在BIND9中實作！
pid-file
程序ID檔案的路徑名。如果沒有指定，預設為/var/run/named.pid。pid-file是給那些需要向運作着的伺服器發送信号的程式使用的。
statistics-file
當使用rndc stats指令的時候，伺服器會将統計資訊追加到的檔案路徑名。如果沒有指定，預設為named.stats在伺服器程式的目前目錄中。
port
伺服器用來接收和發送DNS協定資料的UDP/TCP端口号。預設為53。這個選項主要用于伺服器的檢測；因為如果不使用53端口的話，伺服器将不能與其它的DNS進行通訊。
random-device
伺服器使用的entropy源：entropy主要用于DNSSEC操作，如TKEY的資料交換和加密域的動态更新。此選項指定了entropy将會從哪個裝置（或檔案）中讀取資訊。如果它是一個檔案，則當檔案耗盡後，需要entropy的操作将會失敗。如果沒有指定，預設值是/dev/random（或等價的），如果它存在，否則就是沒有。random-device選項是在伺服器啟動時，初始化配置時起作用的，在以後的重新開機時則被忽略。
A.Boolean 選項
auth-nxdomain
如果是yes，那麼AA位将一直設定成NXDOMAIN響應，甚至在伺服器不是授權伺服器的情況下都是這樣的。預設值是no；這與BIND8不同。如果使用者使用的是非常老版本的DNS軟體，則有必要把它設定成yes。
deallocate-on-exit
此選項在BIND8中用于檢查出口處記憶體洩露。BIND9忽略此選項，并始終進行檢查。
dialup
如果是yes，那麼伺服器将會像在通過一條按需撥号的鍊路進行域傳送一樣，對待所有的域（按需撥号就是在伺服器有流量的時候，鍊路才連通）。根據域類型的不同它有不同的作用，并将集中域的維護操作，這樣所有有關的操作都會集中在一段很短的時間内完成，每個heartbeat-interval一次，一般是在一次調用之中完成。它也禁止一些正常的域維護的流量。預設值是no。
dialup選項也可以定義在view和zone語句中，這樣就會代替了全局設定中dialup的選項。
如果域是一個主域，伺服器就會對所有輔域發送NOTIFY請求。這将激活輔域名伺服器中的對域的序列号的檢驗。這樣當建立一個連接配接時，輔域名伺服器才能确認這個域的傳輸合法性。
如果這個域是一個輔域或是末梢域（stub zone），那麼伺服器将會禁止通常的“zone up to date”（refresh）請求，為了能發送NOTIFY請求，隻有在heartbeat-interval 過期之後才執行。
通過下列的設定，可以實作更好的控制。
1、notify 隻發送NOTIFY資訊。
2、notify-passive 發送NOTIFY資訊，并禁止普通的重新整理（refresh）請求。
3、refresh 禁止普通的重新整理處理，當heartbeat-interval 過期時才發送重新整理請求。
4、passive 隻用于關閉普通的重新整理處理。
fake-iquery
在BIND8中，此選項用來模拟陳舊的DNS查詢類型IQUERY。BIND9不再進行IQUERY模拟。
fetch-glue
這個選項以後不再使用。
has-old-clients
這個選項在BIND8中執行有問題，BIND9則忽略了這個選項。為了達到has-old-clients yes的預期效果，可以設定兩個獨立選項auth-nxdomain yes和rfc2308-type1 no來代替。
host-statistics
在BIND8中，它可以保留每台和域名伺服器互動的主機統計資訊。BIND9中不支援。
maintain-ixfr-base
此選項不再使用了。在BIND8用于判定是否儲存了增量域傳輸的處理日志。BIND9任何可能的時候都會儲存傳輸日志。如果需要禁止流出的增量域傳輸，可以使用provide-ixfr no。
minimal-responses
如果是yes，當産生響應的時候，伺服器将隻會按照需要将記錄添加到authority和additional的資料部分。（例如，delegations，negative responses）。這樣會改善伺服器的性能。預設值為no。
multiple-cnames
這個選項在BIND8中使用，允許一個域名承認多條CNAME記錄（與DNS标準相違
背）。BIND9.2在主hosts檔案和動态更新中都嚴格強制執行CNAME規則。
notify
如果是yes（預設），當一個授權的伺服器修改了一個域後，DNS NOTIFY資訊被發送出去。此資訊将會發給列在域NS記錄上的伺服器（除了由SOA MNAME标示的主域名伺服器）和任何列在also-notify選項中的伺服器。
如果是explicit，則notify将隻發給列在also-notify中的伺服器。如果是no，就不會發出任何封包。
notify選項也可能設定在zone語句中，這樣它就替代了options中的notify 語句。如果notify會使得輔域名伺服器崩潰，就需要将此選項關閉。
recursion
如果是yes，并且一個DNS詢問要求遞歸，那麼伺服器将會做所有能夠回答查詢請求的工作。如果recursion是off的，并且伺服器不知道答案，它将會傳回一個推薦（referral）響應。預設值是yes。注意把recursion設為no，不會阻止使用者從伺服器的緩存中得到資料，它僅僅阻止新資料作為查詢的結果被緩存。伺服器的内部操作還是可以影響本地的緩存内容，如NOTIFY位址查詢。
rfc2308-type1
設定成yes 将會使得伺服器發送NS 記錄和關于negative answer 的SOA記錄。預設值為no。
注：BIND9 中還不支援。
use-id-pool
此選項已經不再使用。BIND9 始終都是從池中配置設定請求ID的。
zone-statistics
如果是yes，預設情況下，伺服器将會收集在伺服器所有域的統計資料。這些統計資料可以通過使用rndc stats來通路，rndc stats指令可以将這些資訊轉儲到statistics-file定義的檔案中去。
use-ixfr
這個選項不再使用。如果需要針對一個或多個特殊的伺服器關閉IXFR，可以參考provide-ixfr中的内容。
provide-ixfr
參閱中關于provide-ixfr的陳述。
request-ixfr
參閱關于request-ixfr的陳述。
treat-cr-as-space
這個選項應用于BIND8中，使伺服器正确處理回車（”\r”）字元，就象其它的空格或tab字元一樣。這樣可以便于在unix系統上加載由NT或DOS系統生成的域檔案。在BIND9中,UNIX”的\n”和DOS 的”\r\n”都可以正确處理為換新行，這個選項就被忽略了。
additional-from-auth
additional-from-cache
當回答具有additional資料的請求，或者當在CNAME 和DNAME串的後面時，這些選項控制一個權威伺服器的操作。
當這兩個選項都被設成yes(預設狀态)，并且查詢的是授權的資料（這個域就配置在本地伺服器中）時，回答中的additional部分的資料将使用來自于其它授權域和cache。
在許多情況下這是不需要的，比如在緩存内容的正确性受到懷疑的情況下，或是在某些輔域可能被非法修改的伺服器。還有，避免對這些additional資料的搜尋将會加速伺服器運轉。
例如，如果一個查詢需要主機foo.example.com的MX記錄，找到的記錄是"MX 10
mail.example.net"，如果知道的話, mail.example.net的位址記錄(A,A6 和AAAA)也會被提供出來。把選項設定為no，則禁止了這種操作。
這些選項用于授權的伺服器，或者是授權的視圖中。把它們設成no，但沒有同時設定recursion no，将會使得伺服器忽略這些選項，并記錄一個警告日志。
設定additional-from-cache為no實際上針對additional資訊的查詢和正在響應的查詢，都禁止了緩存的使用。這常常使用在一台授權的伺服器中，因為在這裡緩存資料的正确性非常重要。
當一台域名伺服器不提供遞歸查詢時，并且查詢的名稱并不在本地域中，一般會對根伺服器或者其他已知的上級伺服器回答"upwards referral(向上推薦)"。既然在向上查詢中的資料來自于緩存，那麼當additional-from-cache被設定為no時，伺服器就不能提供向上推薦。相反，它會使用REFUSED(拒絕)回答這些查詢。因為向上推薦不是在使用者解析過程中需要的，是以就不會出任何問題。
match-mapped-addresses
如果是yes，那麼一個ipv4映射成的ipv6位址就會比對任何位址比對表中能比對于對應的ipv4 位址的記錄。打開這個選項，對于運作了ipv6的linux系統有時非常有用，這樣通過位址映射，就可以使得ipv4的TCP連接配接（如域傳送）實作在Ipv6的soket上，因為位址比對清單是給Ipv4設計的。
B. 轉發
轉發功能可以用來在一些伺服器上産生一個大的緩存，進而減少到外部伺服器鍊路上的流量。它可以使用在和internet沒有直接連接配接的内部域名伺服器上，用來提供對外部域名的查詢。隻有當伺服器是非授權的，并且緩存中沒有相關記錄時，才會進行轉發。
forward
此選項隻有當forwarders清單中有内容的時候才有意義。當值是First，預設情況下，使伺服器先查詢設定的forwarders，如果它沒有得到回答，伺服器就會自己尋找答案。如果設定的是only，伺服器就隻會把請求轉發到其它伺服器上去。
forwarders
設定轉發使用的ip位址。預設的清單是空的(不轉發)。轉發也可以設定在每個域上，這樣全局選項中的轉發設定就不會起作用了。使用者可以将不同的域轉發到伺服器上，或者對不同的域可以實作forward only或first的不同方式，也可以根本就不轉發。
C. 通路控制
可以根據使用者請求使用的IP位址進行限制。
allow-notify
設定哪個主機上的輔域（不包括主域）已經進行了修改。allow-notify也可以在zone語句中設定，這樣全局options中的allow-notify選項在這裡就不起作用了。但它隻對輔域有效。如果沒有設定，預設的是隻從主域發送notify資訊。
allow-query
設定哪個主機可以進行普通的查詢。allow-query也能在zone語句中設定，這樣全局options中的allow-query選項在這裡就不起作用了。預設的是允許所有主機進行查詢。
allow-recursion
設定哪台主機可以進行遞歸查詢。如果沒有設定，預設是允許所有主機進行遞歸查詢。注意禁止一台主機的遞歸查詢，并不能阻止這台主機查詢已經存在于伺服器緩存中的資料。
allow-v6-synthesis
設定哪台主機能接收對ipv6的響應。
allow-transfer
設定哪台主機允許和本地伺服器進行域傳輸。allow-transfer也可以設定在zone語句中，這樣全局options中的allow-transfer選項在這裡就不起作用了。如果沒有設定，預設值是允許和所有主機進行域傳輸。
blackhole
設定一個位址清單，伺服器将不會接收來自這個清單的查詢請求，或者解析這些位址。從這些位址來的查詢将得不到響應。預設值是none。
D. 接口
接口和端口(伺服器回答來自于此的詢問)可以使用listen-on選項來設定。listen-on使用可選的端口和一個位址比對清單（address_match_list）。伺服器将會監聽所有比對位址清單中所允許的端口。如果沒有設定端口，就使用預設的53。
允許使用多個listen-on語句。例如:
listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
将在5.6.7.8 的ip位址上打開53端口，在除了1.2.3.4的1.2 網段上打開1234 端口。
如果沒有設定listen-on，伺服器将在所有接口上監聽端口53。
listen-on-v6選項用來設定監聽進入伺服器的ipv6請求的端口。
伺服器并不象在ipv4中那樣對每個IPV6端口位址綁定一個獨立的socket。相反，它一直監聽ipv6通配的位址。這樣，對于listen-on-v6語句唯一的address_match_list的參數就是：{ any; }和{ none;}
多個listen-on-v6選項可以用來監聽多個端口:
listen-on-v6 port 53 { any; };
listen-on-v6 port 1234 { any; };
要使伺服器不監聽任何ipv6位址，使用：
listen-on-v6 { none; };
如果沒有設定listen-on-v6語句，伺服器将不會監聽任何ipv6位址。
E. 查詢位址
如果伺服器查不到要解析的位址，它将會查詢其它域名伺服器。query-source可以用來設定這類請求所使用的位址和端口。對于使用ipv6發送的查詢，有一個獨立的query-source-v6選項。如果address是*或者被省略了，則将會使用一個通配的IP位址
(INADDR ANY)。如果port是*或者被省略了，則将會使用一個随機的大于1024的端口。
預設為:
query-source address * port *;
query-source-v6 address * port *;
注：query-source選項中設定的位址是同時用于UDP和TCP兩種請求的，但是port僅僅用
于UDP請求。TCP請求使用的是随機的大于1024的端口。
F. 域傳輸
BIND有适當的機制來簡化域傳輸，并限定系統傳輸的負載量。下列設定應用于域傳輸:
also-notify
定義一個用于全局的域名伺服器IP位址清單。無論何時，當一個新的域檔案被調入系統，域名伺服器都會向這些位址，還有這些域中的NS記錄發送NOTIFY資訊。這有助于更新的域檔案盡快在相關的域名伺服器上收斂同步。如果一個also-notify清單配置在一個zone語句中，全局options中的also-notify語句就會在這裡失效。當一個zone-notify語句被設定為no，系統就不會向在全局中also-notify清單中的IP位址發送NOTIFY消息。預設狀态為空表(沒有全局通知清單)。
max-transfer-time-in
比設定時間更長的進入的域傳輸将會被終止。預設值是120分鐘(2小時)。
max-transfer-idle-in
在設定時間下沒有任何進展的進入域傳輸将會被終止。預設為60分鐘(1小時)。
max-transfer-time-out
運作時間比設定的時間長的發出的域傳輸将會被終止。預設為120分鐘(2小時).
max-transfer-idle-out
在設定時間下沒有任何進展的發出的域傳輸将會被終止。預設為60分鐘(1小時)。
serial-query-rate
輔域名伺服器将會定時查詢主域名伺服器，來确定域的串号是否改變。每個查詢将會占用一些輔域名伺服器網絡帶寬。為限制占用的帶寬，BIND9可以限制每個查詢發送的頻率。serial-query-rate的值是一個整數，就是每秒能發送的最大查詢數。預設值為20。
serial-queries
在BIND8中, serial-queries選項設定了在任何時候允許達到的最大的并發查詢數。BIND9不限制串号查詢的數量并忽略了serial-queries選項。它會使用serial-query-rate選項來限制查詢的頻率。
transfer-format
域傳輸可以用兩種不同格式，one-answer和many-answer。transfer-format選項使用在主域名伺服器上，用來确定發送哪種格式。one-answer在每個資源記錄傳輸中使用一個
DNS消息。many-answer則将盡可能多的資源記錄集中在一個消息中。many-answer是
更加有效的，但隻有相對比較新的輔域名伺服器才支援它，如BIND9、BIND8.x 和打了更新檔的BIND4.9.5。預設的設定為many-answer。使用server語句中的相關選項，可以替代全局選項中的transfer-format設定。
transfers-in
可以同時運作的進入的域傳輸的最大值。預設值為10。增加transfers-in的值，可以加速輔域的收斂速度，但也可能增加本地系統的負載。
transfers-out
可以同時運作的發出的傳輸的最大值。超過限定的域傳輸請求将會被拒絕。預設值為10。
transfers-per-ns
從一台指定的遠端域名伺服器，同時進行的進入的域傳輸的最大值。預設值2。增加
transfers-per-ns的值，會加速輔域的收斂速度，但也可能增加遠端系統的負載。使用
server語句中的transfer短語可以替代全局選項中的transfers-per-ns。
transfer-source
transfer-source決定在從外部域名伺服器上得到域傳送資料時，選哪個本地的ip位址使用在IPV4的TCP連接配接中。它可以標明IPV4的源位址，和可選的UDP端口，用于更新的查詢和轉發的動态更新。不過不做設定，它會預設挑選一個系統中的位址(常常是最靠近遠端終端伺服器的接口位址)。但這個位址必須已經配置在遠端終端的allow-tranfer選項中，才能進行域傳送。此語句為所有的域設定了transfer-source，但如果view或zone中也使用了transfer-source語句，則全局選項中的配置就在這裡失效了。
transfer-source-v6
和transfer-source一樣，隻是域傳輸是通過IPV6執行的。
notify-source
notify-source确定使用哪些本地的源位址和可選的UDP端口，用于發送NOTIFY消息。這個位址必須在輔域名伺服器的master域或在allow-notify中設定。它會為所有域設定
notify-source, 但如果view或zone中也使用了notify-source語句，則全局選項中的配置就在這裡失效了。
notify-source-v6
與notify-source類似，但應用于ipv6位址的notify封包的發送。
G. 作業系統資源限制
可以限制伺服器對許多系統資源的使用。這些就是通過調節資源限制的數值來完成的。例如，1G可以代替1073741824，限定一個十億位元組的限制。Unlimited 要求不限制使用，或者最大可用量。Default 将會使用伺服器啟動時的預設值。
下列選項設定了域名伺服器程序的作業系統資源占用限制。一些作業系統可能不支援一些
或所有的限制。在這樣的系統中，當使用不被支援的限制時，會産生一個告警。
coresize
core dump檔案的最大值尺寸。預設值為default
datasize
伺服器可以使用的最大資料記憶體量。預設值為default。這是一個在伺服器系統記憶體中
已經設定了的參數。如果伺服器要超過這個限制的記憶體量，則會失敗，這将使伺服器不能
提供DNS服務。是以，這個選項作為一種限制伺服器所使用的記憶體量的方式就不太有效，但是它能夠将作業系統設定的太小的預設資料尺寸增大。如果要限制伺服器使用的記憶體量，可以使用max-cache-size和recursive-clients選項。
files
伺服器可以同時打開的最大檔案數。預設是unlimited。
stacksize
伺服器可以使用最大的堆棧記憶體量。預設值為default。
H. 伺服器資源限制
下列選項設定了伺服器資源使用限制，這是由域名服務内部做的而不是作業系統設定的。
max-ixfr-log-size
此選項比較老；它由BIND8相容接受或者忽略。
recursive-clients
伺服器同時為使用者執行的遞歸查詢的最大數量。預設值1000，因為每個遞歸使用者使用許多位記憶體，一般為20KB，主機上的recursive-clients選項值必須根據實際記憶體大小調整。
tcp-clients
伺服器同時接受的TCP連接配接的最大數量，預設值100。
max-cache-size
伺服器緩沖使用的最大記憶體量，用比特表示。但在緩存資料的量達到這個界限，伺服器将會使記錄提早過期這樣限制就不會被突破。在多視圖的伺服器中，限制分别使用于每個視圖的緩存。預設值沒有限制，意味着隻有當總的限制被突破的時候記錄才會被緩存清除。
I. 周期性任務間隔
cleaning-interval
伺服器将在cleaning-interval的每一時間中從緩存中清除過期的資源記錄。預設為60分鐘，如果設定為0，就不會有周期性清理。
heartbeat-interval
伺服器将會為所有标記dialup的域運作維護任務，無論它的間隔在何時到期。預設為60分鐘，合理值不超過1天(1440 分鐘)。如果設定為0,不會為這些域産生域維護。
interface-interval
伺服器将在每個interface-interval時間掃描網絡接口表。預設為60分鐘。如果設定為0，僅當配置檔案被加載時才會進行接口掃描。在掃描之後，所有新接口上的監聽器将會被打開(listen-on配置使用的接口)。關閉接口上的監聽器将會被清除。
statistics-interval
域名伺服器統計将會在每個statistics-interval時刻被記入日志。預設值60分鐘，如果設為0，就沒有統計資料記入日志。
注意:BIND9 不支援
J. 拓撲
當伺服器從一個域名伺服器清單中選擇一個域名伺服器查詢時，這些域名伺服器是沒有什麼不同的，但是伺服器會先選擇在拓撲結構上距離自己最近的伺服器去做解析。拓撲語句使用一個位址比對清單并且以一個特殊方式解釋它。每個頂層清單元素被賦了一段距離，非否定元素得到它們在清單中的位置的距離，比對距離表的開頭越近，它離伺服器的距離就越小。否定比對元素将會從伺服器配置設定最大距離；沒有比對的位址将會得到一個比任何非否定表元素都遠的并且比任何否定元素近的距離。例如：
topology {
10/8;
!1.2.3/24;
{ 1.2/16; 3/8; };
};
最優先網段10的伺服器，然後是在網絡1.2.0.0(網絡掩碼255.255.0.0)和3.0.0.0(網絡掩
碼255.0.0.0)；再就是沒列出來的，但是沒有否定的網段。否定的網段1.2.3 的主機(網絡掩
碼255.255.255.0)。
預設拓撲為:
topology { localhost; localnets; };
注意：BIND9不支援拓撲選項。
K. sortlist 語句
對一個DNS詢問的響應包括形成一個資源記錄集(RR集)的多資源記錄(RRs)。名稱伺服器将會以不确定的順序傳回在RRset中的RRs(參見rrset-order語句)。使用者端的解答器會重新适當的排列，也就是說，使用任何在本地網上的位址優先于其他的位址。盡管如此，不是所有的解答器可以做到或者正确配置。當使用者使用一個本地伺服器的時候，伺服器可以基于使用者位址進行分類。這隻要求配置名稱伺服器，而不是所有使用者端。
sortlist語句(如下)使用一個位址比對表甚至比拓撲語句還要特殊的解釋它。每個在sortlist 的頂層語句必須自己就是一個清楚的擁有一個或兩個元素的位址比對表。每個頂級表的第一個元素(可能是一個IP位址，一個IP字首，一個ACL名稱或者一個位址比對表)與查詢源位址進行比對檢查直到找到比對的位址。
一旦查詢的源位址被比對，如果頂級語句隻包括一個元素的話，真正的比對于源位址的原始元素就被用來選擇位址，對應的轉移到了響應的開始。如果語句是兩個元素的表，那麼第二個元素遵照拓撲語句中位址比對表的方式進行處理。每個頂級元素被賦予一個距離和與響應的開頭距離最近的位址。
在下列例子中，任何來自于任何主機位址的查詢将會得到本地網上第一首選位址的響應。下一個首選位址在網段192.168.1/24上，既可以在192.168.2/24或192.168.3/24網段之後。從一台在192.168.1/24網段上的主機收到的查詢将會優先本網段和192.168.2/24和192.168.3/24網。而來自192.168.4/24或192.168.5/24上主機的查詢将隻優先直連的網段。
sortlist {
{ localhost; //IF 主機名
{ localnets;
192.168.1/24; //THEN 在下列網中最适合
{ 192.168.2/24; 192.168.3/24; }; }; }; //IF 在C類192.168.1
{ 192.168.1/24; //THEN 使用.1, 或.2 或.3
{ 192.168.2/24; 192.168.3/24; }; }; };
{ 192.168.2/24; //IF C類192.168.1
{ 192.168.2/24; //THEN使用2, 或.1 或.3
{ 192.168.1/24; 192.168.3/24; }; }; };
{ 192.168.3/24; //IF 在C類192.168.3
{ 192.168.1/24; 192.168.2/24; }; }; }; //THEN使用.3 或.1 或.2
};
};
下個例子将給出一個本地主機和直接連接配接到網上的主機的合理的狀态(behavior)。它很象BIND4.9.x分類的位址狀态。從本地主機發給查詢的響應支援任何直接連接配接的網絡，從其他直接連接配接網絡上的主機發送給查詢的響應優先在相同網段上的位址。對其他查詢的響應沒有分類。
sortlist {
{ localhost; localnets; };
{ localnets; };
};
L. RRset 排序
當多重記錄在一個解答中被傳回的時候，設定在響應中的記錄順序是很有用的.。
rrset-order語句允許對在多記錄響應下的記錄順序的設定。參見sortlist語句。
一個order_spec定義如下：
[ class class_name ][ type type_name ][ name "domain_name"] order ordering
如果沒有設定類，預設值為ANY。如果沒有設定類型，預設值為ANY。如果沒有設定
名稱，預設值為”*”。
合法的排序值是：
fixed:記錄以它們在域檔案中的順序
random:記錄以随機順序被傳回
cyclic:記錄以環順序被傳回
例如：
rrset-order {
class IN type A name "host.example.com" order random;
order cyclic;
};
将會使得任何處于IN類中的A類記錄的響應以随機順序傳回，IN 類以"host.example.com"為字尾。其他的記錄以循環記錄被傳回。
如果多重rrset-order語句出現，它們并不組合在一起，隻适用于最後一個條。
注意：rrset-order語句不被BIND9支援，BIND9目前隻支援"random-cyclic"排序，伺服器随機選擇RRset集中的開始點，有順序傳回在那個點開始的記錄。如果需要的話圍繞RRset
結尾。
M. 合成的IPV6響應
許多現存的子域解答器支援ipv6的DNS查詢(定義在RFC1986 中，使用AAAA 記錄進行前向查詢和ip6.int域中的”nibble labels”進行反向查詢)但是不支援RFC2874-style 查詢(使用A6記錄和在ip6.arpa 中的二進制标簽)對于那些希望繼續使用子域解答器而不是轉到
BIND9 lightweight 解答器的人來說，BIND 9提供一種自動把RFC1886-型查詢轉換成
RFC2874-型查詢的方法。傳回合成的AAAA和PTR記錄。
這個性質預設下是無效的，可以在分使用者基礎上添加一個allow-v6-synthesis
{ address_match_list };子句到選項或者視圖語句中。當它被激活時，遞歸AAAA查詢使服
務器先進行A6查詢，如果失敗，執行AAAA查詢。不管哪個成功，結果都作為一個合成的AAAA 記錄傳回。
類似的，在ip6.int中的遞歸PTR查詢将會促使一個ip6.arpa查詢使用二進制标簽，如果失敗，執行另一個在ip6.int中的查詢，結果将會以在ip6.int中的合成PTR記錄傳回。合成記錄的TTL 為0值。合成響應的DNSSEC确認目前并不被支援；也沒有了AD标記。
注：allow-v6-synthesis僅為提供了遞歸服務的使用者執行。
N. 調諧
lame-ttl
設定緩存有問題伺服器訓示的秒數。0使不緩存(不被推薦)。預設值600(10 分鐘)。最大值1800(30 分鐘)。
max-ncache-ttl
為降低網絡流量和提升伺服器存儲否定回答的性能。max-ncache-ttl以秒為機關設定這些回答的儲存時間。預設max-ncache-ttl是10800秒(3小時)。max-ncache-ttl不能超過7天，如果設成一個更大的值，則将會被自動減為7天。
max-cache-ttl
max-cache-ttl設定了伺服器儲存普通(肯定)答案的最大時間。預設值一周(7 天)。
min-roots
一個請求要求的最小的根伺服器數量。預設為2。
注意:不被BIND9 支援
sig-validity-interval
設定未來作為動态更新結果的自動生成的DNSSEC信号過期的天數。預設是30天。信号的初始時間無條件設為在目前時間的前一個小時，以允許一個有限的時鐘偏差。
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
這些選項控制了伺服器在更新一個域(詢問SOA變化)或者重試失敗的傳輸時的狀态。通常域的SOA值(但是這些值是由主伺服器設定的)幾乎不給此級伺服器管理者對它們内容的控制。
這些選項允許管理者為每域，每個視圖或者全局設定一個最小或者最大更新和重試時間。這些選項對于此級和根域是有效的并且設定SOA更新和重試時間。
O. 統計檔案
由BIND9産生的統計檔案和由BIND8産生的類似，但不完全一樣。
一個統計資料開始于行+++ Statistics Dump +++ (973798949)，這裡出現的數字是一個标準UNIX型的時間戳，從1970年1月1日開始以秒計。緊跟這行的是一系列行，包括一個
記數器類型，記數器值，任意的域名和任意的視圖名，沒有所列的視圖和域的行是整個伺服器的整體統計。具有域和視圖的行以給定的視圖和域命名(對預設的視圖來說視圖名預設)。
這個統計資料以行--- Statistics Dump ---(973798949)結束，在這數字是和開始行的數字一樣的。Success對伺服器或者域做出的成功查詢。定義一個成功查詢是查詢傳回非錯誤響應而不是傳回推薦響應。
Referral：導緻推薦響應查詢
Nxrrset：導緻沒有資料的非錯誤查詢的響應
Nxdomain：導緻NXDOMAIN 的查詢數量
Recursion：使伺服器運作遞歸以找出最後答案的查詢數量
Failure：導緻失敗的查詢數量
轉載于:https://blog.51cto.com/xhaa123/1955920