Máy chủ DNS 2012R2 trả về SERVFAIL cho một số truy vấn AAAA


17

(Viết lại hầu hết câu hỏi này vì rất nhiều bài kiểm tra ban đầu của tôi không liên quan đến thông tin mới)

Tôi đang gặp sự cố với máy chủ DNS Server 2012R2. Tác dụng phụ lớn nhất của những vấn đề này là các email Exchange không được xử lý. Trao đổi truy vấn cho hồ sơ AAAA trước khi thử bản ghi A. Khi nó thấy SERVFAIL cho bản ghi AAAA, nó thậm chí không thử bản ghi A, nó chỉ bỏ cuộc.

Đối với một số tên miền, khi truy vấn các máy chủ DNS thư mục hoạt động của tôi, tôi nhận được SERVFAIL thay vì NOERROR mà không có kết quả.

Tôi đã thử điều này từ một số bộ điều khiển miền Server 2012R2 khác nhau đang chạy DNS. Một trong số đó là một miền hoàn toàn riêng biệt, trên một mạng khác đằng sau một tường lửa và kết nối internet khác.

Hai địa chỉ mà tôi biết gây ra vấn đề này là smtpgw1.gov.on.camxmta.owm.bell.net

Tôi đã sử dụng digtrên máy linux để kiểm tra điều này (192.168.5.5 là bộ điều khiển miền của tôi):

grant@linuxbox:~$ dig @192.168.5.5 smtpgw1.gov.on.ca -t AAAA

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.5.5 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56328
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;smtpgw1.gov.on.ca.             IN      AAAA

;; Query time: 90 msec
;; SERVER: 192.168.5.5#53(192.168.5.5)
;; WHEN: Wed Oct 21 14:09:10 EDT 2015
;; MSG SIZE  rcvd: 46

Nhưng các truy vấn đối với bộ điều khiển miền công cộng hoạt động như mong đợi:

grant@home-ssh:~$ dig @4.2.2.1 smtpgw1.gov.on.ca -t AAAA

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @4.2.2.1 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;smtpgw1.gov.on.ca.             IN      AAAA

;; Query time: 136 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Wed Oct 21 14:11:19 EDT 2015
;; MSG SIZE  rcvd: 46

Như tôi đã nói, tôi đã thử điều này trên hai mạng và miền khác nhau. Một là một tên miền hoàn toàn mới, chắc chắn có tất cả các cài đặt mặc định cho DNS. Cái khác đã được chuyển sang Server 2012, vì vậy một số cài đặt cũ từ 2003/2008 có thể đã được chuyển sang. Tôi nhận được kết quả tương tự trên cả hai.

Vô hiệu hóa EDNS với dmscnd /config /enableednsprobes 0sửa lỗi nó. Tôi thấy nhiều kết quả tìm kiếm về EDNS là một vấn đề trong Server 2003, nhưng không phù hợp với những gì tôi thấy trong Server 2012. Cả tường lửa đều có vấn đề với EDNS. Việc vô hiệu hóa EDNS chỉ là một cách giải quyết tạm thời - nó ngăn chặn việc sử dụng DNSSEC và có thể gây ra các vấn đề khác.

Tôi cũng đã thấy một số bài đăng về các sự cố với Server 2008R2 và EDNS, nhưng những bài đăng tương tự nói rằng mọi thứ đã được sửa trong Server 2012, vì vậy nó sẽ hoạt động tốt.

Tôi cũng đã thử kích hoạt nhật ký gỡ lỗi cho DNS. Tôi có thể thấy các gói mà tôi mong đợi, nhưng nó không cung cấp cho tôi nhiều thông tin chi tiết về lý do tại sao nó trả lại SERVFAIL. Dưới đây là các phần có liên quan của nhật ký gỡ lỗi máy chủ DNS:

Gói đầu tiên - truy vấn từ máy khách đến máy chủ DNS của tôi

