CoreDNS 手冊

涵蓋取得與執行 CoreDNS 各個層面的手冊。

這份手冊尚在撰寫中！歡迎協助！如果您想協助，請參閱本手冊的原始碼。您可以透過發送 Pull Request 或提出Issue，具體說明您希望在此處看到解決的內容、任何遺失的內容或只是令人困惑的部分。

– CoreDNS 作者群

目錄

 

修改日期：

什麼是 CoreDNS？

CoreDNS 是一個 DNS 伺服器。它以 Go 語言撰寫。

CoreDNS 與其他 DNS 伺服器（例如：BIND、Knot、PowerDNS 和 Unbound（嚴格來說是解析器，但仍值得一提），這些都是非常出色的伺服器）不同，因為它非常靈活，幾乎所有功能都外包給外掛程式。

外掛程式可以是獨立的，也可以一起運作以執行「DNS 功能」。

那麼「DNS 功能」是什麼？就 CoreDNS 而言，我們將其定義為實作 CoreDNS 外掛程式 API 的軟體。所實作的功能可能會大不相同。有些外掛程式本身不會產生回應，例如 metrics 或 cache，但會增加功能。然後有些外掛程式會產生回應。這些外掛程式也可以執行任何操作：有些外掛程式會與 Kubernetes 通訊以提供服務探索，有些外掛程式會從檔案或資料庫讀取資料。

目前，預設的 CoreDNS 安裝中包含約 30 個外掛程式，但您也可以將大量外部外掛程式編譯到 CoreDNS 中，以擴展其功能。

CoreDNS 由外掛程式驅動。

撰寫新的外掛程式應該相當容易，但需要了解 Go 以及對 DNS 的運作方式有一定的了解。CoreDNS 抽離了許多 DNS 詳細資訊，因此您可以專注於撰寫您需要的外掛程式功能。

 

修改日期：

安裝

CoreDNS 以 Go 語言撰寫，但除非您想開發外掛程式或自行編譯 CoreDNS，否則您可能不在乎。以下章節詳細說明如何取得 CoreDNS 二進位檔或從原始碼安裝。

二進位檔

對於每個 CoreDNS 版本，我們都會為各種作業系統提供預先編譯的二進位檔。對於 Linux，我們還為 ARM、PowerPC 和其他架構提供交叉編譯的二進位檔。

Docker

我們也會將每個版本推送為 Docker 映像檔。您可以在 CoreDNS 組織的公開 Docker Hub 中找到它們。此 Docker 映像檔基本上是scratch + CoreDNS + TLS 憑證（用於 DoT、DoH 和 gRPC）。

原始碼

若要編譯 CoreDNS，我們假設您已設定好可用的 Go 環境。如果您尚未設定，請參閱各種教學課程。CoreDNS 使用 Go 模組進行相依性管理。

關於如何編譯內容的最新文件保留在coredns 原始碼中。

測試

取得 coredns 二進位檔後，您可以使用 -plugins 旗標來列出所有已編譯的外掛程式。如果沒有 Corefile（請參閱組態設定），CoreDNS 將載入whoami 外掛程式，該外掛程式將會回應用戶端的 IP 位址和連接埠。因此，若要進行測試，我們啟動 CoreDNS 以在連接埠 1053 上執行，並使用 dig 發送查詢。

$ ./coredns -dns.port=1053
.:1053
2018/02/20 10:40:44 [INFO] CoreDNS-1.0.5
2018/02/20 10:40:44 [INFO] linux/amd64, go1.10,
CoreDNS-1.0.5
linux/amd64, go1.10,

在另一個終端機視窗中，dig 應該會傳回類似以下的內容

$ dig @localhost -p 1053 a whoami.example.org

;; QUESTION SECTION:
;whoami.example.org.		IN	A

;; ADDITIONAL SECTION:
whoami.example.org.	0	IN	AAAA	::1
_udp.whoami.example.org. 0	IN	SRV	0 0 39368 .

