Điểm:5

Làm cách nào để xác nhận ai chịu trách nhiệm cung cấp dịch vụ DNS ngược (PTR) yêu cầu chặn IP?

lá cờ gb

Trước khi bất kỳ ai trả lời "hỏi ISP của bạn" hoặc "hỏi nhà cung cấp dịch vụ lưu trữ của bạn", vui lòng đọc toàn bộ.

Kịch bản:

  • Tôi sở hữu một tên miền mydomain.examplevà một khối IP được định tuyến công khai (giả sử 192.0.2.0/28)
  • Bản ghi NS (GLUE) cho miền này được định cấu hình tại công ty đăng ký tên miền của tôi - ns1.mydomain.examplens2.mydomain.example trỏ đến máy chủ của tôi (máy chủ DNS tự lưu trữ)
  • Đảo ngược DNS cho tôi khối IP được định tuyến công khai được phục vụ bởi cùng một máy chủ Điều này là để tôi có thể cập nhật các mục nhập dns đảo ngược cho các IP của mình một cách thoải mái trên thiết bị của mình.

Vấn đề: Tôi đã di chuyển dịch vụ lưu trữ DNS cho miền của mình (mydomain.example) từ máy chủ của riêng tôi sang cloudflare, quyết định rằng việc tự lưu trữ nó là không đáng. Tôi đã thực hiện điều này nhiều lần trước đây với các thiết lập giống hệt nhau và không gặp phải tác dụng phụ nào.

Tuy nhiên, khi các bản ghi NS được cập nhật lên cloudflare, tôi thấy DNS đảo ngược của mình hoàn toàn ngừng hoạt động.

Câu hỏi: Điều gì/ai xác định ai đang trả lời các truy vấn DNS ngược cho khối IP của tôi? Theo hiểu biết của tôi, thông thường, DNS chuyển tiếp và DNS ngược được thực hiện độc lập với nhau, vì vậy tôi không mong đợi việc di chuyển các máy chủ định danh tra cứu chuyển tiếp từ cơ sở hạ tầng tự lưu trữ -> cloudflare sang tra cứu DNS ngược.

Tôi hiểu rằng thực thể trả lời dns chuyển tiếp của bạn (cloudflare) độc lập với thực thể trả lời DNS ngược của bạn (ví dụ: nhà cung cấp dịch vụ lưu trữ của bạn, ISP, v.v.). Nhưng, làm sao tôi có thể khẳng định ai là người thực sự chịu trách nhiệm cho việc này - như tôi sẽ làm cho DNS chuyển tiếp của mình? tôi có thể làm một % đào +tên miền ngắn của tôi.ví dụ NS để xác nhận máy chủ nào chịu trách nhiệm cho các truy vấn DNS chuyển tiếp, quy trình tìm ra ai chịu trách nhiệm cho DNS ngược của (các) địa chỉ IP mà tôi đang sử dụng là gì?

Điểm:6
lá cờ cv

Nếu địa chỉ ip của bạn là 192.0.2.4 và bạn đang sử dụng nslookup, bạn sẽ chạy như sau:

đặt q=ns

4.2.0.192.in-addr.arpa

Điều này sẽ cho bạn thấy các máy chủ định danh chịu trách nhiệm về khối địa chỉ ip mà địa chỉ ip của bạn tồn tại.

lá cờ mx
Bản ghi NS thường không tồn tại cho các IP riêng lẻ. Nó chỉ nên là `2.0.192.in-addr.arpa`. Hoặc sử dụng `dig +trace -x 192.0.2.4`
joeqwerty avatar
lá cờ cv
@Barmar Bạn đã sử dụng nslookup theo cách tôi mô tả chưa? Nếu không, hãy thử xem. Sử dụng "đặt gỡ lỗi" để xem thông tin chi tiết cho truy vấn.
lá cờ mx
`** máy chủ không thể tìm thấy 4.2.0.192.in-addr.arpa: NXDOMAIN`
lá cờ mx
Có vẻ như khối địa chỉ này không được ủy quyền.
joeqwerty avatar
lá cờ cv
Đó là một địa chỉ IP mẫu để sử dụng trong tài liệu. Sử dụng địa chỉ ip của bạn. - https://datatracker.ietf.org/doc/html/rfc5737
Điểm:2
lá cờ jp

Giải pháp cho vấn đề của bạn:

