Bản ghi DNS và cấu trúc thông điệp DNS

Các máy chủ DNS hợp tác để triển khai cơ sở dữ liệu phân tán DNS lưu trữ các bản ghi DNS (RR – Resource Records), bao gồm các bản ghi cung cấp ánh xạ giữa tên miền (hostname) và địa chỉ IP. Mỗi thông điệp phản hồi DNS chứa một hoặc nhiều bản ghi tài nguyên. Trong phần này và phần tiếp theo, mình sẽ cung cấp tổng quan ngắn gọn về các bản ghi DNS và các thông điệp; chi tiết hơn có thể tìm thấy trong các RFC về DNS [RFC 1034; RFC 1035].

Ở bài viết trước mình đã giới thiệu về Dịch vụ phân giải tên miền DNS trên internet.

Bản ghi DNS

Một bản ghi DNS là một bộ 4 phần (four-tuple) chứa các trường sau: (Name, Value, Type, TTL)

TTL là thời gian tồn tại của bản ghi DNS; nó quyết định khi nào một bản ghi DNS nên được xóa khỏi bộ nhớ đệm (cache). Trong các ví dụ về bản ghi dưới đây, bỏ qua trường TTL. Ý nghĩa của Name và Value phụ thuộc vào Type:

• Nếu Type=A, thì Name là một tên miền và Value là địa chỉ IP cho tên miền đó. Như vậy, bản ghi Type A cung cấp ánh xạ tiêu chuẩn giữa tên miền và địa chỉ IP. Ví dụ: (relay1.bar.foo.com, 145.37.93.126, A) là một bản ghi Type A.
• Nếu Type=NS, thì Name là một miền (chẳng hạn như foo.com) và Value là tên miền của một máy chủ DNS có thẩm quyền (authoritative DNS server) biết cách lấy địa chỉ IP cho các máy chủ trong miền đó. Bản ghi này được sử dụng để định tuyến các truy vấn DNS tiếp theo trong chuỗi truy vấn. Ví dụ: (foo.com, dns.foo.com, NS) là một bản ghi Type NS.
• Nếu Type=CNAME, thì Value là tên miền chuẩn (canonical hostname) cho tên miền biệt danh (alias hostname) Name. Bản ghi này có thể cung cấp cho các máy chủ đang truy vấn tên miền chuẩn của một tên miền. Ví dụ: (foo.com, relay1.bar.foo.com, CNAME) là một bản ghi CNAME.
• Nếu Type=MX, thì Value là tên miền chuẩn của một máy chủ thư điện tử (mail server) có tên miền biệt danh Name. Ví dụ: (foo.com, mail.bar.foo.com, MX) là một bản ghi MX. Các bản ghi MX cho phép tên miền của các máy chủ thư điện tử có các biệt danh đơn giản. Lưu ý rằng bằng cách sử dụng bản ghi MX, một công ty có thể có cùng một tên biệt danh cho máy chủ thư điện tử và cho một máy chủ khác (chẳng hạn như máy chủ web). Để lấy tên miền chuẩn cho máy chủ thư điện tử, một máy khách DNS sẽ truy vấn bản ghi MX; để lấy tên miền chuẩn cho máy chủ khác, máy khách DNS sẽ truy vấn bản ghi CNAME.

Nếu một máy chủ DNS có quyền quản lý đối với một tên miền cụ thể, thì máy chủ DNS đó sẽ chứa một bản ghi loại A (Type A) cho tên miền đó. (Ngay cả khi máy chủ DNS không có quyền quản lý, nó vẫn có thể chứa bản ghi Type A trong bộ nhớ đệm của nó). Nếu một máy chủ không có quyền quản lý đối với một tên miền, thì máy chủ đó sẽ chứa một bản ghi loại NS (Type NS) cho miền bao gồm tên miền đó; nó cũng sẽ chứa một bản ghi Type A cung cấp địa chỉ IP của máy chủ DNS trong trường Value của bản ghi NS.

Ví dụ, giả sử một máy chủ DNS của miền cấp cao nhất edu không có quyền quản lý đối với máy chủ gaia.cs.umass.edu. Khi đó, máy chủ edu này sẽ chứa một bản ghi cho một miền bao gồm máy chủ gaia.cs.umass.edu, chẳng hạn như (umass.edu, dns.umass.edu, NS). Máy chủ edu này cũng sẽ chứa một bản ghi loại A, ánh xạ từ máy chủ DNS dns.umass.edu sang địa chỉ IP, ví dụ (dns.umass.edu, 128.119.40.111, A).

Thông điệp DNS (DNS Message)

Hai loại thông điệp duy nhất trong DNS là DNS Query (thông điệp DNS truy vấn) và DNS Response (thông điệp DNS phản hồi). Cả thông điệp truy vấn và phản hồi đều có cùng một định dạng. Ý nghĩa của các trường khác nhau trong một thông điệp DNS như sau:

• Phần đầu (header section): Chiếm 12 byte đầu tiên, bao gồm nhiều trường khác nhau. Trường đầu tiên là một số 16-bit dùng để xác định truy vấn. Số nhận dạng này sẽ được sao chép vào thông điệp phản hồi để cho phép client khớp các phản hồi nhận được với các truy vấn đã gửi. Có một số cờ (flags) trong trường cờ:
  • Cờ 1-bit truy vấn/phản hồi (query/reply) cho biết thông điệp là truy vấn (0) hay phản hồi (1).
• • Cờ 1-bit quyền quản lý (authoritative flag) được đặt trong thông điệp phản hồi khi máy chủ DNS là máy chủ có quyền quản lý đối với tên miền được truy vấn.
• • Cờ 1-bit đệ quy mong muốn (recursion-desired flag) được đặt khi máy khách (máy chủ hoặc DNS server) mong muốn máy chủ DNS thực hiện đệ quy khi nó không có bản ghi.
• • Cờ 1-bit đệ quy khả dụng (recursion-available flag) được đặt trong phản hồi nếu máy chủ DNS hỗ trợ đệ quy.
  Ngoài ra, trong phần đầu còn có 4 trường chỉ số số lượng (number-of fields). Các trường này chỉ số lần xuất hiện của bốn loại phần dữ liệu theo sau phần đầu.
• Phần câu hỏi (question section): Chứa thông tin về truy vấn đang được thực hiện. Phần này bao gồm:
  1. Trường tên (name field) chứa tên miền đang được truy vấn.
  2. Trường loại (type field) chỉ ra loại câu hỏi đang được hỏi về tên miền đó—ví dụ, địa chỉ của máy chủ gắn liền với tên miền (Type A) hoặc máy chủ thư điện tử cho tên miền (Type MX).

• Phần trả lời (answer section): Trong phản hồi từ một máy chủ DNS, phần trả lời chứa các bản ghi tài nguyên (RR – Resource Records) cho tên miền ban đầu được truy vấn. Như đã nhắc lại, mỗi bản ghi tài nguyên bao gồm các trường như Type (ví dụ: A, NS, CNAME, MX), Value, và TTL. Một phản hồi có thể trả về nhiều bản ghi tài nguyên, vì một tên miền có thể có nhiều địa chỉ IP (ví dụ, đối với các máy chủ web được sao chép, như đã thảo luận trước đó trong phần này).
• Phần quyền quản lý (authority section): Chứa các bản ghi DNS về các máy chủ DNS có quyền quản lý khác.
• Phần bổ sung (additional section): Chứa các bản ghi hữu ích khác. Ví dụ, trong một phản hồi đối với truy vấn MX, phần trả lời sẽ chứa bản ghi tài nguyên cung cấp tên miền chuẩn (canonical hostname) của máy chủ thư điện tử. Phần bổ sung sẽ chứa bản ghi loại A (Type A) cung cấp địa chỉ IP của tên miền chuẩn của máy chủ thư điện tử.

Chèn bản ghi DNS vào CSDL DNS

Giả sử ta có một công ty khởi nghiệp tên Network Utopia. Điều đầu tiên sẽ làm là đăng ký tên miền networkutopia.com tại một registrar. Registrar là một thực thể thương mại xác minh tính duy nhất của tên miền, đưa tên miền vào cơ sở dữ liệu DNS, và thu một khoản phí cho dịch vụ này. Trước năm 1999, Network Solutions độc quyền đăng ký tên miền cho các miền com, net, và org, nhưng hiện nay có nhiều registrar khác nhau, được tổ chức ICANN chứng nhận.

Khi đăng ký tên miền networkutopia.com tại một registrar, bạn cần cung cấp cho họ tên và địa chỉ IP của các máy chủ DNS chính và phụ của mình. Ví dụ, tên và địa chỉ IP có thể là dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1, và 212.212.212.2. Sau đó, registrar sẽ đảm bảo rằng các bản ghi loại NS và A được đưa vào các máy chủ TLD com. Cụ thể, registrar sẽ chèn hai bản ghi tài nguyên sau vào hệ thống DNS:

• (networkutopia.com, dns1.networkutopia.com, NS)
• (dns1.networkutopia.com, 212.212.212.1, A)

Chúng ta cũng phải đảm bảo rằng bản ghi loại A cho máy chủ web www.networkutopia.com và bản ghi loại MX cho máy chủ thư điện tử mail.networkutopia.com được đưa vào các máy chủ DNS có thẩm quyền của chúng ta . Trước đây, nội dung của mỗi máy chủ DNS được cấu hình tĩnh từ một tệp cấu hình do người quản lý hệ thống tạo ra. Gần đây, tùy chọn UPDATE đã được thêm vào giao thức DNS để cho phép dữ liệu được thêm hoặc xóa động khỏi cơ sở dữ liệu thông qua thông điệp DNS (xem [RFC 2136] và [RFC 3007]). Khi tất cả các bước này hoàn tất, mọi người có thể truy cập trang web của chúng ta.