下一節將說明如何啟用更多有趣的外掛程式。

 

修改日期：

外掛程式

CoreDNS 啟動並剖析組態後，它會執行伺服器。每個伺服器都由其服務的區域和連接埠定義。每個伺服器都有自己的外掛程式鏈。

當 CoreDNS 正在處理查詢時，會執行以下步驟

  1. 如果設定了多個在查詢連接埠上接聽的伺服器，它會檢查哪一個伺服器具有此查詢最特定的區域（最長字尾比對）。例如，如果有兩個伺服器，一個用於 example.org，另一個用於 a.example.org，而查詢是針對 www.a.example.org，則會將其路由到後者。

  2. 找到伺服器後，會將其路由到為此伺服器設定的外掛程式鏈。這總是按照相同的順序發生。該（靜態）順序在plugin.cfg中定義。

  3. 每個外掛程式都會檢查查詢，並判斷是否應處理它（某些外掛程式允許您進一步篩選查詢名稱或其他屬性）。現在可能會發生以下幾件事

    1. 此外掛程式會處理查詢。
    2. 此外掛程式不會處理查詢。
    3. 此外掛程式會處理查詢，但在中途決定它仍然想要呼叫鏈中的下一個外掛程式。在啟用它的關鍵字之後，我們將其稱為回溯。
    4. 此外掛程式會處理查詢，新增「提示」，並呼叫下一個外掛程式。此提示提供了一種「查看」 (最終) 回應並對其執行動作的方法。

處理查詢表示外掛程式會以回覆回應用戶端。

請注意，外掛程式可以隨意偏離以上列表。不過，目前所有 CoreDNS 隨附的外掛程式都屬於這四個群組之一。請注意，這篇部落格文章也提供了查詢路由的背景資訊。

查詢已處理

外掛程式會處理查詢。它會查詢（或產生，或外掛程式作者決定這個外掛程式的功能）回應，並將其傳回給用戶端。查詢處理會在此處停止，不會呼叫下一個外掛程式。像這樣運作的（簡單）外掛程式是whoami。

查詢未處理

如果外掛程式決定不處理查詢，它只會呼叫鏈中的下一個外掛程式。如果鏈中的最後一個外掛程式決定不處理查詢，CoreDNS 會將 SERVFAIL 傳回給用戶端。

查詢已處理，並回溯

在這種情況下，外掛程式會處理查詢，但從後端取得的回覆 (例如，可能是 NXDOMAIN) 使得它希望鏈中的其他外掛程式也查看。如果提供了回溯（且已啟用！），則會呼叫下一個外掛程式。像這樣運作的外掛程式是hosts 外掛程式。首先，會嘗試在主機表格 (/etc/hosts) 中查詢，如果找到答案，則會傳回該答案。如果找不到，則會回溯到下一個，希望其他外掛程式可以傳回一些內容給用戶端。

查詢已處理，並帶有提示

這種外掛程式會處理查詢，並且始終會呼叫下一個外掛程式。但是，它會提供提示，使其能夠查看將寫入用戶端的回應。執行此動作的外掛程式是prometheus。它會計算持續時間（以及其他內容），但實際上不會對 DNS 請求執行任何操作 - 它只會將其傳遞並檢查傳回路徑上的一些中繼資料。

未註冊的外掛程式

還有另一種特殊類別的外掛程式，它們完全不處理任何 DNS 資料，但會以其他方式影響 CoreDNS 的行為。例如，以bind 外掛程式為例，它會控制 CoreDNS 應繫結到哪些介面。以下外掛程式屬於此類別

  • bind - 如前所述，控制繫結到哪些介面。
  • root - 設定 CoreDNS 外掛程式應尋找檔案的根目錄。
  • health - 啟用 HTTP 健康檢查端點。
  • ready - 支援外掛程式的就緒報告。

外掛程式的剖析

外掛程式由設定、註冊和處理常式部分組成。

設定會剖析組態和外掛程式的指示詞（這些指示詞應在外掛程式的 README 中記錄）。

