네임 서버가 TCP를 통한 쿼리에 응답해야한다는 것이 사실입니까?


23

여러 대형 웹 호스트의 DNS 서버 모니터링을 설정하는 프로세스입니다. 내 목표는 ping에 대한 응답을 추적하여 DNS 서버 응답 시간을 비교하는 것입니다.

이 과정에서 Bluehost 이름 서버가 ping에 응답하지 않는 것을 발견했습니다. bluehost.com 에서 Pingdom DNS Check를 실행하여 자세한 정보를 얻으려고 시도했는데 다음 오류가 발생했습니다.

네임 서버 ns1.bluehost.com (74.220.195.31)은 TCP를 통한 쿼리에 응답하지 않습니다.

이름 서버가 TCP를 통해 전송 된 쿼리에 응답하지 못했습니다. 이름 서버가 올바르게 설정되지 않았거나 방화벽에서 필터링이 잘못 구성되어 있기 때문일 수 있습니다. DNS가 영역 전송을 제공하지 않는 한 DNS에 TCP가 필요하지 않다는 것은 일반적으로 오해입니다. 네임 서버 관리자는 TCP가 일반적으로 필요하다는 것을 인식하지 못합니다.

다음을 알고 싶습니다.

  • 위의 진술은 어느 정도까지 사실입니까?
  • 이름 서버가 TCP를 통한 쿼리에 응답하지 않는 의미는 무엇입니까?

답변:


47

Pingdom의 진단 텍스트는 정확합니다. TCP는 영역 전송만을위한 것이 아닙니다 .

DNS 서버 구현 이제 RFC 5966에 따라 "DNS 전송을 통한 TCP- 구현 요구 사항"에 따라 TCP를 지원하기 위해 "필수"(RFC에 필요한 것이있는만큼)가 필요합니다 .

이것은 서버 소프트웨어 구현에 대한 요구 사항이며, 서버 작동 에는 엄격하게 적용 되지 않으며 운영 실습은 다루지 않습니다.

즉, 특정 DNS 서버가 TCP를 지원하도록 구성되어 있지 않거나 차단 된 경우 장기적인 영향으로 인해 DNSSEC를 올바르게 지원할 수 없게됩니다. 마찬가지로 응답이 512 바이트를 초과하는 다른 DNS 데이터도 차단 될 수 있습니다.

고지 사항 : 나는 그 RFC를 썼습니다.

편집 RFC 5966은 이제 RFC 7766 으로 대체되었습니다.


RE : DNSSEC를 싫어하는 운영 관행 단순히 TCP를 비활성화하고 방화벽에서 TCP를 삭제하여 적절한 조치를 취할 수 있습니다. 당연히 결과가 있습니다. 두 엔드 포인트에서 EDNS0에 대한 지원이 많지 않아 이들 사이의 디바이스가 어떤 식 으로든 간섭하지 않을 수 있습니다. (조각, 고대 방화벽에 의한 잘못된 플래그 등) 인증 서버 (부속 TXT)에 큰 DNS 레코드가있는 경우 대상 세그먼트를 제외하지 않으려면 TCP가 필요합니다. 마찬가지로 재귀 서버에서 비활성화하면 메일 클러스터가 스팸을 처리해야하는 DNS 응답으로부터 격리됩니다.
Andrew B

3

TCP 및 UDP를 지원해야합니다-TCP는 응답 크기> 512 바이트 (영역 전송 포함)입니다 (어쨌든 읽은 내용에 따라. 나는 보통 NS의 TCP 및 UDP를 활성화합니다 ...)


-2

이 주제에 대한 RFC의 의견을 아는 것이 좋으며, 우리는 이미 그에 대한 권위있는 답변을 가지고 있지만 실제적인 목적으로 DJBDNS의 저자 인 Daniel J. Bernstein 교수의 조언을 매우 즐겁게 찾을 수 있습니다.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

TCP 쿼리는 언제 전송됩니까?

다음 상황 중 하나 인 경우 TCP 쿼리에 응답하도록 DNS 서버를 구성해야합니다.

  • 512 바이트보다 큰 레코드 세트를 공개하려고합니다. (거의 항상 실수입니다.)
  • 발신 영역 전송 (예 : 타사 서버)을 허용하려고합니다.
  • TCP 서비스를 설정할 때까지 상위 서버가 이름을 위임하지 않습니다.

이러한 상황이 아닌 경우 TCP 서비스를 제공 할 필요가 없으며 설정하지 않아야합니다. DNS-over-TCP는 DNS-over-UDP보다 훨씬 느리고 본질적으로 서비스 거부 공격에 훨씬 더 취약합니다. (이것은 BIND에도 적용됩니다.)

그는 DNSSEC에 대한 명시적인 언급을 생략했습니다. 그 이유는 DJB에 따르면 DNSSEC은 "항상 실수"범주에 속하기 때문입니다. 자세한 내용은 https://cr.yp.to/djbdns/forgery.html 을 참조하십시오. DJB에는 DNSCurve ( http://dnscurve.org/) 라는 대체 표준이 있는데,이 표준 은 OpenDNS와 같은 일부 공급자가 이미 독립적으로 채택했습니다. 관심있는 부분 : /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

DJBDNS 설정에 관한 위의 문서가 그 기능을 나타내는 것이라면, AXFR for TCP만을 지원하는 것으로 보입니다. 많은 공급자들이 여전히 DJBDNS를 사용하고 있기 때문에 별도의 노력 없이도 DNS over TCP를 지원하지 않을 것입니다.

