全球 NULL 紀錄診斷檢查器
在網域名稱系統高度結構化的階層中，NULL 紀錄是至今為止被編纂過最異常且定義最寬鬆的資料類型。在原始的 RFC 1035 規範中概述，NULL 紀錄完全沒有格式化規則、語法限制或內部語意。不同於期望 IP 位址的 A 紀錄，或需要優先權整數和主機名稱的 MX 紀錄，NULL 紀錄僅僅作為一個空容器存在。它被設計用來容納最大長度為 65,535 位元組的任意二進位資料 Payload，且權威名稱伺服器不會對內容應用任何驗證。
實驗性沙盒
當網際網路的創始工程師開發 DNS 架構時，他們認知到該系統將需要適應未來無法完全契合標準 A、MX 或 TXT 限制的網路協定。NULL 紀錄被明確保留為實驗性協定擴充和學術研究的開發者沙盒。因為 BIND 軟體對 NULL Payload 不應用任何編碼檢查或字元限制（封包大小除外），網路工程師可以直接將原始的、未格式化的十六進位字串、自訂加密雜湊或專有的二進位路由資料注入到區域檔中，供專門的用戶端應用程式解析 (parse)。
為何在生產環境中失敗
儘管其具有理論上的靈活性，但 NULL 紀錄在現代生產環境中幾乎不存在。主要問題是互通性。由於沒有標準化方法讓不同的軟體用戶端解釋任意二進位資料，它只能在管理員同時控制 DNS 伺服器和用戶端應用程式的封閉生態系統中使用。此外，TXT 紀錄的興起——它對於標準 REST API 和 Web 應用程式來說更容易解析——以及 EDNS (Extension Mechanisms for DNS) 的部署，使得 NULL 紀錄的原始二進位 Payload 對於現實世界的應用程式資料而言變得完全過時。
隱蔽通道 (Covert Channels) 與安全稽核
今天，除了在高度專業化的網路安全環境外，很少能看到 NULL 紀錄。進階持續性威脅 (APT) 和複雜的惡意軟體變種歷史上曾試圖使用 NULL 紀錄來建立隱蔽的命令與控制 (C2) 通道。透過在隱藏於 NULL 紀錄中的任意二進位資料區塊內對竊取的資料進行編碼或取得惡意指令，攻擊者可以繞過應用程式層防火牆，因為大多數企業網路會盲目允許連接埠 53 的 DNS 流量。如今，全球 NULL 查詢嚴格來說只在深入的滲透測試、惡意軟體分析或學術協定稽核期間執行，以監控不同的邊緣解析器如何過濾或傳遞網際網路骨幹網上不受管制的二進位 Payload。