Trong trường hợp này, tôi không nghĩ vấn đề là do bản ghi PTR của bạn, mà là do cách thức hoạt động của hệ thống Reverse Proxy của Cloudflare. Nếu tên miền của bạn đang sử dụng proxy của Cloudflare, thì nó không thực sự trỏ đến máy chủ của bạn nữa.

giải pháp là tắt proxy của Cloudflare cho các miền/miền phụ nơi đặt máy chủ thư.

Trả lời cho câu hỏi của bạn:

Các truy vấn DNS và rDNS xảy ra riêng biệt nhưng truy vấn DNS xảy ra trước để xác định IP nào sẽ truy vấn rDNS/PTR. Trong trường hợp này, Cloudflare về cơ bản đang thay thế IP của bạn trong phản hồi DNS bằng IP của chính họ, đây là nguyên nhân gây ra sự cố.

Ví dụ, nếu bạn có mydomain.examplevà cài đặt DNS Cloudflare của bạn là bản ghi A trỏ đến 192.0.2.1 với Proxy được bật, thì miền thực sự đang trỏ đến máy chủ của Cloudflare, sau đó máy chủ này sẽ chuyển tiếp lưu lượng truy cập đến máy chủ của bạn.Tuy nhiên, điều này có nghĩa là tra cứu PTR sẽ truy vấn máy chủ của Cloudflare chứ không phải máy chủ của bạn, máy chủ này sẽ báo cáo không có bản ghi nào:

⯠đào proxy.mydomain.example # Máy chủ thư từ xa truy vấn bản ghi A của miền được ủy quyền.
;; PHẦN CÂU HỎI:
;proxy.mydomain.example. TRONG MỘT
;; PHẦN TRẢ LỜI:
proxy.mydomain.example. 300 TRONG MỘT 104.21.30.252 # Máy chủ Cloudflare
proxy.mydomain.example. 300 TRONG MỘT 172.67.174.61 # Máy chủ Cloudflare
⯠Dig -x 104.21.30.252 # Máy chủ thư từ xa kiểm tra PTR/rDNS của cả hai IP (Đây là từ IP Cloudflare thực)
;; PHẦN CÂU HỎI:
;252.30.21.104.in-addr.arpa. TRONG PTR
;; PHẦN THẨM QUYỀN:
21.104.in-addr.arpa. 3600 TRONG SOA cruz.ns.cloudflare.com. dns.cloudflare.com. 2034580120 10000 2400 604800 3600 
# Máy chủ không trả về bản ghi PTR, vì đó là máy chủ của Cloudflare đang được truy vấn.

Nếu bạn tắt tính năng ủy quyền của Cloudflare cho bản ghi DNS của máy chủ thư, nó sẽ giống như thế này:

⯠đào unproxied.mydomain.example # Máy chủ thư từ xa truy vấn bản ghi A của miền không được ủy quyền.
;; PHẦN CÂU HỎI:
;unproxied.mydomain.example. TRONG MỘT
;; PHẦN TRẢ LỜI:
unproxied.mydomain.example. 300 IN A 192.0.2.1 # Máy chủ DNS trả về IP của máy chủ của bạn.
⯠Dig -x 192.0.2.1 # Máy chủ thư truy vấn máy chủ CỦA BẠN cho PTR.
;; PHẦN CÂU HỎI:
;117.8.209.209.in-addr.arpa. TRONG PTR
;; PHẦN TRẢ LỜI:
117.8.209.209.in-addr.arpa. 86400 TRONG PTR không được ủy quyền.mydomain.example.
# PTR trả về giá trị đúng.

(Xin lưu ý rằng tôi đã bỏ qua tra cứu MX/SPF/DKIM/DMARC trong phản hồi này, vì theo như tôi biết thì Cloudflare không gây rối với những tra cứu đó trừ khi bạn trỏ bản ghi của mình tới bản ghi A/AAAA/CNAME được ủy quyền .)

rgb255_255_255 avatar
lá cờ gb
Xin chào, cảm ơn vì đã phản hồi nhưng đây không phải là vấn đề của tôi, vì việc tra cứu bản ghi PTR được thực hiện trên chính IP đó chứ không phải IP proxy của cloudflare. Ngoài ra, tôi không sử dụng ủy quyền đám mây cho bất kỳ thứ gì, tại thời điểm này, tôi chỉ sử dụng nó để lưu trữ các bản ghi DNS của mình.

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