處理常式是處理查詢並實作所有邏輯的程式碼。

註冊部分會在 CoreDNS 編譯時註冊 CoreDNS 中的外掛程式。伺服器可以使用所有已註冊的外掛程式。在每個伺服器中設定哪些外掛程式的決策會在執行階段發生，並在 CoreDNS 的組態檔 Corefile 中完成。

外掛程式文件

每個外掛程式都有自己的 README，詳細說明如何設定它。此 README 包括範例以及使用者應注意的其他事項。每個 README 都會出現在 https://coredns.dev.org.tw/plugins 上，我們也會將它們編譯到手冊頁面中。

 

修改日期：

組態設定

CoreDNS 中可以設定各種內容。首先是決定要將哪些外掛程式編譯到 CoreDNS 中。我們提供的二進位檔已編譯了plugin.cfg 中列出的所有外掛程式。新增或移除很容易，但需要重新編譯 CoreDNS。

因此，大多數使用者會使用 Corefile 來設定 CoreDNS。當 CoreDNS 啟動且未指定 -conf 旗標時，它會在目前目錄中尋找名為 Corefile 的檔案。該檔案包含一個或多個伺服器區塊。每個伺服器區塊都會列出一個或多個外掛程式。可以使用指示詞進一步設定這些外掛程式。

在 Corefile 中，外掛程式的順序並不會決定外掛程式鏈的執行順序。外掛程式的執行順序是由 plugin.cfg 中的順序所決定。

Corefile 中的註解是以 # 開頭。該行剩下的部分都會被視為註解。

環境變數

CoreDNS 支援在其設定中使用環境變數替換。它們可以在 Corefile 中的任何地方使用。語法為 {$ENV_VAR}（也支援更像 Windows 的語法 {%ENV_VAR%}）。CoreDNS 在解析 Corefile 時會替換變數的內容。

匯入其他檔案

請參閱 import 外掛程式。此外掛程式比較特別，因為它可以放在 Corefile 中的任何地方。

可重複使用的程式碼片段

匯入檔案的一種特殊情況是程式碼片段。程式碼片段是透過使用特殊語法命名一個區塊來定義。名稱必須放在括號中：(name)。之後，可以使用 import 外掛程式將其包含在設定的其他部分中。

# define a snippet
(snip) {
    prometheus
    log
    errors
}

. {
    whoami
    import snip
}

伺服器區塊

每個伺服器區塊都以伺服器應作為權威伺服器的網域開始。在網域名稱或網域名稱列表（以空格分隔）之後，伺服器區塊會以左大括號開啟。伺服器區塊會以右大括號關閉。以下伺服器區塊指定了一個負責根網域下所有網域的伺服器：.；基本上，此伺服器應處理每個可能的查詢

. {
    # Plugins defined here.
}

伺服器區塊可以選擇性地指定要監聽的埠號。預設值為埠 53（DNS 的標準埠）。指定埠號的方式是在網域後面以冒號分隔列出埠號。此 Corefile 指示 CoreDNS 建立一個監聽埠 1053 的伺服器

.:1053 {
    # Plugins defined here.
}

注意：如果您明確為伺服器定義了監聽埠，則無法使用 -dns.port 選項覆寫它。

使用已指派給伺服器的網域且在同一埠上執行來指定伺服器區塊是錯誤的。此 Corefile 將在啟動時產生錯誤

.:1054 {

}

.:1054 {

}

將第二個埠號變更為 1055 會使這些伺服器區塊成為兩個不同的伺服器。請注意，如果您使用 bind 外掛程式，則可以讓相同的網域監聽相同的埠，前提是它們繫結到不同的介面或 IP 位址。這裡使用的語法自 CoreDNS 1.8.4 版本起支援。

.:1054 {
    bind lo
    whoami
}

.:1054 {
    bind eth0
    whoami
}

啟動時會列印如下內容

.:1054 on ::1
.:1054 on 192.168.86.22
.:1054 on 127.0.0.1

