Điểm:2

có tên/liên kết đang từ chối phục vụ một số miền sau khi tự giải quyết chúng

lá cờ co

Tại sao liên kết từ chối một số truy vấn của tôi? Điều này chỉ xảy ra đối với một số miền nhất định.

Một truy vấn thông qua tên không thành công:

$ đào -t Một fedoraproject.org @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33117

$ nhật kýctl -n10
...
Ngày 01 tháng 8 17:07:11 ns3.r3.mclarkdev.com có ​​tên[10807]: hoàn tất truy vấn mồi trình giải quyết
Ngày 01 tháng 8 17:09:57 ns3.r3.mclarkdev.com có ​​tên[10807]: đã hết thời gian giải quyết 'fedoraproject.org/DNSKEY/IN': 8.8.8.8#53
Ngày 01 tháng 8 17:09:59 ns3.r3.mclarkdev.com có ​​tên[10807]: đã hết thời gian giải quyết 'fedoraproject.org/DNSKEY/IN': 8.8.8.8#53

Tuy nhiên, một truy vấn trực tiếp đến người giao nhận hoạt động:

$ đào -t Một fedoraproject.org @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42249

  ... Hồ sơ ...

Bind đang sử dụng một cấu hình khá mặc định.
Điều duy nhất tôi đã thay đổi là cho phép truy vấn từ mọi nơi và thêm tệp vùng để phục vụ một số bản ghi cục bộ.

tùy chọn {
    cổng nghe 53 { bất kỳ; };
    cho phép truy vấn { bất kỳ; };
    giao nhận { 8.8.8.8; };
    đệ quy có;
    ...
    kích hoạt dnssec có;
    xác thực dnssec có; // cũng đã thử tự động
}

...

// bao gồm hai định nghĩa `zone` bổ sung
bao gồm "/opt/dns/named.zones";

Phiên bản của hệ điều hành: CentOS Linux phát hành 8.4.2105
Phiên bản hạt nhân: 4.18.0-305.10.2.el8_4.x86_64
Phiên bản được đặt tên: Ràng buộc 9.11.26-RedHat-9.11.26-4.el8_4

Xem tcpdump, tôi có thể thấy rằng tên đó đang liên hệ với người giao nhận và truy xuất bản ghi A, nhưng lại từ chối cung cấp chúng cho khách hàng sau khi thực hiện một số truy vấn bổ sung.

localhost.49683 > localhost.domain: 14274+ A? fedoraproject.org. (35)
ns3.r3.mclarkdev.com.56668 > 8.8.8.8.domain: 21852+% [1au] A? fedoraproject.org. (58)
localhost.39587 > localhost.domain: 53253+ PTR? 8.8.8.8.in-addr.arpa. (38)
ns3.r3.mclarkdev.com.55378 > 8.8.8.8.domain: 61019+% [1au] PTR? 8.8.8.8.in-addr.arpa. (61)
8.8.8.8.domain > ns3.r3.mclarkdev.com.56668: 21852$ 12/0/1 fedoraproject.org. A 140.211.169.206, fedoraproject.org. A 152.19.134.198, fedoraproject.org. A 8.43.85.73, fedoraproject.org. A 152.19.134.142, fedoraproject.org. A 38.145.60.21, fedoraproject.org. A 140.211.169.196, fedoraproject.org. A 209.132.190.2, fedoraproject.org. A 8.43.85.67, fedoraproject.org. A 67.219.144.68, fedoraproject.org. A 38.145.60.20, fedoraproject.org.RRSIG, fedoraproject.org. RRSIG (528)
  /\ bind có bản ghi A

ns3.r3.mclarkdev.com.52120 > 8.8.8.8.miền: 7073+% [1au] DNSKEY? fedoraproject.org. (58)
8.8.8.8.domain > ns3.r3.mclarkdev.com.55378: 61019 1/0/1 8.8.8.8.in-addr.arpa. PTR dns.google. (73)
ns3.r3.mclarkdev.com.55309 > 8.8.8.8.domain: 23607+% [1au] DS? 8.in-addr.arpa. (55)
localhost.48388 > localhost.domain: 55328+ PTR? 201.23.16.172.in-addr.arpa. (44)
  /\ bind thực hiện một số truy vấn bổ sung

localhost.domain > localhost.48388: 55328 NXDomain* 0/1/0 (98)
  /\ bind phục vụ NXDomain cho client

Tại sao được đặt tên là từ chối cung cấp kết quả cho khách hàng? Nó chỉ xảy ra với khoảng 1% tên miền.

lá cờ co
Tôi đã thay đổi rất ít tùy chọn, chỉ để cho phép những người khác trên mạng sử dụng nó làm proxy và cung cấp cho nó hai vùng cục bộ để phục vụ. Tôi đã thêm các dòng tôi đã thay đổi, mọi thứ khác là mặc định.
Michael Hampton avatar
lá cờ cz
Thật ki quặc. Tại sao bạn đã thiết lập giao nhận?
lá cờ co
Tôi muốn đây là một máy chủ DNS nội bộ; nó sẽ được phân phối với các hợp đồng thuê DHCP để giải quyết tất cả các truy vấn công khai và truy vấn cục bộ (các vùng bổ sung mà tôi đã tải). Tôi chỉ thấy các lỗi liên quan đến `DNSKEY` này - các miền khác giải quyết ổn thỏa thông qua các nhà chuyển tiếp. Chỉ có khoảng 1% tên miền không giải quyết được, sự cố tồn tại trên hai máy chủ mà tôi đang chạy song song.
lá cờ mx
NXDOMAIN không dành cho `fedoraproject.org`, nó dành cho `201.23.16.172.in-addr.arpa`.Đó là tra cứu DNS ngược của một IP riêng.
lá cờ mx
Bạn chưa giải thích lý do tại sao bạn định cấu hình giao nhận thay vì để nó tự giải quyết các miền bên ngoài.
Điểm:1
lá cờ mx

