歡迎您光臨本站 註冊首頁

不同線路的DNS解析疑惑?

←手機掃碼閱讀     火星人 @ 2014-03-04 , reply:0

不同線路的DNS解析疑惑?

這裡以img.alimama.cn域名為例,它有三個DNS解析伺服器:
gtm2.glb.cnz.alimama.com.
gtm1.glb.cnz.alimama.com.
gtm1.glb.cdn.alimama.com.

而我用dig img.alimama.cn +trace它時,最後一段的結果順序都是不一樣的(一般第三次就會變),如下:
1,
;; Received 123 bytes from 203.119.25.1#53(a.dns.cn) in 28 ms
img.alimama.cn.         300     IN      CNAME   img.glb.alimama.com.
glb.alimama.com.        300     IN      NS      gtm2.glb.cnz.alimama.com.
glb.alimama.com.        300     IN      NS      gtm1.glb.cnz.alimama.com.
glb.alimama.com.        300     IN      NS      gtm1.glb.cdn.alimama.com.
2,
;; Received 123 bytes from 203.119.25.1#53(a.dns.cn) in 31 ms
img.alimama.cn.         300     IN      CNAME   img.glb.alimama.com.
glb.alimama.com.        300     IN      NS      gtm1.glb.cnz.alimama.com.
glb.alimama.com.        300     IN      NS      gtm2.glb.cnz.alimama.com.
glb.alimama.com.        300     IN      NS      gtm1.glb.cdn.alimama.com.

是不是哪個NS在前面就是哪個NS負責返回解析結果?  (我覺得是,只是不太肯定)

2,如果這三個NS有一個掛了,而本地DNS中的cache剛好過期了,按上面的說法,就會有三分之一的請求得不到結果? (我覺得肯定是,只是想得到大家的證實)

3,如果這三個ns中有一台放到的網通的線路中,其它兩台在電信的線路中,如果有一個網通的用戶訪問img.alimama.cn,在它請求DNS解析時會有3/2的機會被解析到電信,按中國網路的結構,網通訪問電信肯定會慢些,這樣的話會不會增加相應的解析時間? (我覺得是,只是這個時間太小,大家可以用www.douban.com測試,它的兩個DNS,一個是美國,一個在北京,但兩個解析的時間相差也不是很大)

[ 本帖最後由 dgvri 於 2010-1-21 15:54 編輯 ]
《解決方案》

1. 如果權威DNS有多個,每次+trace時會輪詢使用這些DNS。具體每次是那個會在返回的結果裡面列出。
2.基本上影響不大,不是想象的1/3無法解析,+trace與正常的域名解析(遞歸查詢)的過程是不一樣的。
3.公網DNS與權威DNS通信過程中,公網DNS(即遞歸DNS),會自動聯繫較快的權威DNS(不是機械的輪詢)

[ 本帖最後由 llzqq 於 2010-1-21 15:57 編輯 ]
《解決方案》

1,
# dig @202.106.0.20 www.sina.com.cn +trace

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> @202.106.0.20 www.sina.com.cn +trace
; (1 server found)
;; global options:  printcmd
.                       450455  IN      NS      E.ROOT-SERVERS.NET.
....................
.                       450455  IN      NS      B.ROOT-SERVERS.NET.
;; Received 228 bytes from 202.106.0.20#53(202.106.0.20) in 599 ms  ##由202.106.0.20返回.域的地址

cn.                     172800  IN      NS      E.DNS.cn.
...............................
cn.                     172800  IN      NS      NS.CERNET.NET.
;; Received 296 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 314 ms ##由E.ROOT-SERVERS.NET返回cn域的地址

sina.com.cn.            21600   IN      NS      ns2.sina.com.cn.
sina.com.cn.            21600   IN      NS      ns3.sina.com.cn.
sina.com.cn.            21600   IN      NS      ns1.sina.com.cn.
;; Received 135 bytes from 203.119.29.1#53(E.DNS.cn) in 3091 ms   ##由E.DNS.cn返回sina.com.cn的權威DNS地址

www.sina.com.cn.        60      IN      CNAME   jupiter.sina.com.cn.
jupiter.sina.com.cn.    600     IN      CNAME   hydra.sina.com.cn.
hydra.sina.com.cn.      60      IN      A       218.30.108.188
........................................................
hydra.sina.com.cn.      60      IN      A       218.30.108.185
sina.com.cn.            86400   IN      NS      ns3.sina.com.cn.
sina.com.cn.            86400   IN      NS      ns1.sina.com.cn.
sina.com.cn.            86400   IN      NS      ns2.sina.com.cn.
;; Received 433 bytes from 202.106.184.166#53(ns1.sina.com.cn) in 400 ms   ##由權威ns1.sina.com.cn返回解析地址
是這樣的吧?

2,方便說說怎麼不一樣嗎?舉個例子.

3,公網DNS怎麼去判斷權威DNS是否正常?bind里有這種功能嗎?
《解決方案》

1.是這個過程

2.各地公網DNS會自動發現故障的權威DNS,轉而聯繫其他的權威DNS,這就是為何要使用多台權威DNS的主要原因。+trace后公網DNS是嚴格遵守子上而下的順序得到需要的結果,這時如果一個恰巧被查詢的權威DNS故障了,就得不到結果了。

3.BIND有種演算法(RTT)來判斷最快的權威DNS,實際工作中我們會發現線路質量好的伺服器會承載較多的查詢量。


這是關於RTT的一段概述:
Given a choice of servers, which one is queried?

Every recursive BIND name server (that is, one which is willing to go out and find something if asked something it doesn't know) will remember the measured round trip time (RTT) to each server it sends queries to. If it has a choice of several servers for some domain (like "." for example) it will use the one whose measured RTT is lowest.
Since the measured RTT of all NS RRs starts at zero (0), every one is tried once. Once all have responded, all RTT's will be nonzero, and the "fastest server" will get all queries henceforth, until it slows down for some reason.
To promote dispersion and good recordkeeping, BIND will penalize the RTT by a little bit each time a server is reused, and it will penalize the RTT a _lot_ if it ever has to retransmit a query. For a server to stay "#1", it has to keep on answering quickly and consistently.
Note that this is something BIND does that the DNS Specification does not mention at all. So other servers, those not based on BIND, might behave very differently.

[ 本帖最後由 llzqq 於 2010-1-21 19:52 編輯 ]
《解決方案》

比較容易理解,就不翻譯了,
《解決方案》

OK.
好好看看.
多謝了.
《解決方案》

嗯,學習了
《解決方案》

更正4樓 2小節最後的「這時如果一個恰巧被查詢的權威DNS故障了,就得不到結果了」有誤。  正確的應該為「這時如果一個恰巧被查詢的權威DNS故障了,會轉向查詢另外的權威DNS」
《解決方案》

OK.
學習中

[火星人 ] 不同線路的DNS解析疑惑?已經有489次圍觀

http://coctec.com/docs/service/show-post-19023.html