이것은 자신의 도메인에 대한 DNS 확인을 아웃소싱할지에 대한 정식 질문 입니다.
현재 도메인에 DNS를 제공하는 ISP가 있지만 레코드 추가에 제한이 있습니다. 따라서 내 DNS를 실행할 생각입니다.
자신의 DNS를 호스팅하는 것을 선호합니까, 아니면 ISP가이 작업을 수행하는 것이 더 낫습니까?
내가 볼 수있는 대안이 있습니까?
이것은 자신의 도메인에 대한 DNS 확인을 아웃소싱할지에 대한 정식 질문 입니다.
현재 도메인에 DNS를 제공하는 ISP가 있지만 레코드 추가에 제한이 있습니다. 따라서 내 DNS를 실행할 생각입니다.
자신의 DNS를 호스팅하는 것을 선호합니까, 아니면 ISP가이 작업을 수행하는 것이 더 낫습니까?
내가 볼 수있는 대안이 있습니까?
답변:
나는 내 자신의 DNS 서버를 운영하지 않을 것이다. 내 경우에는 웹 사이트를 호스팅하는 호스팅 회사가 무료 DNS 서비스를 제공한다. 대안으로 DNS 호스팅 만하는 회사 ( DNS Made Easy 가 떠오를 수 있지만 많은 다른 것들이 있습니다)는 아마도 여러분이 살펴 봐야 할 것들입니다.
내가 직접하지 않는 이유는 DNS가 상당히 신뢰할 수 있어야하기 때문에 지리적으로 분산 된 자신의 서버 네트워크가 없다면 모든 알을 한 바구니에 담아 말해야합니다. 또한 전용 DNS 서버가 많이 있으므로 새로운 서버를 시작할 필요가 없습니다.
우리는 항상 자체 DNS를 호스팅합니다 (역방향 DNS도 선호). 이를 통해 타사에 의존하지 않고 긴급 변경을 할 수 있습니다. 위치가 둘 이상인 경우 DNS 서버에 적합한 수준의 중복성을 쉽게 설정할 수 있습니다.
여러 사이트가없는 경우 웹 인터페이스를 사용하여 DNS 호스팅 (ISP는 아님)을 특별히 변경하는 사람을 고려합니다. 연중 무휴 24 시간 지원 및 적절한 SLA도 찾으십시오.
도메인을위한 안정적이고 안정적인 DNS 설정을 위해서는 ...
위의 네트워크 인프라에 액세스 할 가능성이 없기 때문에 위의 네트워크 인프라가있는 평판 좋은 DNS 호스팅 공급자 (다른 사람들이 권장 한대로)를 선택하는 것이 좋습니다.
몇 년 동안 나는 번거 로움없이 BIND (버전 8 & 9)를 사용하여 자체 DNS 서버를 운영했습니다. 영역 파일의 유효성을 검사 한 커밋 후 검사와 함께 버전 제어 내에 구성을 저장 한 다음 DNS 서버가 정기적으로 영역 파일을 체크 아웃하도록했습니다. 문제는 푸시 된 각 커밋으로 SOA 일련 번호가 항상 업데이트되도록하는 것이 었습니다. 그렇지 않으면 캐싱 서버가 업데이트되지 않습니다.
몇 년 후 나는 영역을 관리하기 위해 자동화 된 스크립트를 사용하는 데 이상적이며 BIND 사용과 관련된 SOA 일련 번호 문제를 겪지 않기 때문에 djbdns와 함께 일했습니다. 그러나 특정 리소스 레코드 세트를 형식화하여 승인해야하는 자체 문제가있었습니다.
많은 트래픽이 DNS라는 것을 알았으므로 DNS 요구에 EasyDNS 를 사용 하도록 옮긴 등록 기관을 기쁘게하기 위해 기본 및 보조 DNS 서버를 모두 유지 해야했습니다. 웹 인터페이스는 관리가 쉽고 RR 세트를 관리하는 데 필요한 유연성을 제공합니다. 또한 입력 가능한 사용 가능한 RR 세트를 제한하는 1 & 1 과 같은 일부 호스팅 제공 업체 또는 Windows를 사용하여 DNS를 관리하는 경우에만 작동하는 네트워크 솔루션 과 같은 도메인 등록 기관에서 제공하는 것보다 작업하기가 쉽다는 것을 알았습니다 .
내 개인 도메인 (및 내가 도와주는 친구 도메인)의 경우 자체 DNS를 호스팅하고 등록 기관 (Gandi)은 보조 DNS를 제공합니다. 또는 다른 네트워크의 친구가 보조를 제공합니다. Gandi는 영역을 즉시 업데이트하지 않으며 24 시간마다 한 번씩 정도 확인하는 것처럼 보이지만 변경은 매우 드;니다. 우리를 위해 충분히 잘 작동하고 그들의 서버는 아마도 우리보다 훨씬 신뢰할 수 있습니다.
우리 회사는 자체 DNS를 수행하고 업스트림 네트워크 제공 업체는 보조 DNS를 제공합니다. 그러나 우리는 대학이며 99 %의 사용자가 현장에 있습니다. 로컬 네트워크가 다운 된 경우 DNS가 다운되었는지는 중요하지 않습니다. 또한 약 25 만 개의 DNS 레코드 (물론 25k 개의 역방향 DNS 레코드 포함)를 갖춘 클래스 B (/ 16)를 보유하고 있는데, 이는 웹 인터페이스를 통해 관리하기에는 다소 어색한 것 같습니다. 로컬 DNS 서버는 가용성이 높고 매우 빠릅니다.
둘 다 했어요 직접 호스팅하면 이점이있을 수 있습니다. 상사가 시간이 오래 걸리는 이유를 물었을 때 DNS 작동 방식에 대해 많은 것을 확실히 배웁니다. 또한, 당신은 당신의 영역을 훨씬 더 잘 통제 할 수 있습니다. DNS의 계층 적 분산 특성으로 인해 항상 필요한만큼 강력하지는 않지만 매번 편리하게 사용할 수 있습니다. 당신이 당신의 공급자가 당신을 IP 블록의 역방향 DNS에 대한 SOA로 할당하도록 할 수 있다면, 당신이 그것을 가정한다면.
그러나 위에 내장 된 고장 방지 기능을 실제로 어떻게 갖추어야하는지에 대한 위의 모든 의견이 반영되었습니다. 다른 지역의 다른 데이터 센터에있는 서버가 중요합니다. 2003 년에 북동부의 대규모 정전을 관리 한 우리는 모두 같은 도시 또는 지방 또는 주에있는 두 개의 서로 다른 데이터 센터에 박스를 두는 것만으로도 보호가 충분하지 않다는 것을 알게되었습니다. 배터리를 인식 한 후 디젤 발전기가 엉덩이를 절약했을 때 발생하는 기화는 이제 예비 타이어를 운전하고 있다는 사실로 인해 공포로 대체됩니다.
그러나 항상 LAN에 대한 내부 DNS 서버를 실행합니다. 네트워크가 내부적으로 사용하는 DNS를 완전히 제어하는 것이 매우 편리 할 수 있습니다. 사무실에서 전원이 꺼지면 서버 랙에 있기 때문에 내부 DNS 서버가 배터리 또는 배터리 및 디젤에있을 수 있습니다. 귀하의 PC는 그렇지 않습니다-그래서 서버가 있기 훨씬 전에 클라이언트가 오프라인 상태가됩니다.
정적 DSL 회선에서 기본 DNS를 호스팅하고 등록자 (다른 대륙에있는)가 보조 DNS를 제공하도록하여 이러한 "요구 사항"에 우연히 맞았 기 때문에이 모든 솔루션을 약간 즐겁게 읽었습니다. 훨씬 더 진지하고 안정적인 연결. 이런 식으로, 우리는 바인드를 사용하고 모든 레코드를 설정하는 모든 유연성을 얻음과 동시에 2 차가 이러한 변경 사항을 반영하도록 업데이트되고 맨홀에 불이 붙으면 한 번의 사건을 인용 할 수 있습니다.
이는
"도메인에 대해 최소한 두 개의 신뢰할 수있는 DNS 서버"를 충족시킵니다.
"DNS 서버는 다른 물리적 네트워크 및 전원 공급 장치에 연결되어야합니다."
"DNS 서버는 다른 지역에 있어야합니다."
따라 다릅니다.
80 년대 후반 (BSD 4.3c) 이후 다양한 작업을 위해 자체 DNS를 실행했습니다. 작업을 위해 항상 자체 DNS를 호스팅했지만 항상 여러 데이터 센터 위치를 보유했거나 보조 DNS를 파트너와 교환 할 수있었습니다. 예를 들어, 마지막 직장에서 우리는 다른 .EDU (MN에 있었고 CA에 있음)에 대해 보조 DNS를 수행했으며 우리에게도 똑같이했습니다. 지리적 및 네트워크 다양성.
또는 현재 직장에는 미국 동부와 서해안 데이터 센터가 있습니다. 자체 DNS를 호스팅하면 일부 GUI DNS 서비스에서 지원하지 않을 수있는 비정상적인 DNS 레코드 (SVR, TXT 등)를 넣을 수 있습니다. 또한 원할 때마다 TTL을 변경할 수 있습니다. 우리는 스스로 그것을 수행하는 비용으로 거의 궁극적 인 유연성을 가지고 있습니다.
가정 용품의 경우 두 가지 방법으로 모두 수행했습니다. 비정상적인 작업을 수행하거나 유연성이 필요한 일부 도메인의 경우에도 여전히 "숨겨진"마스터 DNS 서버를 실행하고 동일한 DNS 서버와 공용 DNS 서비스를 교환합니다. RCS를 사용하여 구성 관리를위한 제어 영역 파일을 버전 화하므로 영역 변경의 전체 히스토리를 처음으로 되돌릴 수 있습니다. 단일 블로그 또는 일반 웹 서버 (하나의 A 레코드 또는 하나의 CNAME)가있는 도메인과 같은 간단한 것의 경우, 도메인 등록 기관의 DNS 서비스를 사용하는 것이 더 쉽고 CM에 대해 걱정하는 것이 더 쉽습니다.
트레이드 오프입니다. 궁극적 인 제어 및 유연성은 자체적으로 다양성을 처리하고, 여러 서버를 실행하고, 하드웨어 / 소프트웨어 오류를 처리하는 등의 비용을 발생시킵니다. 유연성 또는 전체 제어가 필요하지 않은 경우 최상위 DNS 제공 업체는 아마도 더 낮은 총 비용으로 문제를 해결하십시오.
이 스레드에서 이미 언급했듯이 DNS에는 몇 가지 특별한 경우가 있으며 가장 중요한 차이점은 정식 네임 서버와 캐싱 네임 서버 배포의 차이점입니다.
인터넷 리소스를 확인하기 위해 DNS 서버가 필요한 경우 일부 무료 현금 인출 DNS 확인자가 현명한 선택입니다. 저는 개인적으로 Linux에서 PowerDNS 리 커서 (pdns-recursor)를 사용합니다.
웹 사이트 또는 MX와 같은 외부 인프라를 서비스하기 위해 내부 NS를 사용하지 않을 것입니다 (여기서 SOHO에 대해 이야기하는 경우). DNSmadeasy 와 같은 우수하고 안정적인 방탄 서비스를 사용하십시오 . 나는 그들의 비즈니스 패키지를 사용하며 매우 저렴하면서 흔들립니다.
최근 모든 서비스를 집에 가져 왔을 때 공개 DNS를 집에 가져 왔습니다. 이를 통해 필요한 모든 정보를 신속하게 업데이트 할 수 있습니다. 웹 서버가 모두 같은 사이트에 있기 때문에 현재 지리적으로 분산 된 DNS를 가질 필요는 없습니다.
나는 두 세계의 최고를 가지고 있습니다.
웹 사이트와 MX 레코드를 "다른 곳에"공개 DNS를 호스팅합니다. 신뢰할 수 있고 안전하며 작동하며 마음대로 수정할 수 있습니다. 나는 서비스 비용을 지불하고 그 가치에 만족합니다.
그러나 집에서는 ISP에 의존하지 않고 자체 캐싱 DNS 서버를 실행합니다. 내 ISP는 DNS를 잃어 버리고 DNS가 느리고 DNS가 유효하지 않은 경우가 있으며 때로는 DNS를 왜곡하여 관심이 있다고 생각되는 곳으로 장애가 발생하기를 원합니다. ISP의 DNS 사용에 관심이 없습니다. 그래서 나는 내 자신의 캐싱 DNS 서버를 가지고 있고 그것을 스스로한다. 처음 (약 2 시간)에 설정하는 데 약간의 노력이 있었지만 깨끗하고 DNS가 안정적입니다. 한 달에 한 번, cron 작업은 루트 서버를 조사하고 힌트 테이블을 새로 고칩니다. 아마도 일년에 한 번 doubleclick.com을 127.0.0.1 또는 이와 유사한 것으로 보내는 것과 같이 바이올린을 사용해야합니다. 그 외에는 개입이 필요 없으며 훌륭하게 작동합니다.
신의 사랑을 위해 자신의 DNS를 호스팅하기로 결정한 경우 사이트 당 두 대의 서버가 있습니다. 전 세계에서 사용자를 찾을 수 있도록 방화벽에 직접 연결된 외부 DNS 용입니다. 그리고 당신의 사내 DNS를 위해 네트워크 내부의 별도의 하나.
각 방법마다 장단점이 있지만 내부 DNS를 내부적으로 호스팅하는 것이 좋습니다. 외부에서 호스팅하는 경우 기본 네트워크 서비스에 의존하는 것의 목록이 마음에 들지 않습니다. CEO는 외부 호스팅을 통해 DNS 서버에서 돈을 절약하는 것이 영리하다고 생각할 수 있지만 인터넷 연결이 끊어지면 전자 메일을받을 수 없을 때 어떻게 생각할까요?
경험상 서비스 거부 공격을 받으려면 자체 DNS를 호스팅하십시오. 그리고 당신의 자신의 웹 사이트.
나는 당신이 스스로해서는 안되는 것들이 있다는 것을 믿는 사람입니다. DNS 호스팅이 그중 하나입니다. 많은 사람들이 말했듯이 중복 서버, 연결 및 물리적 위치가 필요하지만 소규모 호스팅 회사의 복원력에도 여전히 접근하지 못합니다.
자체 DNS 호스팅의 가장 큰 장점은 즉시 변경할 수 있다는 것입니다. 향후 마이그레이션을 위해 TTL을 단축해야합니까? 자신의 서버에서 스크립트를 작성할 수도 있습니다. 호스팅 된 DNS의 경우 로그인하여 수동으로 레코드를 변경하거나 더 나쁜 경우 공급자에게 전화를 걸어 DNS를 철자 할 수있는 수준에 도달 할 때까지 3 가지 수준의 지원을 수행해야합니다. 2-3 일 후에 변경됩니다.
Linux 서버에서 BIND를 사용하여 자체 DNS를 실행합니다. 현재 런던 영국, 마이애미 FL, 산호세 CA 및 싱가포르에 4 곳이 있습니다. 잘 작동하고 나는 완전한 통제권을 가지고 있습니다. 데이터 센터의 안정성이 매우 중요하므로 서버를 운영하기 위해 좋은 DC를 선택했습니다 (ISP 또는 다른 '알 수없는'인프라에 의존하지 않음). 엄격한 기준에 따라 선택한 세계적 수준의 DC를 사용하여 전 세계 어디에서나 DNS 서버 및 기타 서비스를 설정할 수 있습니다. 견고한 DNS는 내가 실행하는 전자 메일 및 웹 서비스에 필수적입니다.
자체 네임 서버를 호스팅해야합니까?
예, 그리고 당신은 또한 큰 제 3 자 DNS 제공 업체 중 하나 개 광석 이상을 사용해야합니다. 하이브리드 솔루션은 특히 여러 가지 이유로 인해 가장 안전한 장기적 접근 방식 일 수 있습니다. 특히 고객에게 SLA 또는 계약 요구 사항이있는 비즈니스의 경우. 당신이 b2b라면 더욱 그렇습니다.
마스터 DNS 서버 (숨겨 지거나 공개 된)가 진실의 원천이라면 공급 업체별 기능에 얽매이지 않도록 운영 적으로 보호 할 수 있습니다. 기본 DNS 이상의 유용한 기능을 사용하기 시작하면 다른 공급자로 전환하거나 고유 한 DNS를 호스팅하는 것이 문제가 될 수 있습니다. 이제 이러한 기능을 복제해야합니다. Dyn 및 UltraDNS가 제공하는 사이트 상태 확인 및 DNS 장애 조치가 그 예입니다. 이러한 기능은 훌륭하지만 일회성으로 간주해야하며 의존성이 아닙니다. 이러한 기능은 공급자에서 공급자로 제대로 복제되지 않습니다.
타사 공급 업체 만있는 경우 대상 DDoS 공격을받을 때 가동 시간에 영향을 줄 수 있습니다. 자체 DNS 서버 만있는 경우 DDoS 공격의 대상이 될 때 가동 시간에 영향을 줄 수 있습니다.
제어하는 숨겨진 마스터 DNS 서버에 종속되는 하나 이상의 DNS 공급자와 자체 분산 DNS 서버가있는 경우 특정 공급 업체에 고정되어 있지 않으며 항상 영역 제어를 유지해야합니다. 공격은 서버와 서버에 종속 된 하나 이상의 주요 공급자를 모두 중단시켜야합니다. 그보다 부족한 것은 서비스 저하와 심각한 중단입니다.
자신의 마스터 (이상적으로 숨겨져 있고 게시되지 않은) 서버를 갖는 또 다른 이점은 고유 한 API를 구축하고 비즈니스 요구에 적합한 방식으로 업데이트 할 수 있다는 것입니다. 타사 DNS 공급자를 사용하면 API에 맞게 조정해야합니다. 각 공급 업체마다 고유 한 것이 있습니다. 또는 경우에 따라 웹 UI 만 있습니다.
또한 마스터가 귀하의 통제하에 있고 공급 업체에 문제가있는 경우 여전히 마스터에 도달 할 수있는 모든 슬레이브 서버가 업데이트를받습니다. 이는 DDoS 사고가 많이 발생하는 동안 마스터로 타사를 보유한 것이 실수이며 공격을받지 않는 공급자의 서버를 변경할 수 없다는 것을 알게 된 후에 원하는 것입니다.
법적 관점에서 볼 때 공급 업체 잠금을 방지하는 것도 비즈니스에 중요 할 수 있습니다. 예를 들어, Dyn은 Oracle에서 잠재적으로 구매하고 있습니다. 이를 통해 Dyn의 모든 고객에 대한 DNS 통계를 수집 할 수 있습니다. 법적 위험을 초래할 수있는 경쟁적인 측면이 있습니다. 즉, 저는 변호사가 아니므로 해당 문제에 대해 법무 팀과 홍보팀에 문의해야합니다.
우리가 잡초를 파고 싶다면이 주제에 대한 다른 많은 측면이 있습니다.
[편집] 소규모 개인 / 취미 도메인 전용 인 경우 서로 같은 데이터 센터에 있지 않은 2 개의 VM이 있으면 작은 DNS 데몬을 실행하는 것으로 충분합니다. 나는 내 개인 도메인을 위해 그렇게합니다. 귀하의 도메인이 비즈니스를위한 것인지 아니면 취미를위한 것인지는 분명하지 않았습니다. 얻을 수있는 가장 작은 VM이면 충분합니다. 내 도메인에 rbldnsd를 사용합니다. 900KB의 램을 차지하고 사람들이 던지는 모든 남용을 처리 할 수 있으므로 내 레코드에 매우 높은 TTL을 사용합니다.
DNS 호스팅을 공공 서비스의 기초로 생각하십시오. 제 경우에는 이메일이 비즈니스에 중요합니다. 내부적으로 DNS를 호스팅하고 인터넷 연결이 불안정한 경우 DNS 레코드가 오래되어 도메인을 사용할 수 없게됩니다.
제 경우에는 도메인에 대한 MX 레코드를 찾을 수 없으면 이메일이 즉시 거부됩니다.
그래서 DNS를 외부에서 호스팅했습니다.
MX 레코드를 사용할 수 있지만 인터넷 연결이 끊어진 경우 도메인으로 전자 메일을 보내려는 서버에서 메일이 계속 대기합니다.
MX
기록 과 관련하여 이것이 사실이라고 생각하지 않는다 . 실제로 이것은 cr.yp.to/djbdns/third-party.html에 문서화되어있는 오해 중 하나입니다 .
2002 년부터 자체 서버를 운영하고 도메인을 관리해 왔습니다.
나는 종종 제공자의 DNS 서버를 사용했습니다.
내 IP에서 내 서버를 사용할 수 있었지만 DNS를 사용할 수없는 횟수가 너무 많았습니다.
내 전쟁 이야기는 다음과 같습니다.
모스크바의 한 yuge 제공 업체 (최초의 VZ 기반 공급 업체)는 저렴한 "가치"DC에서 VPS를 받았지만 DNS는 트래픽이 많은 프리미엄 최첨단 DC에 두 개로 다른 / 24 서브넷은 같은 시간에 약간의 TLD에 의해 요구되었다 . 어느 시점에서 재난이 발생하고 (2005 년 정전? ) 고가의 DC가 오프라인 상태가되었으며 내 사이트 (여전히 모스크바에서는 "가치"DC)가 IP 주소로만 액세스 할 수있었습니다.
흥미롭게도, 어떤 사건이 발생하기 전에도 나는 지역 이중화를 위해 ISP를 "내"DC로 옮기라고 요청하면서 ISP 와 ISP에 traceroute
대해 동일한 DC를 알아 차린 것을 분명히 기억 합니다. 서버는 이미 가장 우수한 DC에 있었기 때문에 지역 중복성에 대한 아이디어를 일축했습니다.ns1
ns2
나는 다른 공급자 (첫번째 ISP 시스템 기반의 공급자)를 가지고 있는데, 그곳에는 ns가 있고 다른 하나는 해외에 있습니다. 간단히 말해서, 전체 설정은 엄청나게 버그가 많았으며 "해외"서버가 영역을 유지 관리하지 못한 경우가 많으므로 도메인에 추가 오류 지점이있어 전체 서버가 여전히 원활하게 실행 되더라도 액세스 할 수 없었습니다.
자체 네트워크를 운영하는 레지스트라가 있습니다. 오프 사이트 서버가 가동 되어도 계속 끊어졌습니다. 내 DNS가 다운되었습니다.
최근에는 보조 용으로 여러 개의 큰 클라우드 공급자를 사용했으며 숨겨진 마스터를 직접 운영했습니다. 두 제공자 모두 설정을 한 번 이상 변경했습니다. 공개 발표와 함께 결코; 내 도메인 중 일부가 해결을 중지했습니다. 같은 공급자 중 한 명과 함께 내 친구에게도 일어났습니다. 사람들이 공개적으로 인정하는 것보다 타사 서비스에서 더 자주 발생합니다.
요컨대, http://cr.yp.to/djbdns/third-party.html 은 주제에 대해 절대적으로 정확합니다.
타사 DNS를 귀찮게하는 데 드는 비용은 종종 가치가 없습니다.
타사 DNS를 사용하는 경우의 부정적인 점은 종종 불공정하게 간과됩니다.
도메인에서 이미 타사 서비스 (예 : 웹, 메일, 음성 또는 텍스트)를 사용하지 않는 한 타사 DNS를 추가하는 것은 거의 항상 비생산적인 것이며 모든 상황에서 최상의 방법은 아닙니다. .