指定協定

目前 CoreDNS 接受四種不同的協定：DNS、DNS over TLS (DoT)、DNS over HTTP/2 (DoH) 和 DNS over gRPC。您可以透過在網域名稱前面加上協定方案，來指定伺服器應接受的協定。

  • dns:// 表示純 DNS（如果未指定任何協定方案，則為預設值）。
  • tls:// 表示 DNS over TLS，請參閱 RFC 7858。
  • https:// 表示 DNS over HTTPS，請參閱 RFC 8484。
  • grpc:// 表示 DNS over gRPC。

外掛程式

每個伺服器區塊都指定了應該針對此特定伺服器鏈接的多個外掛程式。在最簡單的形式中，您只需在伺服器區塊中使用其名稱即可新增外掛程式

. {
    chaos
}

chaos 外掛程式會讓 CoreDNS 回答 CH 類別中的查詢 - 這對於識別伺服器很有用。使用上述設定，CoreDNS 在收到請求時會回答其版本

$ dig @localhost -p 1053 CH version.bind TXT
...
;; ANSWER SECTION:
version.bind.		0	CH	TXT	"CoreDNS-1.0.5"
...

大多數外掛程式都允許使用指令進行更多設定。以 chaos 外掛程式為例，我們可以指定 VERSION 和 AUTHORS，如其語法所示

語法

  chaos [VERSION] [AUTHORS...]
  • VERSION 是要傳回的版本。如果未設定，則預設值為 CoreDNS-<版本>。
  • AUTHORS 是要傳回的作者。預設值為 OWNER 檔案中指定的所有人員。

因此，這會為 chaos 外掛程式新增一些指令，使 CoreDNS 以 CoreDNS-001 作為其版本回應

. {
    chaos CoreDNS-001 info@coredns.io
}

具有更多設定選項的其他外掛程式具有外掛程式區塊，就像伺服器區塊一樣，它也用左大括號和右大括號括起來

. {
    plugin {
       # Plugin Block
    }
}

我們可以將所有這些組合起來，並擁有以下 Corefile，該檔案設定了在兩個不同埠上服務的 4 個網域

coredns.io:5300 {
    file db.coredns.io
}

example.io:53 {
    log
    errors
    file db.example.io
}

example.net:53 {
    file db.example.net
}

.:53 {
    kubernetes
    forward . 8.8.8.8
    log
    errors
    cache
}

當 CoreDNS 解析時，這將產生以下設定

CoreDNS: Zones, plugins and query routing

外部外掛程式

外部外掛程式是未編譯到預設 CoreDNS 中的外掛程式。您可以輕鬆啟用它們，但您需要自行編譯 CoreDNS。

可能發生的錯誤

health 外掛程式的文件指出「此外掛程式只需要啟用一次」，這可能會讓您認為這是一個有效的 Corefile

health

. {
    whoami
}

但這無法運作，並且會導致一些難以理解的錯誤

"Corefile:3 - Error during parsing: Unknown directive '.'".

這裡發生什麼事？health 被視為一個網域（以及伺服器區塊的開頭）。解析器預期看到外掛程式名稱 (cache、etcd 等)，但下一個權杖是 .，而不是外掛程式。Corefile 應該建構如下

. {
    whoami
    health
}

health 外掛程式的文件中的那行表示一旦指定了 health，它就會針對整個 CoreDNS 處理程序全域生效，即使您只為一台伺服器指定它也是如此。

 

修改日期：

設定

在這裡您可以找到許多 CoreDNS 的設定。假設所有設定都是在您不是 root 使用者的情況下完成的，因此無法開始監聽埠 53。我們將改為使用埠 1053，並使用 -dns.port 旗標。在每個設定中，使用的設定檔都是 CoreDNS 的預設檔案，名為 Corefile。這表示我們不需要使用 -conf 旗標來指定設定檔。換句話說，我們使用 ./coredns -dns.port=1053 -conf Corefile 來啟動 CoreDNS，這可以縮寫為 ./coredns -dns.port=1053。

