djbdns 대 바인딩 [닫힘]


20

저는 DNS 네임 서버를 설정하는 방법을 배우고 싶은 초보자입니다. djbdns, BIND 또는 다른 것을 사용해야합니까?

현재 네트워크 요구 사항에는 트래픽이 매우 적은 하위 도메인 지원, SSL 및 메일 서비스가 포함됩니다. 언젠가는 더 많은 트래픽과 더 까다로운 요구 사항 (로드 밸런싱 등)으로 확장 할 수있는 솔루션을 원합니다. 현재 Linux에서 실행 중입니다.

BIND에 올바르게 구성되지 않은 경우 보안 문제가 있으며 구성이 까다로울 수 있다는 것을 읽었습니다. 또한 djbdns가 구성하기 쉽고, 더 안전하며, 많은 부하와 동일하다는 것을 읽었습니다. djbdns에 대한 논쟁은 그럴듯 해 보이지만 나는 그것들을 제대로 평가할 전문 지식이 없다. BIND가 더 낫다면 djbdns에 대한 그러한 주장에 대해 이야기 해 주셔서 감사합니다.

감사.


정식 서비스 또는 재귀 서비스?
bortzmeyer

권위 있다고 생각합니다.
chernevik

답변:


14

나는 과거에 djbdns와 함께 일했으며 현재 많은 BIND 서버를 운영하고 있습니다.

djbdns의 가장 큰 문제는 나의 1 학년 선생님이 내 성적표에 넣는 방식이 "다른 사람들과 잘 어울리지 않는다"는 것이 가장 좋습니다. 그것은 나중에 당신을 물 수있는 모든 종류의 매우 작은 방법으로 유닉스 상자에서 다른 것과 같이 행동하지 않습니다. 다른 곳에서는 볼 수없는 영역 파일의 구문을 사용합니다.

djbdns의 가장 큰 장점은 보안이 목표 # 1로 처음부터 설계되었다는 것입니다.

DNS 서버를 설정하려는 경우 인터넷에 노출 한 다음 유지 관리하지 않으면 djbdns가 사용됩니다.

실제로 대부분의 관리자는 OS 공급 업체의 BIND 패키지를 사용하고 업데이트가있을 때 즉시 패치하는 것이 좋습니다. 그러나 루트로 실행하는 것이 좋습니다. 신뢰할 수있는 DNS 서버를 재귀 적 리졸버 DNS 서버와 분리하는 것이 좋습니다.

DNS가 포함 된 문서를 찾으면 BIND가 포함되고 djbdns가 포함되지 않을 수 있습니다. dig를 사용하면 반환 형식을 BIND 영역 파일에 붙여 넣을 수 있습니다. 다른 행성의 무언가 대신 일반적인 유닉스 데몬처럼 작동합니다.

일부 하드웨어로드 밸런서를 사용하고 재귀 해결 자 BIND 서버를로드 밸런싱합니다. 잘 작동합니다. 사용자가 요청을 보낸 것과 동일한 소스 IP를 가져와야하며 UDP 및 TCP 가능로드 밸런싱 설정이 작동해야합니다. 신뢰할 수있는 DNS를 수행하는 경우로드 밸런싱은 서버가 둘 이상 있고 후이즈 정보에 모든 서버를 게시하는 것만 큼 간단합니다. 다른 DNS 서버는 지능적으로로드 밸런스됩니다.


2
나는 그것이 djdns가 작동하지 않는 것처럼 생각하고, 그것이 당신의 잘못이고, 그렇다면 DJ입니다.
Dave Cheney

2
전체 토론은 도움이되며, 어떤 답변 하나만 골라내는 것은 다른 사람들에게는 약간 불공평 해 보입니다. 이것은 내가 얻은 결론에 가장 가깝습니다. 기술적 차이가 무엇이든 BIND는 문서와 커뮤니티에서 더 잘 지원됩니다. 다른 답변에서 알 수 있듯이 이해하면 향후 DNS 상호 작용이 단순화 될 것으로 보입니다. 이러한 장점은 djbdns가 손쉬운 구성으로 제공하는 이점보다 더 중요해 보입니다.
chernevik 2016 년

9

권위있는 서비스의 경우, NSD .

재귀 적 인 경우 unbound .

