背景分享

遇到過這么一個問題，有童鞋的 Go 程序用 DNS 解析做服務發(fā)現（內網用的 CoreDNS 做的域名解析服務器）。比如，內網有個服務域名，對應 7 個后端節(jié)點。為了做服務發(fā)現，故障的剔除等服務，在 Client 端對一個給定的域名調用 Go 標準庫的 Resolver.LookupHost 方法來解析 ip 列表。如果解析得到的 ip 列表有變化，那么在 Client 內對相應的對后端節(jié)點的鏈接做創(chuàng)建和銷毀。

addrs,err:=resolver.LookupHost(ctx,/*某服務域名A*/)

//addrs的結果會變化，一會返回6個ip，一會返回7個ip

就是這么一個典型的服務發(fā)現的應用場景，還是精準踩坑。那什么坑？

坑就是：解析得到的 ip 列表反復變化，導致反復創(chuàng)、刪連接和對應的結構體。讓人誤以為 DNS 的后端節(jié)點一直在故障，從而導致一系列的問題。

還遇到另一個有趣的問題：同一份業(yè)務代碼，Go 1.15 編譯的版本總會頻繁截斷成 6 個 ip ，Go 1.16 以上的版本則非常穩(wěn)定，一直返回 7 個 ip ? 這又是為啥呢。

這個問題很簡單，但其實也很隱蔽。因為很少人會這么用，也很少人會注意到這個問題。

Go 的 DNS Lookup 的接口語義

先看下 Go 標準庫的接口語義，看下 Resolver.LookupHost 在 Go 的注釋怎么說的。文件在 Go 的標準庫 net/lookup.go ：

//LookupHostlooksupthegivenhostusingthelocalresolver.
//Itreturnsasliceofthathost'saddresses.
func(r*Resolver)LookupHost(ctxcontext.Context,hoststring)(addrs[]string,errerror){
//...
}

LookupHost 查詢一個給定的域名，返回值是一個地址列表。注意：它并沒有保證，要返回該域名的所有 ip 列表。 所以啊，這本來就是用法不對，Go 的接口沒聲明說要返回全部的 ip 。哪怕有域名對應有 100 個 ip ，這個接口只返回 1 個也是對的。

Go 1.15 和 Go 1.16之上的區(qū)別 ？

域名對應 7 個 ip ，同一份解析代碼， Go 1.15 編譯的程序時而返回 6 個？但 Go 1.16 之上的版本編譯則總是 7 個，感覺非常穩(wěn)定。為什么呢？

筆者還真翻了一下 Go 1.15 和 Go 1.16 的區(qū)別，DNS 解析的代碼幾乎一致，只在 dnsPacketRoundTrip 函數中，改了一個 buffer 的大小。

Go 1.15 是這樣的（ 文件：src/net/dnsclient_unix.go ）：

funcdnsPacketRoundTrip(cConn,iduint16,querydnsmessage.Question,b[]byte)(dnsmessage.Parser,dnsmessage.Header,error){
//發(fā)送請求
if_,err:=c.Write(b);err!=nil{
}

//創(chuàng)建一個裝響應包的buffer
b=make([]byte,512)//seeRFC1035
for{
//讀取dns響應
n,err:=c.Read(b)
//...
returnp,h,nil
}
}

Go 1.16 是這樣的（ 文件：src/net/dnsclient_unix.go ）：

const(
//MaximumDNSpacketsize.
//Valuetakenfromhttps://dnsflagday.net/2020/.
maxDNSPacketSize=1232
)

funcdnsPacketRoundTrip(cConn,iduint16,querydnsmessage.Question,b[]byte)(dnsmessage.Parser,dnsmessage.Header,error){
//發(fā)送請求
if_,err:=c.Write(b);err!=nil{
}

//創(chuàng)建一個裝響應包的buffer
b=make([]byte,maxDNSPacketSize)
for{
//讀取dns響應
n,err:=c.Read(b)
//...
returnp,h,nil
}
}

函數邏輯是發(fā)送請求給 DNS Server ，并等待它的響應。兩個版本完全一致，只有 buffer 的大小不一樣，Go 1.16 之上用了 1232 這個大小。請注意，這個大小其實是有講究的，這個值是在盡量避免 IP 包分片又能盡量多裝數據而拍的一個值。詳細看 DNS FLAG DAY 2020[1] 。

這就是 Go 1.15 ，Go 1.16 版本在內網域名解析中的差異。DNS 服務端雖然發(fā)了 7 個 ip 過來，但是 Go 1.15 編譯的版本用 512 個字節(jié) buffer 裝不下，只解析到 6 個有效 ip，Go 1.16 版本則好點，客戶端用的 1232 個字節(jié)的 buffer 大一點，差別就在這個地方。

這里有個細節(jié)提一下：

DNS 的協議，Message 的 Header 有四個字段 QDCOUNT，ANCOUNT，NSCOUNT，ARCOUNT，是指明了數據包里各個 Record 有多少個，Answer 有多少個的。但是在協議實現的時候，往往不依賴于這幾個字段，因為它們可能被偽造攻擊。所以解析的 ip 列表都是按照實際解析結果來的，解析到多少個就多少個，而不是 Header 里聲明了多少個。

//Qdcount,Ancount,Nscount,Arcountcan'tbetrusted,astheyare
//attackercontrolled.

簡單說下 DNS

DNS 協議默認使用 UDP 協議作為其傳輸層協議。UDP 的數據包是有限制的，DNS 的消息大小也是有限制的，基本大小限制為 512 字節(jié)，長消息會被截斷并且設置標記位。

所以，DNS 協議本身就從來沒承諾過，給你解析完整的 IP 列表。它這個名字對應的 IP 而已，至于全不全，它從沒承諾過。

本文并不詳細介紹 DNS 協議的原理。詳細見 RFC 1035[2] 和相關的文檔。為了突破數據包大小，或者其他的限制，也有擴展協議 EDNS ，可以參考 RFC 6891[3] 。

總之，用 DNS 解析 ip 這種方式來替代 consul 這種服務發(fā)現。感覺還是有欠缺的，或者說它的使用場景是不一樣的。

總結

Go 默認的解析方式其實有兩種，一種是 cgo 的方式調用 libc 庫的函數去解析，一種是 Go 自己的實現。本文討論的是默認的 Go 的方式。

DNS 做服務發(fā)現好像并不合適，和 consul 等組件不同。它有自己特定的協議約束著，如果一定要用 DNS 來做服務發(fā)現，那么請千萬要注意本文提到的知識點。

DNS 解析的 ip 列表，并不承諾它是全的。如果業(yè)務想用來做服務發(fā)現和剔除的功能，請千萬牢記。

DNS 服務端和客戶端的行為配合缺一不可，服務端會不會發(fā)全部？客戶端能不能收全部？各種差異都會導致解析出來的 ip 可能不一樣。