Mất bao lâu để bản ghi DNS lan truyền?


68

Đây là một câu hỏi Canonical về tuyên truyền DNS

Mất bao lâu để một loại hồ sơ khác nhau được tuyên truyền?
Làm một số tuyên truyền nhanh hơn những người khác?
Tại sao phải mất thời gian để bản ghi DNS lan truyền và nó hoạt động như thế nào?


1
Lưu ý: Trong lịch sử có một sự khác biệt đáng chú ý và đáng kể về thời gian cần thiết để cập nhật các loại hồ sơ khác nhau (tùy thuộc vào người giữ chúng và như vậy). Điều này không còn là trường hợp ngày nay.
Chris S

4
Khi ppl sử dụng từ "tuyên truyền" cho DNS, nó cho thấy rõ ràng họ không biết DNS là gì và hoạt động như thế nào. Chúng ta hãy hy vọng tài liệu sẽ "tuyên truyền" đủ nhanh (bắt chéo ngón tay).
poige

3
@tonygil Xin vui lòng xem bình luận của Poige. Không có những thứ như tuyên truyền dns. Ngoài ra, ISP không kiểm soát các máy chủ gốc. Nếu các máy chủ DNS của các ISP đó lưu trữ lâu hơn so với TTL của bản ghi thì chúng vi phạm RFC. Bạn dường như có một số hiểu lầm với cách DNS hoạt động; nhưng vi phạm RFC thường sẽ phá vỡ cách thức hoạt động của nó. Điều này không liên quan gì đến Mỹ hay Châu Âu.
Chris S

1
@tonygil: "cyberpolice" để "thực hiện" cập nhật chúng là tất cả các hệ thống, quản trị mạng, v.v., gây áp lực xã hội lên các diễn viên xấu. Internet hoạt động vì tất cả chúng ta đồng ý rằng nó nên. Lợi ích tốt nhất của người dùng, mạng, v.v. của chúng tôi nằm ở "lợi ích tốt nhất" của Internet. re: "người dùng không phải là Technogurus" - Đây là trang dành cho quản trị viên hệ thống chuyên nghiệp và không phải người dùng cuối. Thành thật mà nói, tôi hy vọng sysadins là một loại "technoguru" (sử dụng thuật ngữ của bạn). Quản trị hệ thống được , bởi nghề nghiệp, nghĩa vụ phải chăm sóc như thế nào công cụ này hoạt động.
Evan Anderson

@EvanAnderson tôi hoàn toàn đồng ý rằng áp lực tạo ra sự thay đổi. mặt khác, thực tế là các sysadin lười biếng hoặc bất tài đang ở ngoài kia. và bạn càng di chuyển từ chúng tôi và châu Âu, họ càng trở nên thường xuyên hơn. kỳ vọng của bạn là tốt 4 Mỹ nhưng chúng không khả thi ở hầu hết các nơi trong thế giới thực, nơi các hệ thống không chuẩn bị là quy tắc. Vì vậy, trong khi bạn mong đợi mọi thứ sẽ ổn, bạn shoulkd đối phó với thế giới thực, nơi họ KHÔNG. Dù sao, đã đưa ra quan điểm của tôi, bạn đã thực hiện của bạn. hãy để chúng tôi đồng ý không đồng ý.
tony gil

Câu trả lời:


71

"Sự lan truyền DNS" không phải là một hiện tượng thực sự. Thay vào đó, đó là hiệu ứng rõ ràng của chức năng lưu trữ được chỉ định trong giao thức DNS. Nói rằng thay đổi "lan truyền" giữa các máy chủ DNS là một sai lầm thuận tiện, có thể nói là dễ giải thích hơn cho người dùng không có kỹ thuật so với mô tả tất cả các chi tiết của giao thức DNS. Đó thực sự không phải là cách giao thức hoạt động.

Máy chủ DNS đệ quy thực hiện các truy vấn thay mặt cho khách hàng. Các máy chủ DNS đệ quy, thường được điều hành bởi các ISP hoặc bộ phận CNTT, được sử dụng bởi các máy khách để phân giải tên của các tài nguyên Internet. Các máy chủ DNS đệ quy lưu trữ kết quả của các truy vấn mà chúng thực hiện để cải thiện hiệu quả. Các truy vấn cho thông tin đã được lưu trong bộ nhớ cache có thể được trả lời mà không cần thực hiện bất kỳ truy vấn bổ sung nào. Thời lượng, tính bằng giây, kết quả được lưu trong bộ nhớ cache được cho là dựa trên giá trị có thể định cấu hình được gọi là Thời gian sống (TTL). Giá trị này được chỉ định bởi máy chủ DNS có thẩm quyền đối với bản ghi được truy vấn.

