在DNS query報文中出現兩個questions？
抓包得到的數據都顯示的是在一個DNS query的報文中只有一個question，很好奇為什麼不會有兩個呢？
查看書上說的都是這種話：查詢部分「一般」都只有一個查詢問題。那什麼時候不「一般」？
自己編了一個報文發出去，裡面放了兩個question，結果沒有回應報文。
但是把那兩個question分到兩個DNS報文中，就很快出得到相應報文了。
自己猜測，一個查詢報文中出現兩個question的情況是不是只是在DNS主輔伺服器之間交換數據的時候而且要通過可靠的TCP協議才會出現，我上面的實驗中報文都是UDP承載的。
迷茫了，看書也找不到這是怎麼回事：（
請教一下這是為什麼？
《解決方案》
與udp數據包最大能承載的數據量有關。自己搜一下。
《解決方案》
UDP承載的DNS在早期是不能超過512位元組的，但是
其一：我發送的是query報文，我構造的報文長度是94位元組，沒有超過
其二：如果擔心是我發送的這個含有兩個question的傳輸報文可能會讓伺服器的響應報文過長的話，這個，那讓DNS伺服器截斷好了，我再去發起TCP
其三：DNS報文的Authority部分和Additional部分讓報文長度超過512位元組后即使報文被截斷，客戶端也不會新建立TCP連接去重新獲取數據（書上看到的，自己從來沒看到這樣的報文）
其四：RFC2671不是規定了DNS擴展機制使得UDP長度突破512位元組的限制（也是書上看到的，自己沒見過，見過DNS部分最長的是去看www.python.org的時候出現了一個511位元組 --！）
所以，我了解的知識關於UDP最大承載能力和為什麼query部分從沒見到兩個question聯繫不起來，請大家指教~~3Q
《解決方案》
應該和UDP早期的最大承載能力（512位元組）無關。
1. RFC 1035 留下QDCOUNT欄位，應該是考慮到擴展的需要，但是也提到「usually 1」
2. 當前的bind9實現（9.7.x）會對這樣的請求回復「格式錯」
3. （我）猜測是沒有這樣的需求和實現較複雜。
《解決方案》
謝謝樓上的兩位
我今天也試了一下，也成了format error了，是挺奇怪的，想不明白，這個「通常」為1。
那我再請教各位一下其他問題，現在我去抓DNS包，出現的都是UDP承載的，除去伺服器間的數據交互是用TCP來承載的，作為一般終端用戶（例如只是在家裡上上網的那種）有機會出現動用到TCP的嗎？
看到一個帖子說taobao會出現，我去查看也出現不了。
我看RFC的意思是拼了命的想把DNS的傳送過程弄得快點，信息能多點。。。總之就是能用UDP就用UDP，是在不行那就TCP
《解決方案》
謝謝樓上的兩位
我今天也試了一下，也成了format error了，是挺奇怪的，想不明白，這個「通常」為1。
那我 ...
sophie_stef 發表於 2010-09-03 14:44 http://bbs2.chinaunix.net/images/common/back.gif
參考下之前抓取的TCP查詢報文：
環境：bind 9.51 cache server
《解決方案》
woo。。。
謝謝6樓的silty。。。
《解決方案》
應該和UDP早期的最大承載能力（512位元組）無關。
1. RFC 1035 留下QDCOUNT欄位，應該是考慮到擴展的需要， ...
diancn 發表於 2010-09-03 11:48 http://bbs.chinaunix.net/images/common/back.gif
閣下這本書我下載了不錯 :lol:
《解決方案》
《解決方案》
回復 1# sophie_stef
出現兩個question, 理論上是可以的，但是有一個問題是，但是如果有一個問題有答案，另一個問題沒有答案，遞歸伺服器如何區別查詢的結果？之前有關於這一問題的討論，建議好像是出現兩個question時，query name必須相同（有點忘記）
