Showing posts with label bind. Show all posts
Showing posts with label bind. Show all posts

Saturday, August 7, 2010

對某台dns server進行norecurse查詢

給未來的裕翔

如果我要查一個zone, ex: aaa.bbb.com

向某台dns server查詢, ex: my.dns.server

dig +nocurse aaa.bbb.com @my.dns.server

那個+nocurse的意思可以想成

不准my.dns.server去問別人

不知道就是不知道^^

不知道就會fail

假設它預設不會知道, 但卻沒fail?

那可能是cache有答案

cache的答案可用rndc flush清除

dns的interactive!!!

給未來的裕翔

赫然發現

之前一直以為是iterative的dns 查詢方式

似乎是interactive阿!!!

測試master DNS server是否允許zone-transfer

給未來的裕翔

雖然我沒要架slave DNS server

以下指令我也沒真的去測試

不過先把看到的記下來

之後有問題就可以直接搜尋筆記了

假設有一台DNS server的ip是111.222.222.111

它負責lulumi.com網域

那我要測試它是否有對我這台機器開放zone transfer

dig -t axfr lulumi.com @111.222.222.111

-t是type

axfr是一個mechanism的名稱, 不是四個參數

或是使用指令host

host -l lulumi.com

dig也可不加那個@111.222.222.111

有加的話應該是問"111.222.222.111有否提供lulumi.com的zone transfer?"

沒加的話應該是問"是否有誰提供lulumi.com的zone transfer?"

host要加@111.222.222.111的話, 我還不確定語法上要怎麼加

沒看到範例

喔喔喔! dig的recurse和trace!!!

給未來的裕翔

雖然之前解釋過recursive和iterative查詢

不過有些觀念還不是很清楚

當我想看查詢的過程, 要加+trace

可是我man dig時, 它說recurse這bit是預設set的

不過當使用+trace的話, recurse的bit就會被disable

嗯嗯! 怎會這樣? 當我想看它遞迴查詢的過程, 居然會disable那個recurse的bit!!!

難道, +trace顯示出來的不是recurse?

想了又想, 以下是我的設想:

我是client, 我有架一台dns server, 然後有設定forwarders

當我平常dig時, 我跟dns server說"幫我查"

於是dns server去跟它的forwarders說"幫我client作recursive查詢"

然後forwarders回傳dns server一個結果, dns server也回傳我一個結果

ok, 很合理

而當我使用+trace時, 它給我查詢的過程

我一樣對dns server說"親愛的 幫我查"

而這時dns server心花怒放^^

對forwarders說"幫我一個小忙, 請問哪邊可以查到這答案"

forwarders回我的dns server一個地址

於是dns server再去那個地址問"幫我一個小忙, 請問哪邊可以查到這答案"

這樣一路問下去, dns server終於幫我搞定我要問的了

對dns server而言, 它的行為是iterative

所以我在想, 當我使用+trace時, recurse的bit被disable

就是因為對我的dns server而言, 他是一個個iterative去查的

所以平常講的recursive和iterative, 都是指dns server和forwarders之間的查詢方式!?

簡單說來, recursive查詢就是我請對方幫我搞定

iterative查詢就是我請對方告訴我一個方向

以上, 個人猜測^^"

ref: http://dns-learning.twnic.net.tw/dns/03opDNS.html

Thursday, August 5, 2010

named.conf的listen-on port 53

給未來的裕翔

這次憑印象建立重建DNS server

失敗~^^

不過就一個DNS server, 每次都能失敗其實也該頒給我獎狀...

好在有筆記^^

我就不信每次都會遇到新問題~

原來是我named.conf裡面的listen-on port 53忘記加DNS server本身的ip

加了以後就可以了

以前對於這點很納悶, 127.0.0.1不就是本身的ip嗎?

現在我在猜

那ip代表interface嗎? 是的話就解釋的通了

127.0.0.1代表lo

而DNS server的真實ip代表eth0

就當是這樣吧^^

Tuesday, July 6, 2010

named.conf語法檢查

給未來的裕翔

修改/etc/named.conf後

可以先以

named-checkconf /etc/named.conf

來檢查語法