16/10/2015 9:42:29 AM 0974 GÓI 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) trên (2) ca (0)
Thông tin câu hỏi UDP tại 000000EFF1BF01A0
  Ổ cắm = 508
  Addr từ xa 172.16.0.254, cổng 50764
  Truy vấn thời gian = 4556080, Xếp hàng = 0, Hết hạn = 0
  Chiều dài của buf = 0x0fa0 (4000)
  Chiều dài Msg = 0x002e (46)
  Thông điệp:
    XID 0xa61e
    Cờ 0x0120
      QR 0 (CÂU HỎI)
      OPCODE 0 (NHIỀU)
      Ôi 0
      TC 0
      RD 1
      RA 0
      Z 0
      CD 0
      QUẢNG CÁO 1
      RCODE 0 (NOERROR)
    TÀI KHOẢN 1
    KHOẢN 0
    NSCOUNT 0
    TÀI KHOẢN 1
    PHẦN CÂU HỎI:
    Offset = 0x000c, số RR = 0
    Tên "(7) smtpgw1 (3) gov (2) trên (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    TRẢ LỜI
      trống
    PHẦN TỰ ĐỘNG:
      trống
    PHẦN BỔ SUNG:
    Offset = 0x0023, số RR = 0
    Tên "(0)"
      LOẠI TÙY CHỌN (41)
      LỚP 4096
      0 0
      DLEN 0
      DỮ LIỆU   
        Kích thước bộ đệm = 4096
        Mã số Ext = 0
        Mã đầy đủ = 0
        Phiên bản = 0
        Cờ = 0

Gói thứ hai - truy vấn từ máy chủ DNS của tôi đến máy chủ DNS của họ

16/10/2015 9:42:29 AM 0974 GÓI 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) trên (2) ca (0)
Thông tin câu hỏi UDP tại 000000EFF0A22160
  Ổ cắm = 9812
  Addr từ xa 204.41.8.237, cổng 53
  Truy vấn thời gian = 0, xếp hàng = 0, hết hạn = 0
  Chiều dài của buf = 0x0fa0 (4000)
  Chiều dài Msg = 0x0023 (35)
  Thông điệp:
    XID 0x3e6c
    Cờ 0x0000
      QR 0 (CÂU HỎI)
      OPCODE 0 (NHIỀU)
      Ôi 0
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      QUẢNG CÁO 0
      RCODE 0 (NOERROR)
    TÀI KHOẢN 1
    KHOẢN 0
    NSCOUNT 0
    TÀI KHOẢN 0
    PHẦN CÂU HỎI:
    Offset = 0x000c, số RR = 0
    Tên "(7) smtpgw1 (3) gov (2) trên (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    TRẢ LỜI
      trống
    PHẦN TỰ ĐỘNG:
      trống
    PHẦN BỔ SUNG:
      trống

Gói thứ ba - phản hồi từ máy chủ DNS của họ (NOERROR)

16/10/2015 9:42:29 AM 0974 GÓI 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) trên (2) ca (0)
Thông tin phản hồi UDP tại 000000EFF2188100
  Ổ cắm = 9812
  Addr từ xa 204.41.8.237, cổng 53
  Truy vấn thời gian = 4556080, Xếp hàng = 0, Hết hạn = 0
  Chiều dài của buf = 0x0fa0 (4000)
  Chiều dài Msg = 0x0023 (35)
  Thông điệp:
    XID 0x3e6c
    Cờ 0x8400
      QR 1 (TRẢ LỜI)
      OPCODE 0 (NHIỀU)
      1
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      QUẢNG CÁO 0
      RCODE 0 (NOERROR)
    TÀI KHOẢN 1
    KHOẢN 0
    NSCOUNT 0
    TÀI KHOẢN 0
    PHẦN CÂU HỎI:
    Offset = 0x000c, số RR = 0
    Tên "(7) smtpgw1 (3) gov (2) trên (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    TRẢ LỜI
      trống
    PHẦN TỰ ĐỘNG:
      trống
    PHẦN BỔ SUNG:
      trống

Gói thứ tư - phản hồi từ máy chủ DNS của tôi đến máy khách (SERVFAIL)

16/10/2015 9:42:29 AM 0974 GÓI 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) trên (2) ca (0)
Thông tin phản hồi UDP tại 000000EFF1BF01A0
  Ổ cắm = 508
  Addr từ xa 172.16.0.254, cổng 50764
  Truy vấn thời gian = 4556080, Xếp hàng = 4556080, Hết hạn = 4556083
  Chiều dài của buf = 0x0fa0 (4000)
  Chiều dài Msg = 0x002e (46)
  Thông điệp:
    XID 0xa61e
    Cờ 0x8182
      QR 1 (TRẢ LỜI)
      OPCODE 0 (NHIỀU)
      Ôi 0
      TC 0
      RD 1
      RA 1
      Z 0
      CD 0
      QUẢNG CÁO 0
      RCODE 2 (PHỤC VỤ)
    TÀI KHOẢN 1
    KHOẢN 0
    NSCOUNT 0
    TÀI KHOẢN 1
    PHẦN CÂU HỎI:
    Offset = 0x000c, số RR = 0
    Tên "(7) smtpgw1 (3) gov (2) trên (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    TRẢ LỜI
      trống
    PHẦN TỰ ĐỘNG:
      trống
    PHẦN BỔ SUNG:
    Offset = 0x0023, số RR = 0
    Tên "(0)"
      LOẠI TÙY CHỌN (41)
      LỚP 4000
      0 0
      DLEN 0
      DỮ LIỆU   
        Kích thước bộ đệm = 4000
        Mã số Ext = 0
        Mã đầy đủ = 2
        Phiên bản = 0
        Cờ = 0