Không có câu trả lời cho tất cả các câu hỏi đang được hỏi vì DNS là giao thức phân tán. Hành vi của DNS phụ thuộc vào cấu hình của máy chủ DNS có thẩm quyền đối với bản ghi đã cho, cấu hình của máy chủ DNS đệ quy thực hiện truy vấn thay cho máy khách và chức năng lưu trữ bộ đệm DNS tích hợp vào hệ điều hành của máy khách.

Cách tốt nhất là chỉ định một giá trị TTL đủ ngắn để phù hợp với các thay đổi hàng ngày đối với các bản ghi DNS, nhưng đủ lâu để tạo ra một "chiến thắng" trong bộ nhớ đệm (tức là không quá nhanh để hết bộ nhớ cache quá nhanh cung cấp bất kỳ cải thiện hiệu quả). Sử dụng chiến lược cân bằng với các giá trị TTL sẽ mang lại "chiến thắng" cho mọi người. Nó giảm cả việc sử dụng tải và băng thông cho các máy chủ DNS có thẩm quyền cho một miền nhất định, máy chủ gốc và máy chủ TLD. Nó làm giảm việc sử dụng băng thông ngược dòng cho người vận hành máy chủ DNS đệ quy. Nó dẫn đến phản hồi truy vấn nhanh hơn cho các máy khách.

Vì bản ghi DNS của TTL được đặt tải thấp hơn và việc sử dụng băng thông trên các máy chủ DNS có thẩm quyền sẽ tăng lên vì các máy chủ DNS đệ quy sẽ không thể lưu trữ kết quả trong một thời gian dài. Vì bản ghi của TTL là các thay đổi cao hơn đối với các bản ghi sẽ không xuất hiện để "có hiệu lực" nhanh chóng vì các máy khách sẽ tiếp tục nhận được kết quả được lưu trong bộ nhớ cache trên các máy chủ DNS đệ quy của chúng. Việc thiết lập TTL tối ưu đi đến hành động cân bằng giữa việc sử dụng và khả năng thay đổi hồ sơ nhanh chóng và xem những thay đổi được phản ánh trên máy khách.

Điều đáng chú ý là một số ISP bị lạm dụng và bỏ qua các giá trị TTL được chỉ định bởi các máy chủ DNS có thẩm quyền (thay thế ghi đè quản trị của chính họ, đó là vi phạm RFC). Không có gì để làm về điều này, từ góc độ kỹ thuật. Nếu các nhà khai thác máy chủ DNS lạm dụng có thể bị khiếu nại đối với các quản trị viên hệ thống của họ, điều đó có thể dẫn đến việc thực hiện các thực tiễn tốt nhất của họ (có thể hiểu là mức độ thông thường đối với bất kỳ kỹ sư mạng nào quen thuộc với DNS). Loại lạm dụng đặc biệt này không phải là một vấn đề kỹ thuật.

Nếu mọi người "chơi theo luật" thay đổi bản ghi DNS có thể "có hiệu lực" rất nhanh. Ví dụ, trong trường hợp thay đổi địa chỉ IP được gán cho bản ghi "A", việc sao lưu theo cấp số nhân của giá trị TTL sẽ được thực hiện, dẫn đến thời gian thay đổi sẽ được thực hiện. Chẳng hạn, TTL có thể bắt đầu sau 1 ngày và giảm xuống còn 12 giờ trong khoảng thời gian 24 giờ, sau đó 6 giờ trong khoảng thời gian 12 giờ, 3 giờ trong khoảng thời gian 6 giờ, v.v., xuống một khoảng nhỏ phù hợp. Khi TTL đã được sao lưu, bản ghi có thể được thay đổi và TTL mang lại giá trị mong muốn cho các hoạt động hàng ngày. (Không cần thiết phải sử dụng dự phòng theo cấp số nhân, tuy nhiên chiến lược này giảm thiểu thời gian bản ghi sẽ có chỉ số TTL thấp và giảm tải trên máy chủ DNS có thẩm quyền.)

Sau khi thực hiện một bản ghi thay đổi bản ghi DNS nên được theo dõi cho các nỗ lực truy cập được thực hiện do kết quả của bản ghi DNS cũ. Trong ví dụ về việc thay đổi bản ghi "A" để chỉ địa chỉ IP mới, máy chủ sẽ vẫn hiện diện tại địa chỉ IP cũ để xử lý các nỗ lực truy cập do máy khách vẫn sử dụng bản ghi "A" cũ. Khi các nỗ lực truy cập dựa trên hồ sơ cũ đã đạt đến mức thấp chấp nhận được, địa chỉ IP cũ có thể bị vô hiệu hóa. Nếu các yêu cầu liên quan đến một bản ghi cũ không giảm đi nhanh chóng thì có thể (như được mô tả ở trên), một máy chủ DNS đệ quy sẽ bỏ qua TTL có thẩm quyền. Tuy nhiên, biết địa chỉ IP nguồn của một lần truy cập, tuy nhiên, không cung cấp thông tin trực tiếp cho máy chủ DNS đệ quy chịu trách nhiệm cung cấp bản ghi cũ.

