1. Giới thiệu DNS :
Mỗi máy tính trong mạng muốn liên lạc hay trao đổi thông tin, dữ liệu cho nhau cần phải biết rõ địa chỉ IP của nhau. Nếu số lượng máy tính trong mạng nhiều thì việc nhớ những IP này là rất khó khăn
Mỗi máy tính ngoài địa chỉ IP ra còn có tên máy (host name). Đối với con người thì việc nhớ tên máy bao giờ cũng dễ nhớ hơn địa chỉ IP vì chúng có tính trực quang và gợi nhớ hơn. Do đó người ta tìm cách ánh xạ địa chỉ IP thành tên máy.
Lúc đầu do quy mô của mạng APRA NET (tiền thân của mạng Internet ngày nay) chỉ có vài trăm máy nên chỉ có 1 tập tin hosts.txt lưu thông tin dùng để ánh xạ tên máy thành địa chỉ IP, do đó tên máy chỉ là 1 chuỗi văn bản không phân cấp (flat name). Tập tin này được lưu tại 1 máy chủ và các máy chủ khác lưu bản sao của nó. Khi quy mô mạng lớn hơn thì việc sử dụng file hosts.txt này bộc lộ các khuyết điểm sau :
1. Lưu lượng mạng và máy chủ chứa tập tin hosts.txt bị quá tải do hiệu ứng “cổ chai”.
2. Xung đột tên : không thể có 2 máy có cùng tên trong tập tin hosts.txt (do chưa có cơ chế phân cấp và ủy quyền quản lý tên).
3. Không đảm bảo sự toàn vẹn : việc duy trì 1 tập tin trên mạng lớn rất khó khăn. Ví dụ như khi tập tin hosts.txt vừa cập nhật chưa kịp chuyển đến 1 máy chủ khác ở xa thì đã có sự thay đổi địa chỉ trên mạng rồi.
Tóm lại : việc sử dụng tập tin hosts.txt không phù hợp cho 1 mạng lớn vì thiếu tính phân tán và mở rộng.
Do đó dịch vụ DNS ra đời, và người thiết kế cấu trúc của dịch vụ DNS là Paul Mockapetris – USC’s Information Sciences Institute và các kiến nghị RFC của DNS là RFC 882 và 883, sau đó là RFC 1034 và 1035 cùng với 1 số RFC bổ xung như bảo mật trên hệ thống DNS, cập nhật các record của DNS
Lưu ý: hiện nay trên các máy chủ vẫn sử dụng tập tin hosts.txt để phân giải tên máy tính thành địa chỉ IP (trong Windows tập tin này nằm trong đường dẫn WINDOWS\system32\drivers\tec)
Dịch vụ DNS hoạt động theo mô hình Client-Server :
Server : có chức năng là phân giải tên--->IP và ngược lại IP--->tên, được gọi là Name Server, lưu trữ cơ sở dữ liệu của DNS
Client : truy vấn phân giải tên đến DNS server được gọi là Resolver, chứa các hàm thư viện dùng để tạo các truy vấn (query) đến Name Server.
DNS được thi hành như 1 giao thức của tầng Application trong mô hình mạng TCP/IP
DNS là 1 cơ sở dữ liệu dạng phân tán được tổ chức theo mô hình cây (hierarchical) :
 | Click this bar to view the full image. |
