named查詢使用的是UDP協議和端口53。響應通過UDP返回，除非他們大于512K，這種情況使用TCP。服務器之間的“區傳送”則都使用TCP。

委托：所有的名字服務器都知道根服務器。而根服務器又都知道gTLD，順著這條鏈進一步往下，edu知道fudan.edu，com知道china.com...依次類推。實例：假設我希望從機器marco.comp.fudan.edu查詢機器cs.military.china.com，這里假設查詢之前，除了根服務器的名稱和ip地址之外沒有高速緩存任何這里需要用到的信息。順序是這樣的（主機marco詢問它的本地名字服務器ns.comp.fudan.edu，而ns.comp.fudan.edu是一個遞歸的名字服務器，因此，它將代替主機marco來查詢。由于它不知道這個地址，且不知道有關military.china.com或china.com甚至不知道.com的任何信息。不過它知道根域的一些服務器，根域知道有關.com的數據，因此發送引用給ns.comp.fudan.edu，本地名字服務器隨后就將查詢發送到.com，返回一個china.com的推薦，同樣重復發送查詢到china.com，返回military.china.com服務器的推薦，這樣military.china.com對于這個查詢信息是權威的，并返回cs的地址。這樣就完成了整個過程，哦，不對，還有一點，ns.comp.fudan.edu會在這個過程進行中告訴緩存主機cs的地址，同時緩存了.com,china.com,military.china.com的服務器列表。
高速緩存和效率：高速緩存機制在過去僅能用于肯定的回答，假如找不到主機名則布包存這種實際情況。而RFC1034和RFC2308則先后定義并升級了用于否定告訴緩存的方案。在BIND8.2中是一個可選功能，而在9中已經成為一個必選的功能了。它將保存一下否定類型的回答（其中前兩種否定數據的類型緩存時間為1－3小時，其他類型緩存5分鐘）：
沒有與要查詢的名稱匹配的主機或域
該主機不存在要查詢的數據類型
詢問的服務器無響應
因為網絡問題，服務器不可達
擴展的DNS協議：90年代末期，EDNS0（擴展DNS，版本0）解決了今天的因特網中DNS協議的一些缺點。它答應發言人宣告其組裝緩沖區大笑，可支持選項和通信協議版本。假如接受方的名字服務器以一條錯誤消息作為響應，那么發送方就退回去使用原來的DNS協議。BIND9在服務器和解析器中都實現了EDNS0。^_^。