Dịch vụ DNS cấu hình dịch vụ DNS trên máy chủ CENTOS

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

_________*_________

BÀI TẬP LỚN

THIẾT KẾ MẠNG INTRANET

ĐỀ 4 : DICH VỤ DNS
Giáo viên hướng dẫn : TS Phạm Huy Hoàng.
Sinh viên thực hiện:

1. Ngô Hồng Hải – MSSV 20121638.
2. Hoàng Hữu Hơi – MSSV 20121772
3. Nguyễn Tú Chi – MSSV 20121301

HÀ NỘI – THÁNG 12 NĂM 2015

1


MỤC LỤC

LỜI NÓI ĐẦU
Cùng với sự phát triển nhanh chóng của nền kinh tế, vấn đề ứng dụng hệ
thống mạng thông tin vào điều hành và sản xuất trong doanh nghiệp ngày càng
được đẩy mảnh. Nhà quản lý mong muốn quản trị viên mạng phải nắm bắt được
2

hầu hết các công nghệ mạng để nhanh chóng triển khai, ứng dụng những công
nghệ mạng tiên tiến vào phục vụ điều hành sản xuất cũng như lập kế hoạch xây
dựng và bảo vệ hệ thống thông tin nội bộ của doanh nghiệp.
Chắc hẳn đã nhiều người quan tâm tới lĩnh vực hệ thống và không thể không
biết đến dịch vụ mạng DNS. Một dịch vụ quan trọng nhất trên Internet và trong
nội bộ của các doanh nghiệp, cho phép toàn bộ máy tính và các tài nguyên trên
mạng được lưu dưới dạng tên và khi truy cập vào hệ thống DNS sẽ chuyển từ
tên sang địa chị IP và ngược lại.
DNS server có thể nói là một dịch vụ xương sống của hệ thống mạng, giúp
cho việc truy cập vào các trang web thuận lợi và dễ dàng hơn. Hiện nay có rất
nhiều phần mềm cho phép chúng ta xây dựng một DNS server như trên
windows có Microsoft DNS, trên linux có BIND, powerDNS, MyDNS….
Nhưng có lẽ phần mềm được dùng để xây dựng DNS phổ biến nhất trên thế giới
có thể nói là mạnh nhất hiện nay là BIND.
Trước xu hướng đó, cùng với sự giúp đỡ, hướng dẫn tận tình của thầy chúng
em tiến hành xây dựng một hệ thống DNS server trên nền tảng hệ điều hành
Linux Centos với mong muốn nắm bắt được những vấn đề nền tảng, cốt lõi cũng
như cách thức triển khai hệ thống tên miền.
Do kinh nghiệm và kiến thức chưa được sâu nên trong báo cáo về đề tài của
nhóm chúng em còn nhiều sai sót, mong thầy góp ý thêm để nhóm có thể hoàn
thiện tốt hơn các đề tài nghiên cứu về sau.

3


CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ DỊCH VỤ
DNS
Mạng internet hay bất kì mạng nào đều cho rằng vấn đề phân bố địa chỉ IP duy
nhất cục bộ hoặc toàn cầu cho mỗi thiết bị đầu cuối (máy chủ, máy chủ router,
giao diện). nhưng nếu không có khả năng để chỉ định một số tên tương ứng với

mỗi tài nguyên, mỗi lần chúng ta muốn truy cập vào một nguồn tài nguyên có
sẵn trên mạng, các trang web ví dụ :www.example.com, nó sẽ cần thiết để biết
địa chỉ IP vật lý của nó, chặng hạn như 192.168.34.166. Với hang trăm triệu vạn
thiết bị và hơn 200 triệu trang web, nó là 1 nhiệm vụ không thể cũng như là khá
khó khăn. Thậm chí với một số ít các máy chủ và các nguồn tài nguyên.
Để giải quyết vấn này, các khái niệm về tên máy chủ được tao ra giữa những
năm 1970 để cho phép các thuộc tính nhất định của một tài nguyên được đặt tên,
trong trường hợp này địa chỉ IP của www.example.com , được duy trì trong một
địa điểm tốt. ý tưởng cơ bản là mọi người tìm thấy nó dễ dàng hơn để nhớ tên
của một cái gì đó đặc biệt là khi tên của nó là hợp lý mô tả chức năng, nội dụng
hoặc mục đích chứ không phải là một địa chỉ IP số.
Chương này sẽ giới thiệu các khái niệm cơ bản và tên máy chủ cung cấp một
chút nền tảng về sự tiến hóa của hệ thống tên miền từ một công cụ được sử dụng
để quản lý đến tiện ích toàn cầu về trách nhiệm và duy trì hoạt động tốt của toàn
bộ hệ thống internet hiện đại.
1. A Brief History of Name Servers

Các vấn đề về chuyển đổi tên thành địa chỉ vật lý như cũ như mạng máy tính.
Ngay cả trong dài của quá khứ, người ta tìm tháy nó dễ dàng hơn để nhớ họ đã
sử dụng một thiết bị điện báo gọi là ”tty2” hơn là “cổng 57 của MCCU”, hoặc
bất cứ phương pháp giải quyết sau đó sử dụng. Trong ví dụ trước, người dùng có
thể tiếp tục sử dụng “tty2” ngay cả khi thiết bị đã được cấu hình lại để được vào
cổng 23 vủa MCCU. File cấu hình đơn giản đã thường được sử dụng để thực
hiện dịch địa chỉ. Như mạng, chứ không phải là thông tin liên lạc đơn giản, nổi
lên trong năm 1970, vấn đề trở nên nghiêm trọng hơn. Hệ thống mạng kiến trúc
mạng của IBM (SNA), có lẽ là ông nội của mạng, cơ sở dữ liệu chứa một máy
tính lớn thô sơ khi xuất bản lần đầu vào năm 1974. Mô hình Opem Systems
Interconnect (OSI), được phát triển bởi tổ chức Tiêu Chuẩn Quốc Tế (ISO –
www.iso.org), xác định các dịch vụ Địa Chỉ/Tên tại Transport Layer (Layer 4)
ban đầu được công bố vào năm 1978. NetBOIS cung cấp các tên NetBIOS

Server (NBNS) được xác định vào năm 1984, sau này thành Windows Internet
Naming của Microsoft.
4


ARPANET đầu tiên( đối với mạng sau này thành Internet) RFC, yêu cầu
quaintly tên For Comments tài liệu và chuẩn hóa Internet, trên các khái niệm về
tên miền từ năm 1982 (RFC 799), và các thông số kỹ thuật cho tên miền của hệ
thống Internet như chúng ta biết ngày nay đã được xuất bản năm 1987(RFC
1034 và RFC 1035)
2. Name Server Basics

