DNS&&BIND

時間 2019-11-22

原文原文鏈接

DNS：Domain Name Server，應用層協議，屬於C/S架構，使用tcp和udp(經常使用)的53號端口;web

咱們知道，當咱們訪問互聯網上的資源時，都須要具備一個IP地址，可是咱們要訪問的資源有不少，咱們是沒法記住各個資源的IP地址的，因此咱們有個解決辦法就是使用主機名來對應IP地址，由於人類對於記憶名字仍是比較拿手的，那麼問題又來了，仍是數量的問題，當名字不少時咱們仍是沒法記住，因此又有一個解決辦法出現了，那就是把名字和IP地址都記錄在文件中，須要訪問資源的時候，讓計算機本身查找文件來實現訪問資源；那麼問題又出現了，仍是數量的問題，當計算機不算多的時候使用文件記錄還能夠，可是互聯網上那麼多主機，僅僅使用一個文件來記錄，當計算機查找IP地址時的速度可想而知有多麼慢，而且網絡上的主機名是隨時都會修改，增長和刪除的，咱們也沒法實時的到最新的對應關係，因此dns服務就出現了，它能夠解決如今互聯網主機不斷增多已經沒法使用hosts文件來記錄主機名的情況；數據庫

咱們把這些數據都放在服務器上是爲了方便而且但願它能夠增長速度，可是把這些數據單純的放在服務器上，而後去查找真的會節省時間嗎，答案是否認的，沒準還會浪費時間那，由於多了一步交互的過程；因此爲了加速，其實在服務器啓動時就已經對本地的全部名字和地址的對應關係分別作了hash，而且把它放在內存中，當有客戶端來請求數據時，直接比對hash值，不一樣則響應回答，發送最新的對應關係數據，而且在hash後獲得的都是16進制數，服務器會對它們作分類處理，好比首個字符相同則存在一塊兒，這樣的話在查找時只需在16個字符中查找便可，而後再分層往下查找，因此會節省不少時間，由於是在內存中，中因此會更快；又該可是了，互聯網上的主機真的是多的沒法查清啊，因此咱們使用一臺或者一個羣組來管理這些主機名和ip的對應關係是不現實的，所以就想出了一個解決辦法，把主機名的命名名稱分層，每一個服務器之管理本身下一層的域名；<==分佈式查找緩存

tcp：面向鏈接的協議，穩定；安全

udp：無鏈接的協議，速度快；服務器

當主機想要經過主機名來訪問網絡資源時，首先會調用一個底層的庫文件，這個文件會扮演成客戶端，根據本地事先配置的dns服務器地址，到這臺服務器去請求主機名對應的IP地址，待服務器返回IP地址後，就能夠經過這個IP地址來訪問資源了；這一步對於訪問資源實際上是多餘的，很浪費時間，因此咱們就想讓它越快越好，所以選擇了udp協議；網絡

BIND：Bekerlay Internat Name Domain架構

IANA：分配域名的機構，任何人想本身構建網站而且須要經過域名來訪問，那麼就須要到這個機構去註冊域名，各地都會有相關的註冊機構，各類手續辦完以後，就能夠在全世界範圍內訪問記得域名了（可能會等一段時間：機構錄入信息和各地服務器更新學習都須要時間）；dom

本地名稱解析配置文件：/etc/hosts，主機名找IP地址tcp

格式： IP地址主機名分佈式

例子： 192.168.203.129 www.chen.com

DNS樹狀結構：namespace

DNS樹狀結構：最上層爲根(.)，下面有不少頂級域名(com,org,net等)，之下還有二級域名(通常企業或我的註冊的域名就屬於二級域名)；

Top Level Domain：tld

組織域：com，edu，mil，gov，net，int等；

國家域：cn，iq，hk等；

反向域

DNS查詢類型：

遞歸查詢：把請求發送給別人，讓它去代替本身查詢，而後等待結果便可，通常主機經過本身的服務器查詢就是遞歸；

迭代查詢：一步一步的按級查找，不是必定會直接獲得結果，可能會通過屢次查找，通常服務器幫主機查找就是迭代；