也可以直接service named restart啦

因為

兩個的錯誤訊息居然一樣,   哈哈

但多會用一個named-checkconf感覺比較酷一些^^

host v.s. gethostip v.s. ping

給未來的裕翔

gethostip和ping會看/etc/host

但是host不會

dig的+trace

給未來的裕翔

dig可以拿來從name查ip

ex:

dig redhat.com

不過這樣的話, 單純只秀最後一段

如果想要列出從root nameserver開始的所有查詢

要加+trace

ex:

dig +trace redhat.com

會依序output一堆資訊, 一塊一塊分開

以其中一段來看
com.			172800	IN	NS	a.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
;; Received 499 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 201 ms

前面查詢的結果回傳E.ROOT-SERVERS.NET, 而它說

"我知道哪幾台DNS server是負責com domain的"

"你可以去問看看它們誰知道yahoo.com是由哪台DNS server負責的"

目前感覺是這樣, 有錯請更正^^(根本不會有人看我的這個筆記部落格......)

Monday, July 5, 2010

named的forward only

給未來的裕翔

一開始以為/etc/named.conf
裡面的forward only是把query一律丟給forwarders

所以自己設定的就會找不到

但似乎不是這樣?

它代表的意思好像是

"總是向DNS server作查詢"

(包括自己設定的和外部的)

"而不管cached answer"

後記: 不!!! 我似乎搞錯了!!!

forward only和forwarders是一組的

假設forward沒指明要only的話

它代表的意思是, 每當查詢時, 先向forwarders查詢

查不到再自己去跟root dns查詢(有cache的話當然就直接用)

所以把forward想成forward first應該是ok的

但如果指明要forward only, 那就是只會向forwarders查詢

糾正自己的感覺真爽^^

ref: http://www.akadia.com/services/howto_forward_dns.html

Tuesday, June 1, 2010

DNS雜亂小筆記

給未來的裕翔

domain name轉ip叫做名稱解析

注意, ip轉mac也叫名稱解析 => ARP

gethostip指令會參考/etc/nsswitch.conf

host和dig則是直接去找DNS, 不參考nsswitch.conf

nslookup是第三方軟體, 似乎比較少用

接著講另一個東東

今天我請我朋友A當我的DNS

我要找其他人時, 請A幫我找

A就跑去問他朋友B認不認識我要找的

B說"那個C可能知道 你去問它"

於是A又跑去問C

C說"那個D可能知道 你去問它"

假設最後找到我要找的朋友了

那A這種辛苦幫我搞定的行為

稱之為recursive query

A的朋友都指給方向, 像我實驗室博班學長一樣

那A的朋友對A來說就是忙只幫一半

non-recursive query或iterative query

ref: http://ithelp.ithome.com.tw/question/10040649

再來講另外一件事

每次查詢總是麻煩, 因此永cache server的產生

如果我要查的IP, 由cache解析給我

那就是non-authorized answer

如果是真的去外部查

那就是authorized answer

最後講指令部份

想要反解查詢的話

dig -x 12.34.56.7

這樣可以查PTR資訊

關於CNAME資訊, 想像一下

如果我有三台電腦

一台叫ftp.bob, 一台叫www.bob, 一台叫mail.bob

萬一不幸我只有一台電腦提供三個服務

(像健達出奇蛋一樣)

那就可以在DNS裡面寫下

www.bob IN CNAME real.machine

ftp.bob IN CNAME real.machine

mail.bob IN CNAME real.machine

再話一個話題

dig -t mx redhat.com

可以看那個domain裡面的mail server

Thursday, May 20, 2010

DNS的tcp和udp port

給未來的裕翔

DNS會聽tcp和udp的port 53

udp的port 53是開放查詢的

tcp的port 53是提供DNS slave server作zone transfer

Sunday, May 9, 2010

named的allow query

給未來的裕翔

如果要開放DNS服務給允許的對象

ex: 140.114.28.187

注意, IP是要加到named.confallow-query

而不是listen-on port 53

Monday, March 15, 2010

DNS server反解

給未來的裕翔

DNS server的功能就是把人類認識的文字名稱