所有 DNS 查詢都將使用 dig 工具產生，這是偵錯 DNS 的黃金標準。我們在這裡使用的完整命令列是

$ dig -p 1053 @localhost +noall +answer <name> <type>

但我們在下面的設定中縮短了它，因此 dig www.example.org A 實際上是 dig -p 1053 @localhost +noall +answer www.example.org A

從檔案提供權威服務

此設定使用 file 外掛程式。請注意，外部的 redis 外掛程式可從 Redis 資料庫提供權威服務。讓我們繼續使用 file 進行設定。

我們在這裡建立的檔案是 DNS 網域檔案，它可以有任何名稱（file 外掛程式不在意）。我們放入檔案中的資料是針對網域 example.org.。

在您目前的工作目錄中，建立一個名為 db.example.org 的檔案，並將以下內容放入其中

$ORIGIN example.org.
@	3600 IN	SOA sns.dns.icann.org. noc.dns.icann.org. (
				2017042745 ; serial
				7200       ; refresh (2 hours)
				3600       ; retry (1 hour)
				1209600    ; expire (2 weeks)
				3600       ; minimum (1 hour)
				)

	3600 IN NS a.iana-servers.net.
	3600 IN NS b.iana-servers.net.

www     IN A     127.0.0.1
        IN AAAA  ::1

最後兩行定義了一個名稱 www.example.org.，其中包含兩個位址：127.0.0.1 和（IPv6）::1。

接下來，建立這個最小的 Corefile，它會處理此網域的查詢，並新增 log 外掛程式以啟用查詢記錄

example.org {
    file db.example.org
    log
}

啟動 CoreDNS 並使用 dig 查詢它

$ dig www.example.org AAAA

www.example.org.    3600    IN  AAAA    ::1

它能運作。由於 log 外掛程式，我們也應該看到查詢被記錄

[INFO] [::1]:44390 - 63751 "AAAA IN www.example.org. udp 45 false 4096" NOERROR qr,aa,rd,ra 121 0.000106009s

上面的日誌向我們顯示了 CoreDNS 回應的位址 (::1) 以及它回應的時間和日期。此外，它還記錄了查詢類型、查詢類別、查詢名稱、使用的協定 (udp)、傳入請求的大小（以位元組為單位）、DO 位元的狀態，以及通告的 UDP 緩衝區大小。這是來自傳入查詢的資料。NOERROR 表示回覆的開始，它是傳回的回應碼，後跟回覆上的旗標集：qr,aa,rd,ra，回覆的大小（以位元組為單位）(121)，以及取得回覆所花費的時間。

轉送

可以將 CoreDNS 設定為使用 forward 將流量轉送到遞迴解析器。在這裡，我們將使用 forward 並專注於最基本的設定：轉送到 Google Public DNS (8.8.8.8) 和 Quad9 DNS (9.9.9.9)。

我們不需要建立任何東西，除了包含我們想要的設定的 Corefile。在這種情況下，我們希望所有連到 CoreDNS 的查詢都轉送到 8.8.8.8 或 9.9.9.9

. {
    forward . 8.8.8.8 9.9.9.9
    log
}

請注意，forward 允許您微調它將傳送到上游的名稱。在這裡，我們選擇了所有名稱 (.)。例如：forward example.com 8.8.8.8 9.9.9.9 只會轉送 example.com. 網域內的名稱。

啟動 CoreDNS 並使用 dig 測試它

$ dig www.example.org AAAA
www.example.org.	25837	IN	AAAA	2606:2800:220:1:248:1893:25c8:194

將網域轉送到不同的上游

您可能會遇到一個常見的狀況是，對 example.org 的查詢需要傳送到 8.8.8.8，而其餘的查詢應透過 /etc/resolv.conf 中的名稱伺服器解析。有兩種方法可以在 Corefile 中實作這一點

  1. 在單個伺服器區塊中使用 forward 外掛程式的多個宣告
