Globalny diagnostyczny weryfikator rekordu NULL
W wysoce ustrukturyzowanej hierarchii DNS, rekord NULL wyróżnia się jako najbardziej nietypowy i luźno zdefiniowany typ danych, jaki kiedykolwiek skodyfikowano. Zarysowany w oryginalnej specyfikacji RFC 1035, rekord NULL jest całkowicie pozbawiony reguł formatowania, ograniczeń składniowych czy wewnętrznej semantyki. W przeciwieństwie do rekordu A, który oczekuje adresu IP, lub rekordu MX, który wymaga liczby całkowitej określającej priorytet oraz nazwy hosta, rekord NULL istnieje wyłącznie jako pusty kontener. Został zaprojektowany do przechowywania arbitralnych (dowolnych) Payloadów danych binarnych o maksymalnej długości do 65 535 bajtów, przy czym autorytatywny serwer nazw nie stosuje do tej zawartości żadnej weryfikacji walidacyjnej.
Eksperymentalna piaskownica (Sandbox)
Kiedy początkowi inżynierowie-założyciele Internetu opracowywali architekturę DNS, zdali sobie sprawę, że system będzie musiał dostosować się do przyszłych protokołów sieciowych, które niekoniecznie będą idealnie pasować do standardowych ograniczeń rekordów A, MX czy TXT. Rekord NULL został wyraźnie zarezerwowany jako piaskownica dla programistów przeznaczona do eksperymentalnych rozszerzeń protokołów i badań akademickich. Ponieważ oprogramowanie np. BIND nie stosuje żadnych kontroli kodowania ani limitów znaków (poza samym rozmiarem pakietu) do Payloadu rekordu NULL, inżynierowie sieciowi mogli wstrzykiwać surowe (raw), niesformatowane ciągi szesnastkowe (hexadecimal), niestandardowe hashe kryptograficzne lub zastrzeżone binarne dane dotyczące routingu bezpośrednio do pliku strefy, do późniejszego przetworzenia (parse) przez wyspecjalizowane aplikacje klienckie.
Dlaczego poniósł porażkę w środowisku produkcyjnym
Mimo swojej teoretycznej elastyczności, rekord NULL praktycznie nie występuje w nowoczesnych środowiskach produkcyjnych. Głównym problemem była interoperacyjność. Ponieważ nie było ustandaryzowanego sposobu dla różnych klientów programowych na interpretację arbitralnych danych binarnych, mógł on być używany tylko w zamkniętych ekosystemach, w których ten sam administrator kontrolował zarówno serwer DNS, jak i aplikację klienta. Co więcej, rozwój rekordu TXT — który jest znacznie łatwiejszy do przetwarzania (parse) dla standardowych API REST i aplikacji internetowych — oraz wdrożenie mechanizmu EDNS (Extension Mechanisms for DNS) sprawiły, że nieprzetworzony binarny Payload rekordu NULL stał się całkowicie przestarzały (obsolete) w kontekście rzeczywistych danych aplikacyjnych.
Ukryte kanały (Covert Channels) i audyty bezpieczeństwa
Obecnie rekord NULL rzadko jest spotykany poza wysoce wyspecjalizowanymi kontekstami z obszaru cyberbezpieczeństwa. Zaawansowane uporczywe zagrożenia (APTs - Advanced Persistent Threats) i wyrafinowane warianty złośliwego oprogramowania (malware) próbowały w przeszłości wykorzystywać rekordy NULL do tworzenia ukrytych kanałów Command-and-Control (C2). Szyfrując i przesyłając w ten sposób wykradzione (exfiltrated) dane lub pobierając złośliwe instrukcje poprzez dowolne binarne byty (blobs) ukryte w rekordach NULL, atakujący mogą omijać zapory sieciowe warstwy aplikacji, ponieważ większość sieci korporacyjnych w ciemno zezwala na ruch DNS na porcie 53. Obecnie uruchamianie globalnego wyszukiwania rekordu NULL jest przeprowadzane ściśle podczas dogłębnych testów penetracyjnych (penetration testing), przy analizie złośliwego oprogramowania lub w ramach akademickich audytów protokołów sieciowych, w celu monitorowania w jaki sposób różne brzegowe resolvery (edge resolvers) odfiltrowują lub przepuszczają nieregulowane Payloady binarne przez strukturę szkieletową Internetu (backbone).