Khi name server ra mắt trong một mạng, mọi host chỉ cẩnbiết địa chỉ vật ký của
name server và tên của tài nguyên như là 1 một web site mà nó muốn tiếp cận.
Sử dụng thông tin này, nó có thể tìm địa chỉ () của tài nguyên bằng cách truy vấn
name server. Tài nguyên có thể thêm, di chuyển, thay đổi hoặc xóa ở chỉ một vị
trí, name server, và thông tin mới sẽ ngay lập tức sẵn có cho mọi host dùng
chính name server này. Name server của ta đơn giản là một kho dữ liệu chuyên
dụng, nó dịch tên sang địa chỉ IP. Các name server làm đơn giản hóa việc quản
lý mạng và làm mạng năng động và sẵn sàng thay đổi.
Tuy vậy đáp án có thể còn phát sinh ra vấn đề . Nếu name server của ta không
có sẵn, thì host không thể tiếp cận bất kỳ tài nguyên nào trên mạng. Ta tạo ra
name server 1 nguồn lực quan trọng nên ta tốt hơn hết nên tạo nhiêu hơn 1 name
server trong trường hợp thất bại.
Đáp án đầu tiên cho vấn đề tính sẵn sàng của name server là giới thiệu name
server cơ bản và name server thứ cấp. Nếu name server cơ bản không trả lời truy
vấn, host có thể thử lại bằng name server phụ. Quan trọng là name server ngày
nay có thể thấy danh sách 3, 4, hay nhiều name server. Các điều khoản về name
server cơ bản và name server thứ cấp hay cả name server phụ thứ 3, và phụ thứ
4, trong khi vẫn sử dụng rộng rãi, bao hàm khả năng tiếp cận ưu tiên, cái nào

chống lại tính sẵn có. Không chỉ vấn đề về tính ưu tiên dẫn đến việc tập trung
trao đổi vào name server cơ bản, làm giảm hiệu suất chung, nhưng trong trường
hợp name server cơ bản không hoạt động, mọi trao đổi phải đợi ít thời giản
trước khi thử lại với name server thứ cấp, vv…Phần lớn phần mềm name server
sử dụng một số dạng ngẫu nhiên, thời gian phản hôi cố định hoặc tiếp cận luân
phiên tới danh sách name server để thử và phân tải và giảm thởi gian phản hồi.
Với sự phát triển của mạng, chúng ta bắt đầu tạo ra số lượng đáng kể các tên tại
name server. Nó gây lên 3 vấn đề mới
Sự tổ chức: Việc tìm kiếm chính xác tên ta cần trong hàng triệu tên trong cơ sở
dữ liệu sẽ rất chậm, ta cần cách thức để hiển thị và tổ chức các tên
Khả năng mở rộng: Nếu mọi host tiếp cận tới các name server, việc truyền tải
trở nên rất chậm, ta cần cách thức để dàn trải các tải ra các name server
Quản lý: với rất nhiều bản ghi tên trong cơ sở dữ liệu, vấn đề quản lý trở nên
phức tạp hơn, như nhiều người quản lý có ý định cập nhật bản ghi cùng một lúc.
Ta cần cách thức để phân quyền các người quản lý này.
5


CHƯƠNG 2: KIẾN TRÚC DỊCH VỤ DNS
DNS là sự bổ sung đặc biệt của định nghĩa tên server dùng cho quá trình phổ
biến của nó trên mạng Internet. Có 3 vấn đề được đặt ra:
- Sự cần thiết của hệ thống tên
- Sự cần thiết của việc phân chia tải khi hoạt động của các name servers
- Sự cần thiết của việc ủy quyền cho admin của các name servers
Dịch vụ DNS giải quyết tất cả 3 vấn đề trên
1. Domains và Delegation:

─

─

Dịch vụ DNS sử dụng cấu trúc tên dạng cây. Đỉnh Của cây là node gốc, sau
đó là TLDs (the Top-Level Domains), tiếp theo là SLDs (the Second-Level
Domains), và tiếp sau nữa là các mức thấp hơn, mỗi mức được phân chia
cách nhau bằng dấu “.”.
TLDs gồm 2 loại cơ bản:
- gTLDs (generic Top-Level Domains): .com, .edu, .net, .org, .mil …
- ccTLDs (Country Code Top-Level Domains): .us, .ca, .tv, .uk, …
ccTLDs sử dụng

Figure2. 1

─

─

─

Domain name: là 1 tổ hợp của SLD name và TLD name, được viết từ trái qua
phải với mức thấp nhất trong hệ thống phân cấp bên trái và mức cao nhất bên
phải (sld.tld: sld bên trái, tld bên phải)
Second-level Domain: nó định nghĩa các node mức thứ 2 trong hệ thống phân
cấp tên miền, nhưng nó hơi dài. Ngoài ra tên miền dài hơn thì cần có một
mức nữa là Third-Level Domains, ở mức này thường là các ccTLDs….
Theo quy ước hoặc mục đích sử dụng mà gọi là domain hay domain name,
thường được sử dụng để mô tả thực thể đặc trưng. Ví dụ: example.com, trong
đó: example là SLD và com là TLD.
6

2. Domain Authority:

─

─

─

─

Khái niệm authority và delegation nằm ở phần chính của hệ thống DNS và
phản ánh chính xác tổ chức hệ thống của nó. Mỗi node trong phân cấp hệ
thống domain name được phân quyền cho 1 tổ chức hoặc người chịu trách
nhiệm quản lý và thi hành các node đó. Tổ chức hoặc người như thế được
cho biết để quản lí các node ủy quyền. Quyền cho 1 node cụ thể có thể lần
lượt ủy nhiệm cho node mức dưới của node đó trong hệ thống phân cấp tên
miền. Các qui định và hạn chế của thẩm quyền nằm trong các thỏa thuận qua
các node khác nhau trong hệ thống phân cấp tên miền.
Quyền cho domain gốc quy định bởi ICANN-www.icann.org (Internet
Corporation for Assigned Numbers and Names). Từ năm 1998, ICANN-1 tổ
chức phi lợi nhuận- đã nhận trách nhiệm từ Bộ thương mại Mỹ. Khi ICANN
được thành lập, một phần nhiệm vụ ấy được mở rộng ra là: 1 phần của hệ
thống phân cấp tên miền là trách nhiệm cạnh tranh thương mại. Để thuận
tiện cho sự cạnh tranh này, hệ thống cung cấp khái niệm accredited
registrars, tổ chức được ICANN ủy nhiệm hạn chế đối với việc bán và quản lí
các bộ phận của hệ thống phân cấp tên miền.
gTLDs được ủy quyền quản lí bởi ICANN và được ủy quyền cho 1 loạt các
accredited registrars. ccTLDs được ủy quyền bởi ICANN cho các quốc gia
riêng lẻ với mục đích quản trị. Figure 1-1 cũng cho thấy cơ quan nào có thể
lần lượt đại diện cho cấp thấp hơn trong hệ thống phân cấp; nói cách khác, nó