tcpdump cho thấy nó đã nhận thành công Một hồ sơ của fedoraproject.org, nhưng nó cũng đang cố gắng để có được DNSKEY bản ghi, được sử dụng để xác thực DNSSEC. Nhưng không có phản hồi cho điều đó.

tôi đã hỏi 8.8.8.8 cho việc này DNSKEY ghi lại, và nó hoạt động tốt.

$ đào fedoraproject.org dnskey @8.8.8.8

; <<>> DiG 9.10.6 <<>> fedoraproject.org dnskey @8.8.8.8
;; tùy chọn chung: +cmd
;; Có câu trả lời:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63666
;; cờ: qr rd ra quảng cáo; CÂU HỎI: 1, TRẢ LỜI: 4, AUTHORITY: 0, BỔ SUNG: 1

;; LỰA CHỌN PSEULiều lượng:
; EDNS: phiên bản: 0, cờ:; udp: 512
;; PHẦN CÂU HỎI:
;fedoraproject.org. TRONG DNSKEY

;; PHẦN TRẢ LỜI:
fedoraproject.org. 108 IN  DNSKEY  256 3 5 AwEAAcCWNQWl5pCI3iOOP2r8nStL60Zjb/2JQLQytamVap0L44z0YWft u7pu0hx3cnIM1ejQOsEwbg2/10IyC+38cYqJDXbSdFg1zGztOS5xNz7r 9hzSRK5N2jkycdJ/BoByJ4Y+XGpDqfG4I97++8sIzSrw60TmGAKTvM9v iL3ByeCN
fedoraproject.org. 108 IN  DNSKEY  257 3 5 AwEAAdTXJc0joiKGfTvLXi+LXxGpKvPvOoJEst9PR8TCCvXGVp7h3BY3 uXLkjckuT0aopCp2KF8zHgNgpMK03p1fd94pn9JZSuxfqvKsiYH2KvNO a/655oPj06jRhqAP5grX01Iz4BH411ZhGxIQ1BzZtOr1wAazojMJzLUg ChRJs8GVt3LU0e6T8z1RQF33Dt9UMHIR5EAsFAqfZ/tsbfJDYktGoZi3 nFlW7A745+ObM1LNXOWq3FcYPVzhH08Q7/7WpxmzM6/ET8VeqWIsvh8E nZNDNMfJyPbY9B1BOIrFCpE03ALgFMejaBZwmeQaX+D4Duup5xGOmdtC O4GSpM1YH6c=
fedoraproject.org. 108 TRONG DNSKEY 257 3 14 7ttmhus8JD56ybsvMVZVsXa3U2R+2+WmOPIP7BU6t2LicosMZ2Ju3Ju3pfv ijsa5LvBvVCB4xVtLSqEdLSvW4vJPLSAB2uyJwHPJMezh0SzGmVCImLU 6qDxsxjHqtZ76/Sf
fedoraproject.org. 108 TRONG DNSKEY 256 3 14 04ZsDOgyzs3kJsJ4jEY3MYufkCOWm1OI8N4M+dlBOBmweln0TSaKfafH zNCkaPiVG4bdgdnrzwxmjpK5GQgsiB47np+I8850Ea3EJG5ORDl3f//l rr92HiYh5DxCnhkG

Vì vậy, tôi nghi ngờ điều gì đó trong môi trường của bạn đang chặn truy vấn hoặc phản hồi. Đó có thể là sự cố tường lửa, lọc các loại bản ghi DNS hoặc phản hồi lớn.

Điểm:0
lá cờ cz

Quá trình cài đặt liên kết của bạn dường như bị nghẽn khi xác thực DNSSEC cho các miền đã ký DNSSEC. Các phiên bản gần đây hơn của liên kết có xác thực DNSSEC được bật theo mặc định, nhưng các phiên bản cũ hơn như 9.11 cần được bật rõ ràng:

tùy chọn {
         ...
         tự động xác thực dnssec;
         ...
 };
lá cờ co
Thật không may, tôi đã thử điều này và không có thay đổi.
Michael Hampton avatar
lá cờ cz
@MattClark Tại sao bạn không nói như vậy khi tôi hỏi?
lá cờ co
Rất tiếc, tôi đã thử một số cách - Tôi đã quay lại cấu hình mặc định khá nhiều và vẫn gặp sự cố. Tôi đặt lại giá trị này thành 'có', đây là giá trị mặc định, nhưng tôi đã thử 'tự động' trong khi gỡ lỗi.
Michael Hampton avatar
lá cờ cz
Dù sao nó vẫn cần ở đó, vì vậy bạn nên để nó vào.
lá cờ co
Tôi đã thêm một số thông tin bổ sung vào bài đăng chính, không chắc có giúp được không.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.