Những điều khác cần lưu ý:

  • Một trong các mạng có truy cập internet IPv6 riêng, mạng còn lại thì không (nhưng ngăn xếp IPv6 được bật trên các máy chủ có cài đặt mặc định). Dường như không phải là sự cố mạng IPv6
  • Nó không ảnh hưởng đến tất cả các tên miền. Ví dụ dig @192.168.5.5 -t AAAA serverfault.comtrả về NOERROR và không có kết quả. Điều tương tự để google.comtrả về địa chỉ IPv6 của google đúng cách.
  • Đã thử cài đặt hotfix từ KB3014171 , không có sự khác biệt.
  • Bản cập nhật từ KB3004539 đã được cài đặt.

Chỉnh sửa ngày 7 tháng 11 năm 2015

Tôi đã thiết lập một máy chủ không thuộc miền khác đã tham gia Máy chủ 2012R2 và đã cài đặt vai trò máy chủ DNS và đã thử nghiệm bằng lệnh nslookup -type=aaaa smtpgw1.gov.on.ca localhost. Nó KHÔNG có cùng một vấn đề.

Cả hai máy ảo đều trên cùng một máy chủ và cùng một mạng, do đó loại bỏ mọi sự cố mạng / tường lửa. Bây giờ, nó xuống mức vá hoặc là một thành viên miền / bộ điều khiển miền tạo ra sự khác biệt.

Chỉnh sửa ngày 8 tháng 11 năm 2015

Áp dụng tất cả các cập nhật, không có sự khác biệt. Đã kiểm tra kỹ xem có sự khác biệt nào về cấu hình giữa máy chủ thử nghiệm mới của tôi và cài đặt DNS của bộ điều khiển miền của tôi không và có - bộ điều khiển miền đã thiết lập chuyển tiếp.

Bây giờ, tôi chắc chắn rằng tôi đã thử với các giao nhận và không có trong các thử nghiệm ban đầu của mình, nhưng tôi chỉ thử nó bằng digmáy linux. Tôi nhận được kết quả hơi khác nhau khi có và không có thiết lập chuyển tiếp (đã thử với Google, OpenDNS, 4.2.2.1 và máy chủ DNS ISP của tôi) khi tôi sử dụng nslookup trên máy tính windows.

Với một bộ chuyển tiếp, tôi nhận được Server failed.

Không có giao nhận (vì vậy nó sử dụng máy chủ DNS gốc), tôi nhận được No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Nhưng điều đó vẫn không giống với những gì tôi nhận được cho các tên miền khác không có bản ghi IPv6 - nslookup trên windows chỉ trả về kết quả cho các tên miền khác.

Có hoặc không có chuyển tiếp, digvẫn hiển thị SERVFAILtên đó khi truy vấn máy chủ DNS windows của tôi.

Có một sự khác biệt nhỏ giữa miền vấn đề và các miền khác có vẻ phù hợp, ngay cả khi tôi không liên quan đến máy chủ DNS windows của mình:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca không có câu trả lời, và không có phần thẩm quyền.

dig -t aaaa @8.8.8.8 serverfault.comtrả về không có câu trả lời, nhưng có một phần thẩm quyền. Vì vậy, hầu hết các tên miền khác tôi thử, bất kể tôi sử dụng trình phân giải nào.

Vậy tại sao phần thẩm quyền đó bị thiếu và tại sao máy chủ DNS của Windows coi nó là một lỗi khi các máy chủ DNS khác không có?


Bạn đang thực hiện các thử nghiệm này từ máy chủ Exchange? Nếu không, tôi khuyên bạn nên làm điều đó để bạn có thể thấy nó từ quan điểm của Exchange. Bạn cũng có thể muốn thử chạy SMTPDiag từ máy chủ Exchange. Tôi khuyên bạn nên chạy nó trong khi thực hiện chụp mạng trên máy chủ Exchange để bạn có thể xem chi tiết về hoạt động của mạng / DNS. SMTPDiag là một công cụ cũ, nhưng nó là một công cụ dòng lệnh không yêu cầu cài đặt, vì vậy tôi nghĩ rằng nó nên hoạt động trên tất cả các phiên bản của Exchange. - microsoft.com/en-us/doad/details.aspx?id=11393
joeqwerty

