Số lượng IP tối đa mà bản ghi DNS A có thể có là bao nhiêu?


30

Tôi có một ý tưởng lạ - cho phép nhiều người / tổ chức lưu trữ cùng một ứng dụng và để tất cả các nút của họ có thể truy cập được thông qua một tên miền. Đó là để có một mạng xã hội phân tán thực sự, nơi mà khả năng sử dụng không bị hy sinh (tức là người dùng không phải nhớ các url nhà cung cấp khác nhau và sau đó khi một nhà cung cấp ngừng hoạt động, hãy chuyển sang một nhà cung cấp khác)

Để đạt được điều đó, tôi nghĩ rằng một bản ghi DNS có nhiều IP có thể được sử dụng.

Vậy, một bản ghi DNS A có thể giữ được bao nhiêu IP? Câu trả lời này nói rằng khoảng 30, nhưng usecase thì khác. Đối với kịch bản trên, tôi sẽ không quan tâm nếu một ISP cụ thể chỉ lưu trữ 30, miễn là một ISP khác lưu trữ 30 khác, v.v.


2
Bạn đang dùng về Anycast ?
Nói dối Ryan

4
Trước đây tôi đã học được rằng nếu bạn phải hỏi "Số X tối đa là bao nhiêu?" có lẽ bạn đang sử dụng sai ...
LordOfThePigs

Không nhất thiết;) Nhưng nói chung, có
Bozho

Câu trả lời:


78

Tuyên bố từ chối trách nhiệm: Không xúc phạm, nhưng đây là một ý tưởng thực sự tồi tệ. Tôi không khuyên mọi người làm điều này trong cuộc sống thực.

Nhưng nếu bạn cho một anh chàng IT nhàm chán một phòng thí nghiệm, những điều buồn cười sẽ xảy ra!

Đối với thử nghiệm này, tôi đã sử dụng máy chủ Microsoft DNS chạy trên Máy chủ 2012 R2. Do sự phức tạp của việc lưu trữ một vùng DNS trong Active Directory, tôi đã tạo một vùng chính mới có tên tests.com không được tích hợp AD.

Sử dụng tập lệnh này:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

Tôi đã tiến hành tạo, không có lỗi, 65025 bản ghi lưu trữ cho tên testing.testing.com., với mỗi địa chỉ IPv4 theo nghĩa đen từ 1.1.1.1 đến 1.1.255.255.

Sau đó, tôi muốn đảm bảo rằng tôi có thể vượt qua tổng số 65536 (2 ^ 16 bit) tổng số bản ghi A mà không có lỗi, và tôi có thể, vì vậy tôi cho rằng có lẽ tôi đã có thể đi hết 16581375 (1.1.1.1 đến 1.255 .255.255,) nhưng tôi không muốn ngồi đây và xem kịch bản này chạy suốt đêm.

Quá nhiều hồ sơ

Vì vậy, tôi nghĩ an toàn khi nói rằng không có giới hạn thực tế đối với số lượng bản ghi A bạn có thể thêm vào một vùng cho cùng tên với các IP khác nhau trên máy chủ của bạn.

Nhưng nó sẽ thực sự hoạt động từ quan điểm của khách hàng?

Đây là những gì tôi nhận được từ khách hàng của mình khi được xem bởi Wireshark:

hai truy vấn (Mở hình ảnh trong tab trình duyệt mới để có kích thước đầy đủ.)

nslookup

Truy vấn TCP

Như bạn có thể thấy, khi tôi sử dụng nslookup hoặc ping từ máy khách của mình, nó sẽ tự động đưa ra hai truy vấn - một UDP và một TCP. Như bạn đã biết, phần lớn tôi có thể nhồi nhét vào một datagram UDP là 512 byte, do đó, khi vượt quá giới hạn đó (như 20-30 địa chỉ IP,) người ta phải sử dụng TCP thay thế. Nhưng ngay cả với TCP, tôi chỉ nhận được một tập hợp con A bản ghi rất nhỏ cho tests.testing.com. 1000 hồ sơ đã được trả về mỗi truy vấn TCP. Danh sách các bản ghi A xoay đúng 1 với mỗi truy vấn liên tiếp, chính xác như cách bạn mong đợi DNS vòng tròn hoạt động. Nó sẽ mất hàng triệu truy vấn để làm tròn thông qua tất cả những điều này.

Tôi không thấy cách này sẽ giúp bạn làm cho mạng truyền thông xã hội có khả năng mở rộng, có khả năng phục hồi ồ ạt của bạn, tuy nhiên vẫn có câu trả lời của bạn.