Một hostname trong domain là sự kết hợp giữa những từ phân cách nhau bởi dấu chấm (.)
Ví dụ : tên máy là server1 gọi là hostname. Tên đầy đủ trong domain theo mô hình trên thì là server1.sales.south.nwtraders.com gọi là FQDN (Fully Qualified Domain Name).
Cơ sở dữ liệu (CSDL) của DNS là 1 cây đảo ngược, mỗi node trên cây là gốc của 1 cây con. Mỗi cây con là 1 phân vùng con trong toàn bộ CSDL của DNS gọi là 1 domain. Mỗi domain có thể phân chia thành các miền con nhỏ hơn gọi là subdomain.
Các top-level domain :
Vì sự quá tải của các domain name đã tồn tại, do đó đã làm phát sinh những top-level domain mới. Bảng sau đây liệt kê các top-level domain mới
Bên cạnh đó, mỗi quốc gia cũng có top-level domain. Bảng sau sẽ liệt kê 1 số top-level domain của 1 số quốc gia trên thế giới.
2. Đặc điểm của DNS trong Windows Server 2003
- Conditional forwarder : cho phép Name Server chuyển các request resolve theo tên domain trong request query.
- Stub zone : hỗ trợ cho cơ chế phân giải hiệu quả hơn.
- DNS zone in replication in Active Directory : đồng bộ các DNS zone trong Active Directory.
- Cung cấp 1 số cơ chế bảo mật tốt hơn so với các hệ thống Windows trước đây
- Round Robin : luân chuyển các loại Resource Record
- Event View : cung cấp nhiều cơ chế ghi nhận và theo dõi các lỗi trên DNS.
- Hỗ trợ giao thức DNS Security Extensions (DNSSEC) để cung cấp các tính năng bảo mật cho việc lưu trữ và replicate zone.
- Cung cấp tính năng EDNS0 (Extension Mechanisms for DNS) để cho phép DNS Requestor quảng bá những zone transfer packet có kích thước lớn hơn 512 byte
3. Cách phân bố dữ liệu quản lý domain
Các top-level domain được quản lý bởi những Root Name Server (.) trên Internet. Gọi là Root Hints. Tên máy và địa chỉ IP của những Name Server này được công bố cho mọi người biết và các Name Server này được bảo mật rất kỹ (được quân đội bảo vệ). Đường dẫn của file chứa thông tin Root Hints trên Name Server : %SystemRoot%\System32\DNS\cache.dns. File này được gọi là root name server hints file. Những Name Server này được bố trí khắp nơi trên thế giới. Sau đây là bảng liệt kê tên và địa chỉ IP của các Root Name Server này
| This image has been resized. Click this bar to view the full image. The original image is sized 600x354. |
DNS server gồm có 2 loại :
- Primary name server : là DNS server chính, trên đó cho phép thêm, xóa sửa CSDL của DNS
- Secondary name sever : là DNS server phụ, backup lại CSDL của Primary. Không được thay đổi CSDL DNS. Trong trường hợp Primary name server bị fail, Secondary được sử dụng để phân giải tên. Sau 24h nếu Secondary name server không được chuyển lên Primary name server thì CSDL DNS của nó sẽ bị expire (hết hạn sử dụng) và lúc đó nó sẽ không phân giải tên được nữa.
Thường thì các Name Server này hoạt động theo cơ chế Load Balancing hay Cluster để tăng tính Performing và Fault-Tolerance
Mô hình Cluster DNS
4. Cơ chế phân giải tên
- DNS service có 2 chức năng chính là phân giải tên --> IP và IP --> tên.
4.1 Phân giải tên thành địa chỉ IP
Root Name Server là máy chủ quản lý các name server ở mức top-level domain. Khi có query về 1 tên domain nào đó thì Root Name Server sẽ cung cấp tên và địa chỉ IP của name server quản lý top-level domain đó (thực tế thì hầu hết các root server cũng chính là máy chủ quản lý top-level domain) và đến lược các name server của top-level domain cung cấp danh sách các name server có quyền trên các secon-level domain mà domain này thuộc vào. Cứ như thế đến khi nào tìm được máy chủ quản lý tên domain cần truy vấn.
Qua quá trình trên cho thấy vai trò rất quan trọng của Root Name Server trong quá trình phân giải tên domain. Nếu mọi Root Name Server trên mạng Internet không liên lạc được với nhau thì mọi yêu cầu phân giải tên đều sẽ không được thực hiện.
Ví dụ : client cần truy cập trang web www.yahoo.com thì client sẽ yêu cầu phân giải địa chỉ IP của web server nào có chứa website www.yahoo.com này. Đầu tiên client sẽ tìm trong cache của nó, nếu cache của nó không có thì nó sẽ gửi request querry đến DNS local (nếu trong mạng nội bộ có DNS server). Sau đó DNS local cũng sẽ tìm trong cache của nó, nếu có nó sẽ gửi địa chỉ IP cần truy vấn đến cho client, nếu cache không có thì lúc này DNS local sẽ gửi request query này đến 1 Root Name Server nào đó gần nó nhất mà nó biết được. Sau đó Root Name Server này sẽ trã lời địa chỉ IP của Name Server quản lý miền .com cho DNS local. DNS local lại hỏi tiếp name server quản lý domain .com miền yahoo.com địa chỉ IP là bao nhiêu. Cuối cùng DNS local truy vấn máy chủ quản lý domain www.yahoo.com và nhận được câu trả lời.
Có 2 dạng truy vấn (query) :
- Recursive query : khi Name Server nhận được truy vấn dạng này, nó bắt buộc phải trả kết quả tìm được hoặc thông báo lỗi nếu như truy vấn này không phân giải được. Name Server không thể tham chiếu đến 1 Name Server khác. Name Server có thể gửi truy vấn dạng recursive hoặc interative đến Name Server khác nhưng phải thực hiện cho đến khi nào có kết quả mới thôi.
- Interative query : khi Name Server nhận được truy vấn dạng này, nó sẽ trả lời cho Resolver với thông tin tốt nhất mà nó có được vào thời điểm lúc đó. Bản thân Name Server không thực hiện bất cứ 1 truy vấn nào thêm. Thông tin trả về lúc đó có thể lấy từ dữ liệu cục bộ (kể cả cache). Trong trường hợp Name Server không tìm thấy thông tin trong dữ liệu cục bộ nó sẽ trả về tên miền và địa chỉ IP của Name Server nào gần nhất mà nó biết.
Interactive query
Tóm lại :
- Truy vấn giữa Resolver ---> DNS Server là recursive query
- Truy vấn giữa DNS Server ---> DNS Server là interactive query
4.2 Phân giải địa chỉ IP thành tên host
Để có thể phân giải tên máy tính của 1 địa chỉ IP, trong không gian tên miền người ta bổ xung thêm 1 nhánh tên miền mà được lập chỉ mục theo địa chỉ IP. Phần không gian này có tên miền là in-addr.arpa.
Mỗi node trong miền in-addr.arpa có 1 tên nhãn là chỉ số thập phân của địa chỉ IP. Ví dụ miền in-addr.arpa có thể có 256 subdomain tương ứng với 256 giá trị từ 0 --> 255 của byte đầu tiên trong địa chỉ IP. Trong mỗi subdomain lại có 256 subdomain con nữa ứng với byte thứ 2. Cứ như thế và đến byte thứ 4 có các bản ghi cho biết tên miền đầy đủ của các máy tính hoặc các mạng có địa chỉ IP tương ứng.
5. Một số khái niệm cơ bản
5.1 Domain Name và Zone
Một domain có thể có 1 hoặc nhiều domain con bên trong nó gọi là subdomain.
Ví dụ : domain com có nhiều domain con như vnnetpro.com, yahoo.com, google.com,…
Bạn có thể delegation control cho các DNS Server khác quản lý. Những domain và subdomain mà DNS Server quản lý gọi là Zone. Như vậy 1 zone có thể gồm 1 domain, 1 hoặc nhiều subdomain
Zone và Domain
Các loại zone :
- Primary zone : cho phép đọc và ghi cơ sở dữ liệu
- Secondary zone : là bản sao cơ sở dữ liệu DNS của Primary zone, có được nhờ quá trình zone transfer (phải được primary zone cho phép transfer).
- Stub zone : chứa bản sao cơ sở dữ liệu DNS của zone nào đó, nó chỉ chứa 1 vài resource record.
5.2 Delegation
Một trong các mục tiêu khi thiết kế hệ thống DNS là khả năng quản lý phân tán thông qua cơ chế ủy quyền (delegation control). Trong 1 domain có thể tổ chức thành nhiều subdomain, mỗi subdomain có thể được ủy quyền cho 1 tổ chức khác và tổ chức đó chịu trách nhiệm duy trì thông tin trong subdomain này. Khi đó parent domain chỉ cần 1 con trỏ, trỏ đến subdomain này khi có truy vấn đến subdomain đó.
5.3 Forwarder
Là kỹ thuật cho phép DNS Server local chuyển yêu cầu truy vấn cho các DNS Server khác để phân giải các domain bên ngoài.
Forwarder DNS queries
Theo mô hình trên thì ta thấy khi lnternal DNS server nhận yêu cầu truy vấn của Computer1, thì nó sẽ kiểm tra xem có thể phân giải được tên miền này hay không, nếu không phân giải được thì nó sẽ chuyển yêu cầu này lên Forwarder DNS Server (multihomed) để nhờ Name Server này phân giải dùm. Sau khi xem xét xong thì Forwarder DNS Server sẽ trả lời yêu cầu này cho Internal DNS Server hoặc nó sẽ tiếp tục forwarder lên các Name Server khác ngoài Internet.
5.4 Stub Zone
Là zone chứa bản sao cơ sở dữ liệu DNS từ Master Name Server. Stub zone chỉ chứa các resource record cần thiết như : A, SOA, NS, 1 hoặc vài địa chỉ của Master Name Server hỗ trợ cơ chế cập nhật Stub zone, cơ chế chứng thực Name Server trong zone và cung cấp cơ chế phân giải tên domain được hiệu quả hơn, đơn giản hóa công tác quản trị.
5.5 Resolver
Resolver là những Client truy vấn Name Server. Bất kỳ máy tính nào cần truy vấn thông tin về Domain Name đều dùng Resolver. Resolver đảm nhận 3 vai trò sau :
- Querying a Name Server : truy vấn 1 Name Server.
- Interpreting Responses : phân giải kết quả.
- Returning the information to the programs that requested it : trả kết quả về cho chương trình đã yêu cầu.
5.6 Dynamic DNS
Dynamic DNS là phương thức ánh xạ tên miền --> địa chỉ IP có tần suất thay đổi cao, dynamic DNS cung cấp 1 chương trình đặc biệt chạy trên máy tính của người sử dụng dịch vụ dynamic DNS gọi là dynamic DNS Client. Chương trình này giám sát sự thay đổi địa chỉ IP tại host và liên hệ với hệ thống DNS mỗi khi địa chỉ IP của host thay đổi và sau đó update thông tin vào cơ sở dữ liệu DNS về sự thay đổi địa chỉ đó.
DNS Client đăng ký và cập nhật resource record của nó bằng cách gửi dynamic update.
Dynamic update
Các DHCP Server đăng ký và cập nhật resource record cho client
DHCP Server cập nhật Dynamic update
DHCP & DNS Interaction for pre-Windows 2000 Clients
DHCP and DNS Interaction
5.7 Caching
DNS Server và Client sẽ lưu lại những truy vấn (caching) để khi được truy vấn lần sau nó sẽ tìm trong cache trước, nếu cache có nó sẽ trả lời ngay lập tức mà không cần truy vấn nữa. Đều này giúp cho mạng hoạt động nhanh hơn (tăng performing).
5.8 Time to live (TTL)
Những dữ liệu được cache lại trong DNS server hoặc Client sẽ không tồn tại vĩnh viễn vì có thể thông tin của dữ liệu đó thực tế đã bị thay đổi bởi Primary Name Server phụ trách cho dữ liệu đó. TTL là thời gian mà các DNS Server hoặc Client được phép cache thông tin đã truy vấn được, sau thời gian đó các DNS Server hoặc Client sẽ phải hủy tất cả các cache đó và đi lấy thông tin mới bằng cách truy vấn lại. Giá trị TTL này có thể được thay đổi bởi người quản trị trong việc khai báo TTL cho dữ liệu đó.
5.9 Active Directory – Intergrated Zone
Sử dụng Active Directory – Intergrated Zone có 1 số thuận lợi sau :
- Security : cơ sở dữ liệu DNS được tích hợp chung với Active Directory nên không còn ở dạng plaintext khi transfer nữa mà được encypt chung với cơ sở dữ liệu của AD.
- Replicate : sử dụng cơ chế replicate của AD để update và replicate DNS database
- Sử dụng Security Dynamic update
- Sử dụng nhiều Master Name Server để quản lý Domain Name thay vì chỉ sử dụng 1 Master Name Server
Mô hình Active Directory – Intergrated zone sử dụng Security Dynamic Update
Secure Dynamic Update
- DNS service có 2 chức năng chính là phân giải tên --> IP và IP --> tên.
4.1 Phân giải tên thành địa chỉ IP
Root Name Server là máy chủ quản lý các name server ở mức top-level domain. Khi có query về 1 tên domain nào đó thì Root Name Server sẽ cung cấp tên và địa chỉ IP của name server quản lý top-level domain đó (thực tế thì hầu hết các root server cũng chính là máy chủ quản lý top-level domain) và đến lược các name server của top-level domain cung cấp danh sách các name server có quyền trên các secon-level domain mà domain này thuộc vào. Cứ như thế đến khi nào tìm được máy chủ quản lý tên domain cần truy vấn.
Qua quá trình trên cho thấy vai trò rất quan trọng của Root Name Server trong quá trình phân giải tên domain. Nếu mọi Root Name Server trên mạng Internet không liên lạc được với nhau thì mọi yêu cầu phân giải tên đều sẽ không được thực hiện.
Ví dụ : client cần truy cập trang web www.yahoo.com thì client sẽ yêu cầu phân giải địa chỉ IP của web server nào có chứa website www.yahoo.com này. Đầu tiên client sẽ tìm trong cache của nó, nếu cache của nó không có thì nó sẽ gửi request querry đến DNS local (nếu trong mạng nội bộ có DNS server). Sau đó DNS local cũng sẽ tìm trong cache của nó, nếu có nó sẽ gửi địa chỉ IP cần truy vấn đến cho client, nếu cache không có thì lúc này DNS local sẽ gửi request query này đến 1 Root Name Server nào đó gần nó nhất mà nó biết được. Sau đó Root Name Server này sẽ trã lời địa chỉ IP của Name Server quản lý miền .com cho DNS local. DNS local lại hỏi tiếp name server quản lý domain .com miền yahoo.com địa chỉ IP là bao nhiêu. Cuối cùng DNS local truy vấn máy chủ quản lý domain www.yahoo.com và nhận được câu trả lời.
Có 2 dạng truy vấn (query) :
- Recursive query : khi Name Server nhận được truy vấn dạng này, nó bắt buộc phải trả kết quả tìm được hoặc thông báo lỗi nếu như truy vấn này không phân giải được. Name Server không thể tham chiếu đến 1 Name Server khác. Name Server có thể gửi truy vấn dạng recursive hoặc interative đến Name Server khác nhưng phải thực hiện cho đến khi nào có kết quả mới thôi.
DNS server kiểm tra cache và forward lookup zone để gửi lại query
Recursive query
Recursive query
- Interative query : khi Name Server nhận được truy vấn dạng này, nó sẽ trả lời cho Resolver với thông tin tốt nhất mà nó có được vào thời điểm lúc đó. Bản thân Name Server không thực hiện bất cứ 1 truy vấn nào thêm. Thông tin trả về lúc đó có thể lấy từ dữ liệu cục bộ (kể cả cache). Trong trường hợp Name Server không tìm thấy thông tin trong dữ liệu cục bộ nó sẽ trả về tên miền và địa chỉ IP của Name Server nào gần nhất mà nó biết.
Interactive query
Tóm lại :
- Truy vấn giữa Resolver ---> DNS Server là recursive query
- Truy vấn giữa DNS Server ---> DNS Server là interactive query
4.2 Phân giải địa chỉ IP thành tên host
Để có thể phân giải tên máy tính của 1 địa chỉ IP, trong không gian tên miền người ta bổ xung thêm 1 nhánh tên miền mà được lập chỉ mục theo địa chỉ IP. Phần không gian này có tên miền là in-addr.arpa.
Mỗi node trong miền in-addr.arpa có 1 tên nhãn là chỉ số thập phân của địa chỉ IP. Ví dụ miền in-addr.arpa có thể có 256 subdomain tương ứng với 256 giá trị từ 0 --> 255 của byte đầu tiên trong địa chỉ IP. Trong mỗi subdomain lại có 256 subdomain con nữa ứng với byte thứ 2. Cứ như thế và đến byte thứ 4 có các bản ghi cho biết tên miền đầy đủ của các máy tính hoặc các mạng có địa chỉ IP tương ứng.
5. Một số khái niệm cơ bản
5.1 Domain Name và Zone
Một domain có thể có 1 hoặc nhiều domain con bên trong nó gọi là subdomain.
Ví dụ : domain com có nhiều domain con như vnnetpro.com, yahoo.com, google.com,…
Bạn có thể delegation control cho các DNS Server khác quản lý. Những domain và subdomain mà DNS Server quản lý gọi là Zone. Như vậy 1 zone có thể gồm 1 domain, 1 hoặc nhiều subdomain
| Click this bar to view the full image. |
| Click this bar to view the full image. |
Zone và Domain
Các loại zone :
- Primary zone : cho phép đọc và ghi cơ sở dữ liệu
- Secondary zone : là bản sao cơ sở dữ liệu DNS của Primary zone, có được nhờ quá trình zone transfer (phải được primary zone cho phép transfer).
- Stub zone : chứa bản sao cơ sở dữ liệu DNS của zone nào đó, nó chỉ chứa 1 vài resource record.
5.2 Delegation
Một trong các mục tiêu khi thiết kế hệ thống DNS là khả năng quản lý phân tán thông qua cơ chế ủy quyền (delegation control). Trong 1 domain có thể tổ chức thành nhiều subdomain, mỗi subdomain có thể được ủy quyền cho 1 tổ chức khác và tổ chức đó chịu trách nhiệm duy trì thông tin trong subdomain này. Khi đó parent domain chỉ cần 1 con trỏ, trỏ đến subdomain này khi có truy vấn đến subdomain đó.
5.3 Forwarder
Là kỹ thuật cho phép DNS Server local chuyển yêu cầu truy vấn cho các DNS Server khác để phân giải các domain bên ngoài.
| This image has been resized. Click this bar to view the full image. The original image is sized 598x325. |
Forwarder DNS queries
Theo mô hình trên thì ta thấy khi lnternal DNS server nhận yêu cầu truy vấn của Computer1, thì nó sẽ kiểm tra xem có thể phân giải được tên miền này hay không, nếu không phân giải được thì nó sẽ chuyển yêu cầu này lên Forwarder DNS Server (multihomed) để nhờ Name Server này phân giải dùm. Sau khi xem xét xong thì Forwarder DNS Server sẽ trả lời yêu cầu này cho Internal DNS Server hoặc nó sẽ tiếp tục forwarder lên các Name Server khác ngoài Internet.
5.4 Stub Zone
Là zone chứa bản sao cơ sở dữ liệu DNS từ Master Name Server. Stub zone chỉ chứa các resource record cần thiết như : A, SOA, NS, 1 hoặc vài địa chỉ của Master Name Server hỗ trợ cơ chế cập nhật Stub zone, cơ chế chứng thực Name Server trong zone và cung cấp cơ chế phân giải tên domain được hiệu quả hơn, đơn giản hóa công tác quản trị.
5.5 Resolver
Resolver là những Client truy vấn Name Server. Bất kỳ máy tính nào cần truy vấn thông tin về Domain Name đều dùng Resolver. Resolver đảm nhận 3 vai trò sau :
- Querying a Name Server : truy vấn 1 Name Server.
- Interpreting Responses : phân giải kết quả.
- Returning the information to the programs that requested it : trả kết quả về cho chương trình đã yêu cầu.
5.6 Dynamic DNS
Dynamic DNS là phương thức ánh xạ tên miền --> địa chỉ IP có tần suất thay đổi cao, dynamic DNS cung cấp 1 chương trình đặc biệt chạy trên máy tính của người sử dụng dịch vụ dynamic DNS gọi là dynamic DNS Client. Chương trình này giám sát sự thay đổi địa chỉ IP tại host và liên hệ với hệ thống DNS mỗi khi địa chỉ IP của host thay đổi và sau đó update thông tin vào cơ sở dữ liệu DNS về sự thay đổi địa chỉ đó.
DNS Client đăng ký và cập nhật resource record của nó bằng cách gửi dynamic update.
| This image has been resized. Click this bar to view the full image. The original image is sized 600x383. |
Dynamic update
Các DHCP Server đăng ký và cập nhật resource record cho client
| This image has been resized. Click this bar to view the full image. The original image is sized 599x401. |
DHCP Server cập nhật Dynamic update
| Click this bar to view the full image. |
DHCP & DNS Interaction for pre-Windows 2000 Clients
| This image has been resized. Click this bar to view the full image. The original image is sized 600x371. |
DHCP and DNS Interaction
5.7 Caching
DNS Server và Client sẽ lưu lại những truy vấn (caching) để khi được truy vấn lần sau nó sẽ tìm trong cache trước, nếu cache có nó sẽ trả lời ngay lập tức mà không cần truy vấn nữa. Đều này giúp cho mạng hoạt động nhanh hơn (tăng performing).
5.8 Time to live (TTL)
Những dữ liệu được cache lại trong DNS server hoặc Client sẽ không tồn tại vĩnh viễn vì có thể thông tin của dữ liệu đó thực tế đã bị thay đổi bởi Primary Name Server phụ trách cho dữ liệu đó. TTL là thời gian mà các DNS Server hoặc Client được phép cache thông tin đã truy vấn được, sau thời gian đó các DNS Server hoặc Client sẽ phải hủy tất cả các cache đó và đi lấy thông tin mới bằng cách truy vấn lại. Giá trị TTL này có thể được thay đổi bởi người quản trị trong việc khai báo TTL cho dữ liệu đó.
5.9 Active Directory – Intergrated Zone
Sử dụng Active Directory – Intergrated Zone có 1 số thuận lợi sau :
- Security : cơ sở dữ liệu DNS được tích hợp chung với Active Directory nên không còn ở dạng plaintext khi transfer nữa mà được encypt chung với cơ sở dữ liệu của AD.
- Replicate : sử dụng cơ chế replicate của AD để update và replicate DNS database
- Sử dụng Security Dynamic update
- Sử dụng nhiều Master Name Server để quản lý Domain Name thay vì chỉ sử dụng 1 Master Name Server
Mô hình Active Directory – Intergrated zone sử dụng Security Dynamic Update
| This image has been resized. Click this bar to view the full image. The original image is sized 600x366. |
Secure Dynamic Update
6. Phân loại Domain Name Server
6.1 Primary Name Server
Mỗi Domain phải có 1 Primary Name Server. Server này được register trên Internet để quản lý Domain. Mọi người trên Internet đều biết tên máy tính và IP của Server này. Người quản trị DNS sẽ tổ chức các cơ sở dữ liệu DNS trên Primary Name Server. Server này đảm nhận vai trò chính trong việc phân giải tất cả các máy tính trong Domain hay Zone
6.2 Secondary Name Server
Mỗi Domain có 1 Primary Name Server để quản lý cơ sở dữ liệu DNS. Nếu như Server này tạm ngưng hoạt động vì 1 lý do nào đó thì việc phân giải DNS bị gián đoạn. Để tránh trường hợp này ngườ ta đã thiết kế ra 1 máy chủ dự phòng gọi là Secondary Name Server (hay còn gọi là Slave). Khi Secondary Name Server được khởi động nó sẽ tìm Primary Name Server nào mà nó được phép lấy dữ liệu về máy. Nó sẽ copy lại toàn bộ CSDL DNS của Primary Name Server mà nó được phép transfer (quá trình này gọi là quá trình Zone Transfer). Theo 1 chu kỳ nào đó do người quản trị quy định thì Secondary Name Server sẽ sao chép và cập nhật CSDL từ Primary Name Server.
6.3 Caching Name Server
Caching Name Server không có bất kỳ tập tin CSDL nào. Nó có chức năng phân giải tên máy trên những mạng ở xa thông qua những Name Server khác. Nó sẽ lưu lại những thông tin đã được phân giải trước đó và được sử dụng lại những thông tin này nhằm mục đích :
- Làm tăng tốc độ phân giải bằng cách sử dụng cache.
- Giảm bớt gánh nặng phân giải tên máy cho các Name Server.
- Giảm việc lưu thông trên những mạng lớn.
7. Resource Record (RR)
RR là mẫu thông tin dùng để mô tả các thông tin về cơ sở dữ liệu DNS, các mẫu thông tin này được lưu trong các file cơ sở dữ liệu của DNS (%systemroot%\system32\dns)
7.1 SOA (Start of Authority)
Trong mỗi tập tin CSDL phải có 1 và chỉ 1 record SOA. Bảng ghi SOA này chỉ ra rằng Primary Name Server là nơi cung cấp thông tin tin cậy từ dữ liệu có trong zone.
Cú pháp của 1 record SOA :
[tên-miền] IN SOA [tên-DNS-Server] [địa-chỉ-email] (
Serial number;
Refresh number;
Retry number;
Experi number;
Time-to-line number)
Ví dụ :
vnnetpro.com. IN SOA server1.vnnetpro.com. sangnt.vnnetpro.com. (
1 ; serial
10800 ; refresh after 3 hours
3600 ; retry after 1 hours
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
Giải thích ý nghĩa ví dụ trên :
- Tên Domain : vnnetpro.com. phải ở vị trí cột đầu tiên và kết thúc bằng dấu chấm (.).
- IN là Internet
- server1.vnnetpro.com là tên FQDN của Primary Name Server của dữ liệu này.
- sangnt.vnnetpro.com là địa chỉ email của người phụ trách dữ liệu này. Lưu ý là địa chỉ email thay thế dấu @ bằng dấu chấm sau root.
- Dấu ( ) cho phép ta mở rộng ra viết thành nhiều dòng, tất cả các tham số trong dấu ( ) được dùng cho các Secondary Name Server.
Các thành phần bên trong cú pháp của record SOA :
+ Serial : áp dụng cho mọi dữ liệu trong zone và là 1 số nguyên. Trong ví dụ, giá trị này là 1 nhưng thông thường người ta sẽ sử dụng theo định dạng thời gian như 2007092001. Định dạng này theo kiểu yyyymmddnn, trong đó nn là số lần sửa đổi dữ liệu zone trong ngày. Bất kể theo định dạng nào thì luôn luôn phải tăng số này lên mỗi lần sửa đổi dữ liệu zone. Khi Secondary Name Server liên lạc với Primary Name Server thì trước tiên nó sẽ hỏi số serial này. Nếu số serial của máy Secondary nhỏ hơn số serial của máy Primary tức là dữ liệu trên Secondary đã cũ và sau đó máy Secondary sẽ sao chép dữ liệu mới từ máy Primary thay cho dữ liệu đang có.
+ Refresh : chỉ ra khoản thời gian máy Secondary kiểm tra dữ liệu zone trên máy Primary để cập nhật nếu cần. Trong ví dụ trên thì cứ mổi 3 giờ máy chủ Secondary sẽ liên lạc với máy chủ Primary để cập nhật nếu có. Giá trị này thay đổi theo tần suất thay đổi dữ liệu trong zone.
+ Retry : nếu máy Secondary không kết nối được với máy Primary theo thời hạn mô tả trong refresh (ví dụ trường hợp máy Primary shutdown máy vào lúc đó) thì máy Secondary sẽ tìm cách kết nối lại với máy Primary theo chu kỳ thời gian được xác định trong retry. Thông thường giá trị này nhỏ hơn giá trị refresh
+ Expire : nếu sau khoản thời gian này mà máy Secondary không cập nhật được thông tin mới trên máy Primay thì giá trị của zone này trên máy Secondary sẽ bị hết hạn. Nếu bị expire thì Secondary sẽ không trả lời bất cứ 1 truy vấn nào về zone này. Giá trị expire này phải lớn hơn giá trị refresh và giá trị retry.
+ TTL : giá trị này áp dụng cho mọi record trong zone và được đính kèm trong thông tin trả lời 1 truy vấn. Mục đích của nó là chỉ ra thời gian mà các máy DNS Server khác cache lại thông tin trả lời. Giúp giảm lưu lượng truy vấn DNS trên mạng.
7.2 NS (Name Server)
Record tiếp theo cần có trong zone là NS (Name Server) record. Mỗi Name Server cho zone sẽ có 1 NS record.
Cú pháp :
[domain-name] IN NS [DNS-Server-Name]
Ví dụ : Record NS sau :
vnnetpro.com. IN NS dnsserver1.vnnetpro.com.
vnnetpro.com. IN NS dnsserver2.vnnetpro.com.
chỉ ra rằng Domain vnnetpro.com có 2 Name Server là dnsserver1.vnnetpro.com và dnsserver2.vnnetpro.com
7.3 A (Address) và CNAME (Canonical Name)
Record A (Address) ánh xạ tên máy (hostname) vào địa chỉ IP. Record CNAME (Canonical Name) tạo tên bí danh alias trỏ vào 1 tên canonical. Tên canonical là tên host trong record A hoặc lại trỏ vào 1 tên canonical khác.
Cú pháp : [tên-máy-tính] IN A [địa-chỉ-IP]
Ví dụ : record A trong tập tin db.vnnetpro
server1.vnnetpro.com. IN A 172.29.14.1
dns.vnnetpro.com. IN A 172.29.14.4
//Multi-homed hosts
server.vnnetpro.com. IN A 172.29.14.1
server.vnnetpro.com. IN A 192.253.253.1
7.4 AAAA
Ánh xạ tên máy (hostname) vào địa chỉ IP version 6
Cú pháp : [tên-máy-tính] IN AAAA [địa-chỉ-IPv6]
Ví dụ : Server IN AAAA 1243:123:456:789
2:3:456ab
7.5 SRV
Cung cấp cơ chế định vị dịch vụ, Active Directory sử dụng resource record này để xác định Domain Controller, Global Catalog Servers, Lightweight Directory Access Protocol (LDAP) Server
Các thành phần trong SRV :
- Tên dịch vụ service
- Giao thức sử dụng
- Tên Domain (Domain Name)
- TTL và class
- Priority
- Weight (hỗ trợ Load Balancing)
- Port của dịch vụ
- target chỉ định FQDN cho host hỗ trợ dịch vụ.
Ví dụ : _ftp._tcp.somecompany.com. IN SRV 0 0 21 ftpsvr1.somecompany.com
_ftp._tcp.somecompany.com. IN SRV 10 0 21 ftpsvr1.somecompany.com
7.6 MX (Mail Exchange)
DNS dùng record MX trong việc chuyển mail lên mạng Internet. Ban đầu chức năng chuyển mail dựa trên 2 record : record MD (Mail Destination) và record MF (Mail Forwarder) records. MD chỉ ra đích cuối cùng của 1 thông điệp mail có tên domain cụ thể. MF chỉ ra máy chủ trung gian sẽ chuyển tiếp mail đến được máy chủ đích cuối cùng. Tuy nhiên việc tổ chức này hoạt động không tốt Do đó, chúng được tích hợp lại thành 1 record là MX. Khi nhận được mail, trình chyển mail (mailer) sẽ dựa vào record MX để định đường đi của mail. Record MX sẽ chỉ ra 1 Mail Exchanger cho 1 miền – Mail Exchanger là 1 Server (chuyển mail đến mailbox local hay làm gateway chuyển sang 1 giao thức chuyển mail khác như UUCP) hoặc chuyển tiếp mail đến 1 Mail Exchanger khác (Mail Server trung gian) gần với mình nhất để đến với Server chủ cuối cùng dùng giao thức SMTP.
Để tránh việc gửi mail bị lặp lại, record MX có thêm 1 giá trị bổ sung ngoài tên Domain của Mail Exchanger là 1 số thứ tự tham chiếu. Đây là 1 giá trị nguyên không dấu 16-bit (o-65535) chỉ ra thứ tự ưu tiên của các Mail Exchanger.
Cú pháp : [domain-name] IN MX [priority] [mail-host]
Ví dụ : vnnetpro.com. IN MX 10 mailserver.vnnetpro.com.
Chỉ ra máy chủ mailserver.vnnetpro.com là 1 Mail Exchanger cho Domain vnnetpro.com với độ ưu tiên là 10.
Chú ý : các giá trị này chỉ có ý nghĩa so sánh với nhau. Ví dụ khai báo 2 record MX :
vnnetpro.com. IN MX 1 listo.vnnetpro.com.
vnnetpro.com. IN MX 1 hep.vnnetpro.com.
Trình chuyển mail (mailer) sẽ thử phân phát thư đến Mail Exchager có độ ưu tiên nhỏ nhất trước. Nếu không chuyển mail được thì Mail Exchanger với độ ưu tiên kế sẽ được chọn. Trong trường hợp có nhiều Mail Exchanger có cùng độ ưu tiên thì Mailer sẽ chọn ngẫu nhiên giữa chúng.
Chú ý : chỉ tạo MX record khi chúng ta muốn nhận email từ bên ngoài Internet gửi vào Mail Exchanger của hệ thống. Khi có email đến thì nó sẽ hỏi xem DNS Server là Mail Server của hệ thống này có địa chỉ IP là gì? Lúc này DNS Server sẽ trả lời câu hỏi này bằng cách tìm thông tin trong MX record. Lúc đó DNS Server sẽ forward đến Mail Server. Các User trong local sẽ lên Mail Server lấy mail về bằng cơ chế POP3.
8. Khởi động và ngừng dịch vụ DNS
Để khởi động và ngừng dịch vụ DNS trên máy tính local, chúng ta sử dụng dòng lệnh net start/stop tên_dịch_vụ.
- Ngừng dịch vụ DNS
C:\> net stop dns
The DNS Server service is stopping.
The DNS Server service was stopped successfully.
- Khởi động dịch vụ DNS
C:\> net start dns
The DNS Server service is starting.
The DNS Server service was started successfully.
Để khởi động và ngừng dịch vụ trên các máy từ xa, chúng ta sử dụng dòng lệnh sc. Trên Windows NT thì tiện ích này nằm trong bộ Resource Kit, trên Windows Server 2003 thì tiện ích này có sẵn trên windows. Để thao tác trên các máy từ xa trong mạng nội bộ, chúng ta sử dụng các dòng lệnh sau :
- Ngừng dịch vụ DNS trên máy dnsserver trong local
C:\> sc \\dnsserver stop dns
SERVICE_NAME: dns
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x1
WAIT_HINT : 0x7530
- Khởi động dịch vụ DNS trên máy dnsserver trong local
C:\> sc \\dnsserver start dns
SERVICE_NAME: dns
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
Hãy để ý dòng thông báo START_PENDING đây là dòng thông báo đã khởi động thành công dịch vụ DNS. Ngoài ra để xóa cache DNS trên máy dnsserver, gõ dòng lệnh sau :
C:\> dnscmd matrix /clearcache
9. Cấu trúc của gói tin DNS
Cấu trúc một gói tin DNS
Trong các thành phần của cấu trúc gói tin DNS ở trên, khi đề cập đến vấn đề bảo mật, chúng ta chỉ quan tâm đến 4 vùng được đánh dấu màu xám.
1. Transaction ID : nó là một số ngẫu nhiên (random) dùng để so khớp với truy vấn phản hồi trở lại. Khi client nhận được một phản hồi (respone) từ server, nó sẽ kiểm tra xem số transaction ID này có trùng với số transaction ID mà nó đã gửi đi ban đầu hay không.
2. Answer Resource Record structures : đây là phần nội dung do DNS Server trả lời, được lấy trong resource record (RR) trên chính máy DNS Server đó.
3. Authority Resource Record structures : phần này chứa một trong 2 loại, hoặc là SOA hoặc là NS record chứa thông tin chứng nhận chủ nhân của RR(s) trong phần trả lời trên.
4. Additional Resource Record structures : phần này là thông tin resource record được thêm vào để gửi cho máy nhận (receiver)
Lưu ý : nếu có 2 phản hồi (responces), trình tự tiếp nhận của client sẽ diễn ra như sau : cái nào đến trước sẽ được chấp nhận trước, sau đó bỏ thông tin đã nhận trước đó khi nhận được cái sau. Đây thật sự là điểm yếu để tấn công đầu độc cache.
Tiêu chí để xác định xem những phản hồi (responces) có hợp lệ hay không đó là dựa trên các thông số ban đầu của các yêu cầu (requests) mà client đó đã gửi đi. Client chỉ chấp nhận những phản hồi với cùng một địa chỉ IP, số cổng (port number) và số transaction ID ban đầu do client đã gửi đi. Ví dụ theo bảng sau thì gói tin phản hồi sẽ được chấp nhận :
10. Các điểm yếu của DNS
Do một client bình thường tin tưởng các thông tin phân giải do DNS Server cung cấp. Do đó, nếu DNS Server bị tấn công vì mục đích nào đó nhằm thay đổi các thông tin phân giải trả về cho client. Điền này thật nguy hiểm cho client khi nhận được những thông tin phân giải đã bị “nhiễm bẩn”. Thật tế cho thấy các DNS Server thường bị tấn công theo các phương thức sau đây :
1. Thay đổi zone file
2. Zone file được giả mạo trong việc đồng bộ (synchronize) giữa các DNS server với nhau.
3. Giả mạo thông tin IP gửi đến cho client.
Với các phương thức trên thì có các kiểu tấn công sau:
* Tấn công đầu độc cache (cache poisoning attack)
Như đã đề cập trong phần lý thuyết bên trên, các DNS Server sau khi trả thông tin đã phân giải được vào cache (cache trên DNS Server), mục đích là để tối ưu cho việc phân giải lần sau. Lợi dụng cơ chế này, các attacker tiến hành đầu độc cache của DNS Server. Có vài cách để thực hiện việc này :
- Cách thứ nhất : thiết lập một DNS Server giả mạo với các record độc hại.
Đầu độc cache DNS Server bằng cách sử dụng một DNS Server giả mạo
Mục đích của kẻ tấn công là muốn dẫn các client khi phân giải một cái tên nào đó về địa chỉ IP giả mạo, ví dụ khi client cần phân giải địa chỉ www.cnn.com thì được trả về địa chỉ IP giả là 66.66.66.66. Kẻ tấn công có thể thực hiện được việc đó bằng cách theo các bước sau đây:
1. Thiết lập 1 DNS Server giả mạo, ví dụ tên của server này là ns.attacker.com
2. Sau đó kẻ tấn công tạo ra một truy vấn đến DNS Server của nạn nhân (server này tạm gọi là ns.victim.com), yêu cầu phân giải tên www.attacker.com
3. Khi đó DNS Server (lúc này chưa có record nào phục vụ cho việc phân giải tên www.attacker.com trong cache) của nạn nhân sẽ liên lạc với DNS Server giả mạo của attacker là ns.attacker.com để lấy thông tin trả lời cho việc phân giải tên www.attacker.com
4. Ns.attacker.com trả lời cho địa chỉ www.attacker.com = 44.44.44.44 đến ns.victim.com. Tuy nhiên, cũng trong thời điểm đó, trong gói tin reply trả về thì một record khác cũng được thêm vào chứa thông tin là www.cnn.com = 66.66.66.66 tại vùng Additional Resource Record structures (xem lại cấu trúc gói tin DNS đã trình bày bên trên).
5. Sau khi nhận được reply này từ máy ns.attacker.com, ns.victim.com sẽ trả lời cho attacker là www.attacker.com=44.44.44.44. Tuy nhiên, lúc này ns.victim.com đã cache lại thông tin về www.attacker.com=44.44.44.44 và www.cnn.com=66.66.66.66.
6. Thông tin record www.attacker.com sẽ được trả về cho kẻ tấn công, tuy nhiên đây không phải là mục tiêu chính của kẻ tấn công, mà mục tiêu chính là đặt thông tin sai vào bộ nhớ cache của DNS Server nạn nhân.
7. Khi nào record giả còn tồn tại trong cache của DNS Server nạn nhân, từ đây về sau, các truy vấn của www.cnn.com sẽ được chuyển hướng đến 66.66.66.66, đây có thể là một máy tính được đặc dưới sự kiểm soát của attacker, các thông tin đến www.cnn.com sẽ được attacker forward đến đối tượng thật sự www.cnn.com và ngược lại. Do đó client cuối cùng không biết có sự tồn tại của máy “man in the middle”.
- Cách thứ hai : gửi một spoofed reply đến client nạn nhân thông qua sự giúp đỡ của 1 sniffer
Thay vì thiết lập một DNS Server giả mạo, nếu attacker có thể đặt mình vào vị trí giữa client và DNS Server, attacker có thể ngăn chặn các request của client gửi đến DNS Server và sau đó gửi gói tin reply với thông tin sai đến client.
Đầu độc cache DNS bằng cách nghe lén (sniffer)
Xin nhắc lại là client chỉ chấp nhận các gói tin reply với cùng các thông số đã gửi đi ban đầu như Transaction ID, địa chỉ IP và số port. Để biết các thông số này, attacker có thể nghe lén để capture lại các gói tin trong mạng. Sau khi đã có các thông số đầy đủ, attacker có thể tạo gói tin reply DNS giả để gửi đến cho client. Nội dung gói tin chứa thông tin sai trái phục vụ cho mục đích đen tối của attacker.
Tuy nhiên hạn chế của phương pháp này là gói tin reply phải của attacker phải đến trước gói tin hợp lệ của DNS Server. Nếu gói tin hợp lệ của DNS Server đến trước thì cách tấn công này sẽ không thực hiện được. Đó là do client chỉ chấp nhận gói tin reply nào hợp lệ đến trước, và sẽ làm ngơ (ignore) các gói tin đến sau. Có nhiều cách để thực hiện ý đồ này của attacker, và để tăng khả năng thành công của phương pháp này, attacker có thể tiến hành tấn công từ chối dịch vụ (DOS) để làm chậm hoạt động của DNS Server. Do phải capture các gói tin để lấy các thông số của gói tin request DNS, việc capture các gói tin này khó có thể thực hiện trong môi trường mạng switch (switched netword). Do đó, kỹ thuật tấn công ARP snoofing phải được thực hiện trước.
- Cách thứ 3 : gửi một lượng lớn snoofing reply đến client nạn nhân.
Kỹ thuật tấn công dựa vào số ID DNS snoofing đòi hỏi kẻ tấn công phải biết chính xác số ID giao dịch giữa client và server. Điều này có thể được thực hiện bằng cách gửi một lượng rất lớn các gói tin reply chứa số Transaction ID khác nhau đến client, hy vọng một trong số các gói tin gửi đến client sẽ hợp lệ.
Trên thật tế, số ID này chỉ chiếm 2 byte bộ nhớ, cho nên nó chỉ có tất cả 65525 trường hợp. Vì vậy, bằng cách gửi 65525 gói tin reply (mỗi gói tin có số ID khác nhau), một trong số chúng chắc chắn sẽ phù hợp với số Transaction ID giao dịch giữa client và server, đồng thời có thể làm ngập lụt (fool) máy nạn nhân.
Kỹ thuật tấn công này được gọi là birthday attack bởi vì nó được dựa trên nguyên lý Birthday Paradox, theo nguyên lý này thì sẽ có hai hoặc hơn hai người có cùng một ngày sinh nhật trong số 23 người có cùng ngày sinh nhật là lớn hơn 0.5.
Với cách tấn công này, attacker không cần phải nghe lén số Transaction ID giao dịch giữa client và server. Nhưng vấn đề của nó là khi nào thì nên tiến hành thực hiện birthday attack? Đó là, làm thế nào để biết khi nào client thực hiện truy vấn DNS? Đây là việc gây khó khăn cho phương thức tấn công này.
- Cách thứ 4 : attacker gửi một lượng lớn snoofed reply đến DNS Server.
Trong cách thứ 3, attacker không thể biết khi nào client thực hiện một truy vấn. Tuy nhiên, thật tế, attacker có thể tự thực hiện truy vấn và sau đó gửi gói tin reply giả mạo đến DNS Server. Sau đó, DNS Server sẽ chứa thông tin bị đầu độc.
Đầu độc cache DNS bằng phương pháp birthday attack
Theo mô hình trên, mục đích của attacker là muốn chuyển việc phân giải tên www.cnn.com đến địa chỉ IP 66.66.66.66, các bước thực hiện được tiến hành như sau :
1. Attacker gửi một truy vấn đến DNS Server nạn nhân để truy vấn phân giải tên www.cnn.com.
2. Sau khi nhận được truy vấn này, server sẽ gửi một truy vấn đến ns.cnn.com để nhờ phân giải hộ địa chỉ www.cnn.com, và sau đó đợi phản hồi.
3. Trong khoản thời gian chờ này, attacker sẽ tự giả mạo gói tin reply này để gửi đến cho DNS Server. Trong gói tin này chứa đựng nội dung giả địa chỉ IP cho www.cnn.com là 66.66.66.66.
4. Lúc này, cache của DNS Server đã bị đầu độc. Kể từ thời điểm này, mọi truy vấn yêu cầu phân giải địa chỉ IP cho tên www.cnn.com đều được trả về địa chỉ là 66.66.66.66. Máy tính đó được đặt dưới sự điều khiển của attacker.
Trở ngại của phương pháp này đó là gói tin reply phải chứa cùng số Transaction ID và số port mà DNS Server victim đã sử dụng. Để giải quyết vấn đề này, đối với số Transaction ID thì attacker sử dụng phương pháp birthday attack. Trên DNS Server thì source port sử dụng hầu như không đổi đối với từng client. Lợi dụng điều này, đầu tiên attacker yêu cầu DNS Server victim phân giải một địa chỉ tên domain nào đó của attacker. Trên máy này, sau khi nhận được truy vấn attacker có thể biết được source port nào đang được sử dụng trên DNS Server victim. Dựa trên sự tính toán này, cùng với số source port đã biết, attacker thực hiện gửi 650 request và 650 reply giả mạo đến DNS Server victim. Xác suất thành công của phương pháp tấn công này đạt khoản 96% tỉ lệ thành công.
* Tấn công tràn bộ đệm (buffer overflow attack)
Là dạng tấn công vào vùng nhớ đệm của máy chủ DNS Server để thực thi các dòng lệnh trên máy chủ đó. Đây không phải là gói tin response chứa thông tin độc hại (như chứa tên quá dài, hoặc chiều dài gói tin quá lớn) nhưng có thể làm cho việc ghi đè lên vùng nhớ đệm của victim trở nên quá tải, cho phép thực thi việc leo thang chiếm quyền trên máy tính đó. Với quyền truy cập chiếm được, attacker có thể sửa đổi các thông tin trên file zone.
* Tấn công trong quá trình zone transfer (Zone transfer attack)
Mục đích của việc tấn công này là để đưa thông tin không đúng lên server dự phòng (slave server) thông qua tiến trình zone transfer bình thường giữa server chính và server dự phòng. Sau đây là cách để thực hiện zone transfer attack.
1. Đầu tiên, attacker thực hiện phương pháp tấn công man-in-the-middle để có thể chen ngang việc trao đổi thông tin giữa server chính và server dự phòng.
2. Khi server dự phòng yêu cầu server chính thực hiện quá trình zone transfer, attacker sẽ ngăn chặn yêu cầu này đến server, sau đó attacker sẽ trả về cho server dự phòng thông tin đã được giả mạo.
3. Lúc này, server dự phòng đã chứa thông tin đã bị giả mạo của attacker.
4. Sau đó, attacker thực hiện tấn công từ chối dịch vụ trên server chính.
5. Lúc này, server dự phòng sẽ đóng vai trò là server chính bắt đầu cung cấp dịch vụ DNS cho các client.
6. Sau đó, các client sẽ nhận thông tin đã bị đầu độc từ phía DNS Server.
Để ngăn chặn việc này, các DNS Server sử dụng access control list. Danh sách đó chỉ chứa địa chỉ IP của những máy server chính nào được phép zone transfer.
* Tấn công từ chối dịch vụ (Denial of Service Attack)
Là kiểu tấn công phổ biến với các request dồn dập để làm ngập lục server, làm cho server chậm chạm để có thể chấp nhận các request hợp lệ.
Tuy nhiên, trong DNS, việc thực hiện DoS có thể đạt được bằng cách sử dụng vài loại resource record trong file zone. Cụ thể, Name Server (NS) record thì được dùng để xác định chứng nhận name server cho một domain, ví dụ : “ibm.com IN NS ns.ibm.com”. Nếu attacker có thể đầu độc cache của một DNS Server với một NS record ví dụ như “ibm.com IN NS ns.attacker.com”, server sẽ tham chiếu đến ns.attacker.com để phục vụ bất kỳ yêu cầu truy vấn nào của client về địa chỉ của máy ibm.com. Lúc này nó sẽ từ chối tất cả các client có cùng tên dịch vụ được cung cấp bởi ibm.com.
Mặc khác, Canonical Name (CNAME) record, dùng để map tên bí danh với tên thật, cũng có thể được sử dụng. Cụ thể, một attacker có thể đầu độc cache của một DNS Server với một CNAME record như “www.vnnetpro.com IN CNAME www.vnnetpro.com”, với việc tham chiếu đến chính nó, khi một client yêu cầu truy vấn địa chỉ www.vnnetpro.com, truy vấn có thể bị lập vô tận.
* Tấn công phương thức cập nhật động (Dynamic update attack)
Trong vài trường hợp, sau khi chỉnh sửa các zone file trên DNS Server, server khởi động lại để những thay đổi có hiệu lực. Nhưng khi khối lượng cần thay đổi quá lớn, khi đó các hoạt động của server không hoạt động bình thường như trước.
Để thay đổi vùng dữ liệu một cách hiệu quả, tính năng dynamic update được sử dụng (xem RFC 2136 [3]), cho phép tự động thay đổi (chẳng hạn như việc thêm và xóa) các record của DNS Server trong khi dịch vụ vẫn hoạt động bình thường không bị gián đoạn. Với tính năng này, name server chấp nhận các nguồn thông tin cập nhật từ bên ngoài hoặc các ứng dụng cho các thông tin cá nhân được cập nhật một cách tự động.
Chức năng dynamic update này chủ yếu được sử dụng cho các máy chạy dịch vụ DHCP, sau khi gán IP mới cho một client, DHCP Server sẽ sử dụng giao thức cập nhật động (dynamic update protocol) để cập nhật tên máy với địa chỉ IP phù hợp.
Thật không may, tiến trình cập nhật động thì không được bảo mật. Attacker có thể dễ dàng thay đổi vùng zone data trên DNS Server bằng cách gửi các gói tin cập nhật động một cách liên tục (bằng giao thức UDP).
11. Bảo mật DNS Server
- Ngăn không cho thực hiện zone transfer trái phép bằng cách sử dụng Access control list, chỉ những máy tính nào có địa chỉ IP nằm trong danh sách này được thực hiện quá trình zone transfer với DNS Server chính.
- Disable tính năng recursi trên các server được ủy quyền (Delegated Name Servers) bằng cách check vào ô Disable recursion (đồng nghĩa với việc disable tính năng forwarder) trong thẻ Advanced. Theo mặc định thì name server hỗ trợ tính năng recursive, chúng ta tắt tính năng này đi vì bản thân các name server liên lạc với nhau theo kiểu nonrecursive.
12. DNS trong môi trường Active Directory
Do trong môi trường Active Directory được đặt tên ở dạng DNS nên hệ thống buộc phải có DNS Server để phân giải tên cho Active Directory. Vì vậy DNS Server cần phải được cấu hình trước khi xây dựng Active Directory. Một hệ thống sau khi có Active Directory mà DNS Server bị lỗi sẽ dẫn đến các máy con không truy cập được vào Domain Controller.
Lưu ý : trong một mô hình mạng local, có DNS không nhất thiết phải có Active Directory nhưng trong môi trường Active Directory bắt buộc phải có DNS.
Vấn đề ở đây là xây dựng DNS hoàn chỉnh rồi mới tiến hành lên Domain hay là trong quá trình lên Domain cho phép hệ thống tự tích hợp DNS luôn. Xin thưa là nên tiến hành xây dựng DNS hoàn chỉnh rồi mới tiến hành lên Domain sau. Tại sao lại phải thực hiện đúng trình tự như vậy? Theo sự hiểu biết của riêng sangnt thì về mặt performance thì không biết có sự khác biệt như thế nào (vì chưa có hệ thống thật tế đủ lớn để test) nhưng về mặt ổn định thì hệ thống được xây dựng DNS trước sẽ rất ổn định, nếu tích hợp DNS trong quá trình lên Domain thì hệ thống hoạt động được một thời gian là bị tê liệt (trong trường hợp này bản thân DNS sẽ tự chuyển thành root DNS trong hệ thống local, hoạt động được một thời gian ngắn là DNS bị lỗi nên các máy tính không logon vào Domain được, vì không phân giải được tên Domain).
Một vấn đề nữa sangnt muốn đề cập đến là sau khi xây dựng DNS hoàn chỉnh rồi tiến hành lên Domain thì các bạn nên tích hợp database DNS vào Active Directory ngay. Vì khi DNS được tích hợp với AD (DNS phải là Primary DNS Server), lúc này quá trình Zone Transfer sẽ được mã hóa bằng các tính năng bảo mật có sẵn của Active Directory. DNS không tích hợp thì quá trình Zone Transfer sẽ không được mã hóa.
13. Phân biệt DNS được xây dựng trước rồi mới lên Domain với DNS được tích hợp chung trong quá trình lên Domain
Bạn có bao giờ tự hỏi làm sao để phân biệt sự khác nhau giữa DNS được xây dựng trước với DNS được xây dựng chung trong quá trình dcpromo không? Sangnt xin chỉ ra sự khác nhau này thể hiện qua các chi tiết sau đây :
DNS được xây dựng trước (ký hiệu là A), DNS được tích hợp trong quá trình dcpromo (ký hiệu là B).
1. Trong quá trình thực hiện dcpromo :
A - Quá trình kiểm tra DNS thành công
B - Thông báo chưa cài dịch vụ DNS
A - Không có cài đặt DNS trong quá trình dcpromo
B - Quá trình dcpromo tự cài đặt và config DNS
2. Bên trong cấu trúc của DNS
A - Cấu trúc tổ chức DNS đơn giản
B - Cấu trúc tổ chức DNS phức tạp (lưu ý phần được khoanh tròn màu đỏ)
14. Phân biệt DNS Database tích hợp và không tích hợp với Active Directory (AD)
Sự khác nhau giữa DNS tích hợp và DNS không tích hợp với AD không chỉ thể hiện ở những nơi có thể nhận biết được bằng hình ảnh trực quan (đường dẫn chứa Database và cấu trúc Zone) mà còn khác nhau cả về cơ chế hoạt động.
1. Đường dẫn chứa Database
DNS không tích hợp Active Directory : %systemroot%\system32\dns
DNS tích hợp với Active Directory : %systemroot%\NTDS
Hình minh họa DNS không tích hợp với AD
2. Xem tab General trong Properties của Zone
DNS khi chưa tích hợp với AD
DNS sau khi tích hợp với AD
3. Quá trình Zone Transfer
Khi DNS được tích hợp với AD (DNS phải là Primary DNS Server), lúc này quá trình Zone Transfer sẽ được mã hóa bằng các tính năng bảo mật có sẵn của Active Directory. DNS không tích hợp thì quá trình Zone Transfer sẽ không được mã hóa.
15. Các bước thực hiện xây dựng DNS hoàn chỉnh trước khi thực hiện quá trình dcpromo:
1. Đổi DNS Suffix
Trước khi cấu hình dịch vụ DNS, chúng ta phải đổi DNS Suffix của DNS Server để tránh trường hợp gặp lỗi về Name Server.
1. Chọn Start --> Chuột phải lên My Computer --> chọn Properties (hoặc vào Start à Run gõ lệnh sysdm.cpl)
2. Chọn tab Computer Name --> Change --> more
3. Điền DNS Suffix dưới dạng DNS Name level 2, tên DNS Suffix trùng tên với tên của domain. Ví dụ tôi đặt tên DNS Suffix cùng tên với domain là vnnetpro.com
4. Nhấn OK hai lần và khởi động lại máy.
2. Tạo Forward Lookup Zone : Forward Lookup Zone dùng để phân giải tên máy (hostname) thành địa chỉ IP.
1. Chuột phải vào Forward Lookup Zones --> New Zone
2. Zone type : chọn Primary Zone --> Next
3. Zone name : điền vào tên domian là vnnetpro.com --> Next --> Next
4. Chọn Allow both nonsecure and secure dynamic updates
5. Nhấn Finish để hoàn tất.
3. Tạo Reverse Lookup Zone : Reverse Lookup Zone có cơ chế hoạt động ngược lại với Forward Lookup Zone tức là phân giải địa chỉ IP thành tên máy (hostname).
1. Chuột phải vào Reverse Lookup Zones --> New Zone
2. Zone type : chọn Primary Zone --> Next
3. Zone Name sử dụng Network ID 192.168.1 --> Next --> Next
4. Allow both nonsecure and secure dynamic updates
5. Nhấn Finish để hoàn tất.
6. Tạo pointer chỉ đến Host A là 192.168.1.2 (địa chỉ IP của DNS Server). Có bao nhiêu Host A thì tạo bấy nhiêu pointer chỉ đúng IP của Host đó.
b. Kiểm tra hoạt động của DNS Server : sau khi đã cấu hình tạo Forward Lookup Zone và Reverse Lookup Zone xong, tiến hành kiểm tra DNS Server bằng cách :
1. Vào Start --> Run gõ lệnh cmd.
2. Tại màn hình cmd, gõ lệnh nslookup
OK, như vậy là DNS Server đã được cấu hình hoàn chỉnh. Lúc này các bạn có thể tiến hành lên Domain bằng dòng lệnh dcpromo được rồi đấy.
16. Tạo Secondary Zone
Thông thường trong một Domain ta có thể tổ chức một Primary Name Server (PNS) và một Secondary Name Server (SNS), trong đó SNS đóng vai trò là một DNS dự phòng, nó lưu lại bản sao dữ liệu trên máy PNS. SNS không thể tự động cập nhật các thông tin trong Zone mà phải chờ bên PNS thay đổi sau đó sẽ replicate đồng bộ.
Sau khi đã cài đặt dịch vụ DNS tương tự như đã tiến hành trên máy PNS. Ta bắt đầu cài đặt Secondary Zone như sau :
Tạo Forward Secondary Zone
1. Chọn Start --> Run gõ lệnh dnsmgmt.msc
2. Chuột phải vào Forward Lookup Zone --> New Zone
3. Zone type : chọn Secondary Zone
4. Zone name : cùng tên với Zone name trên Primary DNS Server là vnnetpro.com
5. Master DNS Server : điền địa chỉ IP của Primary DNS Server chứa Primary Zone --> Add
6. Nhấn Finish để hoàn tất
Tạo Reverse Secondary Zone
1. Chuột phải vào Reverse Lookup Zone --> New Zone
2. Zone type : chọn Secondary Zone
3. Network ID : điền vào 192.168.1
4. Master DNS Server : điền vào 192.168.1.2 --> Next
5. Nhấn Finish để hoàn tất
Kiểm tra xem thông tin các Zone cấu hình đã được replicate với Primary Name Server hay chưa.
Đến đây trên máy Secondary DNS sẽ chưa có database DNS của Primary vì trên Primary DNS Server bạn phải cấu hình cho phép địa chỉ IP của Secondary DNS được phép Zone Transfer.
17. Cấu hình DNS Zone Transfer trên máy Primary Name Server
Zone Transfer cho phép máy Secondary được phép lấy DNS database trên máy Primary để cập nhật. Vì lý do bảo mật, mặc định Windows Server không cho phép thực hiện Zone Transfer.
Người thực hiện : Domain Admin, DNS Admin, Local Admin
1. Chuột phải vào ddcsecurity.com trong Forward Lookup Zone --> Properties. Chọn tab Zone Transfer
2. Chọn Only the following Servers. Tại IP Adress điền địa chỉ IP của máy Secondary DNS --> nhấn Add --> Nhấn OK
3. Thao tác tương tự cho Reverse Lookup Zone.
4. Kiểm tra Zone Transfer trên Secondary Name Server : lúc này thì Secondary Name Server đã được phép Zone Transfer đến Primary Name Server để lấy database DNS về lưu trữ thành một bản sao hoàn chỉnh. Các thay đổi về sau trên Primary Name Server sẽ được cập nhật cho Secondary Name Server.
18. Sao lưu và khôi phục Database DNS
Dữ liệu (Database) DNS Server chứa thông tin về các Zone. Dữ liệu có 2 nơi chứa : Systemroot Folder (trường hợp DNS không tích hợp với Active Directory) hoặc nằm chung trong dữ liệu của Active Directory (trường hợp DNS được tích hợp với Active Directory).
Người thực hiện : Domain Admin, DNS Admin, Local Admin, Backup Operator.
Backup DNS Database trong Systemroot
Do Database DNS không nằm chung với Active Directory nên Admin chỉ cần backup lại thư mục %systemroot%\system32\dns bằng các công cụ backup như Veritas Netbackup, Scheduled Tasks,… hoặc backup thủ công.
Sau khi backup DNS trong thư mục Systemroot, ta cần phải tiến hành thêm một bước nữa đó là backup Registry DNS.
1. Vào Start à Run gõ lệnh regedit à OK
2. Tìm đến khóa HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\DNS
3. Chuột phải vào folder DNS rồi chọn Export
4. Chỉ đường dẫn và đặt tên cho file registry này, lưu với tên là backup registry dns 1.reg
5. Tìm đến khóa HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server
6. Chuột phải vào folder DNS Server rồi chọ Export.
7. Chỉ đường dẫn và đặt tên cho file registry này, lưu với tên là backup registry dns 2.reg
Backup DNS Server trong Active Directory
1. Vào Start --> Run gõ lệnh ntbackup
2. Chọn Advanced Mode
3. Chọn tab Backup
4. Chọn System State trong mục My Computer --> Chọn đường dẫn lưu trữ file *.bfk
5. Nhấn Start Backup 2 lần
Restore Database DNS Server
Người thực hiện : Domain Admin, DNS Admin, Local Admin, Backup Operator.
Restore Database DNS Server chứa trong Systemroot Folder
1. Stop DNS Service
2. Copy Database DNS vào lại thư mục %systemroot%\system32\dns trên Server DNS
3. Chạy 2 file backup registry dns 1.reg và backup registry dns 2.reg để backup DNS registry
3. Start DNS Service
4. Refesh lại DNS để xem thông tin các Zone đã được phục hồi.
Restore Database DNS Server trong System Restore (trường hợp DNS tích hợp với AD)
1. Khởi động Server vào chế độ Directory Restore Mode
2. Double Click vào file *.bkf chứa System State của lần Backup trước
3. Tiếp tục chạy quá trình NTBackup phục hồi lại Database DNS Server
Lưu ý: quá trình này sẽ phục hồi toàn bộ Active Directory và override các dữ liệu trên Active Directory
19. Vài dòng lệnh hữu ích liên quan đến DNS trên Windows
Chắc hẳn mọi người ai cũng quen thuộc với dòng lệnh ipconfig trên Windows, tiện ích ipconfig được Microsoft tích hợp sẵn trong các hệ điều hình Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows 7 và Windows Server 2008. Sangnt xin phép cung cấp thêm một ít hiểu biết của mình về các option của dòng lệnh này trong loạt bài viết tìm hiểu về DNS.
ipconfig /displaydns : dùng để xem nội dung các resource record đã được cache lại trên máy tính của mình (hay còn gọi là resolver client). Mỗi resource record bao gồm các thông tin như tên của record (Record Name), kiểu record (Record Type), Thời gian tồn tại của record này trên máy (Time To Live), độ dài gói tin (Data Length), Section và Resource Record Data. Nếu trong cache đã có record chứa thông tin truy vấn nào đó rồi, thì máy tính đó sẽ sử dụng thông tin này để phân giải tên sang địa chỉ IP, không phải tốn thời gian để truy vấn lại thông tin này (thời gian tồn tại của record phụ thuộc vào thông số Time To Live). Nói tóm lại, đầu tiên client sẽ tìm thông tin trong cache của nó trước, nếu không có thì sẽ tiến hành gửi query đến DNS Server được chỉ định. Sau khi nhận được reply từ DNS Server, client sẽ cache lại thông tin này để phục vụ cho lần truy vấn sau.
Nội dung các record được cache lại trên máy client
ipconfig /flushdns : xóa toàn bộ nội dung các record trong cache của chính máy tính đó. Đôi khi chúng ta phải sử dụng dòng lệnh này để giải quyết sự cố trong trường hợp thông tin record được cập nhật trên DNS Server nhưng cache client của chúng ta vẫn còn lưu thông tin cũ.
ipconfig /registerdns : dùng để đăng ký cập nhật động đến DNS Server (sau khi đã được DHCP cung cấp IP và các thông số cần thiết khác như subnet mask, default gateway, ip dns,…), trên DNS Server lúc này sẽ tự động tạo các record như A Host và Pointer tương ứng với IP và tên máy của client).
Link: http://khongtenmien.com/forum/showthread.php?t=1978
6.1 Primary Name Server
Mỗi Domain phải có 1 Primary Name Server. Server này được register trên Internet để quản lý Domain. Mọi người trên Internet đều biết tên máy tính và IP của Server này. Người quản trị DNS sẽ tổ chức các cơ sở dữ liệu DNS trên Primary Name Server. Server này đảm nhận vai trò chính trong việc phân giải tất cả các máy tính trong Domain hay Zone
6.2 Secondary Name Server
Mỗi Domain có 1 Primary Name Server để quản lý cơ sở dữ liệu DNS. Nếu như Server này tạm ngưng hoạt động vì 1 lý do nào đó thì việc phân giải DNS bị gián đoạn. Để tránh trường hợp này ngườ ta đã thiết kế ra 1 máy chủ dự phòng gọi là Secondary Name Server (hay còn gọi là Slave). Khi Secondary Name Server được khởi động nó sẽ tìm Primary Name Server nào mà nó được phép lấy dữ liệu về máy. Nó sẽ copy lại toàn bộ CSDL DNS của Primary Name Server mà nó được phép transfer (quá trình này gọi là quá trình Zone Transfer). Theo 1 chu kỳ nào đó do người quản trị quy định thì Secondary Name Server sẽ sao chép và cập nhật CSDL từ Primary Name Server.
Các bước của một quá trình Zone transfer
Zone Transfer
Zone Transfer
6.3 Caching Name Server
Caching Name Server không có bất kỳ tập tin CSDL nào. Nó có chức năng phân giải tên máy trên những mạng ở xa thông qua những Name Server khác. Nó sẽ lưu lại những thông tin đã được phân giải trước đó và được sử dụng lại những thông tin này nhằm mục đích :
- Làm tăng tốc độ phân giải bằng cách sử dụng cache.
- Giảm bớt gánh nặng phân giải tên máy cho các Name Server.
- Giảm việc lưu thông trên những mạng lớn.
Quy trình truy vấn và cache lại trên máy tính
Bảng cache
| This image has been resized. Click this bar to view the full image. The original image is sized 581x385. |
Bảng cache
7. Resource Record (RR)
RR là mẫu thông tin dùng để mô tả các thông tin về cơ sở dữ liệu DNS, các mẫu thông tin này được lưu trong các file cơ sở dữ liệu của DNS (%systemroot%\system32\dns)
7.1 SOA (Start of Authority)
Trong mỗi tập tin CSDL phải có 1 và chỉ 1 record SOA. Bảng ghi SOA này chỉ ra rằng Primary Name Server là nơi cung cấp thông tin tin cậy từ dữ liệu có trong zone.
Cú pháp của 1 record SOA :
[tên-miền] IN SOA [tên-DNS-Server] [địa-chỉ-email] (
Serial number;
Refresh number;
Retry number;
Experi number;
Time-to-line number)
Ví dụ :
vnnetpro.com. IN SOA server1.vnnetpro.com. sangnt.vnnetpro.com. (
1 ; serial
10800 ; refresh after 3 hours
3600 ; retry after 1 hours
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
Giải thích ý nghĩa ví dụ trên :
- Tên Domain : vnnetpro.com. phải ở vị trí cột đầu tiên và kết thúc bằng dấu chấm (.).
- IN là Internet
- server1.vnnetpro.com là tên FQDN của Primary Name Server của dữ liệu này.
- sangnt.vnnetpro.com là địa chỉ email của người phụ trách dữ liệu này. Lưu ý là địa chỉ email thay thế dấu @ bằng dấu chấm sau root.
- Dấu ( ) cho phép ta mở rộng ra viết thành nhiều dòng, tất cả các tham số trong dấu ( ) được dùng cho các Secondary Name Server.
Các thành phần bên trong cú pháp của record SOA :
+ Serial : áp dụng cho mọi dữ liệu trong zone và là 1 số nguyên. Trong ví dụ, giá trị này là 1 nhưng thông thường người ta sẽ sử dụng theo định dạng thời gian như 2007092001. Định dạng này theo kiểu yyyymmddnn, trong đó nn là số lần sửa đổi dữ liệu zone trong ngày. Bất kể theo định dạng nào thì luôn luôn phải tăng số này lên mỗi lần sửa đổi dữ liệu zone. Khi Secondary Name Server liên lạc với Primary Name Server thì trước tiên nó sẽ hỏi số serial này. Nếu số serial của máy Secondary nhỏ hơn số serial của máy Primary tức là dữ liệu trên Secondary đã cũ và sau đó máy Secondary sẽ sao chép dữ liệu mới từ máy Primary thay cho dữ liệu đang có.
+ Refresh : chỉ ra khoản thời gian máy Secondary kiểm tra dữ liệu zone trên máy Primary để cập nhật nếu cần. Trong ví dụ trên thì cứ mổi 3 giờ máy chủ Secondary sẽ liên lạc với máy chủ Primary để cập nhật nếu có. Giá trị này thay đổi theo tần suất thay đổi dữ liệu trong zone.
+ Retry : nếu máy Secondary không kết nối được với máy Primary theo thời hạn mô tả trong refresh (ví dụ trường hợp máy Primary shutdown máy vào lúc đó) thì máy Secondary sẽ tìm cách kết nối lại với máy Primary theo chu kỳ thời gian được xác định trong retry. Thông thường giá trị này nhỏ hơn giá trị refresh
+ Expire : nếu sau khoản thời gian này mà máy Secondary không cập nhật được thông tin mới trên máy Primay thì giá trị của zone này trên máy Secondary sẽ bị hết hạn. Nếu bị expire thì Secondary sẽ không trả lời bất cứ 1 truy vấn nào về zone này. Giá trị expire này phải lớn hơn giá trị refresh và giá trị retry.
+ TTL : giá trị này áp dụng cho mọi record trong zone và được đính kèm trong thông tin trả lời 1 truy vấn. Mục đích của nó là chỉ ra thời gian mà các máy DNS Server khác cache lại thông tin trả lời. Giúp giảm lưu lượng truy vấn DNS trên mạng.
7.2 NS (Name Server)
Record tiếp theo cần có trong zone là NS (Name Server) record. Mỗi Name Server cho zone sẽ có 1 NS record.
Cú pháp :
[domain-name] IN NS [DNS-Server-Name]
Ví dụ : Record NS sau :
vnnetpro.com. IN NS dnsserver1.vnnetpro.com.
vnnetpro.com. IN NS dnsserver2.vnnetpro.com.
chỉ ra rằng Domain vnnetpro.com có 2 Name Server là dnsserver1.vnnetpro.com và dnsserver2.vnnetpro.com
7.3 A (Address) và CNAME (Canonical Name)
Record A (Address) ánh xạ tên máy (hostname) vào địa chỉ IP. Record CNAME (Canonical Name) tạo tên bí danh alias trỏ vào 1 tên canonical. Tên canonical là tên host trong record A hoặc lại trỏ vào 1 tên canonical khác.
Cú pháp : [tên-máy-tính] IN A [địa-chỉ-IP]
Ví dụ : record A trong tập tin db.vnnetpro
server1.vnnetpro.com. IN A 172.29.14.1
dns.vnnetpro.com. IN A 172.29.14.4
//Multi-homed hosts
server.vnnetpro.com. IN A 172.29.14.1
server.vnnetpro.com. IN A 192.253.253.1
7.4 AAAA
Ánh xạ tên máy (hostname) vào địa chỉ IP version 6
Cú pháp : [tên-máy-tính] IN AAAA [địa-chỉ-IPv6]
Ví dụ : Server IN AAAA 1243:123:456:789
2:3:456ab7.5 SRV
Cung cấp cơ chế định vị dịch vụ, Active Directory sử dụng resource record này để xác định Domain Controller, Global Catalog Servers, Lightweight Directory Access Protocol (LDAP) Server
Các thành phần trong SRV :
- Tên dịch vụ service
- Giao thức sử dụng
- Tên Domain (Domain Name)
- TTL và class
- Priority
- Weight (hỗ trợ Load Balancing)
- Port của dịch vụ
- target chỉ định FQDN cho host hỗ trợ dịch vụ.
Ví dụ : _ftp._tcp.somecompany.com. IN SRV 0 0 21 ftpsvr1.somecompany.com
_ftp._tcp.somecompany.com. IN SRV 10 0 21 ftpsvr1.somecompany.com
7.6 MX (Mail Exchange)
DNS dùng record MX trong việc chuyển mail lên mạng Internet. Ban đầu chức năng chuyển mail dựa trên 2 record : record MD (Mail Destination) và record MF (Mail Forwarder) records. MD chỉ ra đích cuối cùng của 1 thông điệp mail có tên domain cụ thể. MF chỉ ra máy chủ trung gian sẽ chuyển tiếp mail đến được máy chủ đích cuối cùng. Tuy nhiên việc tổ chức này hoạt động không tốt Do đó, chúng được tích hợp lại thành 1 record là MX. Khi nhận được mail, trình chyển mail (mailer) sẽ dựa vào record MX để định đường đi của mail. Record MX sẽ chỉ ra 1 Mail Exchanger cho 1 miền – Mail Exchanger là 1 Server (chuyển mail đến mailbox local hay làm gateway chuyển sang 1 giao thức chuyển mail khác như UUCP) hoặc chuyển tiếp mail đến 1 Mail Exchanger khác (Mail Server trung gian) gần với mình nhất để đến với Server chủ cuối cùng dùng giao thức SMTP.
Để tránh việc gửi mail bị lặp lại, record MX có thêm 1 giá trị bổ sung ngoài tên Domain của Mail Exchanger là 1 số thứ tự tham chiếu. Đây là 1 giá trị nguyên không dấu 16-bit (o-65535) chỉ ra thứ tự ưu tiên của các Mail Exchanger.
Cú pháp : [domain-name] IN MX [priority] [mail-host]
Ví dụ : vnnetpro.com. IN MX 10 mailserver.vnnetpro.com.
Chỉ ra máy chủ mailserver.vnnetpro.com là 1 Mail Exchanger cho Domain vnnetpro.com với độ ưu tiên là 10.
Chú ý : các giá trị này chỉ có ý nghĩa so sánh với nhau. Ví dụ khai báo 2 record MX :
vnnetpro.com. IN MX 1 listo.vnnetpro.com.
vnnetpro.com. IN MX 1 hep.vnnetpro.com.
Trình chuyển mail (mailer) sẽ thử phân phát thư đến Mail Exchager có độ ưu tiên nhỏ nhất trước. Nếu không chuyển mail được thì Mail Exchanger với độ ưu tiên kế sẽ được chọn. Trong trường hợp có nhiều Mail Exchanger có cùng độ ưu tiên thì Mailer sẽ chọn ngẫu nhiên giữa chúng.
Chú ý : chỉ tạo MX record khi chúng ta muốn nhận email từ bên ngoài Internet gửi vào Mail Exchanger của hệ thống. Khi có email đến thì nó sẽ hỏi xem DNS Server là Mail Server của hệ thống này có địa chỉ IP là gì? Lúc này DNS Server sẽ trả lời câu hỏi này bằng cách tìm thông tin trong MX record. Lúc đó DNS Server sẽ forward đến Mail Server. Các User trong local sẽ lên Mail Server lấy mail về bằng cơ chế POP3.
8. Khởi động và ngừng dịch vụ DNS
Để khởi động và ngừng dịch vụ DNS trên máy tính local, chúng ta sử dụng dòng lệnh net start/stop tên_dịch_vụ.
- Ngừng dịch vụ DNS
C:\> net stop dns
The DNS Server service is stopping.
The DNS Server service was stopped successfully.
- Khởi động dịch vụ DNS
C:\> net start dns
The DNS Server service is starting.
The DNS Server service was started successfully.
Để khởi động và ngừng dịch vụ trên các máy từ xa, chúng ta sử dụng dòng lệnh sc. Trên Windows NT thì tiện ích này nằm trong bộ Resource Kit, trên Windows Server 2003 thì tiện ích này có sẵn trên windows. Để thao tác trên các máy từ xa trong mạng nội bộ, chúng ta sử dụng các dòng lệnh sau :
- Ngừng dịch vụ DNS trên máy dnsserver trong local
C:\> sc \\dnsserver stop dns
SERVICE_NAME: dns
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x1
WAIT_HINT : 0x7530
- Khởi động dịch vụ DNS trên máy dnsserver trong local
C:\> sc \\dnsserver start dns
SERVICE_NAME: dns
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
Hãy để ý dòng thông báo START_PENDING đây là dòng thông báo đã khởi động thành công dịch vụ DNS. Ngoài ra để xóa cache DNS trên máy dnsserver, gõ dòng lệnh sau :
C:\> dnscmd matrix /clearcache
9. Cấu trúc của gói tin DNS
Trong các thành phần của cấu trúc gói tin DNS ở trên, khi đề cập đến vấn đề bảo mật, chúng ta chỉ quan tâm đến 4 vùng được đánh dấu màu xám.
1. Transaction ID : nó là một số ngẫu nhiên (random) dùng để so khớp với truy vấn phản hồi trở lại. Khi client nhận được một phản hồi (respone) từ server, nó sẽ kiểm tra xem số transaction ID này có trùng với số transaction ID mà nó đã gửi đi ban đầu hay không.
2. Answer Resource Record structures : đây là phần nội dung do DNS Server trả lời, được lấy trong resource record (RR) trên chính máy DNS Server đó.
3. Authority Resource Record structures : phần này chứa một trong 2 loại, hoặc là SOA hoặc là NS record chứa thông tin chứng nhận chủ nhân của RR(s) trong phần trả lời trên.
4. Additional Resource Record structures : phần này là thông tin resource record được thêm vào để gửi cho máy nhận (receiver)
Lưu ý : nếu có 2 phản hồi (responces), trình tự tiếp nhận của client sẽ diễn ra như sau : cái nào đến trước sẽ được chấp nhận trước, sau đó bỏ thông tin đã nhận trước đó khi nhận được cái sau. Đây thật sự là điểm yếu để tấn công đầu độc cache.
Tiêu chí để xác định xem những phản hồi (responces) có hợp lệ hay không đó là dựa trên các thông số ban đầu của các yêu cầu (requests) mà client đó đã gửi đi. Client chỉ chấp nhận những phản hồi với cùng một địa chỉ IP, số cổng (port number) và số transaction ID ban đầu do client đã gửi đi. Ví dụ theo bảng sau thì gói tin phản hồi sẽ được chấp nhận :
10. Các điểm yếu của DNS
Do một client bình thường tin tưởng các thông tin phân giải do DNS Server cung cấp. Do đó, nếu DNS Server bị tấn công vì mục đích nào đó nhằm thay đổi các thông tin phân giải trả về cho client. Điền này thật nguy hiểm cho client khi nhận được những thông tin phân giải đã bị “nhiễm bẩn”. Thật tế cho thấy các DNS Server thường bị tấn công theo các phương thức sau đây :
1. Thay đổi zone file
2. Zone file được giả mạo trong việc đồng bộ (synchronize) giữa các DNS server với nhau.
3. Giả mạo thông tin IP gửi đến cho client.
Với các phương thức trên thì có các kiểu tấn công sau:
* Tấn công đầu độc cache (cache poisoning attack)
Như đã đề cập trong phần lý thuyết bên trên, các DNS Server sau khi trả thông tin đã phân giải được vào cache (cache trên DNS Server), mục đích là để tối ưu cho việc phân giải lần sau. Lợi dụng cơ chế này, các attacker tiến hành đầu độc cache của DNS Server. Có vài cách để thực hiện việc này :
- Cách thứ nhất : thiết lập một DNS Server giả mạo với các record độc hại.
| Click this bar to view the full image. |
Đầu độc cache DNS Server bằng cách sử dụng một DNS Server giả mạo
Mục đích của kẻ tấn công là muốn dẫn các client khi phân giải một cái tên nào đó về địa chỉ IP giả mạo, ví dụ khi client cần phân giải địa chỉ www.cnn.com thì được trả về địa chỉ IP giả là 66.66.66.66. Kẻ tấn công có thể thực hiện được việc đó bằng cách theo các bước sau đây:
1. Thiết lập 1 DNS Server giả mạo, ví dụ tên của server này là ns.attacker.com
2. Sau đó kẻ tấn công tạo ra một truy vấn đến DNS Server của nạn nhân (server này tạm gọi là ns.victim.com), yêu cầu phân giải tên www.attacker.com
3. Khi đó DNS Server (lúc này chưa có record nào phục vụ cho việc phân giải tên www.attacker.com trong cache) của nạn nhân sẽ liên lạc với DNS Server giả mạo của attacker là ns.attacker.com để lấy thông tin trả lời cho việc phân giải tên www.attacker.com
4. Ns.attacker.com trả lời cho địa chỉ www.attacker.com = 44.44.44.44 đến ns.victim.com. Tuy nhiên, cũng trong thời điểm đó, trong gói tin reply trả về thì một record khác cũng được thêm vào chứa thông tin là www.cnn.com = 66.66.66.66 tại vùng Additional Resource Record structures (xem lại cấu trúc gói tin DNS đã trình bày bên trên).
5. Sau khi nhận được reply này từ máy ns.attacker.com, ns.victim.com sẽ trả lời cho attacker là www.attacker.com=44.44.44.44. Tuy nhiên, lúc này ns.victim.com đã cache lại thông tin về www.attacker.com=44.44.44.44 và www.cnn.com=66.66.66.66.
6. Thông tin record www.attacker.com sẽ được trả về cho kẻ tấn công, tuy nhiên đây không phải là mục tiêu chính của kẻ tấn công, mà mục tiêu chính là đặt thông tin sai vào bộ nhớ cache của DNS Server nạn nhân.
7. Khi nào record giả còn tồn tại trong cache của DNS Server nạn nhân, từ đây về sau, các truy vấn của www.cnn.com sẽ được chuyển hướng đến 66.66.66.66, đây có thể là một máy tính được đặc dưới sự kiểm soát của attacker, các thông tin đến www.cnn.com sẽ được attacker forward đến đối tượng thật sự www.cnn.com và ngược lại. Do đó client cuối cùng không biết có sự tồn tại của máy “man in the middle”.
- Cách thứ hai : gửi một spoofed reply đến client nạn nhân thông qua sự giúp đỡ của 1 sniffer
Thay vì thiết lập một DNS Server giả mạo, nếu attacker có thể đặt mình vào vị trí giữa client và DNS Server, attacker có thể ngăn chặn các request của client gửi đến DNS Server và sau đó gửi gói tin reply với thông tin sai đến client.
Đầu độc cache DNS bằng cách nghe lén (sniffer)
Xin nhắc lại là client chỉ chấp nhận các gói tin reply với cùng các thông số đã gửi đi ban đầu như Transaction ID, địa chỉ IP và số port. Để biết các thông số này, attacker có thể nghe lén để capture lại các gói tin trong mạng. Sau khi đã có các thông số đầy đủ, attacker có thể tạo gói tin reply DNS giả để gửi đến cho client. Nội dung gói tin chứa thông tin sai trái phục vụ cho mục đích đen tối của attacker.
Tuy nhiên hạn chế của phương pháp này là gói tin reply phải của attacker phải đến trước gói tin hợp lệ của DNS Server. Nếu gói tin hợp lệ của DNS Server đến trước thì cách tấn công này sẽ không thực hiện được. Đó là do client chỉ chấp nhận gói tin reply nào hợp lệ đến trước, và sẽ làm ngơ (ignore) các gói tin đến sau. Có nhiều cách để thực hiện ý đồ này của attacker, và để tăng khả năng thành công của phương pháp này, attacker có thể tiến hành tấn công từ chối dịch vụ (DOS) để làm chậm hoạt động của DNS Server. Do phải capture các gói tin để lấy các thông số của gói tin request DNS, việc capture các gói tin này khó có thể thực hiện trong môi trường mạng switch (switched netword). Do đó, kỹ thuật tấn công ARP snoofing phải được thực hiện trước.
- Cách thứ 3 : gửi một lượng lớn snoofing reply đến client nạn nhân.
Kỹ thuật tấn công dựa vào số ID DNS snoofing đòi hỏi kẻ tấn công phải biết chính xác số ID giao dịch giữa client và server. Điều này có thể được thực hiện bằng cách gửi một lượng rất lớn các gói tin reply chứa số Transaction ID khác nhau đến client, hy vọng một trong số các gói tin gửi đến client sẽ hợp lệ.
Trên thật tế, số ID này chỉ chiếm 2 byte bộ nhớ, cho nên nó chỉ có tất cả 65525 trường hợp. Vì vậy, bằng cách gửi 65525 gói tin reply (mỗi gói tin có số ID khác nhau), một trong số chúng chắc chắn sẽ phù hợp với số Transaction ID giao dịch giữa client và server, đồng thời có thể làm ngập lụt (fool) máy nạn nhân.
Kỹ thuật tấn công này được gọi là birthday attack bởi vì nó được dựa trên nguyên lý Birthday Paradox, theo nguyên lý này thì sẽ có hai hoặc hơn hai người có cùng một ngày sinh nhật trong số 23 người có cùng ngày sinh nhật là lớn hơn 0.5.
Với cách tấn công này, attacker không cần phải nghe lén số Transaction ID giao dịch giữa client và server. Nhưng vấn đề của nó là khi nào thì nên tiến hành thực hiện birthday attack? Đó là, làm thế nào để biết khi nào client thực hiện truy vấn DNS? Đây là việc gây khó khăn cho phương thức tấn công này.
- Cách thứ 4 : attacker gửi một lượng lớn snoofed reply đến DNS Server.
Trong cách thứ 3, attacker không thể biết khi nào client thực hiện một truy vấn. Tuy nhiên, thật tế, attacker có thể tự thực hiện truy vấn và sau đó gửi gói tin reply giả mạo đến DNS Server. Sau đó, DNS Server sẽ chứa thông tin bị đầu độc.
Đầu độc cache DNS bằng phương pháp birthday attack
Theo mô hình trên, mục đích của attacker là muốn chuyển việc phân giải tên www.cnn.com đến địa chỉ IP 66.66.66.66, các bước thực hiện được tiến hành như sau :
1. Attacker gửi một truy vấn đến DNS Server nạn nhân để truy vấn phân giải tên www.cnn.com.
2. Sau khi nhận được truy vấn này, server sẽ gửi một truy vấn đến ns.cnn.com để nhờ phân giải hộ địa chỉ www.cnn.com, và sau đó đợi phản hồi.
3. Trong khoản thời gian chờ này, attacker sẽ tự giả mạo gói tin reply này để gửi đến cho DNS Server. Trong gói tin này chứa đựng nội dung giả địa chỉ IP cho www.cnn.com là 66.66.66.66.
4. Lúc này, cache của DNS Server đã bị đầu độc. Kể từ thời điểm này, mọi truy vấn yêu cầu phân giải địa chỉ IP cho tên www.cnn.com đều được trả về địa chỉ là 66.66.66.66. Máy tính đó được đặt dưới sự điều khiển của attacker.
Trở ngại của phương pháp này đó là gói tin reply phải chứa cùng số Transaction ID và số port mà DNS Server victim đã sử dụng. Để giải quyết vấn đề này, đối với số Transaction ID thì attacker sử dụng phương pháp birthday attack. Trên DNS Server thì source port sử dụng hầu như không đổi đối với từng client. Lợi dụng điều này, đầu tiên attacker yêu cầu DNS Server victim phân giải một địa chỉ tên domain nào đó của attacker. Trên máy này, sau khi nhận được truy vấn attacker có thể biết được source port nào đang được sử dụng trên DNS Server victim. Dựa trên sự tính toán này, cùng với số source port đã biết, attacker thực hiện gửi 650 request và 650 reply giả mạo đến DNS Server victim. Xác suất thành công của phương pháp tấn công này đạt khoản 96% tỉ lệ thành công.
* Tấn công tràn bộ đệm (buffer overflow attack)
Là dạng tấn công vào vùng nhớ đệm của máy chủ DNS Server để thực thi các dòng lệnh trên máy chủ đó. Đây không phải là gói tin response chứa thông tin độc hại (như chứa tên quá dài, hoặc chiều dài gói tin quá lớn) nhưng có thể làm cho việc ghi đè lên vùng nhớ đệm của victim trở nên quá tải, cho phép thực thi việc leo thang chiếm quyền trên máy tính đó. Với quyền truy cập chiếm được, attacker có thể sửa đổi các thông tin trên file zone.
* Tấn công trong quá trình zone transfer (Zone transfer attack)
Mục đích của việc tấn công này là để đưa thông tin không đúng lên server dự phòng (slave server) thông qua tiến trình zone transfer bình thường giữa server chính và server dự phòng. Sau đây là cách để thực hiện zone transfer attack.
1. Đầu tiên, attacker thực hiện phương pháp tấn công man-in-the-middle để có thể chen ngang việc trao đổi thông tin giữa server chính và server dự phòng.
2. Khi server dự phòng yêu cầu server chính thực hiện quá trình zone transfer, attacker sẽ ngăn chặn yêu cầu này đến server, sau đó attacker sẽ trả về cho server dự phòng thông tin đã được giả mạo.
3. Lúc này, server dự phòng đã chứa thông tin đã bị giả mạo của attacker.
4. Sau đó, attacker thực hiện tấn công từ chối dịch vụ trên server chính.
5. Lúc này, server dự phòng sẽ đóng vai trò là server chính bắt đầu cung cấp dịch vụ DNS cho các client.
6. Sau đó, các client sẽ nhận thông tin đã bị đầu độc từ phía DNS Server.
Để ngăn chặn việc này, các DNS Server sử dụng access control list. Danh sách đó chỉ chứa địa chỉ IP của những máy server chính nào được phép zone transfer.
* Tấn công từ chối dịch vụ (Denial of Service Attack)
Là kiểu tấn công phổ biến với các request dồn dập để làm ngập lục server, làm cho server chậm chạm để có thể chấp nhận các request hợp lệ.
Tuy nhiên, trong DNS, việc thực hiện DoS có thể đạt được bằng cách sử dụng vài loại resource record trong file zone. Cụ thể, Name Server (NS) record thì được dùng để xác định chứng nhận name server cho một domain, ví dụ : “ibm.com IN NS ns.ibm.com”. Nếu attacker có thể đầu độc cache của một DNS Server với một NS record ví dụ như “ibm.com IN NS ns.attacker.com”, server sẽ tham chiếu đến ns.attacker.com để phục vụ bất kỳ yêu cầu truy vấn nào của client về địa chỉ của máy ibm.com. Lúc này nó sẽ từ chối tất cả các client có cùng tên dịch vụ được cung cấp bởi ibm.com.
Mặc khác, Canonical Name (CNAME) record, dùng để map tên bí danh với tên thật, cũng có thể được sử dụng. Cụ thể, một attacker có thể đầu độc cache của một DNS Server với một CNAME record như “www.vnnetpro.com IN CNAME www.vnnetpro.com”, với việc tham chiếu đến chính nó, khi một client yêu cầu truy vấn địa chỉ www.vnnetpro.com, truy vấn có thể bị lập vô tận.
* Tấn công phương thức cập nhật động (Dynamic update attack)
Trong vài trường hợp, sau khi chỉnh sửa các zone file trên DNS Server, server khởi động lại để những thay đổi có hiệu lực. Nhưng khi khối lượng cần thay đổi quá lớn, khi đó các hoạt động của server không hoạt động bình thường như trước.
Để thay đổi vùng dữ liệu một cách hiệu quả, tính năng dynamic update được sử dụng (xem RFC 2136 [3]), cho phép tự động thay đổi (chẳng hạn như việc thêm và xóa) các record của DNS Server trong khi dịch vụ vẫn hoạt động bình thường không bị gián đoạn. Với tính năng này, name server chấp nhận các nguồn thông tin cập nhật từ bên ngoài hoặc các ứng dụng cho các thông tin cá nhân được cập nhật một cách tự động.
Chức năng dynamic update này chủ yếu được sử dụng cho các máy chạy dịch vụ DHCP, sau khi gán IP mới cho một client, DHCP Server sẽ sử dụng giao thức cập nhật động (dynamic update protocol) để cập nhật tên máy với địa chỉ IP phù hợp.
Thật không may, tiến trình cập nhật động thì không được bảo mật. Attacker có thể dễ dàng thay đổi vùng zone data trên DNS Server bằng cách gửi các gói tin cập nhật động một cách liên tục (bằng giao thức UDP).
11. Bảo mật DNS Server
- Ngăn không cho thực hiện zone transfer trái phép bằng cách sử dụng Access control list, chỉ những máy tính nào có địa chỉ IP nằm trong danh sách này được thực hiện quá trình zone transfer với DNS Server chính.
- Disable tính năng recursi trên các server được ủy quyền (Delegated Name Servers) bằng cách check vào ô Disable recursion (đồng nghĩa với việc disable tính năng forwarder) trong thẻ Advanced. Theo mặc định thì name server hỗ trợ tính năng recursive, chúng ta tắt tính năng này đi vì bản thân các name server liên lạc với nhau theo kiểu nonrecursive.
12. DNS trong môi trường Active Directory
Do trong môi trường Active Directory được đặt tên ở dạng DNS nên hệ thống buộc phải có DNS Server để phân giải tên cho Active Directory. Vì vậy DNS Server cần phải được cấu hình trước khi xây dựng Active Directory. Một hệ thống sau khi có Active Directory mà DNS Server bị lỗi sẽ dẫn đến các máy con không truy cập được vào Domain Controller.
Lưu ý : trong một mô hình mạng local, có DNS không nhất thiết phải có Active Directory nhưng trong môi trường Active Directory bắt buộc phải có DNS.
Vấn đề ở đây là xây dựng DNS hoàn chỉnh rồi mới tiến hành lên Domain hay là trong quá trình lên Domain cho phép hệ thống tự tích hợp DNS luôn. Xin thưa là nên tiến hành xây dựng DNS hoàn chỉnh rồi mới tiến hành lên Domain sau. Tại sao lại phải thực hiện đúng trình tự như vậy? Theo sự hiểu biết của riêng sangnt thì về mặt performance thì không biết có sự khác biệt như thế nào (vì chưa có hệ thống thật tế đủ lớn để test) nhưng về mặt ổn định thì hệ thống được xây dựng DNS trước sẽ rất ổn định, nếu tích hợp DNS trong quá trình lên Domain thì hệ thống hoạt động được một thời gian là bị tê liệt (trong trường hợp này bản thân DNS sẽ tự chuyển thành root DNS trong hệ thống local, hoạt động được một thời gian ngắn là DNS bị lỗi nên các máy tính không logon vào Domain được, vì không phân giải được tên Domain).
Một vấn đề nữa sangnt muốn đề cập đến là sau khi xây dựng DNS hoàn chỉnh rồi tiến hành lên Domain thì các bạn nên tích hợp database DNS vào Active Directory ngay. Vì khi DNS được tích hợp với AD (DNS phải là Primary DNS Server), lúc này quá trình Zone Transfer sẽ được mã hóa bằng các tính năng bảo mật có sẵn của Active Directory. DNS không tích hợp thì quá trình Zone Transfer sẽ không được mã hóa.
13. Phân biệt DNS được xây dựng trước rồi mới lên Domain với DNS được tích hợp chung trong quá trình lên Domain
Bạn có bao giờ tự hỏi làm sao để phân biệt sự khác nhau giữa DNS được xây dựng trước với DNS được xây dựng chung trong quá trình dcpromo không? Sangnt xin chỉ ra sự khác nhau này thể hiện qua các chi tiết sau đây :
DNS được xây dựng trước (ký hiệu là A), DNS được tích hợp trong quá trình dcpromo (ký hiệu là B).
1. Trong quá trình thực hiện dcpromo :
A - Quá trình kiểm tra DNS thành công
| Click this bar to view the full image. |
B - Thông báo chưa cài dịch vụ DNS
A - Không có cài đặt DNS trong quá trình dcpromo
B - Quá trình dcpromo tự cài đặt và config DNS
2. Bên trong cấu trúc của DNS
| This image has been resized. Click this bar to view the full image. The original image is sized 522x340. |
A - Cấu trúc tổ chức DNS đơn giản
| Click this bar to view the full image. |
B - Cấu trúc tổ chức DNS phức tạp (lưu ý phần được khoanh tròn màu đỏ)
14. Phân biệt DNS Database tích hợp và không tích hợp với Active Directory (AD)
Sự khác nhau giữa DNS tích hợp và DNS không tích hợp với AD không chỉ thể hiện ở những nơi có thể nhận biết được bằng hình ảnh trực quan (đường dẫn chứa Database và cấu trúc Zone) mà còn khác nhau cả về cơ chế hoạt động.
1. Đường dẫn chứa Database
DNS không tích hợp Active Directory : %systemroot%\system32\dns
DNS tích hợp với Active Directory : %systemroot%\NTDS
Hình minh họa DNS không tích hợp với AD
2. Xem tab General trong Properties của Zone
DNS khi chưa tích hợp với AD
DNS sau khi tích hợp với AD
3. Quá trình Zone Transfer
Khi DNS được tích hợp với AD (DNS phải là Primary DNS Server), lúc này quá trình Zone Transfer sẽ được mã hóa bằng các tính năng bảo mật có sẵn của Active Directory. DNS không tích hợp thì quá trình Zone Transfer sẽ không được mã hóa.
15. Các bước thực hiện xây dựng DNS hoàn chỉnh trước khi thực hiện quá trình dcpromo:
1. Đổi DNS Suffix
Trước khi cấu hình dịch vụ DNS, chúng ta phải đổi DNS Suffix của DNS Server để tránh trường hợp gặp lỗi về Name Server.
1. Chọn Start --> Chuột phải lên My Computer --> chọn Properties (hoặc vào Start à Run gõ lệnh sysdm.cpl)
2. Chọn tab Computer Name --> Change --> more
3. Điền DNS Suffix dưới dạng DNS Name level 2, tên DNS Suffix trùng tên với tên của domain. Ví dụ tôi đặt tên DNS Suffix cùng tên với domain là vnnetpro.com
4. Nhấn OK hai lần và khởi động lại máy.
2. Tạo Forward Lookup Zone : Forward Lookup Zone dùng để phân giải tên máy (hostname) thành địa chỉ IP.
1. Chuột phải vào Forward Lookup Zones --> New Zone
2. Zone type : chọn Primary Zone --> Next
3. Zone name : điền vào tên domian là vnnetpro.com --> Next --> Next
4. Chọn Allow both nonsecure and secure dynamic updates
5. Nhấn Finish để hoàn tất.
3. Tạo Reverse Lookup Zone : Reverse Lookup Zone có cơ chế hoạt động ngược lại với Forward Lookup Zone tức là phân giải địa chỉ IP thành tên máy (hostname).
1. Chuột phải vào Reverse Lookup Zones --> New Zone
2. Zone type : chọn Primary Zone --> Next
3. Zone Name sử dụng Network ID 192.168.1 --> Next --> Next
4. Allow both nonsecure and secure dynamic updates
5. Nhấn Finish để hoàn tất.
6. Tạo pointer chỉ đến Host A là 192.168.1.2 (địa chỉ IP của DNS Server). Có bao nhiêu Host A thì tạo bấy nhiêu pointer chỉ đúng IP của Host đó.
b. Kiểm tra hoạt động của DNS Server : sau khi đã cấu hình tạo Forward Lookup Zone và Reverse Lookup Zone xong, tiến hành kiểm tra DNS Server bằng cách :
1. Vào Start --> Run gõ lệnh cmd.
2. Tại màn hình cmd, gõ lệnh nslookup
OK, như vậy là DNS Server đã được cấu hình hoàn chỉnh. Lúc này các bạn có thể tiến hành lên Domain bằng dòng lệnh dcpromo được rồi đấy.
16. Tạo Secondary Zone
Thông thường trong một Domain ta có thể tổ chức một Primary Name Server (PNS) và một Secondary Name Server (SNS), trong đó SNS đóng vai trò là một DNS dự phòng, nó lưu lại bản sao dữ liệu trên máy PNS. SNS không thể tự động cập nhật các thông tin trong Zone mà phải chờ bên PNS thay đổi sau đó sẽ replicate đồng bộ.
Sau khi đã cài đặt dịch vụ DNS tương tự như đã tiến hành trên máy PNS. Ta bắt đầu cài đặt Secondary Zone như sau :
Tạo Forward Secondary Zone
1. Chọn Start --> Run gõ lệnh dnsmgmt.msc
2. Chuột phải vào Forward Lookup Zone --> New Zone
3. Zone type : chọn Secondary Zone
4. Zone name : cùng tên với Zone name trên Primary DNS Server là vnnetpro.com
5. Master DNS Server : điền địa chỉ IP của Primary DNS Server chứa Primary Zone --> Add
| Click this bar to view the full image. |
6. Nhấn Finish để hoàn tất
Tạo Reverse Secondary Zone
1. Chuột phải vào Reverse Lookup Zone --> New Zone
2. Zone type : chọn Secondary Zone
3. Network ID : điền vào 192.168.1
| Click this bar to view the full image. |
4. Master DNS Server : điền vào 192.168.1.2 --> Next
| Click this bar to view the full image. |
5. Nhấn Finish để hoàn tất
Kiểm tra xem thông tin các Zone cấu hình đã được replicate với Primary Name Server hay chưa.
Đến đây trên máy Secondary DNS sẽ chưa có database DNS của Primary vì trên Primary DNS Server bạn phải cấu hình cho phép địa chỉ IP của Secondary DNS được phép Zone Transfer.
17. Cấu hình DNS Zone Transfer trên máy Primary Name Server
Zone Transfer cho phép máy Secondary được phép lấy DNS database trên máy Primary để cập nhật. Vì lý do bảo mật, mặc định Windows Server không cho phép thực hiện Zone Transfer.
Người thực hiện : Domain Admin, DNS Admin, Local Admin
1. Chuột phải vào ddcsecurity.com trong Forward Lookup Zone --> Properties. Chọn tab Zone Transfer
2. Chọn Only the following Servers. Tại IP Adress điền địa chỉ IP của máy Secondary DNS --> nhấn Add --> Nhấn OK
3. Thao tác tương tự cho Reverse Lookup Zone.
4. Kiểm tra Zone Transfer trên Secondary Name Server : lúc này thì Secondary Name Server đã được phép Zone Transfer đến Primary Name Server để lấy database DNS về lưu trữ thành một bản sao hoàn chỉnh. Các thay đổi về sau trên Primary Name Server sẽ được cập nhật cho Secondary Name Server.
18. Sao lưu và khôi phục Database DNS
Dữ liệu (Database) DNS Server chứa thông tin về các Zone. Dữ liệu có 2 nơi chứa : Systemroot Folder (trường hợp DNS không tích hợp với Active Directory) hoặc nằm chung trong dữ liệu của Active Directory (trường hợp DNS được tích hợp với Active Directory).
Người thực hiện : Domain Admin, DNS Admin, Local Admin, Backup Operator.
Backup DNS Database trong Systemroot
Do Database DNS không nằm chung với Active Directory nên Admin chỉ cần backup lại thư mục %systemroot%\system32\dns bằng các công cụ backup như Veritas Netbackup, Scheduled Tasks,… hoặc backup thủ công.
Sau khi backup DNS trong thư mục Systemroot, ta cần phải tiến hành thêm một bước nữa đó là backup Registry DNS.
1. Vào Start à Run gõ lệnh regedit à OK
2. Tìm đến khóa HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\DNS
3. Chuột phải vào folder DNS rồi chọn Export
4. Chỉ đường dẫn và đặt tên cho file registry này, lưu với tên là backup registry dns 1.reg
| Click this bar to view the full image. |
5. Tìm đến khóa HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server
6. Chuột phải vào folder DNS Server rồi chọ Export.
7. Chỉ đường dẫn và đặt tên cho file registry này, lưu với tên là backup registry dns 2.reg
| Click this bar to view the full image. |
Backup DNS Server trong Active Directory
1. Vào Start --> Run gõ lệnh ntbackup
2. Chọn Advanced Mode
| Click this bar to view the full image. |
3. Chọn tab Backup
4. Chọn System State trong mục My Computer --> Chọn đường dẫn lưu trữ file *.bfk
| Click this bar to view the full image. |
5. Nhấn Start Backup 2 lần
Restore Database DNS Server
Người thực hiện : Domain Admin, DNS Admin, Local Admin, Backup Operator.
Restore Database DNS Server chứa trong Systemroot Folder
1. Stop DNS Service
2. Copy Database DNS vào lại thư mục %systemroot%\system32\dns trên Server DNS
3. Chạy 2 file backup registry dns 1.reg và backup registry dns 2.reg để backup DNS registry
3. Start DNS Service
4. Refesh lại DNS để xem thông tin các Zone đã được phục hồi.
Restore Database DNS Server trong System Restore (trường hợp DNS tích hợp với AD)
1. Khởi động Server vào chế độ Directory Restore Mode
2. Double Click vào file *.bkf chứa System State của lần Backup trước
3. Tiếp tục chạy quá trình NTBackup phục hồi lại Database DNS Server
Lưu ý: quá trình này sẽ phục hồi toàn bộ Active Directory và override các dữ liệu trên Active Directory
19. Vài dòng lệnh hữu ích liên quan đến DNS trên Windows
Chắc hẳn mọi người ai cũng quen thuộc với dòng lệnh ipconfig trên Windows, tiện ích ipconfig được Microsoft tích hợp sẵn trong các hệ điều hình Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows 7 và Windows Server 2008. Sangnt xin phép cung cấp thêm một ít hiểu biết của mình về các option của dòng lệnh này trong loạt bài viết tìm hiểu về DNS.
ipconfig /displaydns : dùng để xem nội dung các resource record đã được cache lại trên máy tính của mình (hay còn gọi là resolver client). Mỗi resource record bao gồm các thông tin như tên của record (Record Name), kiểu record (Record Type), Thời gian tồn tại của record này trên máy (Time To Live), độ dài gói tin (Data Length), Section và Resource Record Data. Nếu trong cache đã có record chứa thông tin truy vấn nào đó rồi, thì máy tính đó sẽ sử dụng thông tin này để phân giải tên sang địa chỉ IP, không phải tốn thời gian để truy vấn lại thông tin này (thời gian tồn tại của record phụ thuộc vào thông số Time To Live). Nói tóm lại, đầu tiên client sẽ tìm thông tin trong cache của nó trước, nếu không có thì sẽ tiến hành gửi query đến DNS Server được chỉ định. Sau khi nhận được reply từ DNS Server, client sẽ cache lại thông tin này để phục vụ cho lần truy vấn sau.
| Click this bar to view the full image. |
Nội dung các record được cache lại trên máy client
ipconfig /flushdns : xóa toàn bộ nội dung các record trong cache của chính máy tính đó. Đôi khi chúng ta phải sử dụng dòng lệnh này để giải quyết sự cố trong trường hợp thông tin record được cập nhật trên DNS Server nhưng cache client của chúng ta vẫn còn lưu thông tin cũ.
ipconfig /registerdns : dùng để đăng ký cập nhật động đến DNS Server (sau khi đã được DHCP cung cấp IP và các thông số cần thiết khác như subnet mask, default gateway, ip dns,…), trên DNS Server lúc này sẽ tự động tạo các record như A Host và Pointer tương ứng với IP và tên máy của client).
Link: http://khongtenmien.com/forum/showthread.php?t=1978