알 수없는 도메인 요청에 DNS 서버가 응답해야하는 RFC

내 도메인 등록 기관과 DNS는 현재 알 수없는 도메인에 대한 DNS 요청을 무시합니다. 무시한다는 것은 블랙홀을 의미하며 응답하지 않으므로 DNS 클라이언트와 리졸버 라이브러리가 재시도, 종료 및 마지막으로 시간 초과를 유발합니다.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

다른 인기있는 도메인 이름 서비스를 조사 할 때 다른 공급 업체가 5의 RCODE (REFUSED)를 반환하기 때문에이 동작은 매우 고유 한 것으로 나타났습니다.

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

모두 다음과 같은 것을 반환합니다.

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

또는

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

서버 룸에 요청을 삭제하는 대신 반품 REFUSED또는 NXDOMAIN즉시 IMHO가 적절합니다.

서버가 응답하지 않는다고 공급자에게 불만을 표시하면 서버가 위반 한 RFC를 인용하도록 요청합니다. 서버가 모든 요청에 ​​응답해야한다는 것을 증명하도록 요구하는 것이 이상하다는 것을 알고 있습니다.

질문 :

• 중복 된 요청 ID 또는 일종의 DOS 응답이 없으면 서버는 항상 요청에 응답해야한다고 규정합니다. 이 올바른지?
• 규정을 지원하기 위해 어떤 RFC 및 특정 섹션을 인용해야합니까?

나에게 DNS 쿼리에 응답하지 않는 것은 나쁘다. 대부분의 클라이언트는 동일한 쿼리를 같은 DNS 서버 나 다른 서버로 전송 한 다음 다시 전송합니다. 그들은 클라이언트의 속도를 늦출뿐만 아니라 신뢰할 수있는 이름 서버와 NS 항목에 따라 자체 또는 다른 서버에서 동일한 쿼리를 다시 수행하게합니다.

RFC 1536 및 2308 에서는 성능상의 이유로 동일한 캐싱에 대한 부정적인 캐싱에 대한 많은 정보를보고 동일한 쿼리의 재전송을 중지합니다. 에서 4074 나는 클라이언트가 클라이언트가 빈 응답의 또 다른 예입니다 RR에 대해 질문하게한다 IPv6의 정보가없는 알 수 있도록 영의 RCODE와 빈 응답을 반환에 대한 정보를 참조하십시오.

그러나 DNS 서버는 요청이 암시되어 있기 때문에 요청에 응답해야한다는 RFC를 찾을 수 없습니다.

특정 문제는 도메인 (및 관련 DNS 레코드)을 서버로 마이그레이션하거나 서비스에 새 도메인을 등록한 후 처음 X 분이 지나면 발생합니다. 신뢰할 수있는 이름 서버가 변경되는 시간 (요즘 꽤 빠르다)과 서버가 내 DNS 레코드를 제공하기 시작하는 시간 사이에 지연이 있습니다. 이 지연 시간 동안 DNS 클라이언트는 자신의 서버가 신뢰할 수 있다고 생각하지만을 사용해도 요청에 응답하지 않습니다 REFUSED. 지연은 이해하지만 DNS 요청에 응답하지 않기로 한 결정에 동의하지 않습니다. 레코드의 경우 시스템에서 이러한 제한 사항을 해결하는 방법을 이해하지만 DNS 프로토콜에 더 부합하도록 서비스를 개선하기 위해 여전히 협력하고 있습니다.

도와 주셔서 감사합니다.

편집하다:

이것을 게시하고 제 공급자와 후속 조치를 취한 후 두 달 안에 그들은 NXDOMAIN알 수없는 도메인 으로 돌아가도록 서버를 변경했습니다 .