Cá nhân, tôi đã thấy những thay đổi "có hiệu lực" ngay lập tức, trong vài giờ và trong một số trường hợp với một ISP bị tổn thương não cụ thể, sau vài ngày. Thực hiện một backback của TTL của bạn và chú ý đến cách quá trình hoạt động sẽ tăng sự thay đổi của bạn để thành công, nhưng bạn không bao giờ chắc chắn một số kẻ ngốc có ý nghĩa tốt có thể làm gì với các máy chủ DNS đệ quy của họ.


9
Đây không phải là câu trả lời về "OpenDNS" - đó là câu trả lời về DNS. Bất kỳ nhà cung cấp DNS đệ quy nào cũng có thể thực hiện bất kỳ giao diện nào họ muốn cho phép xóa bộ nhớ cache, v.v. Chúng tôi đang nói về DNS - không phải về API của nhà cung cấp. Trong chừng mực các chỉnh sửa của bạn: Tôi đang đứng trước cụm từ "hại não" là cụm từ được sử dụng từ lâu trong văn hóa hacker và tôi đang sử dụng nó trong bối cảnh đó (xem Tệp Jargon, "Hacker" của Steven Levy, v.v.) . Theo như "ngu ngốc", tôi nghĩ rằng nó được thiết lập một cách hợp lý rằng, bên ngoài các quy tắc pháp lý, đây là một thuật ngữ thông tục cho các hành động có bản chất bất tài. Tôi cũng đứng bên cạnh nó
Evan Anderson

11
@tonygil - OpenDNS không phải là DNS. Đó chỉ là một dịch vụ mà ai đó cung cấp. Điều gì xảy ra nếu FooDNS mở vào ngày mai và có một số API xóa bộ nhớ cache mới thú vị? Câu trả lời của tôi có nên bao gồm điều đó không? Nó dừng ở đâu? Đây là sự thoái hóa thành điên rồ. re: quyền dân sự - Tôi không phải là chủ nhân hoặc tổ chức chính phủ từ chối quyền công dân đối với thành viên của một lớp được bảo vệ. Chắc chắn-- hãy tiếp tục và xem nếu bạn có thể tìm thấy ai đó muốn truy tố tôi. Họ có thể liên lạc với tôi qua thư tại PO Box 852, Troy, OH. (866) 569-9799, x801 chuyển tiếp đến điện thoại di động của tôi 24x7. (Đó là một công việc thám tử giỏi ở đó nhìn vào hồ sơ của tôi, BTW.)
Evan Anderson

1
u thấy, bạn nói rằng áp lực ngang hàng mang lại sự thay đổi. đó là những gì tôi đã làm gây chú ý với bạn rằng tôi không đồng ý với việc bạn sử dụng "thằng ngốc" và "bị tổn thương não" vì chúng gây khó chịu và xúc phạm. thực tế là ai đó sử dụng nó một cách thô bạo (tức là tin tặc) không làm cho nó đúng. các kkk sử dụng từ n rất nhiều. xin tôn trọng những người trong chúng ta chăm sóc ppl suy yếu. Tôi hiểu rằng bạn kết hợp các thuật ngữ một cách ẩn dụ trong phong cách đầy màu sắc của bạn, nhưng hãy tin tôi: chúng gây khó chịu và không cần thiết.
tony gil

Về việc tôn vinh TTL: TTL là giá trị tối đa để giữ mọi thứ trong bộ đệm, bộ giải quyết bộ đệm được tự do bỏ dữ liệu trước nó. Vì vậy, họ có thể hạ thấp nó nếu họ muốn. Tuy nhiên, đúng là họ không nên tăng nó, đó là vi phạm giao thức. Nhưng đối với những người đặt 1 giây trong TTL, một số bộ đệm tự bảo vệ mình bằng cách không tôn trọng điều đó và thay vào đó chỉ trong 5 phút.
Patrick Mevzek

Máy chủ recursive DNS, thường do các ISP hoặc bộ phận IT, hiện nay họ đang hạm đội khổng lồ (anycast đám mây) của máy chủ tên đệ quy mở như 1.1.1.1hoặc 8.8.8.8hoặc 9.9.9.9hoặc 80.80.80.80. Điều quan trọng là phải hiểu rằng chúng bị bỏ qua: câu trả lời có thể thay đổi dựa trên IP nguồn bởi vì nó sẽ có khả năng là một thể hiện vật lý hoàn toàn khác VÀ bộ đệm mà chúng có thể là toàn cầu đối với tất cả các trường hợp, hoặc không.
Patrick Mevzek
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.