DNS vừa bắt đầu phân giải địa chỉ server.prod của tôi thành 127.0.53.53

Tôi có máy chủ được đặt tên như thế server.prod.example.com, và tôi thường xuyên đăng nhập vào chúng như server.prod. Gần đây, các tên máy chủ này đã bắt đầu phân giải thành 127.0.53.53.

Hóa ra ICANN gần đây đã kích hoạt .prodTLD. Ngoài ra, mọi yêu cầu gửi đến .prodmáy chủ tên đều được giải quyết thành 127.0.53.53 thay vì quay lại dưới dạng NXDOMAIN, điều này sẽ cho phép độ phân giải tiếp tục hoạt động bình thường. (Tôi đoán vấn đề đằng sau điều này là để mọi người biết rằng công cụ của họ sẽ bị hỏng trước khi những người đó bắt đầu giải quyết vấn đề thực sự.)

Làm thế nào tôi có thể tránh phải nhập tên miền của mình cho mọi máy chủ như thế này?

Điều này vẫn thỉnh thoảng cắn bạn? Tôi không thể tìm thấy danh sách các TLD mới và khi chúng được thêm vào, vì vậy tôi tự thiết lập một danh sách: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
nguồn

Thay đổi này của ICANN cũng đóng vai trò là một lời nhắc tốt rằng việc để các ứng dụng của bạn sử dụng đường dẫn tìm kiếm là xấu. Mặc dù câu hỏi này chắc chắn có giá trị khi đầu vào của người dùng dẫn đến hành vi này, tốt nhất là các ứng dụng của bạn sử dụng các mục nhập tệp máy chủ hoặc chấm FQDN có hậu tố. Ít người nhận ra rằng glibc sẽ không chuyển sang máy chủ tiếp theo cho đến khi hết thời gian thử mọi hậu tố tìm kiếm đã xác định.

— Andrew B

Tôi có thể chỉ mất một chút thời gian để nhắc nhở mọi người rằng đó .prodlà một TLD ngu ngốc . :(

— Cuộc đua nhẹ nhàng với Monica

Câu hỏi của bạn đã trả lời câu hỏi tôi sẽ hỏi, bằng cách nói "ICANN gần đây đã kích hoạt <anything> TLD". Hóa ra tôi đã sử dụng .haus cho mạng LAN của mình và bắt đầu nhận được những thứ này: D Cảm ơn bạn đã hỏi / trả lời :)

— Arno Teigseth

@LightnessRacesinOrbit .prod là một trong nhiều TLD mới của Google. Đổ lỗi cho họ.

— Michael Hampton

@LightnessRacesinOrbit có thể là ngu ngốc nếu bạn nhìn theo cách đó, nhưng đồng thời cũng không tốt khi phụ thuộc vào danh sách tìm kiếm hoặc sử dụng tên không được đăng ký trên toàn cầu, vì bạn sẽ va chạm.

— Patrick Mevzek

Câu trả lời:

Khi bạn thấy các tên miền nội bộ đột nhiên giải quyết cho 127.0.53.53bạn có một tên miền và ICANN đang cố gắng nói với bạn rằng bạn cần sửa chữa cấu hình DNS của mình.
Nếu nó trả về NXDOMAIN như bạn đề xuất, bạn đã đúng, nó sẽ tiếp tục hoạt động - ngay bây giờ .

Nó cũng sẽ rò rỉ truy vấn DNS dự định nội bộ của bạn cho các bên ngoài.

Tệ hơn, trong tương lai ai đó có thể đăng ký server.prodvà khiến bạn gặp nhiều rắc rối hơn.

Xem tại đây để biết thêm thông tin https://icann.org/namecollision hoặc chạy:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

Về cách giải quyết vấn đề này: Phụ thuộc vào trường hợp sử dụng, tôi có thể chỉ cần thêm chúng vào .ssh/configvới các tên ngắn. Hoặc bắt đầu sử dụng FQDN thực sự.

— kẻ giả mạo
nguồn

@MichaelHampton không thực sự, tôi đề nghị chương 5.3 : Train users and system administrators in using FQDNs;)

— mạo

Có, bởi vì tôi thực sự muốn, 20 lần một ngày, nhập ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comthay vì ssh db.

— wfaulk

@wfaulk: Tại sao nó sẽ là một "trò đùa"? Nếu bạn không thích gõ quá nhiều, tại sao bạn lại ám ảnh tránh cơ chế tốt nhất để cho phép tương tác với máy tính tránh gõ quá nhiều? Một số bạn mọt sách Unix chỉ là barmy.

— Cuộc đua nhẹ nhàng với Monica

@Lightness Nói chung vì chúng ta có xu hướng bị hút về phía máy chủ pháo đài. Các lớp phủ công ty của chúng tôi ngày càng ít có khả năng cho phép công nhân của họ chạy Unix trên các thiết bị do công ty phát hành khi năm tháng trôi qua và thời gian được tiết kiệm bằng cách truy cập vào các tập lệnh shell từ điểm truy cập của chúng tôi một cách khéo léo bất cứ điều gì GUI cung cấp . GUI và bảng điều khiển văn bản đều có chung các thói quen xấu liên quan đến chúng. : P