셰인의 조언이 맞습니다. 컷 오버를 시작하기 전에 한 권한있는 서버에서 다른 권한 서버로 데이터를 마이그레이션하지 못하는 것은 정전에 대한 초대입니다. 그 시점부터 어떤 일이 발생하든 NS 레코드를 변경 한 사람이 중단 한 것입니다. 이것은 왜 더 많은 사람들이 귀하의 서비스 제공자에게 불만을 제기하지 않는지를 설명합니다.

즉, 이것은 여전히 ​​흥미로운 질문입니다. 그래서 나는 그것에 착수 할 것입니다.

DNS 서버의 기본 기능은 STD 13을 구성 하는 문서 RFC 1034 및 RFC 1035 에서 다룹니다 . 답은이 두 RFC에서 나왔거나 나중에이를 업데이트하는 RFC에 의해 명확 해져야합니다.

계속하기 전에 DNS의 범위를 벗어나야 할 큰 함정이 있습니다.이 두 RFC는 모두 BCP 14 (1997) 보다 앞서서 , 언어를 명확하게 설명 한 문서는 반드시해야합니다.

• 이 언어가 공식화되기 전에 작성된 표준은 명확한 언어를 사용했을 수도 있지만 몇몇 경우에는 그렇지 않았습니다. 이로 인해 소프트웨어, 대량 혼란 등이 다양하게 구현되었습니다.
• STD 13은 불행히도 여러 분야에서 해석이 유죄입니다. 운영 영역에서 언어가 확실하지 않은 경우 명확한 RFC를 찾아야하는 경우가 종종 있습니다.

RFC 1034 §4.3.1 이 말한 내용부터 시작하겠습니다 .

• 서버에 대한 가장 간단한 모드는 로컬 정보 만 사용하여 쿼리에 응답 할 수 있기 때문에 비재 귀적입니다. 응답에 오류, 응답 또는 다른 서버에 대한 참조가 포함되어 있습니다. 모든 이름 서버는 비 재귀 쿼리를 구현해야합니다.

...

재귀 서비스가 요청되지 않거나 사용할 수없는 경우 비 재귀 응답은 다음 중 하나입니다.

• 이름이 존재하지 않음을 나타내는 신뢰할 수있는 이름 오류입니다.

• 일시적인 오류 표시

• 일부 조합 :

  데이터가 영역에서 왔는지 또는 캐시되어 있는지에 대한 표시와 함께 질문에 응답하는 RR.

  응답을 보내는 서버보다 이름에 더 가까운 영역이있는 네임 서버에 대한 추천.

• 네임 서버가 생각하는 RR은 요청자에게 유용 할 것입니다.

여기의 언어는 합리적입니다. "해야한다"는 없지만 "있을 것"이다. 즉, 최종 결과는 1) 위 목록에 정의되어 있거나 2) 표준 트랙의 이후 문서에서 기능이 수정 된 문서에 의해 허용되어야합니다. 나는 그 요청을 무시한 것에 대해 존재하는 그러한 말들을 알지 못하며 연구를 반증하는 언어를 찾는 개발자에게 책임이 있다고 말할 것이다.

