저는 항상 (예를 들어 .com) TLD에 대한 DNS 인프라가 어떻게 설계되었는지 궁금했습니다. 높은 수준의 신뢰성을 유지할 수 있을 뿐만 아니라 기록에 대한 대량의 실시간 업데이트도 지원해야 합니다.
ISC의 BIND가 해당 수준에서 사용된다고 가정합니다. 나는 BIND를 사용하여 확장 가능한 인프라를 구축하는 방법에 대해 상당히 명확한 그림을 가지고 있습니다. 제가 확실하지 않은 부분은 몇 초마다 수백 개의 DNS 영역을 추가, 삭제 및 변경하는 시스템을 어떻게 설계할 것인가입니다. 전 세계에는 수많은 도메인 등록 기관이 있으며 .com만으로도 엄청난 양의 활동을 볼 수 있습니다. BIND 영역 파일을 기반으로 구축된 시스템은 어떻게 그렇게 많은 변화를 수용할 수 있나요?
TLD 운영자가 텍스트 파일을 사용하고 새로운 .com이 등록될 때마다 BIND가 변경 사항을 지속적으로 다시 로드하도록 의심하는 것이 옳습니까? 그렇다면 그들은 무엇을 합니까? SQL 또는 LDAP 데이터베이스가 지원됩니까? 그것도 확장이 되나요?
답변1
첫째, 전 세계적으로 초당 신용카드 거래가 2~3개 회사에 의해 관리되는 것보다 더 많은 업데이트가 있다고 생각하시나요? 작동하므로 해결 가능한 문제입니다 :-)
둘째, 업데이트가 어떻게 진행되는지 혼란스러울 수 있습니다. 등록 평면과 게시 평면이라는 두 평면이 교차하는 부분이 자주 이해되지 않는 부분이기 때문입니다. 레지스트리 네임서버에서 정확히 무슨 일이 일어나는지 혼란스러울 수도 있습니다( NS도메인 위임에 대한 기록만 유지하고 해당 영역의 전체 콘텐츠는 유지하지 않음).
그러나 그것에 들어가기 전에 업데이트는 둘 다 필요하지 않고 종종 필요하지 않은 실시간이어야 한다고 가정하는 것 같습니다. TTL 때문에 DNS에는 실시간이 없습니다.
이제 두 개의 비행기로 돌아갑니다.
- 등록 기관은 네임 서버가 변경되거나 DNS 부작용이 있는 기타 작업(예: EPP 상태 설정
clientHold)이 있을 때 레지스트리에 업데이트를 보냅니다. 이것은 등록 플레인이며 DNS 게시와 완전히 관련이 없으며 일반적으로 EPP라는 프로토콜을 사용합니다. 레지스트리에서 "업데이트 승인됨"이라고 응답한다고 해서 DNS 인프라에 이미 게시되었다는 의미는 아니며 "언젠가는 게시될 것"이라는 보장일 뿐입니다. NS레지스트리는 DNS 게시 평면을 유지 관리하여 네임서버가 모든 위임, 즉 관리하는 TLD에 등록된 모든 도메인에 대해 올바른 레코드를 게시하는지 확인합니다 .
따라서 변경 횟수는 여러분이 생각하는 것보다 훨씬 적을 것입니다. 소유자가 .com새 기록을 사용하여 해당 영역의 내용을 변경하는 경우 대부분의 경우 등록 기관을 통해 할 수 있는 작업이 없으며 레지스트리 권한에서 변경 사항도 없습니다. 네임서버.
그리고 이러한 변경 사항은 DNS 업데이트 메커니즘을 통해 발생하지 않습니다. 변경 사항은 특정 프로토콜인 EPP를 사용하여 등록 기관에 의해 푸시되고, 변경 사항은 일부 레지스트리 데이터베이스에 어떻게든 저장되며, 그 후 새 데이터는 레지스트리에 의해 권한 있는 이름 서버에 게시됩니다.
당신은 또한 "실시간"이 필수라고 생각하는 것 같습니다. 기술적으로는 그렇지 않으며 심지어 비효율적인 설계일 수도 있습니다(일부 레지스트리에서 이름 확인을 위해 이름 이름 서버가 올바르게 구성되었는지 확인하는 것처럼 새로운 변경 사항이 적합한지 테스트하고 싶다면 고려하십시오). 예를 들어 DNSSEC 테스트에 대한 권한이 있는 것으로 곧 나열될 것입니다...).
"업데이트 10분 지연" 또는 "1시간"과 같은 기능을 제공하는 많은 레지스트리에서 사용하는 일반적인 설정 방법은 해당 기간 동안 요청된 모든 변경 사항을 내부 버퍼에 저장한 다음 한 번에 저장하는 것입니다. 새 영역을 생성하고 게시하는 동시에 다음 기간에 적용될 모든 변경 사항을 수집하기 위해 새 버퍼를 시작합니다.
ISC의 BIND가 해당 수준에서 사용된다고 가정합니다.
별말씀을요. Verisign은 Atlas라는 자체 독점 네임서버 소프트웨어를 운영합니다. 예를 들어 참조https://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html 이 2004년 기사에는 이미 다음과 같은 내용이 나와 있습니다.
VNDS(VeriSign Naming and Directory Services)는 5분 이내에 핵심 13개의 .com 및 .net 신뢰할 수 있는 이름 서버를 업데이트할 것을 약속합니다. 현재 요금은 하루에 2번 정도입니다.
물론 그 이후로는 좋아졌습니다. 그러나 나는 5분에 한 번이라도 DNS를 실제로 실제로 사용하는 데는 충분하다고 생각합니다.
또한 계약상의 의무가 있을 수 있으며, 특히 ICANN과 계약을 맺은 gTLD 등록 기관 및 등록 기관의 경우 더욱 그렇습니다. 현재 Verisign-ICANN 계약은 다음과 같습니다.https://www.icann.org/en/registry-agreements/details/com 부록 §6.6에서 확인할 수 있습니다.https://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-en업데이트 제약 조건에 대한 세부정보:
6.6 업데이트 빈도. 레지스트리 운영자는 DNS 이름 서버 및 Whois의 데이터를 적시에 업데이트합니다. ICANN 인증 등록기관은 SRS를 통해 이러한 업데이트를 기록합니다. 그런 다음 SRS는 DNS 이름 서버와 Whois를 업데이트합니다. 레지스트리 운영자는 거의 실시간으로 이 업데이트를 처리합니다.
DNS 이름 서버와 Whois 모두의 업데이트 빈도와 관련된 약속된 성능 사양은 월별 기간 동안 트랜잭션의 95%에 대해 3분입니다. 즉, 월별 기간 동안 DNS 이름 서버 및 Whois에 대한 업데이트의 95%가 3분 이내에 완료됩니다. 업데이트 빈도는 레지스트리 운영자가 업데이트를 확인한 시간부터 업데이트가 DNS 이름 서버 및 Whois에 나타나는 시간까지 측정됩니다. 업데이트 빈도 성과는 부록 4에 따라 매월 ICANN에 보고됩니다.
많은 SLA에 사용되는 "95%"라는 일반적인 표시를 기록해 두십시오. 따라서 가능한 경우 거의 실시간이지만 실제로는 일반적으로 3분입니다(따라서 위에서 설명한 일반적인 버퍼 설정).
나는 BIND를 사용하여 확장 가능한 인프라를 구축하는 방법에 대해 상당히 명확한 그림을 가지고 있습니다. 제가 확실하지 않은 부분은 몇 초마다 수백 개의 DNS 영역을 추가, 삭제 및 변경하는 시스템을 어떻게 설계할 것인가입니다.
.comVerisign에는 , 일부 IDN 등 몇 개의 영역만 있습니다. .net"수백 개의 영역"을 관리하지 않습니다. 그리고 확실히 매초마다 많은 변화가 있는 수백 개가 아닙니다.
높은 빈도로 업데이트할 수 있는 수백만 개의 영역을 호스팅하는 DNS 공급자에 더 관심을 가질 수도 있고 원할 수도 있습니다. 다음은 권한 있는 DNS 서비스와 관련하여 성능 측면에서 어떤 일을 하는지 설명하는 CloudFlare의 기사입니다.https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/
전 세계에는 셀 수 없이 많은 도메인 등록업체가 있습니다.
아니요, 전부는 아닙니다. 셀 수 없이 많습니다. 실제로는 2000개 미만이며, 실제로 많은 양의 변경 사항이 적용되어 실제로 활성화되는 경우는 500개 정도에 불과합니다. gTLD의 모든 등록기관은 ICANN의 인증을 받아야 합니다. 전체 목록은 다음에서 찾을 수 있습니다.https://www.icann.org/en/accredited-registrars
TLD 운영자가 텍스트 파일을 사용하고 새로운 .com이 등록될 때마다 BIND가 변경 사항을 지속적으로 다시 로드하도록 의심하는 것이 옳습니까?
정상적인 높은 수준의 트랜잭션 네임서버 소프트웨어는 텍스트 파일로 뒷받침되지 않습니다. 바인드도 그렇지 않습니다. 동적 업데이트가 활성화되면 "저널" 파일(바이너리)이 있으며 특별히 해당 영역의 텍스트 파일 버전을 편집해서는 안 됩니다(먼저 업데이트를 중단한 다음 업데이트 후에 다시 허용하지 않음). 편집하다).
그렇다면 그들은 무엇을 합니까? SQL 또는 LDAP 데이터베이스가 지원됩니까? 그것도 확장이 되나요?
SQL이나 LDAP가 DNS에 적합한 스토리지 엔진인지 의심스럽습니다. DNS는 본질적으로 계층적이므로 다양한 제약이 따릅니다.
답변2
우선, 어떤 경우에는 즉시 다시 로드할 필요가 없습니다.
"저희에게 비용을 지불하면 X시간 이내에 도메인이 등록됩니다"라는 SLA가 있는 경우 일부 cron 작업이나 유사한 작업을 사용하여 주기적으로 다시 로드할 수도 있습니다. 따라서 일부 등록 기관은 플랫 파일을 사용하고 주기적으로 다시 로드할 수 있습니다.
동일한 IP 주소에 여러 DNS 서버가 연결될 수 있으므로(예: 애니캐스트 사용) 모든 위치에서 플랫 파일을 변경하고 한 번에 하나의 DNS 서버를 다시 로드하는 "롤링 배포" 메커니즘을 설정할 수도 있습니다. 시간.
즉, Bind >9는 기본적으로 Bind가 데이터베이스를 영역 데이터 백엔드로 사용할 수 있도록 하는 DLZ(Dynamically Loadable Zones)를 지원합니다. 그런 다음 데이터베이스에 유효한 DLZ 드라이버가 있는 한 기존 데이터베이스 확장 전략에 따라 데이터베이스(및 데이터베이스 연결)를 확장할 수 있습니다.
마지막으로 한 의견에서 말했듯이 수직적 확장(즉, 각 서버에 대해 많은 CPU, RAM 및 IOPS를 갖는 것)이 도움이 됩니다.
2009년이 있다사노그슬라이드는 분명히 약간 구식이지만 흥미로울 수 있습니다.https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf