Không thêm dấu chấm vào tên RR. Sử dụng nó như thế này:
máy chủ my.dns.server
ví dụ vùng.com
key example.com some-key-data
cập nhật xóa ví dụ.com 604800 A
cập nhật thêm ví dụ.com 604800 A 192.0.2.1
gửi
Tôi vừa thử nghiệm nó với bản ghi A và MX; nó hoạt động với tôi, máy chủ là PowerDNS, máy khách là ISC nsupdate từ các công cụ liên kết, xác thực thông qua TSIG, tên khóa bằng với tên vùng để đơn giản.
Tôi có ấn tượng rằng bạn không hiểu đầy đủ về cách $Origin và @ làm việc, vì vậy đây là một lời giải thích nhỏ. Để được giải thích đầy đủ, xem RFC1035.
Trên dây những thứ này không bao giờ xuất hiện. Nó chỉ là một "đường cú pháp" thuận tiện để rút ngắn việc gõ và đọc các tệp vùng. Ba ví dụ sau xác định các vùng giống hệt nhau (Tôi lười hoàn thành các bản ghi SOA, giá trị chính xác của chúng không quan trọng đối với chủ đề của chúng ta):
$ORIGIN ví dụ.com.
@ 604800 TRONG SOA ns1 ....
604800 TRONG NS ns1
ns1 3600 TRONG 192.0.2.1
@ 3600 TRONG 192.0.2.5
GỐC $.
example.com 604800 TRONG SOA ns1.example.com ....
$Origin com.
ví dụ 604800 TRONG NS ns1.ví dụ
$ORIGIN ns1.example.com.
@ 3600 TRONG 192.0.2.1
ví dụ.com. 3600 TRONG 192.0.2.5
ví dụ.com. 604800 TRONG SOA ns1.example.com. ....
ví dụ.com. 604800 TRONG NS ns1.example.com.
ns1.example.com. 3600 TRONG 192.0.2.1
ví dụ.com. 3600 TRONG 192.0.2.5
Trong ví dụ đầu tiên, tôi không chỉ định bất kỳ tên RR nào trong dòng thứ ba (NS RR sau SOA RR), vì vậy trình phân tích cú pháp sẽ lấy nó từ dòng trước. Hành vi này là lý do chính xác cho @ tồn tại cú pháp: bạn không thể để trống trường tên RR, vì nó sẽ lấy tên bản ghi trước đó. Nếu tôi bỏ qua @ ở bản ghi cuối cùng, tôi sẽ xác định một giây Một ghi lại cho ns1. Vì vậy, để xác định một bản ghi có tên tương đương với điểm gốc được đặt hiện tại (nó sẽ là "đỉnh" nếu điểm gốc được đặt thành tên vùng), bạn không thể sử dụng "tên trống", vì nó sẽ gọi hành vi "lấy trước đó".Bạn phải đánh vần rõ ràng tên bản ghi đầy đủ bằng dấu chấm để nó không thêm phần gốc (như được viết trong các ví dụ khác), thay đổi phần gốc hoặc sử dụng một ký hiệu đặc biệt @ thông báo cho trình phân tích cú pháp: "đừng lặp lại tên trước đó, ở đây có nguồn gốc trần trụi", vì vậy dòng cuối cùng trong ví dụ đầu tiên xác định ví dụ.com..
Ví dụ thứ hai chỉ là trình diễn lạ mắt về cách $Origin và @ làm việc cùng nhau.
Ví dụ thứ ba không sử dụng đường. Đây là dữ liệu tuyệt đối thực sự mà vùng chứa trong ba ví dụ đó.
Vì vậy, bản ghi của bạn có thể được trình bày trong tệp vùng dưới dạng ví dụ.com sau đó GỐC $., hoặc ví dụ.com. bất cứ nơi nào, hoặc @ sau đó $ORIGIN ví dụ.com., hoặc thậm chí ví dụ sau đó $Origin com., không thành vấn đề. Những trường hợp này đều bình đẳng. Có thể bạn đang mong đợi thấy biến thể "@", nhưng BIND có thể quyết định đánh vần nó là bất kỳ biến thể nào trong số đó, vì vậy hãy chuẩn bị để nhận ra tất cả chúng. Và bạn không thể buộc nó sử dụng bất kỳ biến thể cụ thể nào, xin lỗi.
Một lưu ý khác là bạn có thể đọc tệp vùng sau khi cập nhật mà không đóng băng tệp đó trước. Lưu ý tệp "jnl" bên cạnh tệp vùng; đó là nhật ký nơi dữ liệu cập nhật của bạn được lưu trữ lần đầu tiên. Chỉ khi bạn làm rndc đóng băng ví dụ.com dữ liệu được ghi vào tệp vùng (nhưng vùng này sau đó bị khóa để cập nhật, để mở khóa, bạn cần thực hiện tan băng hoạt động hoặc tải lại máy chủ). Cách thích hợp để kiểm tra xem vùng có được cập nhật hay không là thực hiện truy vấn DNS thực tế, với đào hoặc chủ nhà hoặc nslookup, bất cứ thứ gì bạn thích:
máy chủ -v example.com