Chỉnh sửa: Trong bình luận tiếp theo của bạn, bạn hỏi tại sao tôi nghĩ rằng đây thường là một ý tưởng tồi.

  • Giả sử tôi là người dùng internet trung bình và tôi muốn kết nối với dịch vụ của bạn. Tôi gõ www.bozho.biz vào trình duyệt web của mình. Máy khách DNS trên máy tính của tôi nhận lại 1000 bản ghi. Chà, thật không may, 30 bản ghi đầu tiên trong danh sách không phản hồi vì danh sách các bản ghi A không được cập nhật hoặc có thể có sự cố mất điện quy mô lớn ảnh hưởng đến một đoạn internet. Giả sử trình duyệt web của tôi hết thời gian 5 giây cho mỗi IP trước khi nó tiếp tục và thử cái tiếp theo. Vì vậy, bây giờ tôi đang ngồi đây nhìn chằm chằm vào một chiếc đồng hồ cát quay trong 2 phút rưỡi chờ trang web của bạn tải. Không ai có thời gian cho việc đó. Và tôi chỉ giả sử rằng trình duyệt web của tôi hoặc bất kỳ ứng dụng nào tôi sử dụng để truy cập dịch vụ của bạn thậm chí sẽ cố gắng nhiều hơn 4 hoặc 5 địa chỉ IP đầu tiên. Có lẽ nó sẽ không.

  • Nếu bạn đã sử dụng chức năng nhặt rác tự động và cho phép các bản cập nhật không xác thực hoặc ẩn danh vào vùng DNS với hy vọng giữ cho danh sách các bản ghi A luôn mới ... hãy tưởng tượng xem nó sẽ không an toàn đến mức nào! Ngay cả khi bạn thiết kế một số hệ thống mà khách hàng cần chứng chỉ TLS của khách hàng mà họ đã nhận được từ bạn trước đó để cập nhật vùng, một khách hàng bị xâm phạm ở bất cứ đâu trên hành tinh sẽ khởi động botnet và phá hủy dịch vụ của bạn. DNS truyền thống bấp bênh vì nó không có nguồn cung cấp đám đông.

  • Sử dụng băng thông khiêm tốn và lãng phí. Nếu mọi truy vấn DNS yêu cầu băng thông 32 kilobyte trở lên, điều đó sẽ không có quy mô tốt.

  • DNS round-robin không thay thế cho cân bằng tải thích hợp. Nó cung cấp không có cách nào để phục hồi từ một nút đi xuống hoặc không có sẵn ở giữa mọi thứ. Bạn có định hướng dẫn người dùng thực hiện ipconfig / flushdns nếu nút mà họ được kết nối không hoạt động không? Những loại vấn đề này đã được giải quyết bằng những thứ như GSLB và Anycast.

  • V.v.


15
Chậm .... vỗ tay ....., thưa ngài.
mfinni

4
Để thêm vào điều này, nếu các bản ghi A đang được truy vấn thông qua BIND (đó là những gì đang chạy trên phần lớn các máy chủ DNS), nó sẽ xáo trộn các bản ghi A và trả lại một số lượng bản ghi A nhất định từ đó. Số lượng nhất định được xác định trong MAX_SHUFFLEmã nguồn BIND (theo mặc định là 32).
ub3rst4r

1
Vì tò mò, tại sao bạn không khuyên bạn? Đó chắc chắn là một điều rất kỳ lạ, nhưng ngoài việc có các nút độc hại phục vụ yêu cầu trong một miền 'tốt' và các nút không thành công vẫn nhận được yêu cầu, còn điều gì khác có thể sai :-)
Bozho 13/12/14

Ngoài ra, trải nghiệm người dùng sẽ tiếp tục thay đổi? Là mỗi nút một bản sao hoàn chỉnh? Làm thế nào bạn có thể đảm bảo rằng đó là nếu họ nằm dưới sự kiểm soát của người khác? Nếu chúng khác nhau, thì mọi người sẽ có được một trang web hôm nay và một trang web khác vào ngày mai. Cá nhân, điều đó sẽ lái tôi hạt dẻ!
Brandon

18

Để trả lời câu hỏi như đã nêu ("một bản ghi DNS A có thể giữ bao nhiêu IP?"), Câu trả lời rất đơn giản: một Abản ghi duy nhất giữ chính xác một địa chỉ. Tuy nhiên, có thể có nhiều Abản ghi cho cùng một tên.


