─ Để đơn giản hóa các hoạt động của name server, nó rất hữu ích nếu một nguồn duy nhất có thể cập nhật nhiều máy chủ. Bảo trì có thể quá trình khu vực này liên quan đến việc chuyển giao các tập tin khu vực từ một máy chủ DNS khác giữa một master và slave DNS cho các tính năng zone-sử dụng của giao thức DNS. Thời gian giữa chuyển đổi khu tập tin là một yếu tố quyết định lớn của tốc độ mà thay đổi các thông tin được lan truyền khắp vùng Internet.
─ Thiết kế ban đầu của DNS cho phép để thay đổi để được truyền ra bằng cách sử dụng chuyển vùng hoàn toàn (AXFR), nhưng thế giới của Internet đã được đơn giản hơn trong những ngày đó (1987). Mong muốn tăng tốc độ quá trình khu vực cập nhật propagation, đồng thời giảm thiểu sử dụng tài nguyên, đã dẫn đến một số thay đổi đối với khía cạnh này của thiết kế DNS và thực hiện từ đơn giản nhưng hiệu quả-mày mò như chuyển vùng gia tăng (AXFR) và THÔNG BÁO tin nhắn đến các khái niệm phức tạp hơn của bản cập nhật động (DDNS).
─ Warning: Trong khi di chuyển vùng nói chung là cần thiết cho sự hoạt động
hiệu quả của các hệ thống DNS, họ cũng là một nguồn chính của các mối đe dọa. Một DNS slave có thể trở nên độc nếu nó chấp nhận cập nhật vùng từ một nguồn độc hại. Nên cẩn thận trong quá trình cấu hình DNS để đảm bảo rằng, là mức tối thiểu, các DNS slave sẽ chấp nhận vận chuyển từ nguồn chỉ được biết đến và tin cậy. Các cấu hình ví dụ được cung cấp trong chương sau thực hiện các biện pháp phòng ngừa tối thiểu.
Full Zone Transfer (AXFR)
─ Các thông số kỹ thuật DNS gốc (RFC 1034 và RFC 1035) dự kiến rằng slave(hoặc Secondary) name server cho zone sẽ thăm dò ý kiến các master name server cho zone. Thời gian giữa các điểm bỏ phiếu được xác định bằng giá trị refresh của SOA RR của miền, được mô tả trong Chương 2. Trong một khu tập tin điển hình, giá trị này sẽ là 12 giờ hoặc nhiều hơn.
─ Quá trình bỏ phiếu DNS được thực hiện bởi các slave name server gửi một truy vấn tới zone master yêu cầu SOA RR. Nếu số serial của SOA RR là lớn hơn hiện tại được duy trì bởi các slave name server, 1 full zone transfer (AXFR) được yêu cầu bởi slave DNS. Đây là lý do quan trọng là phải xử lý kỷ luật về việc cập nhật các số serial SOA mỗi khi bất cứ điều gì thay đổi trong bất kỳ zone records. Ví dụ sau đây chứng tỏ việc cập nhật các số nối tiếp bằng cách sử dụng định dạng số ngày được đề nghị của yyyymmddss, nơi yyyy là một số năm có bốn chữ số, mm là một số tháng có hai chữ số, dd
là một số ngày hai chữ số, và ss là một chuỗi số để các vùng có thể được cập nhật nhiều hơn một lần mỗi ngày. Giả sử một SOA RR như ở đây:
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080803 ; sn = serial number
3h ; refresh time
15m ; retry = refresh retry 3w ; expiry
3h ; nx = nxdomain ttl )
─ Sử dụng định dạng ngày, điều này cho thấy rằng zone file đã được cập nhật 4 lần (ss=03) vào ngày 8/8/2003. Nếu chúng ta giả định hôm nay là 7/8/2003, sau đó là số serial nên được thiết lập giá trị hiện chỗ này:
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003090700 ; sn = serial number
3h ; refresh time
15m ; retry = refresh retry 3w ; expiry
3h ; nx = nxdomain ttl )
─ Số thứ tự cũng đã được thiết lập lại đến 00 để đảm bảo chúng tôi có nhiều không gian để sửa chữa lỗi! Nếu tháng và ngày ví dụ trước là để được trao đổi trong lỗi, sau đó là số serial sẽ được
2003070900 ; sn = serial number
─ Con số này không lớn hơn số trước đây, do đó, các slave sẽ không yêu cầu chuyển vùng và các bản cập nhật sẽ không được phổ biến. Việc sửa chữa trong trường hợp này là đơn giản bởi vì lỗi là trở lại trong thời gian. Ví dụ sau đây cho thấy số serial được đặt phía trước không chính xác trong thời gian:
2005090700 ; sn = serial number
─ Để khôi phục lại số serial này vào đúng ngày là phức tạp hơn nhiều, và bạn sẽ không muốn làm điều này đến lần thứ 2. Các thủ tục được diễn tả trong Chương 8. Hãy nhớ rằng các định dạng ngày là một quy ước được sử dụng rộng rãi và được đề nghị; BIND không xác nhận số lượng cho các phạm vi chính xác, đó là, sau đây được chấp nhận khá vui vẻ bởi BIND, đó là ngày thứ 45 của tháng 14 năm 2003 !:
2003144500 ; sn = serial number
─ Trong trường hợp này, 1 zone transfer sẽ diễn ra bởi vì số lượng lớn hơn giá trị ban đầu. Zone transfer (AXFR) hoạt động sử dụng TCP trên cổng 53. ─ Warning Luôn cập nhật các số serial SOA RR khi bạn thực hiện bất kỳ thay
─ Chuyển các tập tin khu vực lớn có thể mất thời gian dài và tốn băng thông và nhiều tài nguyên khác. Nó đặc biệt lãng phí nếu chỉ có 1 bản trong các tập tin đó thay đổi. RFC 1995 đã giới thiệu IXFR (the incremental zone transfer), điều này cho phép các name server phụ thuộc và name server chủ để chỉ chuyển những bản đã bị thay đổi.
─ Quá trình này làm việc như AXFR. Name server phụ thuộc gửi truy vấn cho các SOA RR để làm chủ vùng mỗi khi làm mới. Nếu số serial của SOA RR lớn hơn số serial được lưu ở name server phụ thuộc thì name server yêu cầu chuyển vùng và chỉ ra hoặc ko có khả năng chấp nhận IXFR. Nếu cả name server chủ và phụ thuộc đều hỗ trợ các tính năng thì IXFR được diễn ra; ngoài ra, AXFR cũng được diễn ra. IXFRs sử dụng TCP tại cổng 53.
─ Chế độ mặc định cho BIND khi hoạt động như một name server phụ thuộc để yêu cầu IXFR trừ khi nó không được cầu hình bằng cách sử dụng các yêu cầu từ máy chủ hoặc những phần trong file named.conf. chế độ mặc định cho BIND khi hoạt động như 1 name server chủ là sử dụng IXFR chỉ khi miền là miền động. Việc sử dụng IXFD được điều khiển qua phần mà server sử dụng hoặc những điều trong file named.conf. IXFRs chỉ ảnh hưởng đến đến khối dữ liệu được chuyển; chúng ko tác động đến thời gian thông báo cho các vùng việc thay đổi file.
Notify (NOTIFY)
─ RFC 1912 đề nghị một khoảng thời gian 2-12 tiếng hoặc cao hơn để làm mới cho SOA RR. điều này có nghĩa là thay đổi zone master có thể không được hiển thị cho zone slave lên tới 12 giờ hoặc bất cứ giá trị nào được thiết lập. Trong thế giới thay đổi nhanh của Internet, điều này có thể chấp nhận được. ─ RFC 1996 giới thiệu một chương trình theo đó zone name server (cả master
hay slave) sẽ gửi một thông điệm NOTIFY tới zone name servers (được xác định bởi các NS RR cho các zone) bất cứ khi nào zone được load hoặc update. Thông báo này chỉ ra rằng một sự thay đổi có thể xảy ra trong domain records. Các name server khi nhận được thông điệp NOTIFY sẽ yêu cầu SOA RR từ zone master, và nếu số serial là lớn hơn hiện tại, sẽ cố gắng chuyển vùng bằng cách sử dụng một AXFR hoặc một IXFR.
─ Hành vi mặc định của BIND là gửi thông điệp NOTIFY tới name servers được định nghĩa trong NS RRs cho zone. NOTIFY trong BIND được điều khiển bởi notify, also-notify, và notify-source báo cáo trong zone các mục hoặc tùy chọn của file named.conf (xem chương 12 để biết chi tiết). (adsbygoogle = window.adsbygoogle || []).push({});
─ NOTIFY có thể làm giảm thời gian đáng kể để tuyên truyền thay đổi zone tới servers.
─ Các phương pháp cổ điển của cập nhật zone RR là tự chỉnh sửa các zone files và sau đó stop và start lại name server để đọc zone files và phổ biến các thay đổi. khi volume thay đổi đến một mức độ nhất định, điều này có thể trở thành một hoạt động khó chấp nhận, nhất là trong các tổ chức mà xử lý số lượng lớn các zone file, chẳng hạn như các nhà cung cấp dịch vụ, BIND có thể mất 1 khoảng thời gian dài để khởi động lại bởi vì nó khởi tạo với số lượng rất là lớn các zone file.
─ Với lượng người dùng lớn hơn thì DNS tiến tới một phương pháp để thay đổi nhanh chóng các zone record trong khi các name server tiếp tục trả lời các truy vấn của người dùng. Có 2 cách tiếp cận kiến trúc để giải quyết vấn đề này:
+ Cho phép cập nhật thời gian chạy của zone RR từ một nguồn bên ngoài hoặc ứng dụng.
+ Trực tiếp cung cấp zone RR từ 1 database, có thể được cập nhật tự động.
+ RFC 2136 có những phương pháp tiếp cận đầu tiên và định nghĩa một quá trình được gọi là Dynamic DNS (DDNS), theo đó thì zone record có thể được update từ 1 hoặc nhiều nguồn bên ngoài. Giới hạn chính trong phương pháp này là một tên miền mới hoặc zone không thể được thêm vào hoặc xóa tự động. Tất cả bản ghi trong vòng zone hiện tại có thể được bổ sung, thay đổi, hoặc xóa, với ngoại lệ là các SOA RR không thể được thêm vào hoặc xóa bởi vì điều này sẽ làm cho hình thêm hoặc lại bỏ các zone.
+ Là một phần của RFC 2136, the term primary master đã được giới thiệu để mô tả cá name server được định nghĩa trong SOA RR cho zone. Khi tự động cập nhật các zone RR, nó là điều cần thiết để cập nhật chỉ 1 máy chủ. mặc dù có thể có nhiều máy chủ tổng thể cho zone. Để giải quyết vấn đề này, một boss server phải được chọn. The boss server, the primary master, không có đặc điểm đặc biệt khác với nó được định nghĩa là các name server trong SOA RR và có thể xuất hiện trong một cập nhật trong tập tin cấu hình named.conf của BIND để kiểm soát quá trình cập nhật tự động (xem chương 12 để biết chi tiết).
─ DDNS thường được mô tả trong sự kết hợp với tính năng bảo mật DNS-cụ thể, TSIG (RFC 2845) và TKey (RFC 2930). DDNS, tuy nhiên, không yêu cầu hoặc dựa vào các tính năng TSIG/TKey.
─ Lý do tại sao hai tính năng liên kết chặt chẽ là cho phép Dynamic DNS, zone files có thể được mở ra cho các khả năng buộc đóng hoặc bị phá hoại bởi các nguồn độc hại. Việc bảo vệ địa chỉ IP có thể được cấu hình vào trong BIND (sử dụng câu lệnh cho phép cập nhật BIND của mô tả trong chương 12), nhưng nó chỉ cung cấp 1 phương thức bảo mật còn hạn chế. kiến trúc hệ
cả các host được phép cập nhật nó đằng sau vành đai an toàn. Tuy nhiên, trong DDNS là điều khiển từ xa và người dùng phân tán được cập nhật và kiểm soát tên miền của họ. Trong hoàn cảnh này, những user nguy hiểm của DNS động sẽ luôn luôn sử dụng TSIG/TKEY được mô tả trong chương 10, để xác thực các request đến.
─ Hành vi mặc định của DDNS là từ chối tất cả các host. Kiểm soát việc cập nhật tự động được cung cấp bởi file named.conf và cập nhật chính sách (có thể sử dụng chỉ với TSIG/TKey) trong các điều khoản zone hoặc tùy chọn. Các báo cáo và điều khoản được đề cập trong chương 12.
─ Có một số công cụ mã nguồn mở sẽ bắt đầu cập nhật DDNS; chúng bao gồm ns update, đó là một trong những tiện ích được phân phối bởi BIND ( mô tả trong chương 9).
Alternative Dynamic DNS Approaches( Phương pháp tiếp cận Dynamic DNS thay thế)
─ Như đã nói trước đó, hạn chế lớn trong DDNS (RFC 2136) là các domain mới không thể được tạo ra tự động. Cách tiếp cận khác cho vấn đề này vẫn tồn tại.
─ BIND-DLZ (mã cơ sở tích hợp vào BIND từ bản release 9.4) có một cách tiếp cận triệt để hơn và thay thế tất cả các zone file bằng 1 zone file đơn giản, mô tả 1 cơ sở dữ liệu. BIND-DLZ hỗ trợ các cơ sở dữ liệu mã nguồn mở bao gồm MySQL, PostgreSQL, BDB, và LDAP.. Tất cả truy vấn đến DNS đầu tiên được hướng dẫn đến các truy cập thường xuyên do vậy tạo mới, sửa hoặc xóa zone data ngay lập tức phản ánh trong phản hồi của name server. ─ Giống như mọi thứ trong cuộc sống, ở đây có một lựa chọn. Tùy thuộc vào cơ
sở dữ liệu được lựa chọn, hiệu suất có thể giảm xuống. Trình điều khiển cơ sơ dữ liệu BIN-DLZ có trong thư mục /contrib của bản phát hành BIND( từ bản 9.4). Đối với thông tin cấu hình BIND-DLZ, các trình điều khiển cơ sở dữ liệu mới nhất và dữ liệu hiệu suất sử dụng website BIND-DLZ (binddlz.sourgeforge.net).
─ PowerDNS (www.powerdns.com) có một quyền- chỉ name server có thể lấy 1 cách tiếp cận tương tự (non-BIND) với mã cơ sở bằng cách tham khảo tất cả các truy vấn cơ sỡ dữ liệu back-end và do đó cho phép các domain mới sẽ được thêm vào tự động.
─ BIND 10 ( mô tả trong chương 14) hỗ trợ đầy đủ việc tạo hoặc xóa zone sử dụng một cơ sở dữ liệu back-end (mặc định là SQLite). File vùng văn bản tiêu chuẩn có thể được nạp vào cơ sỡ dữ liệu bằng cách sử dụng các tiện ích loadzone mới.
─ Caution: Việu sử dụng thay đổi thời gian thực với DNS record mà không có
biện pháp bảo vệ tích hợp có thể dẫn đến những lỗi nhỏ lan truyền khắp mạng internet với hậu quả thảm khốc bởi vì DNS cache giữ hồ sơ này trong 12 giờ hoặc hơn (được xác định bỏi một trong hai $TTL cho zone file hoặc giá trị TTL cho các RR cụ thể), các lỗi như vậy mất một thời gian dài để sửa chữa.