면책 조항 : 위반은 없지만 이것은 정말 나쁜 생각입니다. 나는 누군가가 이것을 실제 생활에서하는 것을 권장하지 않습니다.
그러나 지루한 IT 담당자에게 실험실을 제공하면 재미있는 일이 일어날 것입니다!
이 실험에서는 Server 2012 R2에서 실행되는 Microsoft DNS 서버를 사용했습니다. Active Directory에서 DNS 영역을 호스팅하는 복잡한 문제로 인해 AD 통합 이 아닌 testing.com이라는 새 기본 영역을 만들었습니다 .
이 스크립트를 사용하여 :
$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
}
}
}
testing.testing.com.말 그대로 1.1.1.1에서 1.1.255.255까지 모든 IPv4 주소 를 사용하여 name에 대한 65025 호스트 레코드를 오류없이 작성 했습니다.
그런 다음 65536 (2 ^ 16 비트) 총 A 레코드 수를 오류없이 깰 수 있기를 원했기 때문에 16581375 (1.1.1.1 ~ 1.255)까지 갔다고 가정합니다. .255.255)) 저는 여기 앉아서 밤새이 스크립트가 실행되는 것을보고 싶지 않았습니다.
따라서 서버의 IP가 다른 동일한 이름의 영역에 추가 할 수있는 A 레코드 수에는 실질적인 제한이 없다고 말하는 것이 안전하다고 생각합니다.
그러나 실제로 고객의 관점에서 작동 합니까?
Wireshark에서 본 클라이언트에서 얻는 것은 다음과 같습니다.
전체 크기를 보려면 새 브라우저 탭에서 이미지를여십시오.
보시다시피, 클라이언트에서 nslookup 또는 ping을 사용하면 UDP와 TCP라는 두 가지 쿼리가 자동으로 발행됩니다. 아시다시피, UDP 데이터 그램에 넣을 수있는 최대 용량은 512 바이트이므로, 한도 (20-30 개의 IP 주소와 같이)가 초과되면 TCP를 대신 사용해야합니다. 그러나 TCP를 사용하더라도 testing.testing.com에 대한 아주 작은 A 레코드 하위 집합 만 얻습니다. TCP 쿼리 당 1000 개의 레코드가 반환되었습니다. 라운드 로빈 DNS가 작동하는 것과 정확히 같은 방식으로 연속 쿼리마다 A 레코드 목록이 1 씩 올바르게 회전합니다. 이 모든 것을 통해 로빈을 반올림하려면 수백만 개의 쿼리가 필요합니다.
이것이 어떻게 확장 가능하고 탄력적 인 소셜 미디어 네트워크를 만드는 데 도움이 될지는 모르겠지만 그럼에도 대답은 있습니다.
편집 : 후속 의견에서 이것이 일반적으로 나쁜 생각이라고 생각하는 이유를 묻습니다.
내가 평균 인터넷 사용자이고 귀하의 서비스에 연결하고 싶다고 가정 해 봅시다. 웹 브라우저에 www.bozho.biz를 입력합니다. 내 컴퓨터의 DNS 클라이언트는 1000 개의 레코드를 다시받습니다. 불행히도, A 레코드 목록이 최신 상태로 유지되지 않거나 인터넷 덩어리에 영향을 미치는 대규모 중단이 있기 때문에 목록의 처음 30 개 레코드가 응답하지 않습니다. 웹 브라우저가 IP 당 5 초의 시간 초과가 발생하여 다음 브라우저를 시도한다고 가정 해 보겠습니다. 이제 나는 여기에 앉아 모래 시계를 2 분 반 동안 응시하여 귀하의 사이트가로드되기를 기다립니다. 아무도 그럴 시간이 없습니다. 그리고 내 웹 브라우저 또는 서비스에 액세스하는 데 사용하는 모든 응용 프로그램이 첫 번째 4 또는 5 개의 IP 주소 이상을 시도한다고 가정합니다. 아마 아닐 것입니다.
자동 청소를 사용하고 A 레코드 목록을 최신 상태로 유지하기 위해 DNS 영역에 대해 유효하지 않은 또는 익명 업데이트를 허용하는 경우 얼마나 안전하지 않은지 상상해보십시오! 영역을 업데이트하기 위해 클라이언트가 사전에 확보 한 클라이언트 TLS 인증서가 필요한 일부 시스템을 설계 했더라도 지구상의 어느 곳에서든 손상된 클라이언트가 봇넷을 시작하고 서비스를 중단하게됩니다. 기존의 DNS는 군중을 소싱하지 않고있는 그대로 불안정합니다.
엄청난 대역폭 사용 및 낭비. 모든 DNS 쿼리에 32KB 이상의 대역폭이 필요한 경우 전혀 확장되지 않습니다.
DNS 라운드 로빈은 적절한로드 균형 조정을 대체하지 않습니다. 한 노드에서 다운되거나 복구 할 수없는 방법을 제공하지 않습니다. 연결된 노드가 다운되면 사용자에게 ipconfig / flushdns를 수행하도록 지시합니까? 이러한 종류의 문제는 GSLB 및 Anycast와 같은 것으로 이미 해결되었습니다.
기타.