10

Mỗi địa chỉ IPv4 sẽ chiếm 16 byte trong câu trả lời. Mỗi địa chỉ IPv6 sẽ chiếm 28 byte trong câu trả lời.

Chúng tôi khuyên bạn nên đảm bảo rằng câu trả lời sẽ phù hợp với 512 byte. Điều đó sẽ cho phép khoảng 25 địa chỉ IPv4 và 14 địa chỉ IPv6 (xem xét rằng bạn cũng cần một số thông tin khác trong gói). Giới hạn chính xác phụ thuộc vào độ dài của tên miền của bạn.

Nếu bạn có cả 25 địa chỉ IPv4 và 14 địa chỉ IPv6, thì bạn đang tính đến các máy khách yêu cầu địa chỉ IPv4 và IPv6 trong các truy vấn riêng biệt. Nếu khách hàng yêu cầu cả hai loại địa chỉ trong một truy vấn duy nhất (rất hiếm), thì bạn sẽ phải hạ xuống.

Nếu kích thước trả lời vượt quá 512 byte, nó vẫn có thể hoạt động trên UDP nếu máy khách và máy chủ hỗ trợ EDNS. Nếu không có EDNS, máy khách sẽ nhận được câu trả lời bị cắt ngắn và nó sẽ phải thử lại qua TCP. Điều này làm tăng giao tiếp từ 1 đến 4 vòng. Nhưng thậm chí tệ hơn, đôi khi có các cấu hình sai ngăn DNS qua TCP hoạt động.

Ngay cả khi bạn có thể ép hơn 14 địa chỉ vào thư trả lời mà không gây ra sự cố ở lớp DNS, thì rất có thể nó sẽ không hữu ích. Thời gian chờ được sử dụng bởi khách hàng trước khi từ bỏ một địa chỉ và tiếp tục đến địa chỉ tiếp theo thường rất đáng kể.

Phải chờ thời gian chờ đó dù chỉ một lần có thể dẫn đến trải nghiệm người dùng kém. Nếu khách hàng phải đi qua 14 địa chỉ trước khi nhận được phản hồi, người dùng sẽ phải chờ 13 lần hết giờ.


2
Mọi DNS nên hỗ trợ EDNS những ngày này. Giới hạn 512 byte đối với phản hồi DNS không còn thực tế do DNSSEC.
Barmar

@Barmar Nhưng nếu bạn bật nó lên, có một rủi ro khá đáng kể, rằng máy chủ của bạn sẽ được sử dụng trong các cuộc tấn công khuếch đại. Lần trước tôi đã kiểm tra tôi thấy rằng khi tắt ràng buộc đó là điều duy nhất, có thể được thực hiện để giảm thiểu các cuộc tấn công khuếch đại. Cho đến khi EDNS được mở rộng với trường cookie và hỗ trợ cho việc đó được triển khai rộng rãi, tắt hỗ trợ trả lời lớn hơn 512 byte vẫn được khuyến nghị thực hành.
kasperd

1
Tôi thực sự không hiểu nhiều về cách kết quả tìm kiếm để vô hiệu hóa EDNS là cách thực hành tốt nhất. Xin trích dẫn? Các cuộc tấn công khuếch đại tận dụng các máy chủ đệ quy sẽ xảy ra bất kể EDNS có được bật hay không nếu mạng của bạn không thực hiện xác thực địa chỉ nguồn. Ngay cả khi chúng ta đang nói về một máy chủ chỉ có thẩm quyền, điều đó chỉ trở nên phù hợp khi bạn đã cấu hình nó để trả lại nhiều dữ liệu đó trong một câu trả lời, tại thời điểm đó, việc vô hiệu hóa nó sẽ không giúp ích gì cho bạn.
Andrew B

@AndrewB Tôi không nhớ mình đã đọc đề xuất đó ở đâu. Tôi đã đọc nhiều khuyến nghị khác nhau về cách tránh các cuộc tấn công khuếch đại, và tất cả chúng đều hút. Thật đáng tiếc EDNS đã không giới thiệu cookie, đây có thể là một giải pháp hiệu quả cho các cuộc tấn công khuếch đại bằng DNS. Điều tôi khuyên bạn nên trả lời là tránh đặt quá nhiều hồ sơ vào một truy vấn, rằng bạn đang dựa vào người khác để kích hoạt EDNS để câu trả lời có hiệu quả.
kasperd