네트워크 남용 시나리오에서 DNS의 빈번한 역할을 고려할 때 DNS 서버 소프트웨어가 선택적으로 트래픽을 플로어에 떨어 뜨릴 수있는 노브를 제공하지 않는다고해서 기술적으로이를 위반하는 것은 아닙니다 . 즉, 이것은 기본 행동이 아니거나 매우 보수적 인 기본값입니다. 두 가지 예는 소프트웨어가 특정 이름 ( rpz-drop.) 을 삭제하도록 요구 하거나 특정 수치 임계 값 (BIND 's max-clients-per-query)을 초과 해야하는 사용자 입니다. 이 옵션이 표준을 위반하는 구형 제품에 대한 내성을 증가시키지 않는 한 소프트웨어가 표준을 위반하는 방식으로 모든 패킷의 기본 동작 을 완전히 변경 하는 것은 내 경험상 거의 들어 보지 못했습니다 . 여기서는 그렇지 않습니다.

요컨대,이 RFC는 운영자의 재량에 따라 위반 될 수 있으며 위반 될 수 있지만 일반적으로 이는 일부 정밀한 방식으로 수행됩니다. 특히 전문적인 합의 (예 : BCP 16 §3.3 )가 DNS 시스템 전체에 불필요한 부하를 발생시키는 것이 바람직하지 않다는 점에서 편의상 표준의 섹션 을 완전히 무시하는 것은 매우 드문 일 입니다. 신뢰할 수있는 데이터가 존재하지 않는 모든 요청을 삭제하지 않아도 재 시도하는 것은 바람직하지 않습니다.

최신 정보:

@Alnitak은 당연히 바닥에 쿼리를 삭제하는 것이 바람직하지 않다는 점에 대해 현재이 주제를 자세히 다루는 초안 BCP 가 있음을 우리와 공유했습니다 . 이것을 인용으로 사용하는 것은 다소 시기상조이지만, 공동체의 합의가 여기에 표현되는 것과 일치하도록 강화하는 데 도움이됩니다. 특히:

네임 서버가 공격을받지 않는 한, 다음과 같은 위임의 결과로 네임 서버에 대한 모든 쿼리에 응답해야합니다. 또한 코드는 영역을 제공하도록 구성되지 않은 경우에도 서버에 위임이 없다고 가정해서는 안됩니다. 손상된 위임은 DNS에서 일반적으로 발생하며 서버가 구성되지 않은 영역에 대한 쿼리를받는 것이 반드시 서버가 공격을 받고 있음을 나타내는 것은 아닙니다. 부모 영역 운영자는 위임 NS 레코드가 위임 영역의 레코드와 일치하는지 정기적으로 확인하고 그렇지 않은 경우 수정해야합니다 [RFC1034]. 이 작업을 정기적으로 수행하면 위임 된 부서의 인스턴스가 훨씬 낮아집니다.

이 답변은이 문서의 상태가 변경 될 때 업데이트됩니다.

도메인의 신뢰할 수있는 DNS를 새 공급자로 옮길 때는 항상 도메인 등록 정보 (누군가)를 변경하기 전에 항상 새 공급자에 대해 명시 적으로 테스트 (항상!)하고 테스트를 거쳐야합니다. 새로운 신뢰할 수있는 DNS 서버를 가리 킵니다.

대략적으로 수행 할 단계 :

1. 새로운 DNS 공급자에 모든 것을 설정하십시오. 모든 영역을 작성하고 채워야합니다.

2. 새로운 인증 서버가 올바르게 작동하는지 확인하십시오. 명시 적으로 쿼리하십시오.

   dig @new-ns.example.com mydomain.com
   

   귀하의 질문에 따르면,이 질문에 응답하지 않는다는 것입니까? 그러나 지금은 "알 수없는 도메인"이라고 말했지만 시스템에서 완전히 구성하고 구성한 레코드로 응답해야합니다.

   당신이 경우에, 한 이미 시스템에 도메인을 구성,이 시점에서 올바른 레코드로 응답해야한다. 그렇지 않은 경우 해당 영역을 제대로 호스팅하지 않는 것이므로 소리를 지르십시오. 구성하지 않은 도메인에 응답하는지 여부는 중요하지 않습니다. (여전히 말한 내용이 여전히 누락 된 경우 알려주십시오).

3. 도메인 등록 기관 (whois)과 함께 권한있는 이름 서버를 전환하여 트래픽이 더 이상 적중하지 않을 때까지 (최소한 24 시간 제공) 기존 DNS 공급자를 그대로두고 실행하십시오.

새 공급자가 전환하기 전에 레코드를 채울 수없는 경우 응답 방식이 실제로 중요하지 않습니다. 사용자가 쿼리를 완전히 거부하는 권한을 가진 사용자를 지정하면 마치 도메인과 동일한 방식으로 도메인의 다운 타임이 발생합니다. 전혀 응답이 없습니다.