Điểm:0

Ubuntu 20.04 đã giải quyết chờ kết quả IPV6 bị từ chối với dnsmasq

lá cờ cn

TL; DR

Các truy vấn DNS của tôi bị chậm vì các truy vấn được phân giải bằng hệ thống thành công trên máy chủ DNS trên IPv4 nhưng truy vấn liên tục trên IPv6 sau khi máy chủ DNS phản hồi bằng REFUSED. Đây có phải là cấu hình đã giải quyết được phát hành không? Một vấn đề dnsmasq? hoặc một lỗi?

Tôi có một bản cài đặt Ubuntu 20.04 có sẵn được kết nối với dnsmasq đang chạy trên một thiết bị bị ngắt kết nối không khí (bộ định tuyến cạnh phổ biến) với tên miền cấp cao nhất 'thanh' (bộ nhớ ngắt kết nối không khí nhưng có vẻ như đây không phải là vấn đề - tức là .com, v.v.) . Yêu cầu DNS giải quyết nhanh chóng thông qua máy khách Mac và Windows. Đối với Ubuntu, các truy vấn DNS mất khoảng 5 giây để giải quyết. Tìm kiếm xung quanh, các vấn đề về DNS của Ubuntu được thảo luận ở nhiều nơi nhưng hành vi cơ bản mà tôi đang thấy không được tôi biết.

Vấn đề cấp cao nhất: nếu tôi ping một máy bằng Ubuntu, sẽ mất khoảng 5 giây để phản hồi trở lại:

$ ping foo
# khoảng 5 giây trôi qua
PING foo.bar (10.2.1.132) 56(84) byte dữ liệu.
64 byte từ foo.bar (10.2.1.132): icmp_seq=1 ttl=63 time=1,10 ms
64 byte từ foo.bar (10.2.1.132): icmp_seq=2 ttl=63 time=1,02 ms
...

Mà có vẻ như là một vấn đề thời gian chờ rõ ràng. Điều thú vị là nó không giải quyết mặc dù. Đang chạy trạng thái giải quyết cung cấp cho tôi kết quả tiêu chuẩn bao gồm DNS đang được cung cấp bởi hợp đồng thuê DHCP do dnsmasq cấp.

$ trạng thái giải quyết

...
rất nhiều thứ
...

Liên Kết 3 (enp0s25)
      Phạm vi hiện tại: DNS     
Cài đặt DefaultRoute: có     
       Cài đặt LLMNR: có     
Cài đặt MulticastDNS: không      
  Cài đặt DNSOverTLS: không      
      Cài đặt DNSSEC: không      
    DNSSEC được hỗ trợ: không      
         Máy chủ DNS: 10.1.1.1
          Tên miền DNS: ~.      
                      quán ba

Dừng giải quyết và chạy trong chế độ gỡ lỗi dường như cho thấy sự cố. Máy ubuntu truy vấn máy chủ DNS qua IPv4 và nó nhận được câu trả lời ngay lập tức. Sau đó, nó liên tục truy vấn qua IPv6 mà máy chủ DNS phản hồi bằng REFUSED cho đến khi hết thời gian chờ.