둘 다 작고 (따라서 검색 대기중인 보안 허점이 적을 수 있음) 적극적으로 유지 관리하고 모든 최신 DNS (DNSSEC, IPv6 등)를 지원합니다.

그렇지 않으면 BIND는 좋은 소프트웨어입니다.

djbdns는 오랫동안 유지 관리되지 않은 한 사람의 프로젝트로 더 안전하지는 않지만 (저자는 그렇게 말합니다) 공식 웹 사이트에는 실수가 가득합니다. (이제 djbboys로부터 많은 downvotes를 얻을 것이라고 확신합니다. 내 담당자는 내 취향에 비해 너무 높았습니다 :-)


8

그것이 자신을위한 것이고 DNS가 어떻게 작동하는지 배우고 싶다면 djbdns를 사용하십시오.

다른 사람이 DNS를 수행하는 방법과 일반적인 엔터프라이즈 배포를 지원하는 방법을 이해하려면 바인드를 배우십시오.

목표가 최소한의 노력과 지원이고 합리적으로 유능한 경우 djbdns는 지원 오버 헤드가 훨씬 낮습니다.

펜스의 초보자쪽에 더 익숙하다면 아마도 묶고 달리는 데 더 쉬운 시간이있을 것입니다.하지만 이상하고 엉뚱한 방법으로 폭발 할 가능성이 훨씬 높다는 것을 명심하십시오.

내가 djbdns (및 바인드)를 아직 몰랐다면 powerdns와 maradns도 살펴볼 것이지만, 작은 설치의 경우 djbdns 제품군보다 낫습니다.

그럼에도 불구하고 인터넷에 DNS를 알리기 위해 bind를 사용하더라도 시스템의 리졸버를 위해 localhost에서 dnscache (djbdns 제품군의 일부)를 실행해야합니다.


6

djbdns를 건너 뜁니다. djb는 영웅이지만 소프트웨어에 대한 수학자의 오만을 이어받습니다. 시작 / 중지와 관련하여 다른 소프트웨어처럼 작동하지 않는다는 사실은 영리한 데몬 관리 기술을 잘 보여줍니다. 그러나 모든 것이 너무 다르기 때문에 정기적으로 사용하지 않으면 문서를 꺼내야합니다. 다른 사람도 유지 관리하는 시스템에 설정 한 경우, 간단한 작업을 수행하려면 전체를 읽어야하는 명확한 문서를 작성해야합니다. init에서 물건을 돌리는 것은 귀엽고 영리합니다. 그러나 그것은 또한 독특하고 놀랍고 비표준입니다.

또한 djbdns와 관련하여 소프트웨어 상호 운용성이 아닌 표준만을 고집하여 심각한 문제를 일으켰습니다. DNS 패킷의 작은 차이로 인해 이러한 문제를 해결하는 데 많은 시간이 소요되었습니다.

또한 djbdns는 경우에 따라 djb 이외의 도구 (예 : nslookup)로 DNS 서버 문제를 해결하여 놀라운 결과를 얻을 수있는 이상한 동작을합니다. "실제로 djbdns라는이 불분명 한 DNS 서버를 사용하는 데 시간을 낭비하게됩니다. 문제는 진단 도구에서 이상한 메시지를 표시하지만 문제가없는 것입니다.이 패킷 캡처를 보면 이것은 djbdns가 DNS 서버와 올바르게 상호 운용되지 않는 몇 개월 전의 문제와 관련이 없으며 몇 주 전에 사무실을 비 웠던 문제와도 관련이 없습니다. 한 시간 동안 팀원이 DNS 서버를 다시 시작합니다. "

큐메일과 비슷한 문제.

질문을하고 죽일 시간이 있다면 djbdns를 설정하는 데 약간의 교육적 가치가 있습니다. djb의 웹 사이트를 읽으면 많은 것을 배울 수 있습니다.

보안 문제에는 두 가지가 있습니다. 공격자가 시스템에 액세스 할 수있게하는 보안 허점-djbdns에는 이러한 기능이 거의 없습니다. 몇 년 전 바인드는 단기간에 발견 된 몇 가지 창피한 것들을 발견했으며 나쁜 디자인을 드러 냈습니다. 나는 수년 동안 완전히 다시 쓰여질 것으로 기대합니다. 이 점에서 안전을 원한다면 가상 머신 (예 : Xen)에서 실행하십시오. 또한 대상 모드에서 SELinux를 사용하는 Linux 시스템에서 실행중인 경우 바인드 설정이 있으며 djbdns에 대한 설정을 방해하지 않을 것입니다. 바인드 + SELinux 시스템은 잠재적으로 더 안전합니다.