. {
    forward example.org 8.8.8.8
    forward . /etc/resolv.conf
    log
}
  1. 使用多個伺服器區塊，每個區塊對應您要路由的每個網域
example.org {
    forward . 8.8.8.8
    log
}

. {
    forward . /etc/resolv.conf
    log
}

這將網域路由留給 CoreDNS，它也會處理 DS 查詢等特殊情況。擁有兩個較小的伺服器區塊而不是一個伺服器區塊沒有負面影響，只是您的 Corefile 會稍微長一點。程式碼片段和 import 等東西將會有所幫助。

遞迴解析器

CoreDNS 沒有原生（即以 Go 撰寫）遞迴解析器，但有一個 (外部) 外掛程式使用 libunbound。若要使此設定運作，您必須先重新編譯 CoreDNS 並 啟用 unbound 外掛程式。這裡有一個快速入門（您必須已安裝 CoreDNS 原始碼）

  • 將 unbound:github.com/coredns/unbound 新增至 plugin.cfg。
  • 執行 go generate，然後執行 make。

注意：unbound 外掛程式需要編譯 cgo，這也表示 coredns 二進位檔現在連結到 libunbound，而不再是靜態二進位檔。

假設這能運作，您可以使用以下 Corefile 啟用 unbound

. {
    unbound
    cache
    log
}

已包含 cache，因為已停用 unbound 中的（內部）快取，以允許快取的度量標準像正常一樣運作。

 

修改日期：

撰寫外掛程式

正如本手冊前面提到的，外掛程式是讓 CoreDNS 運作的原因。我們在上一節中看到了一些設定，但是如何編寫自己的外掛程式呢？

請參閱 為 CoreDNS 編寫外掛程式，以取得有關此主題的舊文章。CoreDNS 原始碼中記錄的 plugin.md 也提供了一些背景資訊，並討論了 README.md 的樣式。

典型的範例外掛程式是 example 外掛程式。它的 github 儲存庫顯示了建立外掛程式所需的最簡程式碼（包含測試！）。

它有

  1. setup.go 和 setup_test.go，它們實作了從 Corefile 解析設定的功能。每當 Corefile 解析器看到外掛程式的名稱時（在此案例中為「example」），就會呼叫（通常命名為）setup 函式。
  2. example.go（通常命名為 <plugin_name>.go），其中包含處理查詢的邏輯，以及 example_test.go，其中包含檢查外掛程式是否正常運作的基本單元測試。
  3. README.md 文件，以 Unix 手冊風格記錄如何設定此外掛程式。
  4. 一個 LICENSE 檔案。若要包含在 CoreDNS 中，這需要一個類似 APL 的授權。

程式碼也有大量的註解；隨時可 fork 並以其為基礎來建立您的外掛程式。

外掛程式的呼叫方式

當 CoreDNS 想要使用外掛程式時，它會呼叫 ServeDNS 方法。ServeDNS 有三個參數：

  • 一個 context.Context；
  • 一個 dns.ResponseWriter，基本上是客戶端的連線；
  • 一個 *dns.Msg，是來自客戶端的請求。

ServeDNS 會傳回兩個值：一個（回應）代碼和一個錯誤。當這個伺服器使用errors時，錯誤會被記錄下來。

程式碼會告知 CoreDNS，外掛程式鏈是否已寫入回覆。在後者的情況下，CoreDNS 將會處理。對於程式碼的值，我們重複使用來自 dns 套件的 DNS 返回代碼 (rcodes)。

CoreDNS 將以下情況視為特殊情況：

  • SERVFAIL (dns.RcodeServerFailure)
  • REFUSED (dns.RcodeRefused)
  • FORMERR (dns.RcodeFormatError)
  • NOTIMP (dns.RcodeNotImplemented)

並會假設沒有任何東西被寫入到客戶端。在所有其他情況下，它會假設（外掛程式）已將某些東西寫入到客戶端。