Giả sử Alice ở Úc muốn xem trang web www.networkutopia.com. Như đã thảo luận trước đó, máy chủ của cô ấy sẽ gửi một truy vấn DNS đến máy chủ DNS cục bộ. Máy chủ DNS cục bộ sau đó sẽ liên hệ với một máy chủ TLD com (hoặc một máy chủ root nếu địa chỉ của máy chủ TLD không được lưu trong bộ nhớ đệm). Máy chủ TLD com chứa các bản ghi tài nguyên NS và A mà registrar đã thêm vào. Máy chủ TLD com sẽ gửi một phản hồi chứa hai bản ghi tài nguyên này về cho máy chủ DNS cục bộ của Alice. Sau đó, máy chủ DNS cục bộ sẽ gửi một truy vấn DNS đến địa chỉ 212.212.212.1, yêu cầu bản ghi loại A cho www.networkutopia.com. Bản ghi này sẽ cung cấp địa chỉ IP của máy chủ web mà Alice muốn truy cập, ví dụ 212.212.71.4. Máy chủ DNS cục bộ sau đó sẽ gửi địa chỉ này về cho máy của Alice. Trình duyệt của Alice có thể khởi tạo kết nối TCP đến máy chủ 212.212.71.4 và gửi yêu cầu HTTP qua kết nối đó.

Lỗ hổng trong giao thức DNS

DNS là một thành phần quan trọng của cơ sở hạ tầng Internet, với nhiều dịch vụ thiết yếu như Web và email không thể hoạt động nếu thiếu nó. Do đó, câu hỏi tự nhiên đặt ra là: DNS có thể bị tấn công không? Liệu DNS có dễ bị tấn công và làm gián đoạn hầu hết các ứng dụng Internet?

Một trong những loại tấn công dễ thấy nhất là tấn công từ chối dịch vụ phân tán (DDoS) bằng cách làm ngập băng thông (DDoS bandwidth-flooding attack) đối với các máy chủ DNS. Ví dụ, kẻ tấn công có thể cố gắng gửi lượng lớn gói tin đến mỗi máy chủ root DNS để khiến phần lớn các truy vấn DNS hợp lệ không nhận được phản hồi. Một cuộc tấn công DDoS quy mô lớn như vậy đã xảy ra vào ngày 21 tháng 10 năm 2002. Trong cuộc tấn công này, kẻ tấn công sử dụng botnet để gửi hàng loạt thông điệp ICMP ping đến 13 địa chỉ IP của các máy chủ root DNS. Tuy nhiên, cuộc tấn công này gây thiệt hại rất nhỏ hoặc không ảnh hưởng đến trải nghiệm của người dùng Internet. Nhiều máy chủ root DNS đã được bảo vệ bằng các bộ lọc gói tin, chặn các thông điệp ICMP ping, nên chúng vẫn hoạt động bình thường. Ngoài ra, các máy chủ DNS cục bộ thường lưu trữ cache địa chỉ IP của các máy chủ TLD (top-level domain), cho phép quy trình truy vấn thường bỏ qua các máy chủ root DNS.

Một hình thức tấn công DDoS tiềm năng khác là làm ngập các truy vấn DNS đến các máy chủ TLD, chẳng hạn như các máy chủ TLD xử lý miền .com. Việc lọc các truy vấn DNS khó hơn, và các máy chủ TLD không dễ bị bỏ qua như các máy chủ root. Một ví dụ điển hình là cuộc tấn công DDoS vào nhà cung cấp dịch vụ TLD Dyn vào ngày 21 tháng 10 năm 2016. Cuộc tấn công này được thực hiện qua botnet gồm khoảng 100.000 thiết bị IoT (như máy in, camera IP, cổng kết nối dân dụng, và máy theo dõi trẻ em) bị nhiễm malware Mirai. Trong gần một ngày, các dịch vụ của Amazon, Twitter, Netflix, Github, và Spotify đã bị gián đoạn.

DNS cũng có thể bị tấn công theo nhiều cách khác. Ví dụ, trong cuộc tấn công man-in-the-middle, kẻ tấn công chặn các truy vấn và trả lại phản hồi giả mạo. Trong tấn công DNS poisoning, kẻ tấn công gửi các phản hồi giả mạo đến máy chủ DNS, khiến máy chủ lưu trữ các bản ghi sai vào bộ nhớ đệm. Những cuộc tấn công này có thể được sử dụng để chuyển hướng người dùng Web không nghi ngờ đến trang web của kẻ tấn công. Để chống lại những cuộc tấn công này, đã có sự ra đời của DNS Security Extensions (DNSSEC), một phiên bản bảo mật của DNS, được thiết kế để bảo vệ chống lại các cuộc tấn công trên. DNSSEC đang ngày càng phổ biến trên Internet nhờ khả năng bảo vệ này.

Bài viết tiếp theo mình sẽ tiếp tục giới thiệu về Dịch vụ chia sẻ file ngang hàng trên Internet.