名稱服務器：域內負責解析本域名內的名稱的主機；域只是一個概念上的區域，它須要一個或一組主機來實現它，那個它就是名稱服務器，通常使用"ns"命名；

根服務器：世界上有13組根服務器；

解析類型：

正向解析：FQDN→Ip

反向解析：Ip→FQDN

正反向各須要一個解析庫來分別負責本地域名的正反和反向解析；

FQDN：徹底合格域名；

例子：www.chen.com.

查找過程：自頂向下查找；

好比查找www.chen.com 這個主機時，首先會去尋找根(.)，跟一看不是本身直接管理的主機，可是是屬於本身管理的com域中的主機，因此就將com域的信息發給客戶端，客戶端再去com域找，com域發現是本身管理的主機，就將www主機的IP地址返回給客戶端，客戶端就能夠鏈接www.chen.com了；

詳細過程：

Client→hosts文件→DNS Server：Local Cache→DNS Server(recursion遞歸)→Server Cache→iteration(迭代)→自頂向下查找過程；

客戶端首先會檢查hosts文件，若是沒有則會檢查本地緩存，如若尚未則會到事先設置的主dns服務器查詢，服務器首先會檢查本身的緩存，如若沒有才會去迭代查詢，最後將結果返回給客戶端；

DNS服務器的類型：

主DNS服務器：維護所負責解析的域內解析庫服務器，解析庫由管理員維護，可使手動的也可使用軟件；

輔助(從)DNS服務器：從主DNS服務器或其餘的從DNS服務器那裏"複製"(區域傳送)一份解析庫文件；

主從服務器須要保持數據的統一，故從服務會按期到主服務器那裏更新數據；主從之間根據序列號的大小來標識數據的新舊；

序列號：解析庫的版本，主服務器解析庫內容發生改變，序列號增大(越大越新)；

刷新時間間隔：從服務器從主服務器那裏請求同步解析庫的時間間隔；

重試時間間隔：從服務器從主服務器那裏請求同步解析庫失敗時，再次嘗試的時間間隔；

過時時長：從服務器始終聯繫不到主服務器時，多久放棄從服務器角色，中止提供服務(不會搶佔成爲主服務器)；

區域傳送：

全量傳送：傳送整個解析庫數據；

增量傳送：僅傳送解析庫變化的那部分數據；

緩存DNS服務器：沒有在互聯網上註冊域名，只是讓客戶端將它當作DNS服務器，當客戶端請求解析時，它會去請求真正提供DNS解析服務的服務器幫它解析，而後將DNS服務器返回的結果保存一份在本身的本地緩存中，而後再發送給客戶端；這樣能夠減輕公網帶寬的負擔；提供的是遞歸查詢；

轉發器

子域受權：每一個域的名稱服務器，都是經過其上級名稱服務器在解析庫中進行受權的；

chen.com. 受權過程：

相似根域受權tld：

.com. IN NS ns1.com.

.com. IN NS ns2.com.

ns1.com. IN A 9.9.9.9

ns2.com. IN A 10.10.10.10

chen.com.在.com(9.9.9.9)的名稱服務器上的解析庫中添加資源記錄；

chen.com. IN NS ns1.chen.com.

chen.com. IN NS ns2.chen.com.

ns1.chen.com. IN A 6.6.6.1

ns2.chen.com. IN A 6.6.6.2

chen.com.(6.6.6.1)本地設置；

chen.com. IN NS ns1.chen.com.

ns1.chen.com. IN A 6.6.6.1

www.chen.com. IN A 3.3.3.1

域名註冊：

中國代理商：萬網，新網；

外國代理商：godaddy

BIND的安裝配置：

dns服務：程序包名；bind，程序名：named；

程序包：

bind：主程序；

bind-libs：band和相關命令使用的函數庫；

bind-utils：客戶端查找主機名的相關命令；(host,dig,nslookup)

bind-chroot：將bind主程序的根目錄限制到/var/named/chroot

Note：測試環境能夠不裝，生產環境建議安裝；

bind：

服務腳本：/etc/rc.d/init.d/named

主配置文件：/etc/named.conf,/etc/named.rfc1912.zones,/etc/rndc.key