có thể ủy quyền cho bất cứ điều gì mà nó có thẩm quyền. Mỗi cấp trong hệ
thống phân cấp có thể ủy quyền việc có thẩm quyền để kiểm soát các phân
cấp tiếp theo hoặc thấp hơn.
Trong trường hợp của ccTLDs, các quốc gia tự đưa ra các quy tắc riêng của
nước mình. Các quốc gia như Hoa Kỳ thì ccTLDs là .us, Canada: .ca… Do
đó example.md.us là tên miền của example được quản lí bởi bang Maryland
của Hoa Kì.
3. DNS Implementation and Structure:

─

Việc thực thi của DNS ánh xạ chính xác cấu trúc tên miền ủy quyền được mô
tả trước đó. Có nhiều tên servers (servers chạy DNS software) ở mỗi cấp
trong hệ thống phân cấp tên miền ủy quyền , và chịu trách nhiệm việc chạy
name server nằm cùng với sự kiểm soát có thẩm quyền ở cấp đó. Figure 1-2
cho thấy cấu trúc này:

7


Figure2. 2
─

─

Root name server (hay gọi là root-servers) là nguồn quan trọng nhất trong
Internet. Khi bất kì name server nào được truy vấn thông tin về 1 domain
name mà nó ko có thông tin, thì đầu tiên nó sẽ gửi yêu cầu đến 1 trong các
root DNS servers. Hiện nay có 13 root-servers trên toàn thế giới, sẽ được mô
tả chi tiết hơn trong phần sau. Root-servers được biết là mọi name server

trên thế giới sử dụng 1 zone file đặc biệt, điều này được phân phối với tất cả
DNS software.
TLD name servers (gTLD và ccTLD) được điều hành bởi một loạt tổ chứcRegistry Operators, dưới sự đồng ý của ICANN và được mô tả chi tiết hơn ở
phần sau. Người sở hữu một tên miền thì đã được ủy quyền để quản lí tên
miền đó và vì vậy có trách nhiệm cho các hoạt động của người sử dụng
( hoặc name domain) name servers- phải có tối thiểu 2 khả năng phục hồi.
Name server chịu trách nhiệm vận hành phải được ủy quyền của chủ sở hữu
tên miền tới 1 ISP, 1 web hosting company, hoặc phải đăng kí một tên miền.
Có rất nhiều công ty và chủ sở hữu tên miền,tuy nhiên để chạy các name
server riêng của họ, thậm chí là việc ủy quyền và trách nhiệm cho các tên
miền phụ (subdomain name servers) thì chia thành các bộ phận tách biệt
nhau. Khi bất kì một name server nào ko trả lời, hay giải quyết, 1 yêu cầu
cho 1 tên, Ví dụ: fred.example.com, truy vấn được đưa tới 1 root server (điều
này sẽ được thảo luận trong phần tiếp theo), sau đó nó sẽ trả về 1 lời chỉ dẫn
đến các TLD name server thích hợp, do đó sẽ cung cấp chỉ dẫn đến domain
name server thích hợp-để trả về câu trả lời thực. Figure 1-3 sẽ làm rõ quá
trình này:

8


Figure2. 3

4. Root DNS Operations

─

─

Các root servers (root DNS) là trách nhiệm của ICANN, nhưng được thực

hiện dưới sự đồng ý của ICANN và bộ thương mại Hoa kỳ với bản thỏa
thuận CRADA (The Cooperative Research and Development Agreement).
Thỏa thuận này bao gồm các phương pháp và quy trình theo đó các bản cập
nhật tới hệ thống root name được thực hiện. ICANN cũng thành lập ủy ban
tư vấn hệ thống root server (the root server system advisory committeeRSSAC) để tư vấn và hướng dẫn về các hoạt động và phát triển các nguồn tài
nguyên quan trọng này. RSSAC đã yêu cầu IETF phát triển các tiêu chuẩn kĩ
thuật cho hoạt động của các root servers. Yêu cầu này dẫn đến việc xuất bản
RFC 2870.
Hiện nay có 13 root server. Chúng giữ 1 tên miền được giành riêng: rootservers.net. Mỗi root- server thường gồm nhiều máy chủ vật lý, nhưng sử
dụng 1 quá trình gọi là anycasting, mỗi máy chủ vật lý này chia sẻ 1 địa chỉ
IP duy nhất. các root servers được đặt tên từ a.root-servers.net qua m.rootservers.net, như được trình bày trong Table 1-1. Tính đến năm 2010, trong
khi có 13 tên root-servers, thì có hơn 200 trường (instances) trên toàn thế
giới. thông tin hiện tại về root-server được lấy từ www.root-servers.org.

9


Ser
ver
A

B
C

─

Operator

Location

IP Address

VeriSign Global
Registry Services.

Sites=6; Los Angeles,US; New
York,US*;Frankfurt,DE;Hong
Kong,HK;Palo
Alto,US*;Ashburn,US*

IPv4:198.41.0.4
IPv6:2001:503:BA3E::2:30

Information
Sciences Institute

Sites=1;Marina del Rey,US

IPv4:192.288.79.201
IPv6:2001:478:65::53

Cogent
Communications

Sites=6;Chicago,US;Herdon,US;Lo
s Angeles,US;New York
City,US;Frankfurt,DE;Madrid,ES

IPv4:192.33.4.14

Công việc của root-servers là cung cấp lời chỉ dẫn đến các name servers có
thẩm quyền cho các TLDs được yêu cầu (gTLDs hoặc ccTLD). Ví dụ, nếu
người dùng yêu cầu thông tin về fred.example.com, thì các root-servers sẽ
cung cấp danh sách các name servers có thẩm quyền cho TLD .com. Năm
2004, ICANN đã nhận trách nhiệm cho việc duy trì các tập tin tổng thể TLD
root-servers- những tập tin mà danh sách các servers có thẩm quyền cho mỗi
TLD. Sự phân phối của tập tin này tới mỗi hoạt động root-servers là thực
hiện an toàn các giao dịch. Để tăng cường an ninh, server cung cấp bản cập
nhật gốc mà chỉ được truy cập từ các root-servers. Nó ko phải là 1 server
hiển thi công khai. Figure 1-4 minh họa quá trình này.

5. Top-Level Domains

─

Top-Level Domain được chia thành Generic Top-Level Domains và Country
Code Top-Level Domains. Mỗi nhóm được quản lý có chút khác nhau,
nhưng đều được kiểm soát bởi ICANN. ICANN sử dụng quá trình đã được kí
10


kết để điều khiển gTLDs. Trong trường hợp của ccTLDs, bởi nhiều quốc gia
và vùng lãnh thổ tham gia, nên quá trình là tư vấn hơn là kí kết bằng văn bản.
Generic Top-Level Domains

─

Generic Top-Level Domains, hay gTLDs, được ICANN sử dụng quá trình
hợp đồng hoá để kiểm soát. ICANN đã thừa hưởng gTLDs được liệt kê trong
Table 1-2, được thành lập vào năm 1998.

- Com: tên miền này được dùng cho các tổ chức thương mại.
- Edu: tên miền này được dùng cho các cơ quan giáo dục, trường