PS : DJB는 실제로 자신이 설교하는 것을 실천합니다. 자신의 서버 (1)은 DNSCurve를 실행하고 (2) TCP에 제대로 응답하지 않습니다. +notcp성공 만 가능합니다 (기본값).

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

반면에 a +tcp는 실패합니다 (선택한 서버에 따라 다른 오류 메시지가 나타남).

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

2
DJB fanboi 행위가 다소 마모되고 있습니다. 는 DNS 커뮤니티는 DNSSEC를 선택했다, 그리고 훨씬 DNSCurve에 대한 문헌은 완전히 conflates 직교 의 요구 사항 데이터의 신뢰성데이터의 암호화를 . IMNSHO, 귀하의 답변 은이 질문 에 아무런 영향을 미치지 않습니다 .
Alnitak

@Alnitak, DNS에 TCP가 필요하다는 귀하의 주장은 이것이 DNS에 대한 실제 요구 사항이 아닙니다. 분명히 많은 사람들이 TCP없이 실행되며 자신의 웹 사이트를 사용할 수 있다는 문제가 발생하지 않습니다. 그러나 당신은 잘못된 정보와 FUD를 계속해서 홍보합니다.
cnst

2
그 문서는 실제로 2003 년에 나온 것입니까? 2017 년에도 여전히 똑바로 얼굴을 주장 할 수 있습니까?
Michael Hampton

1
@MichaelHampton, 예, 진심으로 그리고 절대적으로. 어떤 것이 바뀌지 않고 DJB는 멍청한 것일 수도 있지만, 그는 꽤 똑똑합니다. 그가 제시하는 모든 주장은 본질적으로 철학적이며 기술이 변경하는 것처럼 변하지 않습니다. 한편, (1), 왜 ​​그렇게 믿기 어려운가, (2) 왜 구형 RFC를 똑바로 연결하고, 위선자가 아닌지, (3) 실제 반론이 아닌 다른 반론은 무엇입니까? 날짜"? 사람들은 자신의 방식에 상호 운용성 문제가 있다고 말하면서 2003 년에 그가 다시 제안한 주장 (예 : 반송 메일)을 주장합니다!
cnst

-5

TCP는 필수이며 일반적으로 긴 응답이 필요한 경우에만 사용됩니다. 부정적인 영향이있을 수 있습니다. 영역 전송은 TCP를 통해 이루어지며 신뢰할 수 있어야합니다. 신뢰할 수없는 서버에서 TCP를 허용하지 않으면 작은 응답 만 제공 할 수 있습니다.

서명 된 DNS 응답이 도입됨에 따라 UPD 응답으로 512 바이트 제한을 완화해야했습니다. EDNS0은 더 긴 UDP 응답을위한 메커니즘을 제공합니다. TCP를 통한 DNS를 허용하지 않으면 보안 DNS 구현이 중단 될 가능성이 높습니다.

인터넷에 UDP 포트 53 만 열려있는 DNS 서버를 실행할 수 있습니다. DNS 피어에 대한 TCP 액세스가 필요하지만이 목록은 소규모 호스트입니다.

전체 DNS 구현을 위해 TCP가 필요한 최신 RFC596 이 있습니다. 이것은 구현자를 목표로합니다. 이 문서는 특히 운영자를 다루지는 않지만 TCP를 허용하지 않으면 여러 가지 실패 시나리오가 발생할 수 있다고 경고합니다. DNS over TCP가 지원되지 않는 경우 발생할 수있는 다양한 장애에 대해 자세히 설명합니다.

DNS 증폭 공격을 방지하기 위해 TCP를 사용하는 것에 대한 논의가있었습니다. TCP에는 자체 서비스 거부 위험이 있지만 배포가 더 어렵습니다.


DNSSEC는 1999 년에 EDNS0이 한도를 완화하지 않았다 (RFC 2671 참조).
Alnitak

Alnitak에 의해 설명 된 바와 같이, 대부분의 경우 TCP가 필요합니다 (응답이 512 바이트보다 크지 않을 것이라는 것을 절대 확신 할 수없는 경우, 일반적으로 미리 알지 못하는 것)
bortzmeyer

UDP 만 허용하는 방화벽을 통해 DNS를 성공적으로 실행했습니다. 병적 구성을 제외하고 주소 조회는 512 자 미만입니다. DNS 경로가 256 자로 제한된다는 참조를 보았습니다. 내 메일 서버에 대한 데이터베이스의 증거에 따르면 서버 DNS 경로는 거의 100자를 초과하지 않으며 PTR 레코드에서 여러 이름을 반환하는 사이트는 거의 256자를 넘지 않습니다. 이 모든 응답은 UDP에서 실행됩니다. DNSSEC 또는 영역 전송없이 512 자 정도의 합리적인 사례를 가진 사람이 있습니까?
BillThor

DNSSEC에서 확장 크기에 대한 RFC를 확인하지는 않았지만 UDP에서 확장 패킷 크기를 사용하는 것으로 확인한 유일한 참조는 ben DSNSEC입니다.
BillThor

대규모 콘텐츠 제공 업체 중 하나가 웹 팜 중 하나에 512 바이트를 초과하는 A 레코드를 너무 많이 추가하여 몇 년 전 중단되었습니다. 실제 interop 문제가 발생했습니다.
Alnitak
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.