全局配置：options { }

日誌子系統配置：logging { }

區域定義；本機可以爲哪些zone提供解析，就要定義哪些zone；

zone "ZONE_NAME.zone" IN { }

注意：任何服務程序若是指望其可以經過網絡被其餘主機訪問，至少應該監聽在一個能與外部主機通訊的ip地址上

解析庫文件：/var/named/ZONE_NAME.zone

注意：

1.一臺物理服務器可同時爲多個區域提供解析；

2.必需要有根區域文件；

3.應該有兩個實現localhost和本地迴環地址的解析庫，用來聯繫本身；

rndc：remote name domain controller，默認與bind安裝在同一主機，且只能經過127.0.0.1來鏈接named進程；提供輔助性的管理功能；使用953/tcp

緩存名稱服務器的配置：

監聽外部地址便可；

dnssec：與dns的安全有關，對dns服務解析時的每個解析包文都要加數字簽名，作校驗，但配置麻煩；測試環境建議關閉，在配置文件中便可關閉 "dnssec-enable no"；

主zone DNS名稱服務器：

正向解析：

1.在主配置文件中定義區域；/etc/named.conf：

options {

listen-on port 53 { 192.168.10.20; 127.0.0.1; };

// listen-on-v6 port 53 { ::1; };

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 { any; };

recursion yes;

// dnssec-enable yes;

// dnssec-validation yes;

/* Path to ISC DLV key */

bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

};

/etc/named.rfc1912.zones：

zone "chen.com" IN {

type master ;

file "chen.com.zone" ;

};

zone "10.168.192.in-addr.arpa" IN {

type master ;

file "10.168.192.in-addr.arpa.zone" ;

};

2.定義區域解析庫文件；/var/named/chen.com.zone

宏定義:

$TTL 時間(s)

$ORIGIN 域名(chen.com.)

資源記錄:

/var/named/chen.com.zone ：

$TTL 86400

@(代指區域) IN SOA na1.chen.com.(區域名或者主dns服務器名) admin.chen.com.(管理員郵箱地址) (

2018103001 序列號

1H 更新時間

5M 失敗後重連時間

7H 失效時間

1D 緩存時間 )

chen.com.(與上一條內容相同，則能夠省略) IN NS ns1.chen.com.

chen.com. IN NS ns2.chen.com.

chen.com. IN MX 10 mail.chen.com.

ns1 IN A 192.168.10.20

ns2.chen.com. IN A 192.168.10.1

mail IN A 192.168.10.20

www.chen.com. IN A 192.168.10.20

web.chen.com. IN CNAME www.chen.com.

反向解析：

區域名稱：網絡地址反寫.in-addr.arpa.

192.168.10. →10.168.192.in-addr.arpa.

定義區域：

zone "ZONE_NAME" IN {

type {master|slave|forward};

file "網絡地址.zone" ;

};

區域解析庫文件：

不須要A,AAAA,MX等記錄，以NS及PTR爲主；

/var/named/10.168.192.in-addr.arpa.zone ：

$TTL 86400

10.168.192.in-addr.arpa. IN SOA ns1.chen.com. admin.chen.com. (

2018103001

10M

1D )

10.168.192.in-addr.arpa. IN NS ns1.chen.com.

10.168.192.in-addr.arpa. IN NS ns2.chen.com.

20 IN PTR ns1.chen.com.

1 IN PTR ns2.chen.com.

20 IN PTR mail.chen.com.

20 IN PTR www.chen.com.

檢查配置文件語法是否有錯：

named-checkconf [區域配置文件]

named-checkzone ：檢查解析庫文件語法是否正確；

例如：named-checkzone "chen.com" /var/named/chen.com.zone

Note：最後須要修改區域文件的權限(640)，屬主爲root，屬組爲named；

從zone DNS名稱服務器：

定義從區域正向解析：

zone "chen.com" IN {

type slave;

masters { MASTRT_IP; };

file "slaves/chen.com.zone";

};

定義從服務器反向解析：