다른 문제는 캐시 중독에 대한 보안입니다. 내 생각 엔 djbdns가 릴리스되었을 때 더 좋았으며, 더 큰 관심으로 인해 bind가 더 나아 졌을 것이다. 이것은 "적절하게 구성되지 않은"경우 청력이 안전하지 않은 청각의 원인 일 수 있습니다. 최소한이 문제를 연구하고 이해해야합니다. 이 과정에서 두 DNS 서버 모두에 어떤 구성 위험이 있는지 알아볼 것입니다.

로드가 많은 경우의 동작은 대부분의 사용자에게 넌센스 기준입니다. 성능 병목 현상이 거의없는 소프트웨어를 평가하는 기준으로 사용되는 성능에주의하십시오. 대규모 사용자를 위해 캐싱 DNS 서버를 호스팅하지 않으므로 상당한 비율로 요청을받을 수 있습니다. 동일한 시스템에서 실행중인 서비스를 제공하기 위해 신뢰할 수있는 DNS를 실행하고 있습니다. 이러한 서비스는 DNS보다 수천 배나 비쌉니다. 인터넷 링크가 DNS 서버를 과도하게로드하기에 충분하지 않을 수도 있지만 제공하는 서비스에 대한로드가 너무 많으면 DNS에 병목 현상이 발생하지 않습니다.


5

보안 인식 DNS 서버 인 MaraDNS를 살펴볼 수 있습니다 .

  • 안전한. MaraDNS는 다른 DNS 서버보다 보안 기록이 우수합니다. 예를 들어, MaraDNS는 보안 난수 생성기, 쿼리 ID 및 DNS 쿼리의 소스 포트를 사용하여 항상 임의 화했습니다. "새로운"캐시 중독 공격에 결코 취약하지 않았습니다.

  • 지원합니다. MaraDNS는 오랜 기간 동안 유지 보수 및 업데이트를 해왔습니다. MaraDNS는 원래 2001 년에 만들어졌습니다. MaraDNS 1.0은 2002 년에 출시되었고 MaraDNS 1.2는 2005 년 12 월에 출시되었습니다. MaraDNS는 SQA 프로세스와 4 년이 넘는 실제 사용으로 광범위하게 테스트되었습니다. MaraDNS는 계속 완벽하게 지원됩니다. 가장 최근 릴리스는 2009 년 2 월 13 일에 완료되었습니다. MaraDNS 2.0의 일부가 될 코드 인 Deadwood는 활발히 개발되고 있습니다.

  • 사용하기 쉬운. 기본 재귀 구성에는 단일 3 줄 구성 파일 만 필요합니다. 기본 권한 구성에는 4 줄 구성 파일과 1 줄 영역 파일 만 있으면됩니다. MaraDNS는 이해하기 쉬운 자습서와 완전한 최신 참조 설명서와 함께 완벽하게 문서화되어 있습니다.

  • 작은. MaraDNS는 서버가 가능한 최소한의 리소스를 사용해야하는 임베디드 응용 프로그램 및 기타 환경에 적합합니다. MaraDNS의 바이너리는 현재 유지 관리되는 다른 재귀 DNS 서버의 바이너리보다 작습니다.

  • 오픈 소스. MaraDNS는 완전히 오픈 소스이며 라이센스는 FreeBSD 라이센스와 거의 동일한 2 절 BSD 라이센스입니다.

선택하는 데 도움이되는 여러 DNS 서버 소프트웨어가 비교되어있는 maraDNS 옹호 페이지를 참조 하십시오.


MaraDNS는 더 이상 프로젝트 홈 페이지에서 언급 한 것처럼 저자가 유지 관리하지 않습니다. maradns.org
Joseph Holsten

1
정정으로 더 이상 MaraDNS를 적극적으로 개발하지는 않지만 여전히 버그 수정, 새 컴파일러 및 Linux 배포판 업데이트 등을 유지하고 있습니다. 사실, 저는 올해 새로운 MaraDNS 릴리스 (2014)를 내놓았으며
samiam

4

스스로 DNS를 실행하고 있다면 djbdns가 더 나은 소프트웨어 패키지입니다. 지난해 주요 DNS 보안 문제를 확인한 몇 안되는 소프트웨어 패키지 중 하나였으며 몇 년 전에 수정하기 위해 빌드 / 패치되었습니다. DNS 캐싱의 경우 권한있는 DNS 서버로 실행되지 않는 모든 서버에 dnscache (djbdns의 일부)를 설치합니다. 대부분의 항목에서 BIND보다 실제로 더 잘 작동하지만 오늘날의 하드웨어를 고려할 때 BIND의 추가 무게와 느린 속도는 문제가되지 않습니다.

경험을 위해 어떤 패키지를 실행하든 관계없이 BIND의 기본 사항을 배웠습니다.

Djbdns는 명령 줄에서 관리하기가 매우 쉽습니다. DNS 데이터에 대한 모든 변경은 명령으로 수행됩니다. BIND에서 일련의 텍스트 파일을 편집합니다.

둘 다 패키지를 얻을 수 있습니다. IE와 다른 브라우저의 차이점을 봅니다. IE는 내장되어 많은 것들을 위해 작동하며 기본값에서 변경하지 않습니다. Djbdns는 다르며 다른 트레이드 오프 세트가 필요합니다. ISP의 경우 BIND에서 djbdns로 이동하는 것은 약간 까다로울 수 있습니다. 기본적으로 BIND는 캐싱 및 이름 지정을 수행하므로 djbdns는 이것을 두 부분으로 나눕니다. 이 보안 솔루션을 선호하지만 설정하기가 어렵 기 때문에 많은 BIND 설치가 방해가되지 않습니다.


3

개인적으로 참조를 위해 BIND의 기본 사항을 배워야하지만 다른 것으로 옮겨 가면 미래를 위해 더 행복한 시스템 관리자가 될 것입니다. :)

ISP 업계에서 일한 대부분의 장소는 djbdns를 사용하는 것처럼 보이며, '관리되는'서비스를 계층화하기위한 훌륭한 빌딩 블록과 기초를 제공합니다. 영역 파일을 생성하는 스크립트를 작성하는 것은 매우 사소한 일이므로 모든 DNS 데이터를 저장할 수 있습니다. 어쨌든 SQL에서. 초당 엄청나게 많은 쿼리를 처리하고 부팅하기에 안전합니다.

확장해야 할 경우 http://haproxy.1wt.eu를 살펴보고 그 뒤에 몇 가지 권위있는 서버를 넣으십시오! 또한 배포하기로 선택한 모든 설정에서 신뢰할 수있는 서버에서 리졸버를 분리하는 것이 좋습니다.

읽을 가치가있는 다른 것들은 MaraDNS와 PowerDNS입니다.


2

나는 주로 이런 종류의 것들에 FreeBSD를 사용하고 BIND와 번들로 제공되므로 다른 것을 배우려고 결코 노력하지 않았습니다. 그러나 BIND는 구성하기가 쉽지만 FreeBSD가 보안 관점에서 유지 관리하기 때문에 보안 문제에 대해 해당 채널 만 추적하면됩니다.

따라서 가장 좋은 방법은 두 가지를 모두 시도하고 가장 적합한 스위트를 확인하는 것입니다. 즉, 둘 중 하나와 함께 제공되는 OS를 사용하지 않는 한입니다.


2

DNS에 대해 배우려면 O'Reilly 책 " DNS and BIND "와 최신 버전의 bind가 설치되어있는 것이 가장 좋은 방법 일 것입니다.

BIND의 수명 기간 동안 더 많은 보안 문제가 발생했다는 것은 사실입니다. dnjdns는 작년까지는 없었지만 BIND와는 매우 다른 아키텍처를 가지고 있으며 이름 지정 시스템의 작동 방식에 익숙하지 않으면 선택하기가 더 어려울 수 있습니다.