@AndrewB Nếu tôi đặt các bản ghi A có giá trị hơn 512 byte vào một vùng và đảm bảo nó được lưu trữ trên máy chủ DNS có thẩm quyền nơi EDNS được bật, đó có thể là vấn đề đối với người dùng trình phân giải đệ quy không cho phép phản hồi lớn. Và đó là lý do tại sao tôi khuyên bạn nên giữ số lượng hồ sơ A thấp hơn. Ngoài ra, tôi đã giải thích lý do tại sao lợi ích nhận được của nhiều hồ sơ A không liên quan.
kasperd

5

Những gì bạn đang mô tả không phải là một ý tưởng đặc biệt mới. Vì các câu trả lời khác đã được đề cập, bạn bị giới hạn về số lượng bản ghi A bạn có thể có trong một câu trả lời, nhưng điều đó không nói gì về tổng số bản ghi A có thể có.

Ví dụ, bạn có thể triển khai máy chủ DNS trả lời bất kỳ truy vấn nào cho bản ghi A có IP ngẫu nhiên. Đã truy vấn đủ số lần, điều này sẽ dẫn đến 4294967296 bản ghi A duy nhất: một bản ghi cho mỗi địa chỉ IPv4.

Như tôi đã nói, đây không phải là một ý tưởng mới. Trên thực tế, đó là một phần cách Akamai hoạt động (và có thể là rất nhiều CDN khác). Bản ghi bạn nhận được cho bất kỳ miền Akamai nào được xác định bởi các máy chủ DNS ma thuật đen của họ. Tôi đặt cược câu trả lời bạn nhận được phụ thuộc vào cân bằng tải động và mối quan tâm địa lý.

Ví dụ: tôi đã chọn a338.g.akamaitech.net. Nếu tôi nhìn vào máy tính của mình ngay bây giờ, nó sử dụng máy chủ tên được gán DHCP từ Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

Nếu tôi hỏi DNS của Google thì sao?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Tôi đặt cược nếu bạn thử nó, tôi cá là bạn sẽ nhận được một câu trả lời khác. Akamai có bao nhiêu máy chủ biên phục vụ bất kỳ tài nguyên cụ thể nào? Hơn hai, tôi đặt cược.


Cảm ơn. Vâng, tôi biết rằng CDN hoạt động theo cách đó, nhưng theo quan điểm của tôi, họ có số lượng hồ sơ hạn chế trên mỗi tên miền phụ. (2 trong bài kiểm tra của bạn). Câu hỏi gần đây khác của tôi là chính xác về CDN và việc triển khai DNS của họ :-)
Bozho

2

Những người khác đã đề cập đến nó như một chi tiết, nhưng từ quan điểm thực tế, giới hạn cứng là giới hạn kích thước gói UDP là 512 byte. Mặc dù có thể chuyển sang TCP khi phát hiện cắt ngắn, nhưng trên thực tế, nhiều / hầu hết khách hàng sẽ không làm điều đó (và có thể là họ không nên; nó sẽ mang lại trải nghiệm xấu cho hầu hết các ứng dụng và tôi chỉ mong đợi chuyển vùng hoặc khác tra cứu mục đích đặc biệt để hỗ trợ TCP). Vì vậy, bạn đang xem xét giới hạn ở đâu đó khoảng 30 địa chỉ cho IPv4 (bản ghi A) và phần nào ít hơn cho IPv6 (AAAA) vì chúng lớn hơn. Độ dài của tên miền cắt vào đây và sẽ giới hạn số lượng hơn nữa.


1
Bạn hoàn toàn chính xác rằng có nhiều máy khách và trình phân giải sai không xử lý đúng các phản hồi DNS không phù hợp với một datagram UDP duy nhất, nhưng vui lòng từ bỏ ý tưởng rằng chỉ chuyển vùng hoặc yêu cầu bất thường mới cần kích thước phản hồi lớn hơn. Từ câu trả lời của bạn, rõ ràng bạn không sử dụng xác nhận DNSSEC, nhưng nhiều người (cũng không phải là DNSSEC là lý do duy nhất tại sao cần trả lời lớn hơn, nhưng đó là một điều rất quan trọng.)
Michael McNally

@MichaelMcNally: DNSSEC không có ý định (ít nhất là không phải bởi những người triển khai, dựa trên các luồng trên danh sách gửi thư glibc mà tôi đã tham gia) để được sử dụng tại các điểm cuối (ứng dụng tạo tra cứu DNS) nhưng tại máy chủ tên đệ quy cục bộ sẽ thực hiện tra cứu thay mặt cho các ứng dụng. Do đó, ngay cả với thiết lập DNSSEC, không có lý do gì để mong đợi các ứng dụng nói DNS qua TCP. UDP hoạt động hoàn toàn tốt.
R ..