轉成電腦認識的數字名稱(IP)


這整個過程稱為正解

因此不難猜到

反解就是從IP去查它們對應的文字名稱

以下列出在/etc/named.conf對反解所需要的設定

zone "229.114.140.in-addr.arpa" IN {
type master;
file "named.140.114.229";
};


以下列出/var/named/named.140.114.229檔案裡面的內容

$TTL 1D
@       IN SOA  @ rname.invalid. (
0       ; serial
1D      ; refresh
1H      ; retry
1W      ; expire
3H )    ; minimum
@        NS         ru129.dorm.nthu.
129     PTR     ru129.dorm.nthu.


重點依舊是最後那兩行


尤其注意那個PTR

還有就是, 兩行最右邊的host鳥哥建議附點


否則可能被自動append"229.114.140.in-addr.arpa"

像在正解裡一樣



DNS server的zone檔

給未來的裕翔

為了避免每次架設DNS server


都要擔心DNS server的失敗是不是因為zone寫錯

以下列出成功範例

$TTL 1D
@       IN SOA  @ rname.invalid. (
0         ; serial
1D      ; refresh
1H      ; retry
1W     ; expire
3H )    ; minimum
@          NS      ru129
ru129   A        140.114.229.129


由於我沒有要架設slave DNS


所以只有最後兩行重要

最後兩行的完整寫法是

dorm.nthu.                NS      ru129.dorm.nthu.
ru129.dorm.nthu.   A         140.114.229.129


白話意思是:

dorm.nthu.這個domain的name server是ru129.dorm.nthu.
而ru129.dorm.nthu.這個name server的IP是140.114.229.129

DNS server架設失敗可能原因之一

給未來的裕翔

由於更早之前的成功筆記紀錄不完全

導致我這次又失敗......

現在情況是:


iptables也設定好了

selinux雖然有開啟但預設也沒擋才

我新增的named.dorm.nthunamed.ee.nthu

也都是依過去成功筆記照打的

此時還是失敗的可能原因

終於在我檢視/var/log/messages時發現了(早該檢視了...)

named.dorm.nthunamed.ee.nthu這兩個檔案

owner.group麻煩從原來的root.root改成root.named

chown root.named named*

當初就是漏記這步驟才會造成二次失敗

Thursday, March 11, 2010

cache-only DNS server設定

給未來的裕翔

如果想要架設cache-only DNS server

只需要修改/etc/named.conf就好

假設serverIP140.114.229.129, clientIP140.114.28.187

option欄位裡添加server IPclient IP和還有forwarders

並且註解dnssec-lookaside . trust-anchor dlv.isc.org.;

以下列出/etc/named.conf最小修改內容

options {

listen-on port 53 { 127.0.0.1; 140.114.229.129; };
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     { localhost; 140.114.28.187; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
//dnssec-lookaside . trust-anchor dlv.isc.org.;
forwarders { 168.95.1.1; };


};

關於大括弧裡的格式(以ß代表空格)

listen-on port 53 {ß127.0.0.1;ß140.114.229.129;ß};
listen-on port 53 {
ß127.0.0.1;140.114.229.129;ß};
listen-on port 53 {127.0.0.1;ß140.114.229.129;};
listen-on port 53 {127.0.0.1;140.114.229.129;};



都是可以的~

server端記得在iptables添加兩行

-A INPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p udp --dport 53 -j ACCEPT



client端在測試時

記得要把DNS改成140.114.229.129


建議改在/etc/sysconfig/network-scripts/ifcfg-eth0

然後service NetworkManager start

如果改在/etc/resolv.conf

下次網路重開就會被蓋掉了



DNS server的chroot設定與觀察

給未來的裕翔

以下是我對DNS server的chroot的小小觀察

首先, 安裝套件bind-chroot

/etc/sysconfig/named最底下

添加ROOTDIR=/var/named/chroot

到此, 環境已設定好

接著, 每當named的服務開啟時

它都會把/etc/named.conf複製一份成/var/named/chroot/etc/named.conf

我觀察發現

雖然這兩個檔案彼此不是對方的連結檔


但是, 當對其中一個作修改時

另一個會馬上同步

以上