這種方法是許多方法中的一個，它對于希望向Internet隱瞞自己的主機名的機構很有用。這種辦法的成功取決于這樣一個事實：即一臺機器上的DNS客戶機不必與在同一臺機器上的DNS服務器對話。換句話說，正是由于在一臺機器上有一個DNS服務器，因此，將這部機器的DNS客戶機活動重定向到另一臺機器上的DNS服務器沒有任何不妥(并且經常有好處)。

首先，你在可以與外部世界通信的橋頭堡主機上建立DNS服務器。你建立這臺服務器使它宣布對你的域名具有訪問的權力。事實上，這臺服務器所了解的就是你想讓外部世界所了解的：你網關的名稱和地址、你的通配符MX記錄等等。這臺服務器就是“公共”服務器。

然后，在內部機器上建立一臺DNS服務器。這臺服務器也宣布對你的域名具有權力;與公共服務器不同，這臺服務器“講的是真話”。它是你的“正常”的命名服務器，你可以在這臺服務器中放入你所有的“正常”DNS名。你再設置這臺服務器，使它可以將它不能解決的查詢轉發到公共服務器(例如，使用Unix機上的/etc/ named.boot中的“轉發器”行——forwarder line)。

最后，設置你所有的DNS客戶機(例如，Unix機上的/etc/resolv.conf文件)使用內部服務器，這些DNS客戶機包括公共服務器所在機器上的DNS客戶機。這是關鍵。

詢問有關一臺內部主機信息的內部客戶機向內部服務器提出問題，并得到回答;詢問有關一部外部主機信息的內部客戶機向內部服務器查詢，內部客戶機再向公共服務器進行查詢，公共服務器再向Internet查詢，然后將得到的答案再一步一步傳回來。公共服務器上的客戶機也以相同的方式工作。但是，一臺詢問關于一臺內部主機信息的外部客戶機，只能從公共服務器上得到“限制性”的答案。

這種方式假定在這兩臺服務器之間有一個包過濾防火墻，這個防火墻允許服務器相互傳遞DNS，但除此之外，限制其它主機之間的DNS.

這種方式中的另一項有用的技巧是利用你的IN-ADDR.AROA域名中通配符PTR記錄。這將引起對任何非公共主機的“地址到名稱”(address-to-name)的查找返回像“unknown.YOUR.DOMAIN”這樣的信息，而非返回一個錯誤。這就滿足了像匿名FTP站點的要求。這類站點要求得到與它們通信的計算機的名字。當與進行DNS交叉檢查的站點通信時，這種方法就不靈了。在交叉檢查中，主機名要與它的地址匹配，地址也要與主機名匹配。