— Andrew B

Đây không phải là nơi để thảo luận về GUI và CLI. Tôi đã đề xuất một giải pháp, nó có thể không phải là tốt nhất cho mọi người và đó là tất cả những gì cần nói.

— mạo

Nếu bạn nhập tên máy chủ không có dấu chấm trong đó, trình phân giải DNS sẽ cố gắng tra cứu tên máy chủ đó bằng cách nối thêm các miền tìm kiếm được định cấu hình vào đó.

Đối với hầu hết các trình phân giải, nếu bạn sử dụng tên máy chủ có ít nhất một dấu chấm trong đó, trước tiên trình phân giải sẽ tự thử tên máy chủ đó và quay lại nối thêm các miền tìm kiếm được định cấu hình.

Nhiều trình phân giải có khả năng thay đổi hành vi của họ để họ nối các miền tìm kiếm cho tên máy chủ có dấu chấm. Điều này thường thông qua một tùy chọn có tên " ndots" cho biết trình phân giải có bao nhiêu dấu chấm mà tên máy chủ phải có trước khi nó tự tìm kiếm tên máy chủ. Để thực hiện server.prodcông việc, hãy thêm dòng này vào resolv.conf:

options ndots:2

Nếu bạn cũng muốn có thể giải quyết server.subzone.prod, bạn sẽ phải đặt tùy chọn thành 3, v.v.

Nếu bất cứ ai biết cách làm cho điều này hoạt động trong MacOS X, xin vui lòng cho tôi biết; thay đổi /etc/resolv.confđược ghi nhận là không hoạt động (và không) và tôi không thể tìm ra scutilcâu thần chú đúng .

(Lưu ý: Tôi bảo hiểm các khoản cược của mình ở đây nhiều hơn có thể được bảo đảm. Tôi tin rằng ndotstùy chọn này sẽ hoạt động trên 99% hệ thống Unix (không phải MacOSX).)

— wfaulk
nguồn

Bạn đang nhầm lẫn thư viện trình phân giải hệ điều hành với BIND. /etc/resolv.confđược sở hữu bởi hệ điều hành. :)

— Andrew B

Hầu hết, nếu không phải tất cả, các trình phân giải hệ điều hành Unix được trích xuất trực tiếp từ các thư viện trình phân giải của BIND, nếu không hoàn toàn sử dụng chúng trực tiếp. Quan điểm của tôi khi gọi BIND là có thể có một số HĐH ngoài đó sử dụng một cái gì đó khác biệt mà sẽ không đáp ứng với tùy chọn "ndots".

— wfaulk

Một tuyên bố như vậy có nhiều khả năng khiến mọi người hiểu lầm rằng bộ giải quyết được thực hiện bởi thư viện chuẩn C có sự phụ thuộc vào các thư viện do ISC cung cấp. Trong trường hợp của glibc, nó chắc chắn là không .

— Andrew B

Đủ công bằng. Đã sửa lỗi để kết hợp rằng nó có thể không hoạt động trong khi không tham chiếu BIND.

— wfaulk

Các câu trả lời khác đã cho bạn giải pháp kỹ thuật cho vấn đề. Nhưng không ai trả lời bạn:

Tôi không thể tìm thấy danh sách các TLD mới và khi chúng được thêm vào

Vì vậy, đây là.

Bạn có nhiều cách khác nhau.

Truy cập trang web IANA tại: https://www.iana.org/domains/root/db ; bạn sẽ thấy danh sách các TLD được ủy quyền hiện tại, đó là các TLD được giải quyết và nằm trong vùng gốc. Nếu bạn nhấp vào bất kỳ cái nào trên chúng, ở phía dưới bạn sẽ có một ngày cho bạn biết khi chúng xuất hiện
Dữ liệu chính xác đó cũng có sẵn whois, ví dụ trong trường hợp của bạn whois -h whois.iana.org prod | grep createdsẽ cung cấp cho bạncreated: 2014-08-23
Có nhiều bot khác nhau trên Twitter / Mastodon đăng khi nội dung IANA thay đổi, xem ví dụ https://twitter.com/ianawhois hoặc https://twitter.com/rootchanges
Dữ liệu IANA có thể chậm hơn một chút trong bản cập nhật, vì vậy cơ sở dữ liệu chính tắc cho gTLD và để xem chúng đang ở giai đoạn nào (bây giờ là một chút ít kể từ vòng ICANN 2012 giới thiệu gTLD mới hầu hết đã kết thúc, nhưng các vòng mới sẽ đến nơi), ở đây: https://gtldresult.icann.org/application-result/applicationstatus ; bạn có thể tìm kiếm bằng TLD. Tất cả các gTLD cũng được yêu cầu một số giai đoạn bắt đầu cụ thể, vì vậy bạn sẽ tìm thấy dữ liệu tại đây: https://newgtlds.icann.org/en/program-status/sunawn-claims- periods bạn có thể xuất tất cả dữ liệu.
Bạn cũng có thể sử dụng dữ liệu ICANN trong JSON: https://www.icann.org/resource/registers/gtlds/v2/gtlds.json

— Patrick Mevzek
nguồn