zone "10.168.192.in-addr.arpa" IN {

type slave;

masters { MASTER_IP; };

file "slaves/10.168.192.in-addr.arpa.zone

通常咱們修改DNS配置的時候都是修改主服務器，不會修改從服務器，因此咱們但願傳送過來的文件，dns服務使用的用戶named對它具備讀寫權限，默認named用戶或組對/var/named/目錄沒有寫權限，可是對/var/named/slaves/目錄具備讀寫權限，因此通常默認會將文件放在這個目錄中，不然沒法從主服務器傳輸配置文件到從服務器；

咱們上面說過從服務器會定時到主服務器那裏同步解析庫文件的數據，而且當主服務器修改之後還會主動通知從服務器來作同步，那麼是怎麼通知的那，其實很簡單，就是在主服務器的區域配置文件中要設置從服務器的NS和A的記錄，讓主服務器能夠找到從服務器便可；

主從複製：

1.主從都應該是一臺獨立的服務器；

2.主服務器的區域解析庫文件中必須有一條NS記錄是指向從服務器的；

3.從服務器只需定義區域，無需提供解析庫文件；解析庫文件應該放置於/var/named/slaves/目錄中；

4.主服務器容許從服務器作區域傳送，通常這個是須要管理員作限制的，只容許從服務器作傳送，其餘的都應該被禁止；

5.主從服務器時間應該同步，能夠經過使用ntp進行同步；

6.bind程序的版本應該保持一致，若是不一致，從應該比主新；

由於正反域都是獨立的區域，因此能夠獨立設置；所以正反、主從服務器可使用多個主機，例如A爲正主，B爲反主，C爲正從，D爲反從；若是是三個dns主機，一主兩從，可使兩個主機是同一個主機的從，也可使一個主機是另外一個從的從；

測試命令：dig，nslookup，host

dig：DNS lookup utility

dig用於測試dns系統，所以不會查詢hosts文件；

dig [-t type] name [@server] [query options]

選項：

-x IP_ADDR：反向解析；

-t type：A,PTR,SOA,MX等；

+[no]trace：跟蹤解析過程；

+[no]recurse：進行遞歸解析；

模擬全量區域傳送：

dig -t axfr zone_name @server_ipaddr

nslookup：query Internet name servers interactively

nslookup [options] [FQDN] [server]

交互式模式：

nslookup>

server IP：指明使用哪一個DNS server進行查詢；

set type=any：列出全部正解信息；

set q=RR_TYPE：指明查詢的資源記錄類型；

host：DNS lookup utility

host [-a] FQDN [server]

選項：

-a：列出該主機全部相關信息；

-l：列出該domain所管理的全部主機名對應的數據；

-t type：A，PTR，SOA，MX等；

rndc：name server control utility

當dns服務啓動時rndc也會跟着啓動，它就像服務器同樣監聽在953端口，咱們能夠經過客戶端鍵入rndc命令來管理dns服務；可是默認狀況下rndc不容許遠程使用，只能夠在本地使用；由於若是rndc出現bug被不良人利用豈不是完蛋了；

COMMAND：

reload：重載主配置文件和區域解析庫文件；

重載意義重大啊，別看咱們在學習測試時每每隨意就從新啓動服務，可是在生產環境中服務不是隨便就可以重啓的，不然可能會形成在成巨大的損失，可能會被炒呦！切記！！！

reload zone：重載區域解析庫文件；

retransfer zone：手動啓動其他傳送過程，且無論序列號是否增長；

notify zone：從新對區域傳送發通知；

reconfig：重載主配置文件；

querylog：開啓或關閉查詢日誌；

通常狀況處於關閉狀態，除非是出現問題時，排錯時才建議啓動；爲了確保突發證況下日誌文件不丟失，通常日誌都是同步寫入的，這樣的話就會加大內存與磁盤的I/O，增長服務器負載，因此建議關閉；

trace：遞增debug級別；

trace LEVEL：直接設置debug級別；

能夠經過rndc-h來查看選項幫助；

本身定義受權子域：分佈式數據庫；

正向解析區域子域受權：

在上一級服務器中須要定義子區域：

stk.chen.com. IN NS ns1.stk.chen.com.

stk.chen.com. IN NS ns2.stk.chen.com.

ns1.stk.chen.com. IN A 192.168.20.1

ns2.stk.chen.com. IN A 192.168.20.2

在子域中配置主機名：

stk.chen.com. IN NS ns1.stk.chen.com.

stk.chen.com. IN NS ns2.stk.chen.com.

ns1.stk.chen.com. IN A 192.168.20.1

ns2.stk.chen.com. IN A 192.168.20.2

www.stk.chen.com. IN A 192.168.20.10

ftp.stk.chen.com. IN A 192.168.20.20

定義轉發服務器：

注意：被要求轉發的服務器須要可以爲請求者作遞歸，不然轉發請求不予進行；

轉發的意義：

咱們假設一種狀況，在chen.com.域中有stk.chen.com.這個子域；當子域中www這個主機想訪問父域chen.com.中的www主機時，若是不設置轉發，則子域中www主機會直接找根來解析父域中的www主機；這是很不合理的，因此咱們在這種狀況下就須要設置轉發功能；父域查找子域中的主機時就不須要，由於父域是知道子域服務器的位置的；

所有轉發：凡是非本機所負責解析的請求，都轉交給指定服務器，請求他代爲查詢，在主配置文件的options中定義；

options {

...

forward {first|only};

forwarders { IP };

}；

first：表示當客戶端請求的主機解析不是本身所管理的，就轉發給指定服務器，若是他沒有返回解析結果，就本身找根去解析；遞歸不成就迭代；

only：表示當客戶端請求的主機解析不是本身所管理的，就轉發給指定服務器，哪怕他不給解析，也不作處理，就像把本身的但願放到了別人的手裏；僅遞歸；

區域轉發：僅轉發對特定的區域的請求至指定服務器，在區域配置文件中定義；

zone "ZONE_NAME" IN {

type forward;

forward {first|only};

forwarders { IP; };

};

Note：使用yum安裝的dnssec是啓用的，因此作轉發服務器的時候可能會很差使，建議關閉(學習測試環境中)；

dnssec-enable no;

dnssec-validation no;

BIND中基礎的與安全相關的配置：

acl：將一個或多個主機歸併爲一個集合，並經過一個統一的名稱調用；

acl ACL_NAME {

IP;

NET/prelen; ==>192.168.10.0/24;

…;

};

bind有四個內置的acl：能夠直接調用的；

none：沒有主機；

any：任意主機；

local：本機：

localnet：本機的IP同掩碼運算後獲得的網絡地址；

注意：只能先定義，後使用；所以，其通常定義在配置文件中options的前面；

訪問控制的指令(能夠在options中設置，也能夠在zone中)：

allow-query { }；：容許作查詢的主機；相似設置白名單；通常是any；

allow-transfer { }；：容許區域傳送的主機；白名單；

allow-recursion { };：容許遞歸的主機；白名單；

allow-update { };：容許更新區域數據庫中的內容；通常不容許經過其餘服務更新，好比使用DHCP更新，每次重啓服務或從新開機時ip地址可能會有變更而致使錯誤，建議不容許任何人更新=>"none"；

BIND view(視圖)：自上而下檢查

視圖的做用是：能夠根據不一樣用戶訪問同一域名時所處的位置不一樣而指定不一樣的服務器爲其解析(經過指定不一樣的解析庫文件來實現)；

一個bind服務器能夠定義多個view，每一個view能夠定義一個或多個zone；

每一個view用來匹配一組客戶端；

多個view內可能須要對同一個區域解析，可是用不一樣的區域解析庫文件；

view VIEW_NAME {

…

match-clients { }; 匹配的客戶端；

};

能夠經過view來實現僅對本身本地管理的客戶端進行遞歸，來自其餘的客戶端不予遞歸；

Note：1.一旦使用了view，全部的zone都只能定義在view中；(包括".")

2.僅有必要在匹配到容許遞歸請求的客戶所在view中定義根區域；

3.客戶端請求到達時，是自上而下檢查每一個view所服務的客戶端列表的(像優先被匹配的應該放在上面)；

智能DNS提供商：

dnspod，dns.la

相關標籤/搜索

系統網絡

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。