$ Sudo systemctl dừng giải quyết systemd
$ Sudo SYSTEMD_LOG_LEVEL=gỡ lỗi /lib/systemd/systemd-resolved
...
rất nhiều đăng nhập khởi động
...
Có gói truy vấn UDP sơ khai DNS cho id 40457
Tra cứu RR cho foo.bar IN A.
Chuyển sang máy chủ DNS 10.1.1.1 cho giao diện enp0s25.
Lỗi bộ nhớ cache cho foo.bar TRONG A
Giao dịch 42924 cho dns phạm vi <foo.bar IN A> trên enp0s25/*.
Sử dụng mức tính năng UDP+EDNS0 cho giao dịch 42924.
Sử dụng máy chủ DNS 10.1.1.1 cho giao dịch 42924.
Đang gửi gói truy vấn có id 42924.
Đang xử lý truy vấn...
Có gói truy vấn UDP sơ khai DNS cho id 59119
Tra cứu RR cho foo.bar TRONG AAAA.
Lỗi bộ nhớ cache cho foo.bar TRONG AAAA
Giao dịch 21734 cho dns phạm vi <foo.bar IN AAAA> trên enp0s25/*.
Sử dụng mức tính năng UDP+EDNS0 cho giao dịch 21734.
Sử dụng máy chủ DNS 10.1.1.1 cho giao dịch 21734.
Đang gửi gói truy vấn có id 21734.
Đang xử lý truy vấn...
Đang xử lý gói tin đến trong giao dịch 42924 (rcode=SUCCESS).
Đã xác minh, chúng tôi nhận được phản hồi ở cấp tính năng UDP+EDNS0 từ máy chủ DNS 10.1.1.1.
Đã thêm mục nhập bộ nhớ cache chưa được xác thực tích cực cho foo.bar IN A 7200s trên enp0s25/INET/10.1.1.1
Giao dịch 42924 cho <foo.bar IN A> trên dns phạm vi trên enp0s25/* hiện đã hoàn tất với <thành công> từ mạng (chưa ký).
Đang gửi gói phản hồi có id 40457 trên giao diện 1/AF_INET.
Giải phóng giao dịch 42924.
Đang xử lý gói đến trong giao dịch 21734 (rcode=REFUSED).
Máy chủ trả về REFUSED, chuyển đổi máy chủ và thử lại.
Thử lại giao dịch 21734.
Lỗi bộ nhớ cache cho foo.bar TRONG AAAA
Giao dịch 21734 cho dns phạm vi <foo.bar IN AAAA> trên enp0s25/*.
Sử dụng mức tính năng UDP+EDNS0 cho giao dịch 21734.
Đang gửi gói truy vấn có id 21734.
Đang xử lý gói đến trong giao dịch 21734 (rcode=REFUSED).
Máy chủ trả về REFUSED, chuyển đổi máy chủ và thử lại.
...
lặp lại trong ~5 giây
...
Giao dịch 44267 cho <foo.bar IN AAAA> trên phạm vi dns trên enp0s25/* hiện đã hoàn tất với <attempts-max-reached> từ mạng (chưa được ký).
Giải phóng giao dịch 44267.

Cũng gợi ý rằng đây là vấn đề:

$ nslookup foo
Máy chủ: 127.0.0.53
Địa chỉ: 127.0.0.53#53

Câu trả lời không có thẩm quyền:
Tên: foo.bar
Địa chỉ: 10.2.1.132
...
khoảng 5 giây trôi qua
...
;; kết nối quá hạn; không thể truy cập máy chủ

# điều này trả lại ngay lập tức
$ nslookup -query=A foo
Máy chủ: 127.0.0.53
Địa chỉ: 127.0.0.53#53

Câu trả lời không có thẩm quyền:
Tên: foo.bar
Địa chỉ: 10.2.1.132

# while this time out in about 5 sec.
$ nslookup -query=AAAA foo
;; kết nối quá hạn; không thể truy cập máy chủ

câu hỏi:

  1. Nếu máy chủ DNS đang cung cấp câu trả lời IPv4 tốt, thì tại sao máy ubuntu lại đợi trong khi liên tục cố gắng không thành công để có được câu trả lời IPv6?

  2. Đây có phải là sự cố cấu hình Ubuntu hay sự cố dnsmasq không?

Cảm ơn trước.

tegtmeye avatar
lá cờ cn
Nhân tiện, tôi thấy ai đó đăng vấn đề tương tự lên danh sách gửi thư của dnsmasq: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013094.html
tegtmeye avatar
lá cờ cn
Một số nội dung bổ sung khiến tôi nghĩ rằng có sự cố với cả tệp đã giải quyết và tệp dsnmasq. Việc dnsmasq trả về REFUSED dường như là một lỗi (xem RFC 4074 "Hành vi sai trái phổ biến đối với truy vấn DNS cho địa chỉ IPv6"). Nếu nó không biết địa chỉ IPv6 là gì, thì nó sẽ trả về một câu trả lời trống theo RFC nhưng có lẽ tôi đang hiểu sai. Điều đó nói rằng, giải quyết không nên liên tục đập vào máy chủ DNS sau khi nó từ chối trả lời bạn. Xem thêm: https://lists.isc.org/pipermail/bind-users/2018-April/100056.html https://bugs.centos.org/view.php?id=16317
Điểm:0
lá cờ jp

Tôi đã gặp chính xác cùng một vấn đề trong khi định cấu hình giải quyết systemddnsmasq.

Đối với câu hỏi của bạn 1, tôi không thể tìm ra lý do tại sao giải quyết systemd truy vấn cho AAAA ghi âm liên tục trong khi không có trả lời từ dnsmasq.

Đối với câu hỏi 2, các dnsmasq không được định cấu hình chính xác để thêm bản ghi cho foo.bar. Bạn chỉ thêm một Một kỷ lục cho tên miền này, trong khi giải quyết systemd truy vấn cho cả hai MộtAAAA ghi cùng một lúc. dnsmasq không có ý tưởng trong AAAA bản ghi cho miền này, do đó, nó sẽ chuyển tiếp truy vấn này tới máy chủ upsteam. Tôi không rõ về những gì sẽ xảy ra tiếp theo nhưng dnsmasq không đưa ra một câu trả lời mong đợi.

Bạn đã không đề cập đến cách bạn cấu hình dnsmasq. Trong thử nghiệm của tôi, mọi cấu hình bên dưới sẽ hoạt động như mong đợi. Lưu ý có sự khác biệt giữa 1 và 2, 3.

  1. địa chỉ=/foo.bar/10.2.1.132/
  2. cục bộ=/thanh/, addn-hosts=/tmp/hosts và thêm 10.2.1.132 foo.bar đến /tmp/máy chủ
  3. máy chủ-record=foo.bar,10.2.1.132cục bộ=/thanh/

Từ dnsmasq trang man cho tùy chọn --địa phương

Cũng được phép là cờ -S cung cấp tên miền nhưng không có địa chỉ IP; điều này cho dnsmasq biết rằng một miền là cục bộ và nó có thể trả lời các truy vấn từ /etc/hosts hoặc DHCP nhưng không bao giờ được chuyển tiếp các truy vấn trên miền đó tới bất kỳ máy chủ ngược dòng nào. --local là một từ đồng nghĩa với --server để làm cho các tệp cấu hình rõ ràng hơn trong trường hợp này.

Đă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.