請參閱這篇文章，瞭解如何使用您的外掛程式編譯 CoreDNS。

從外掛程式記錄

使用 log 套件 來為您的外掛程式新增記錄功能。您可以使用以下方式初始化：

var log = clog.NewWithPlugin("example")

現在您可以使用 log.Infof("...") 將內容列印到標準輸出，並加上 [INFO] plugin/example 層級的前綴。層級可以是：INFO、WARNING 或 ERROR。

一般來說，當返回錯誤時，記錄應留給較高的層級。但是，如果有理由要處理錯誤，但仍要通知使用者，那麼在外掛程式中記錄是可以接受的。

指標

在匯出指標時，命名空間應為 plugin.Namespace (=“coredns”)，而子系統應為外掛程式的名稱。外掛程式的 README.md 也應包含一個指標區段，詳細說明指標。如果外掛程式支援就緒報告，則它也應有一個就緒區段來詳細說明。

文件

每個外掛程式都應有一個 README.md，說明此外掛程式的作用及其設定方式。該檔案應具有以下佈局：

  • 標題：使用外掛程式的名稱
  • 標題為「Named」的子區段，內容為 <plugin name> - <one line description>.，即「名稱-描述」。
  • 標題為「Description」的子區段，包含更詳細的描述以及外掛程式支援的所有選項。
  • 標題為「Syntax」的子區段，詳細說明語法和支援的指令。
  • 標題為「Examples」的子區段。
  • 選擇性的標題為「See Also」的子區段，其中參考外部文件，例如 IETF RFC。
  • 選擇性的標題為「Bugs」的子區段，其中列出尚未運作的功能。

當然，還可以有更多區段。

樣式

我們使用 Unix 手冊頁的樣式：

  • 在內文中使用斜體表示外掛程式的名稱：*plugin*。
  • 內文中所有大寫的使用者提供引數都應使用粗體文字：**EXAMPLE**。
  • 選擇性文字應以區塊引號括住：[optional]。
  • 使用三個點來表示允許多個選項：arg...。
  • 項目使用原文：literal。

範例網域名稱

請務必在您提供的任何範例和測試中使用 example.org 或 example.net。這些是為此目的而建立的標準網域名稱。如果您不這樣做，您的虛擬網域名稱可能會被其他人註冊，並且實際上會提供網路內容（您可能喜歡或不喜歡）。

向下傳遞

在理想的世界中，對於外掛程式來說，以下情況將會成立：「您要么負責一個區域，要么不負責」。如果答案是「不負責」，則外掛程式應呼叫鏈中的下一個外掛程式。如果答案是「負責」，則應處理屬於此區域的所有名稱以及以下名稱 - 即它應處理整個網域和所有子網域，另請參閱此處，瞭解如何在啟用 fallthrough 的情況下處理查詢。

. {
    file example.org db.example
}

在此範例中，file 外掛程式正在處理 example.org 以下（包括）的所有名稱。如果收到一個不屬於 example.org 子網域（或等於）的查詢，則會呼叫下一個外掛程式。

現在，世界並不完美，並且有充分的理由「向下傳遞」到下一個中介軟體，這表示外掛程式僅負責區域內部分名稱。首先出現的是 reverse 外掛程式，現在已由可以合成各種回應的通用 template 外掛程式取代。

template 外掛程式的性質可能只處理指定的記錄 TYPE，並且只處理部分名稱。理想情況下，您希望將 template **置於**另一個外掛程式（例如 file 或 auto）**之前**。這表示 template 可以處理一些特殊的反向案例，而**所有其他**請求都由後端的其他外掛程式處理。這正是「向下傳遞」的作用。為了保持明確性，我們選擇讓實作這種行為的外掛程式應實作 fallthrough 關鍵字。

fallthrough 指令應選擇性地接受區域清單。只有對這些區域之一中的記錄的查詢才允許向下傳遞。

符合主儲存庫的資格

請參閱此文件，其中描述了要求。

本手冊的來源