Một số thiết bị mạng không nhận ra và sẽ từ chối các gói EDNS. Nhóm mạng của bạn đã giới thiệu thiết bị / cài đặt mới gần đây? Để loại bỏ khả năng này, hãy thử giải quyết bản ghi AAAA của google.com, nó sẽ trả về địa chỉ IPv6.
mạnh

@strongline gói EDNS đi qua tốt. Bản ghi AAAA cho google hoạt động, cũng như một vài trang web khác mà tôi biết có IPv6 đang chạy. Chỉ có cơ hội được thực hiện gần đây là thoát khỏi máy chủ DC / DNS Server 2008R2 cuối cùng của chúng tôi và thay thế bằng 2012R2.
Cấp

IPv6 có bị vô hiệu hóa theo bất kỳ cách nào trong môi trường của bạn không?
Jim B

@JimB không thực sự được kích hoạt cũng không bị vô hiệu hóa ... Ngăn xếp IPv6 đang chạy trên các máy chủ, bởi vì nó được bật theo mặc định, với bất kỳ cấu hình mặc định nào. Cổng và kết nối internet không có IPv6 gì.
Cấp

Câu trả lời:


3

Tôi đã nhìn vào mạng một số chi tiết và đọc một số. Yêu cầu cho bản ghi AAAA, khi không tồn tại, trả về một SOA. Hóa ra, SOA dành cho một miền khác đang được yêu cầu. Tôi nghi ngờ đó là lý do tại sao Windows từ chối phản hồi. Yêu cầu AAAA cho mx.atom Worldwide.com. Phản hồi SOA cho lgfl.org.uk. Tôi sẽ xem liệu chúng ta có thể đạt được một số tiến bộ với thông tin này. EDIT: Chỉ để tham khảo trong tương lai, tạm thời tắt "Bộ nhớ cache an toàn chống ô nhiễm" sẽ cho phép truy vấn thành công. Không lý tưởng, nhưng chứng minh vấn đề là với một bản ghi DNS tinh ranh. RFC4074 cũng là một tài liệu tham khảo tốt - Giới thiệu và Phần.


Tôi sẽ cố gắng thử nghiệm điều này ngày hôm nay trong môi trường của tôi, nhưng tôi nghĩ bạn có thể đang ở một cái gì đó!
Cấp

Ngoài ra tôi đã chỉnh sửa liên kết của bạn - chữ ký và liên kết ngoài chủ đề không được phép ở đây và tôi không muốn thấy câu trả lời xuất sắc của bạn bị xóa cho nó.
Cấp

0

Theo KB832223

Nguyên nhân

Sự cố này xảy ra do chức năng Cơ chế mở rộng cho DNS (EDNS0) được hỗ trợ trong Windows Server DNS.

EDNS0 cho phép kích thước gói lớn hơn Giao thức gói dữ liệu người dùng (UDP). Tuy nhiên, một số chương trình tường lửa có thể không cho phép các gói UDP lớn hơn 512 byte. Do đó, các gói DNS này có thể bị chặn bởi tường lửa.

Microsoft có độ phân giải sau:

Nghị quyết

Để giải quyết vấn đề này, hãy cập nhật chương trình tường lửa để nhận biết và cho phép các gói UDP lớn hơn 512 byte. Để biết thêm thông tin về cách thực hiện việc này, hãy liên hệ với nhà sản xuất chương trình tường lửa của bạn.

Microsoft có đề xuất sau đây để khắc phục sự cố:

Cách giải quyết

Để khắc phục sự cố này, hãy tắt tính năng EDNS0 trên các máy chủ DNS dựa trên Windows. Để làm điều này, hãy thực hiện hành động sau:

Tại dấu nhắc lệnh, nhập lệnh sau, rồi nhấn Enter:

dnscmd /config /enableednsprobes 0

Lưu ý Nhập 0 (không) và không phải chữ "O" sau "enableednsprobes" trong lệnh này.


Tôi đã thấy bài viết này - các tường lửa tôi đã thử nghiệm với cả hai vượt qua gói dns lớn mà không có vấn đề gì, bằng chứng là nó hoạt động hoàn hảo trên linux. Vô hiệu hóa edns ngăn chặn việc sử dụng DNSSEC, vì vậy mặc dù nó khắc phục vấn đề nhưng đó không phải là một giải pháp tốt.
Cấp

xin lỗi tôi đã không nhận ra rằng hướng dẫn của Microsoft cũng sẽ áp dụng cho Linux. Ra khỏi tò mò, làm bạn có bất kỳ hệ điều hành của Microsoft đang làm việc thông qua các bức tường lửa?
Tim Penner
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.