học.
Net: tên miền này được dùng cho các tổ chức mạng lớn.
Gov: tên miền này được dùng cho các tổ chức chính phủ.
Org: tên miền này được dùng cho các tổ chức khác.
Int: tên miền này được dùng cho các tổ chức quốc tế.
Infor: tên miền này dùng cho việc phục vụ thông tin.
Arpa: tên miền ngược.
Mil: tên miền dành cho các tổ chức quân sự, quốc phòng.

─

Vào tháng 11 năm 2000, ICANN đã cho phép các gTLDs mới, bạn thấy
trong Table 1-3

gTLD
Use
.aero
Sử dụng riêng cho ngành công nghiệp hàng không.
.biz
Tên miền chung cho doanh nghiệp.
.coop
Tên miền dành riêng cho các hợp tác.
.info
Tên miền dành cho phục vụ thông tin.
.museum
Tên miền dành riêng cho các bảo tang.
.name

Tên miền dành riêng cho các cá nhân.
.pro
Tên miền dành riêng cho các tổ chức, doanh nghiệp
─ Như ta thấy trong, Một số gTLDs, như .aero, chỉ đăng ký được số lượng hữu
hạn, còn những cái khác thì ko. Trong năm 2004, ICANN đã tiến hành xem
xét lại các chính sách của gTLD, 1 trong những ảnh hưởng của nó là tạo ra 1
tập hợp gTLD gọi là Sponsored TLDs (sTLDs) để làm rõ hình thức truy cập
đăng kí được cung cấp bởi gTLDs mới đó. Những tên miền .museum,
.coop, .aero, .gov, .mil, .edu, và .int đều được phân loại là sTLDs. Kể từ
tháng 11 năm 2000, ICANN cho phép 6 TLDs mới, các sTLDs: .travel, .jobs,
.mobi, .cat, .tel, và .asia.
─ Việc cấp quyền gTLDs mới luôn thu hút sự tranh luận. Vào tháng 6 năm
2008, ICANN đã thông qua 1 chính sách gTLD mới trên cơ sở là 1 bản báo
cáo của tổ chức GNSO ( Generic Names Supporting Organization Working
Group. Về bản chất, chính sách này ko giới hạn số lượng của gTLDs mới có
11


thể được tạo ra trong tương lai và cho phép bất kì bên nào có thẩm quyền để
đề xuất một gTLD mới sẽ được cân nhắc dựa theo môt nhóm các tiêu chí
khách quan. Tính đến hiện tại, không có ứng dụng gTLD được ủy quyền theo
chính sách mới này.
Country Code Top-Level Domains

─

─

Country Code Top-Level Domains được kiểm soát bởi ICANN và gồm 1 mã
2 kí tự được xác định theo tiêu chuẩn ISO 3166. ICANN đã tránh né những

vấn đề của các nước bằng cách sử dụng tiêu chuẩn ISO 3166. Tiêu chuẩn
ISO 3166 được điều khiển bởi 1 chi nhánh của Liên Hiệp Quốc, nó được tìm
ra trong những định nghĩa cái gì là (hoặc không là) 1 quốc gia.
Quản lí mã quốc gia là 1 thuật ngữ lịch sử phản ánh thời kỳ khi Internet còn
bé và riêng biệt- mã quốc gia là 1 chi nhánh của chính phủ, và mã quốc gia
trở thành 1 nguồn tài nguyên có giá trị kinh tế. Mối quan hệ giữa ICANN và
các bên quản lý mã quốc gia khá phức tạp bởi vấn đề chủ quyền và vấn đề
văn hóa, và quá trình này nghiêng về tư vấn hơn là hợp đồng hóa. Đó là 1
minh chứng cho tiêu chí tốt của tất cả các bên mà quá trình hoạt động của nó
vẫn tốt như kỳ vọng. Nhìn chung, các nhà quản lí đất nước chịu trách nhiệm
quản lí và điều hành các mã quốc gia và liên kết các TLD servers với cái nhìn
theo các tình huống riêng của họ giới hạn trong phạm vi của RFC 1591 và
ICANN’s ICP-1 (www.icann.org/en/icp/icp-1.htm). Như một phần làm cho
Internet có thể truy cập trên toàn thế giới, IDN (Internationalized Domain
Name) ccTLDs đang được giới thiệu. Xem Chương 17 để biết thêm thông tin
chi tiết về IDN ccTLDs.

CHƯƠNG 3: MÔ HÌNH HOẠT ĐỘNG CỦA
HỆ THỐNG DNS
1. Giao thức DNS

─

Hoạt động của DNS cho ví dụ, truy vấn và các hoạt động duy trì vùng sử
dụng cổng mặc định 53. Vì lí do hiệu năng, các truy vấn sử dụng giao thức
UDP với block-size là 512 bytes. TCP có thể tùy ý sắp xếp dựa trên cơ sở
giao dịch- giao dịch cho hoạt động truy vấn, nhưng do hiệu quả thực hiện với
TCP ko cao, nên điều này chỉ mang tính lí thuyết. Từ trước tới nay, thường
tránh sự vượt quá kích thước đáp ứng là 512 byte, và thực vậy 13 Ipv4 rootservers là giá trị lớn nhất để trả lại 1 giao dịch UDP đơn kích thước 512 byte.
Cả Ipv6, địa chỉ của nó dài hơn, và DNSSEC thì không làm tăng khối dữ liệu

12


─

trong giao dịch DNS. Để tránh sử dụng TCP khi kích thước khối giao dịch
DNS vượt quá 512 byte, thì có 1 tính năng gọi là EDNS0 (Extended DNS 0
RFC 2671) được sử dụng. EDNS0 (Được mô tả chi tiết hơn ở chương 17) về
cơ bản chuyển thành 1 khối kích thước UDP được mở rộng. BIND 9 và 10
đều được chuyển thành 1 khối EDNS0 có kích thước tối đa là 4096 (4K) byte
theo mặc định, mặc dù nó có thể được cấu hình. Ngay cả khi EDNS0 đã được
chuyển thành khối kích thước lớn này, phần lớn các giao dịch DNS ko an
toàn vẫn dưới mức giới hạn 512 byte. Tuy nhiên, việc thực hiện DNSSEC
nghĩa là kích thước các khối nằm trong khoảng từ 1.7K đến 2.4K, hoặc thậm
chí cao hơn. Tại những khối kích thước này, phân mảnh IP được yêu cầu trên
nhiều phương tiện truyền thông bao gồm cả mạng Ethernet LAN. Mặc dù
phân mảnh IP là 1 phần chuẩn rõ ràng của phần mềm IP, nhưng chất lượng
thực hiện của nó có thể được thay đổi trên các thiết bị local router và
modems DSL-phần phổ biến nhất của cơ sở hạ tầng thông tin liên lạc cục bộ
hiện nay. Hiệu quả duy trì do sư dụng TCP của vùng, 1 lần nữa được mặc
định trên cổng 53.
Tất cả các thông điệp trong các giao thức của hệ thống DNS sử dụng 1 định
dạng duy nhất. Định dạng này được thể hiện rõ hơn trong Figure 12-5 trang
440. Frame này được gửi bởi thiết bị phân giải đến name server. Chỉ phần
Header và phần câu hỏi được sử dụng để tạo các truy vấn. Trả lời và chuyển
tiếp các truy vấn thì sử dụng cùng frame, nhưng với nhiều phần được điền
vào hơn (câu trả lời/ sự cho phép/ những phần bổ sung khác).
0

8

16
31
Id entification
Parameters
QDcount
ANcount
NScount
ARcount
Question Section
Answer Section
Authority Section
Additional Information Section

Header format

─
─

Phần header thì luôn luôn có và có độ dài 12 bytes. Những phần khác là độ
dài biến.
ID: Là một trường 16 bits, chứa mã nhận dạng, nó được tạo ra bởi một
chương trình để thay cho truy vấn. Gói tin hồi đáp sẽ dựa vào mã nhận dạng
13


này để hồi đáp lại. Chính vì vậy mà truy vấn và hồi đáp có thể phù hợp với
nhau.
Thông số 1 giá trị 16 bit như trong Table 12-3

0 1 2 3

Q Op code
R

─
─
─
─

4

5
A
A

6
T
C

7
R
D

8 9 10
R Zero
A

11

12 13
Rcode

14

15

- QR: Là một trường 1 bit. Bít này sẽ được thiết lập là 0 nếu là gói tin truy
vấn, được thiết lập là một nếu là gói tin hồi đáp.
- Opcode: Là một trường 4 bits, được thiết lập là 0 cho cờ hiệu truy vấn,
được thiết lập là 1 cho truy vấn ngược, và được thiết lập là 2 cho tình
trạng truy vấn.
- AA: Là trường 1 bit, nếu gói tin hồi đáp được thiết lập là 1, sau đó nó sẽ
đi đến một server có thẫm quyền giải quyết truy vấn.
- TC: Là trường 1 bit, trường này sẽ cho biết là gói tin có bị cắt khúc ra do
kích thước gói tin vượt quá băng thông cho phép hay không.
- RD: Là trường 1 bit, trường này sẽ cho biết là truy vấn muốn server tiếp
tục truy vấn một cách đệ quy.
- RA: Trường 1 bit này sẽ cho biết truy vấn đệ quy có được thực thi trên
server không.
- Zero: Là trường 1 bit. Đây là một trường dự trữ, và được thiết lập là 0.
- Rcode: Là trường 4 bits, gói tin hồi đáp sẽ có thể nhận các giá trị sau:
+ 0: Cho biết là không có lỗi trong quá trình truy vấn.
+ 1: Cho biết định dạng gói tin bị lỗi, server không hiểu được truy vấn.
+ 2: Server bị trục trặc, không thực hiện hồi đáp được.
+ 3: Tên bị lỗi. Chỉ có server có đủ thẩm quyền mới có thể thiết lập giá
trị náy.
+ 4: Không thi hành. Server không thể thực hiện chức năng này.
+ 5: Server từ chối thực thi truy vấn.
QDcount: Số lần truy vấn của gói tin trong một vấn đề.
ANcount: Số lượng tài nguyên tham gia trong phần trả lời.
NScount: Chỉ ra số lượng tài nguyên được ghi lại trong các phần có thẩm

quyền của gói tin.
ARcount: Chỉ ra số lượng tài nguyên ghi lại trong phần thêm vào của gói tin.

Question section

Phần tiếp theo bao gồm các truy vấn cho name server. Nó gồm truy vấn
QDcount( thường là 1), mỗi định dạng được thể hiện trong Figure 12-6
14


0
8
Length

16

24
label 1……

31

//

//
……label n
type

─
─

─
─
─
─

00
class

Length: 1 byte chứa độ dài của lable đó
Label: 1 phần của các kí tự tên miền ( để minh họa, ibm từ ral.ibm.com). tên
miền được tham chiếu đến các câu hỏi đã được lưu lại như 1 loạt các label
biến dài, mỗi thứ được đặt trước với độ dài 1 byte.
00 cho biết phần kết thúc của tên miền và là nhãn null của tên miền gốc
Type độ dài 2bytes là kiểu của loại truy vấn. nó có thể có bất kì giá trị nào từ
trường Type trong bản ghi nguồn.
Class độ dài 2 bytes là class của truy vấn. Với những truy cập Internet, class
là IN
Ví dụ, tên miền mydiv.mycorp.com được mã hóa với những trường sau:

X'05'
"mydiv"
X'06'
"mycorp"
X'03'
"com"
X'00'
─

Vì vậy, phần vào trong phần question section này cho mydiv.mycorp.com
yêu cầu 22 bytes: trong đó 18 để lưu cho domain name và Qtype, Qclass

mỗi trường 2

Answer, authority, and additional resource sections
3 phần này gồm 1 biến số của bản ghi nguồn. Số này được chỉ rõ trong trường
phù hợp của Header. Bản ghi nguồn được trình bày trong Figure 12-7

15


─
+
+
+
2.

─

─

─

Các trường trước trường TTL có ý nghĩa tương tự như các mục câu hỏi
và:
TTL độ dài 32 bit, giá trị time to live trong các giây của bản ghi. Nghĩa là
thời gian bao lâu nó có giá trị
Rdlength có độ dài 16bit, độ dài cho trường Rdata
Rdata 1 chuỗi biến dài mà những thể hiện của nó phụ thuộc vào trường
Type

Cấu trúc dữ liệu DNS-Resource Record

Cơ sở dữ liệu phân tán của hệ thống DNS gồm các bản ghi nguồn (RRs),
được chia thành các class cho các loại network khác nhau. Chúng ta chỉ
thảo luận các class Internet của các bản ghi đó. Bản ghi nguồn cung cấp 1
ánh xạ giữa các tên miền và các đối tượng mạng. các đối tượng mạng phổ
biến là các địa chỉ các các máy chủ Internet, nhưng hệ thống DNS được
thiết kế để chứa 1 loạt các đối tượng khác nhau.
1 khu vực bao gồm 1 nhóm các bản ghi nguồn, bắt đầu với bản ghi SOA
(start of authority). Bản ghi SOA xác định tên miền của khu vực. Sẽ có
một bản ghi name server (NS) cho name server chính cho khu vực này.
Cũng có thể là những bản ghi NS cho các name servers thứ cấp. Các bản
ghi NS được sử dụng để xác định các name servers có thẩm quyền. Tiếp
theo nhưng bản ghi này là những bản ghi nguồn, nó có thể ánh xạ tên tới
địa chỉ IP hoặc tên riêng.
Figure 12-4 thể hiện điều này

16


Name
Type
Class
.TTL
RDlength
RData

─
+

Trong đó:
Name là tên miền. Hệ thống DNS rất tổng quát trong các quy tắc của nó đối

với các thành phần của domain name. Tuy nhiên, nó cũng đưa ra 1 cú pháp
cho các domain names làm giảm thiểu các khả năng của các ứng dụng mà sử
dụng phân giải DNS (có nghĩa là, gần như tất cả các ứng dụng TCp/IP) từ
những phân giải sai 1 domain name. Sự tham gia của domain name tới cú
pháp này gồm 1 loạt các label bao gồm các kí tự chữ hoặc dấu gạch ngang,
mỗi label có chiều dài từ 1 đến 63 kí tự, bắt đầu với 1 chữ cái. Mỗi cặp label
được phân cách nhau bằng dấu chấm (.) có thể đọc được, nhưng đó không
phải là các hình thức được sử dụng trong thông điệp DNS. Các Domain
names thì có phân biệt hoa thường.
+ Type kiểu của nguồn trong các bản ghi này. Có nhiều giá trị nhưng có vài
cái chung, điều đó được xác định với RFCs, được liệt kê trong Table 12-2
trang 438.
+ Class tập các giao thức. chỉ sử dụng các giá trị là IN (the internet system),
mặc dù các giá trị khác được xác định bởi RFC 1035 và bao gồm:
- CS (value 2): class CSNET. Điều này hiện nay ít được sử dụng.
- CH (value 3): class CHAOS
- HS (value 4): class Hesiod
+ TTL (time to live) thời gian mà bản ghi nguồn được lưu tại name server
cache. Nó được lưu trong DNS như 1 giá trị với độ dài 32 bit. Giá trị điển
hình cho điểm bản ghi đến địa chỉ IP là 86400s (1 ngày)
+ Rdlength giá trị nguyên độ dài 16 bit, tính theo hệ bát phân, của trường Rdata
+ Rdata chuỗi độ dài biến của hệ bát phân mô tả nguồn.
─ Định dạng của biến thông tin này theo Type và Class của bản ghi nguồn.

17


type
A
NS

CNAME
SOA
MB
MG
MR
NULL
WKS
PTR
HINFO
MINFO
MX
TXT
RP
AFSDB
X25
ISDN
RT
NSAP
NSAP-PIT
KEY
AAAA
LOC
SRV
CERT
A6
DNAME
DS
RRSIG
NSEC
DNSKEY

─

Value
1
2
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
25
28
29
33
37

38
39
39
46
47
48

Meaning
Một địa chỉ host
Máy chủ có thẩm quyền
Tên kinh điển của một bí danh
Đánh dấu sự khởi đầu của một cơ quan
Tên miền của một hộp thư
Một thành viên của nhóm mail
Đổi tên domain mail
Một bản ghi tài nguyên rỗng

RFC def
1035
1035
1035
1035
1035
1035
1035
1035
1035
Một con trỏ tên miền
1035
Máy chủ lưu trữ thông tin

1035
Hộp thư hay danh sách mail thông tin
1035
Mail trao đổi
1035
Chuỗi văn bản
1035
Ngươì chịu trách nhiệm ghi chép
1183
Tập tin cơ sở dữ liệu hệ thống
1183
X.25 bản ghi tài nguyên
1183
ISDN bản ghi tài nguyên
1183
Định tuyến qua bản ghi tài nguyên
1183
Dịch vụ mạng tích hợp với truy cập
1348
NSAP ghi con trỏ
1348
Khóa công khai kết hợp với một tên DNS 2535
Một bản ghi địa chỉ IPv6
3596
Bản ghi GPS
1876
Xác định các dịch vụ có sẵn trong khu vực 2876
Chứng nhận bản ghi tài nguyên
4398
Bản đồ của IPv6

2874
Địa chỉ ngược của IPv6
2672
Người ký gửi
4034
Chữ kí bản ghi tài nguyên số
4034
Ký gửi an toàn tiếp theo
4034
Bản ghi khóa công khai
4034

3. The SOA Resource Record
Bản ghi nguồn SOA xác định các kí tự khóa và thuộc tính cho các vùng hoặc
tên miền và được chuẩn hóa trong RFC 1035. Do sự thích hợp RR quan trong
nhất trong tập tin vùng, nó nằm giữa những phần phức tạp nhất và số lượng
đáng kể các thông số. Cú pháp của SOA RR như sau:

name ttl class rr name-server e-mail sn refresh retry expiry min
─

ví dụ:

@ IN SOA ns1.example.com. hostmaster.example.com. (
18


2003080800 ; sn = serial number
3h ; refresh time
15m ; retry = refresh retry

3w ; expiry
3h ; nx = nxdomain ttl )
─
+

SOA RR minh họa cho 2 nguyên tắc:
Sử dụng các định dạng nhiều dòng chuẩn nơi mở ngoặc đơn dòng đầu tiên,
những đóng ngoặc đơn có thể xuất hiện trên cùng hoặc bất kì dòng tiếp theo.
sự phân cách giữa các trường có thể là khoảng trắng hoặc tabs. Trong các tập
tin khu vực, tabs được sử dụng để bố trí và chỉ rõ những trường đã mất.

+

Table 2-1 là các giá trị trong ví dụ trên
Syntax

Example Usage

Description

name

@

Kí tự @ thay thế giá trị hiện tại của $ORIGIN
(trong ví dụ là example.com)

ttl

class

Không có giá trị TTL được xác định cho RR, vì
vậy ngầm định là 2 ngày từ định hướng $TTL
được sử dụng
IN

IN chỉ rõ class để là Internet (được ngầm định nếu
quên). Những giá trị khác tồn tại nhưng hiếm khi
được sử dụng.

name-server ns1.example.com

Xác định rõ name server Master chình cho vùng và
có nghĩa đặc biệt chỉ khi được sử dụng cấu hình
DNS tự động. name server tham chiếu ở đây cũng
cần phải được xác định bằng cách sử dụng một RR
NS. Trong kĩ thuật DNS, được gọi là trường
MNAME

e-mail

hostmaster.example.com. Xác định 1 địa chỉ email được cấp quyền cho khu
vực. Nó được giới thiệu trong RFC 2142 rằng
hostmaster địa chỉ email này được sử dụng duy
nhất cho mục đích này, nhưng bất kì địa chỉ có giá
trị và ổn định nào cũng có thể được sử dụng. trong
khi trường này ko thường sử dụng dấu chấm phân
cách để định rõ địa chỉ email. Trong đặc điểm của
DNS, nó được biết như là 1 trường RNAME.

Sn

2003080800

Chỉ rõ từng số hiện tại được liên kết với vùng.
Từng số phải được cập nhật thường xuyên bất kì
thay đổi tới tên miền. Chú ý rằng từng số đó có thể
là bất cứ số nào từ 0 đến 4294967295. Theo quy

19


ước, định dạng ngày được sử dụng form
yyyymmddss, trong đó yyyy là năm, mm là tháng,
dd là ngày, và ss là số lần tập tin khu vực được cập
nhật hơn 1 lần trong ngày.giá trị từ file khu vực
cho biết lần cập nhật cuối cùng vào 8 tháng 8 năm
2003. Giá trị này được sử dụng trong hoạt động
chuyển khu vực để xác định file đã thay đổi. sự
phục hồi giá trị từng số tự ra khỏi là ko tầm
thường. cần quan tâm khi cập nhật các số này.
Việc sử dụng quy ước này được thiết kế để giảm
thiểu sai sót cũng như cung cấp một cách đơn giản
theo dõi thay đổi cuối cùng tới các khu vực này
nhưng nó ko được thực hiện phổ biến.
refresh

12h

Khi giá trị refresh được dẫn tới, slave name server

cho khu vực này sẽ đọc SOA RR từ zone master.
Nếu giá trị từng số trong SOA RR cao hơn giá trị
hiện tại được lưu bới slave thì hoạt động chuyển
vùng sẽ được gọi để cập nhật hoặc làm mới bản
sao của báo cáo vùng. Tùy thuộc vào cách di
chuyển vùng được thực hiên mà giá trị tham số này
có thể xác định thay đổi nhanh như thế nào được
truyền từ master đến slave. Giá trị này từ 3 đến 24
giờ.

retry

15m

Xác định khoảng thời gian nếu slave ko liên lạc
đến zne master trong 1 chu kì. Giá trị từ 10 đến 60
phút.

expiry

3w

Xác định thời gian mà các báo cáo vùng được giả
định là ko được coi là hợp lệ và do dừng lại để trả
lời các truy vấn cho khu vực. Do đó, khi đạt thời
gian giới hạn, slave cố gắng liên lạc với zone
master; trong trường hợp thất bại thì sẽ kết nối lại
từng giai đoạn. nếu các slave thất bại trong việc
thực hiện liên lạc khi hết thời gian thì các slave dẽ
ngừng đáp ứng bất kì truy vấn nào. Lúc này vùng

đã ko hoạt động. Để đáp ứng các giá trị thiếu, giá
trị kết thúc thường được thiết lập giá trị rất cao ví
dụ từ 1 đến 3 tuần.

Nx

3h

NX đã được xác định lại trong RFC 2308, là
khoảng thời gian mà những phản hồi tiêu cực được
lưu trữ bởi 1 bộ phân tích. Như vậy, nếu 1 yêu cầu
được thực hiện cho fred.example.com và nó ko thể
phân giải, sau đó bộ phân giải sẽ trả lại Name
Error (còn được gọi là NX Domain). Bộ phân giải
sẽ tiếp tục trả lại giá trị này đến khi NX kết thúc,
lúc này nó sẽ thử lại hoạt động đã bị lỗi. BIND cho
phép 1 giá trị NX trong khoảng 0 đến 10800 ( 3

20


giờ).

3.1. The NS Resource Record
Bản ghi nguồn NS được định chuẩn trong RFC 1035 và xác định rõ name
servers có thẩm quyền( phải có ít nhất là 2) cho tên miền hoặc vùng. Cấu trúc
NS RR như sau:
name ttl class rr name
Trở lại ví dụ:

─

+
─

; name servers Resource Records for the domain
IN NS ns1.example.com.
; the second name server is
; external to this zone (domain).
IN NS ns2.example.net.
Table 2-2 cấu trúc NS RR
Syntax

─
+
+

+

Example Usage

Description

Name

Là trường trống và ngầm thay thế các giá trị hiện tại của
các trường tên (trong trường hợp này, các trường tên của
SOA RR). Có thể viết như sau example.com. IN NS
ns1.example.com., làm ít gây nhầm lẫn. Đây là ví dụ về
cách dùng những cách khác nhau cho ra cùng 1 kết quả.

Ttl

Không có giá trị TTL định nghĩa cho RR, mặc định là 2d
cho $TTL được sử dụng.

class

IN

IN xác định các class trong Internet

name

ns1.example.com. Xác định name server có thẩm quyền đối với tên miền.
trong ví dụ này, định dạng FQDN được sử dụng, nhưng
nó có thể được viết chỉ là ns1 (ko có dấu chấm) và sẽ
thay thế $ORIGIN. Báo cáo NS chỉ tới 1 name server
trong tên miền và vì vậy phải có 1 tương ứng được xác
đinh: A RR đối với Ipv4 và AAAA RR đối với Ipv6.

Cấu trúc NS RR thứ cấp từ ví dụ:
IN NS ns2.example.net.
Đây là phương thức cổ điển để định nghĩa 1 name server thứ cấp cho tên
miền. Trong trường hợp 1 name server là không có sẵn, các server thay thế sẽ
được sử dụng, dó đó đảm bảo quyền truy cập các dịch vụ như email ngay cả
khi trang web chính ko có.
NS RR thứ cấp được định nghĩa trong 1 quốc gia hoặc vùng lãnh thổ, vì vậy
ko yêu cầu 1 A RR nếu là Ipv4 (là AAAA RR nếu là Ipv6). Thêm nữa, nó
21

phải được định nghĩa sử dụng 1 FQDn; nói cách khác nó phải được ngăn
cách bằng dấu “.”. Để minh họa các lỗi có thể xảy ra do thay thế $ORIGIN,
giả sử dấu chấm trong RR bị mất, có nghĩa là, nó được viết như
ns2.example.net (ko có dấu .). phần mềm DNS sẽ được thay thế và tạo ra 1
tên ns2.example.net.example.com.- kết quả ko mong muốn nhận được.
─
+
+

─

3.2. MX Resource Record (MX RR)
Các MX RR được chuẩn hóa trong RFC 1035, xác định các máy chủ mail cho
các tên miền hay vùng. Cú pháp chính thức như sau:
Name ttl class rr preference name
Trong file ví dụ, các MX RR sau đây được định nghĩa:
- ; máy chủ mail Resource Records cho các zone (domain)
- 3w IN MX 10 mail.example.com.
- ; các máy chủ thư thứ hai là
- ; mở rộng cho zone (domain)
- IN MX 20 mail.example.net.
Bảng 2-3 bản đồ cú pháp chính thức để các bản ghi MX đầu tiên được sử
dụng trong các tập tin ví dụ, đó là nội bộ vào miền.
Bảng 2-3:
Cú pháp
name

Ví dụ

ttl

3w

class
preference

IN
10

Mô tả
Đây là trường trống và ngầm thay thế cho giá
trị ở bên phải trường name từ RR trước ( ở file
ví dụ, đây là example.com.).
Điều này minh họa việc sử dụng một giá trị ttl
rõ ràng trong một RR đó sẽ ghi đè zone mặc
định (được định nghĩa trong $TTL). Giá trị
hiển thị (ba tuần) là cao hơn zone mặc định,
đó là hai ngày. Vì domain MX RR là không
thay đổi (nó tương ứng với một RR có thể
thay đổi thường xuyên hơn) tại sao không
giảm thiểu tải DNS trên những gì là bình
thường một loại RR rất tích cực sử dụng? Ttl
có thể, tuy nhiên, có bất kỳ giá trị cần thiết
bao gồm cả thiếu sót, trong đó có trường hợp
mặc định khu vực này sẽ được sử dụng.
IN định nghĩa class tới Internet.
Trường preference chỉ ra các ưu tiên tương
đối hoặc ưu tiên của máy chủ mail nó xác

định và có thể mất bất kỳ giá trị giữa 0 và
65535. Số càng thấp, sự ưa thích hơn các máy

22


name

mail.example.com

chủ. Theo truyền thống, máy chủ mail ưa
thích nhất có giá trị ưu đãi 10 hoàn toàn
không có lý do cho điều này khác hơn là nó
cho phép một bản ghi MX với một giá trị
thích hợp hơn (1 số nhỏ hơn) sẽ được thêm
vào mà không cần thay đổi bất cứ bản ghi
khác.
Định nghĩa một máy chủ mail với giá trị
preference quy định đối với tên miền. Trong
ví dụ này, một định dạng FQDN đã được sử
dụng, nhưng bạn có thể viết mail chỉ như này
(không có dấu chấm) và một $ORIGIN sẽ
thay thế. MX này điểm ghi vào một mail
server trong miền và do đó phải có một tương
ứng A RR cho IPv4 (hoặc AAAA cho IPv6).

─ Các MX RR thứ hai từ file ví dụ như sau:
+ IN MX 20 mail.example.net.
+ Đây là phương pháp cổ điển của việc xác định một máy chủ mail dự phòng,
trong đó có một giá trị ưu đãi thấp hơn (20 trong ví dụ). Trong trường hợp

các máy chủ mail đầu tiên là không có sẵn, các máy chủ mail dự phòng (lý
tưởng tại một vị trí địa lý khác nhau) sẽ được sử dụng. Máy chủ mail dự
phòng này thường được định nghĩa là một máy chủ mail chuyển tiếp đơn
giản cho các tên miền, không ngừng cố gắng để vượt qua mail cho các mail
server được ưa tiên nhất (hoặc sơ cấp nhất) (mail.example.com) khi dịch vụ
được phục hồi. Các MX RR thứ hai được xác định là trong một miền nước
ngoài hoặc bên ngoài và do đó không yêu cầu A RR nếu IPv4 (hoặc một RR
AAAA nếu IPv6) được định nghĩa và phải luôn luôn là một FQDN (nói cách
khác, nó phải kết thúc với một chấm).

─

+
+
-

3.3. A Resource Record ( A RR)
A RR được chuẩn hóa trong RFC 1035, xác định các địa chỉ IPv4 của một
máy chủ cụ thể trong lĩnh vực hoặc khu vực. RR tương đương cho IPv6 là
RR AAAA mô tả trong Chương 5. Cú pháp chính thức của Địa chỉ RR là như
sau:
name ttl class rr ipv4
Trong file ví dụ, A RRs được định nghĩa:
ns1 IN A 192.168.254.2
mail IN A 192.168.254.4
joe IN A 192.168.254.6
23


- www IN A 192.168.254.7

Bảng 2-4: A RR Syntax
Cú pháp
name

Ví dụ
ns1

Ttl
class
Ipv4

IN
192.168.254.2

Mô tả
Tên của nó không đủ tiêu chuẩn, gây nên sự thay
thế $ ORIGIN. Bạn có thể viết này như
ns1.example.com. (bằng cách sử dụng định dạng
FQDN), có thể dễ hiểu hơn.
Không có giá trị tt1 định nghĩa cho RR, mặc định
vùng 2d những chỉ thị $TTL sẽ được sử dụng.
IN định nghĩa class tới Internet.
Xác định rằng host ns1 có địa chỉ IPv4
192.168.254.2. Những bản ghi theo quy định của
NS hay RR MX có tên chứa trong miền này phải có
tương ứng A RR như trong khu tập tin ví dụ cho
ns1 và mail. Bất kỳ máy chủ khác khi người dùng
muốn làm cho hiển thị công khai cũng được xác
định bằng cách sử dụng A RR; trong file ví dụ, điều

này bao gồm các dịch vụ web (www) và các name
server joe vì một lý do tốt nhất được biết đến chủ
sở hữu tên miền.

─ Nó được cho phép để xác định địa chỉ IP cùng với nhiều tên như trong đoạn
sau đây (ở đây là name server và máy chủ web được đồng nằm trên một
máy):
ns1 IN A 192.168.254.2
mail IN A 192.168.254.4
joe IN A 192.168.254.6
A RR này có địa chỉ IPv4 giống như ns1 bên trên.
www IN A 192.168.254.2
─ Cùng một kết quả có thể đạt được bằng cách sử dụng một bản ghi CNAME
(xem phần tiếp theo). Nhiều địa chỉ IP cũng có thể được xác định cho các
24


máy chủ giống như trong đoạn này, nơi ba địa chỉ IPv4 được cung cấp cho
host www.example.com :
www IN A 192.168.254.2
IN A 192.168.254.7
IN A 192.168.254.8
─ Phần mềm DNS sẽ cung cấp địa chỉ IP ấn định trong một round-robin hoặc
thứ tự ngẫu nhiên (được xác định bởi cấu hình có chỉ thị) để truy vấn liên
tiếp. Tính năng này có thể được sử dụng để cung cấp cân bằng tải và được
mô tả ở Chương 8. Đoạn trên cũng minh họa việc sử dụng một tên null hoặc
trống kế thừa các tên trước đây; nghĩa là, tất cả các mục với một tên trống
liên quan đến www (và giả định một chỉ thị $ ORIGIN của example.com sẽ
xác định www.example.com).
3.4. CNAME Resource Record

─ CNAME RR được chuẩn hóa trong RFC 1035, định nghĩa một bí danh cho
một máy chủ hiện tại được xác định bởi một A RR. Cú pháp chính thức như
sau:
name ttl class rr canonical-name
─ Trong ví dụ tập tin, các CNAME RR sau đây được định nghĩa:
ftp IN CNAME ftp.example.net.
Bảng 2-5 cú pháp CNAME RR:
Cú pháp
name

Ví dụ
ftp

Ttl

class
Canonicalname

IN
ftp.example.net

Mô tả
Tên của nó không đủ tiêu chuẩn, gây nên sự thay
thế $ ORIGIN. Bạn có thể viết này như
ftp.example.com. (bằng cách sử dụng định dạng
FQDN), có thể dễ hiểu hơn.
Không có giá trị tt1 định nghĩa cho RR, mặc
định vùng 2d những chỉ thị $TTL sẽ được sử
dụng.
IN định nghĩa class tới Internet.

Xác định rằng tên ftp.example.com được đặt bí
danh cho host ftp.example.net. trong một miền
nước ngoài hoặc bên ngoài. Trong DNS biệt
ngữ, ftp.example.net. được gọi là tên kinh điển,
mà chỉ đơn giản có nghĩa là tên dự kiến hoặc tên

25