DNS 서버 를 실행하는 방법에 대해 배우고 싶다면 (프로토콜 등을 배우는 것이 아니라), 하나를 선택하고 뛰어 드는 것이 가장 좋습니다. * nix 배포판을 선택하십시오. 즉, 보안 취약점이 발표 된 경우 다시 빌드해야하는 소프트웨어를 사용하여 소스에서 컴파일 할 경우 몇 가지 이점이 있습니다.

인터넷 연결 서비스와 마찬가지로 어떤 소프트웨어를 사용하든 상관없이 상식과 실용적인 사고가 가장 좋습니다. 동적 업데이트를 활성화해야하는 경우 해당 업데이트가 서명되어 있는지 확인하십시오. 영역 전송을 허용하는 경우 서버 등에서 영역 전송을 수행 할 수있는 사람을 제한하십시오.


1
나는 djbdns와 함께 일하면서 사소한 설치 문제를 빨리 겪었고 그러한 문제를 기록하는 매우 큰 커뮤니티가 없다는 것을 알았습니다. "DNS 및 BIND"와 같은 것은 없습니다. 이 장애물을 지나쳐도 내가 원하는 모든 것은 BIND 솔루션에 대한 토론을 할 가능성이 높습니다. 기술이 좋든 나쁘 든 BIND는 더 나은 지원을 제공하는 것 같습니다.
chernevik

분명히, 당신이 원하는만큼 어렵지 않습니다. 나는 일을하려고 노력하고 있으며 특정 도구의 잠재력을 소진시키지 않고 제한된 이해로 최선의 선택을합니다. djbdns, perl, lighttpd, Free BSD 및 현재 사용 하지 않는 다른 모든 오픈 소스에 감사합니다 . 글쎄, 거의 모든. 그러나 나는 당신이 나보다 RTFM이나 TFM을 찾는 초보자를 진지하게 기대할 수 있다고 생각하지 않습니다. 당신은 djbdns에 분명히 투자하고 있습니다. 내 의견이 당신을 귀찮게한다면, 당신은 더 똑똑한 초보자를 희망 할 수 있거나, 우리가 더 쉽게 답을 찾을 수 있도록 노력할 수 있다고 생각합니다.
chernevik

2

묶다.

구성하는 방법을 배우면 (어떤 피곤한 DNS 관련 RFC를 읽는 동안) 나중에 다른 DNS 서버로 쉽게 전환 할 수 있습니다 (어떤 목적 으로든). FreeBSD, Linux 및 Vista 랩톱 (VMware NAT의 호스트 용)의 모든 곳에서 BIND를 기본 및 보조 서버로 사용하고 있습니다.

Btw, BIND의 소스를 읽고 gethostbyname () 또는 gethostbyaddr ()와 같은 클래식 함수가 어떻게 작동하는지 발견하는 것은 재미있는 일입니다.


2

바인드를 몇 년 동안 사용한 후에 마침내 대부분의 서버가 자체 DNS 데몬을 전혀 실행할 필요가 없다는 결론을 얻었습니다. 오늘날에는 거의 모든 도메인 등록 기관이 귀하를 위해 DNS 레코드를 서버에 제공합니다 (일반적으로 DNS 레코드를 편집 할 수있는 웹 기반 방법을 제공합니다). 정보 제공, 보조 관리 등을 처리합니다. 서버가 DNS 쿼리에 응답 할 필요가 없으면 서버가 DNS 조회를 수행하기 만하면됩니다. 이를 위해 레벨 3 "애니 캐스트"DNS 서버 인 4.2.2.1 및 4.2.2.2에서 /etc/resolv.conf를 가리키며 매우 빠르고 안정적인 것으로 보입니다.

또한 서버의 방화벽 구성에서 더 이상 DNS를 허용하지 않아도됩니다. 서버의 DNS 쿼리가 작동하도록하려면 "확립 된 관련"규칙 만 있으면됩니다.

그래, DNS 데몬을 실행할 필요가 있는지 묻지 않았지만 이것이 내가 대답 한 질문입니다. 완료하기 위해서는 하나를 실행해야한다는 것을 발견하면 바인드를 사용하는 것이 좋습니다. 매우 많이 사용되므로 많은 문서를 찾고 원하는 작업을 수행하는 데 도움이됩니다.


합리적으로 보이지만, 먼저 직접 호스팅하여 이것이 어떻게 작동하는지 알아내는 것이 더 쉬운 것 같습니다.
chernevik 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.