雖然很多人都知道何謂網址，可能大多數人也聽過DNS，但是詳細的技術內容可能就很少人知道，因此本文將要介紹負責運作網址與IP位址相關資料的DNS背景知識。
而所有名稱伺服器又可分為Master名稱伺服器以及Slave名稱伺服器，Master名稱伺服器會儲存所有Zones最原本的資料，而相對於Master名稱伺服器而言，Slave名稱伺服器的資料則是經由DNS協定中所定義之自動更新的機制所取得。可信賴的名稱伺服器可以是Master名稱伺服器，也可以是Slave名稱伺服器。對於每一個DNS Zone而言，都必須指定一個或是多個可信賴的名稱伺服器。
DNS的資料種類與格式
DNS的訊息分為兩大類型：「查詢」（Query）資料以及「回應」（Answer）資料。兩種類型的資料擁有一樣的資料格式。每一個這樣的資料會包含Header，以及以下四個主要的欄位：
·Question
·Answer
·Authority
·Additional
而在Header中，則包含以下幾個欄位：
·Identification
·Flags
·Question欄位的數目
·Answer欄位的數目
·Authority Resource Record欄位的數目
·Additional Resource Record欄位的數目
這裡Resource Record通常也簡稱RR。第一個Identification欄位用來標示這筆DNS資料是屬於哪一種查詢，這個欄位的長度是16個位元。接下來的Flag欄位長度是4個位元，第一個位元用於標示這個DNS資料是屬於「查詢」還是「回應」，如果是查詢，則這個位元的值為0，否則為1。
而第二個位元，在當DNS伺服器是針對要查詢的主機名稱來說是可信賴的話，其值為1，否則為0，這裡可以看得出來，以這個位元的目的來說，是只會用於「回應」的DNS訊息。
最後一個位元則用來標示DNS伺服器是否支援循環式查詢，如果是的話，其值為1，一樣從這裡可以看出這個位元只會用於回應種類的DNS訊息。
而在Question這個欄位中，會包含查詢的種類（例如A、AAA或MX等等）以及要查詢的主機名稱。所回應的資料（也就是IP位址），會放在Answer欄位中。當然，如果一個主機名稱會對應到多個IP位址，則Answer欄位就會包含多個IP位址的Resource Record。
網域名稱的儲存與維護
在瞭解整個DNS大致的運作過程之前，先來看看這些網域名稱是如何被儲存的。儲存這些網域名稱的地方，稱為Domain Name Space，這裡是用一個樹狀結構的方式來儲存這些資訊。這個樹狀結構的節點（Nodes）可以連結一個或是多個子節點，每一個節點裡面會包含與網域名稱相關的資訊，而一個或是多個節點的組合則稱為Zone。
所以，整個樹狀結構可以被區分為多個Zones，至於如何區分這些Zones，而每一個Zone又必須包含哪些節點，這些都是由系統管理人員來設定。整個樹狀結構最根源的Zone，又稱為Root Zone。
網域名稱基本上都是由一個稱為ICANN（Internet Corporation for Assigned Names and Numbers）的組織所維護。除了ICANN之外，每一個Top Level Domain（簡稱TLD）也會被其他組織所維護，一旦收到網域名稱的申請，就會在資料庫內建立，並且透過WHOIS協定發布新註冊的網域名稱。而所有這些其他組織所維護的網域名稱資料，會由ICANN來發布整個完整的清單。
由整個網域名稱的組成來看，可以很清楚地看出，最高層級的標籤通常會是「國家」的部分。目前已經超過290個這樣的國家層級的網域，也稱為Country Code Top Level Domains，簡稱ccTLDs。每一個國家都會有自己的一個組織或機構來維護自己國家的對應資料庫，例如台灣的部分是由台灣網路資訊中心（Taiwan Network Information Center）來負責.tw的網域名稱。
Resource Record的格式
Resource Record在上一個段落被提到幾次，Resource Record是DNS系統中最基本的資料元素。Resource Record有許多不同的類型，許多同一種類型的Resource Records會組成Resource Record Set，簡稱RRset。而Resource Record的格式都被定義在RFC 1035文件中。一個Resource Record包含Name、Type、Class、TTL、RDLENGTH、RDATA等欄位。
Name是在樹狀結構中這個節點的網域名稱，長度是不固定的。Type則代表著這個Resource Record的類型，它可以用來表示一個Resource Record可能是用於把網域名稱轉換成IPv4的位址，也可能是用於列出在DNS Zone之中有哪些名稱伺服器是可以回應所要查詢的資料等等，它是以數字的方式儲存。
RDATA欄位用來儲存所要呈現的資料，可能是IP位址，也可能是主機名稱等等，而RDLENGTH代表RDATA欄位的長度。Class欄位用於辨識這個Resource Record可能是一般DNS的資料（主機名稱、伺服器或是IP等資料），或者其他特殊資料，例如Chaos或Hesiod等等，由於篇幅有限，這裡就不再針對這些資料多做敘述了。
DNS的資料傳遞方式
DNS是以Client-Server的模式，在分散式系統的環境中運作。DNS使用53號埠來運作，主要會使用UDP（User Datagram Protocol）的方式傳遞。DNS的查詢資料會使用單一UDP封包的方式傳遞，之後的回應也是使用一個UDP封包來傳遞。但如果回傳的資料大小超過512個位元，就會使用TCP來傳遞，以便於保證其資料的完整性以及資料傳遞成功。
何謂名稱解析自動化
名稱解析的部分最主要當然就是在DNS之中，主要的目的在於解析人類可讀的網址（例如www.gooogle.com）轉換成電腦或網路設備連線時所使用的IP位址。這是一個很重要的功能，因為IP位址很難記下來，而IPv6的位址更難記憶。
要做到這樣的功能，一般來說，必須在每一台電腦或網路設備設定好DNS伺服器的IP位址，這樣才知道這些名稱解析的需求動作要傳送到哪一台伺服器，早期是這樣的做法。不過，後來的網路系統，尤其是廣域網路或是各位家中與電信業者申請的網路，上網設備都已經自動從電信業者（例如中華電信）那邊取得DNS的各種資料，因此在家中上網時就不需要再設定DNS等資訊。
而DNS的設計，沒有辦法自動更正錯誤的設定值，也就是說，任何相關服務設定的改變，都必須人工去做相對應的改變。舉例來說，如果更動一個印表機或網路服務到不同的樓層或是給予不同的IP，則這些服務的IP與對應的名稱解析服務就必須手動做更改。
也因此，出現一些可以自動化的服務或協定，例如微軟在1992年的Windows 3.11作業系統中提供NetBIOS Name Service服務，這個服務可以在單一子網路的範圍中完成Zero-Configuration的動作。NetBIOS也可以與WINS伺服器一同使用，或者與支援自動註冊位址的DNS伺服器一起運作。