1

Câu trả lời ngắn gọn: khoảng 25 bản ghi A phù hợp với gói UDP. Ngoài ra, DNS sẽ chuyển sang TCP và nó sẽ không nhanh như vậy. Bạn cũng sẽ gặp vấn đề với các máy khách không sử dụng trình phân giải DNS có khả năng chọn IP "gần nhất". Ngoài ra, với wifi và thiết bị di động, "gần nhất" thường không phải là máy chủ phù hợp.

Câu trả lời dài hơn:

Đừng làm vậy. Cách tốt hơn là thiết lập các bản ghi CNAME riêng cho từng người dùng trỏ đến máy chủ phù hợp. Giả sử bạn có hai máy chủ server-fserver-rđược sử dụng cho IMAP. Định cấu hình ứng dụng khách IMAP của mỗi người với tên máy chủ là USERNAME.imap.example.com trong đó "USERNAME" được thay thế bằng tên người dùng email của họ. Bây giờ bạn có thể di chuyển mọi người giữa các máy chủ mà không phải cấu hình lại ứng dụng email của họ.

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

Tuy nhiên, nếu bạn làm điều này, tôi rất khuyến khích rằng bạn tự động tạo các bản ghi DNS từ cơ sở dữ liệu của người dùng. Bạn muốn đảm bảo rằng khi các tài khoản được tạo và xóa, các bản ghi DNS cũng được tạo và xóa. Nếu không, bạn sẽ kết thúc với một mớ hỗn độn và rất nhiều nhầm lẫn.

Tôi đã thấy điều này được thực hiện tại các công ty với hàng ngàn người dùng theo nghĩa đen và, vì mọi thứ được tự động hóa, thế giới rất tốt.


0

Như những người khác đã chỉ ra, đó là một ý tưởng khủng khiếp để sử dụng trong thế giới thực.

Trong thế giới thực, có các máy khách và bộ giải quyết không phù hợp gặp sự cố với các phản hồi không phù hợp trong một datagram UDP duy nhất và có các tường lửa sẽ thực thi các ý tưởng cụ thể nhưng không tuân thủ giao thức về giới hạn kích thước thông báo DNS.

Và ngay cả khi bạn có thể tin tưởng vào phản ứng to lớn của mình trong mọi trường hợp (mà bạn hoàn toàn không thể), có một lý do khác đây là Ý tưởng rất tồi. Kích thước phản hồi DNS của bạn càng lớn thì càng hấp dẫn vì nó là một trọng tải cho các cuộc tấn công phản chiếu vì bạn cung cấp một hệ số khuếch đại rất lớn. Trong kiểu tấn công từ chối dịch vụ này, thường gặp trong DNS, truy vấn UDP được gửi đến bộ giải quyết đệ quy mở. Địa chỉ nguồn của các truy vấn UDP thường dễ bị giả mạo và kẻ tấn công đặt nguồn truy vấn thành IP của mục tiêu dự định của chúng. Hai hiệu ứng mong muốn (đối với kẻ tấn công) đã đạt được: thứ nhất - một nỗ lực gửi tương đối nhỏ từ phía chúng (từ một truy vấn giả mạo nhỏ) dẫn đến một luồng tương đối lớn lưu lượng truy cập không mong muốn đến mục tiêu (đây là hệ số khuếch đại), và thứ hai - nguồn thực sự của cuộc tấn công được ẩn khỏi mục tiêu; mục tiêu chỉ biết địa chỉ của các bộ giải quyết đệ quy đang được sử dụng làm gương phản xạ.


0

Điểm thú vị của những câu đố lịch sử về chủ đề này. Vào những năm 90, AOL đã mở rộng các bản ghi DNS của họ sao cho một truy vấn MX sẽ trả về> 512 byte. Điều này đã vi phạm RFC, phá vỡ rất nhiều máy chủ SMTP (qmail là một máy chủ phổ biến tại thời điểm đó) và gây ra rất nhiều vấn đề đau đầu. Việc sửa chữa yêu cầu hoặc hoặc thêm các tuyến tĩnh.

Tôi không biết tình hình hiện tại là gì, nhưng vài năm trước, khi tôi chạm vào qmail lần cuối, các bản vá vẫn còn nguyên.

http://www.gossamer-threads.com/lists/qmail/users/30503

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.