DNS에서 신뢰할 수있는 네임 서버를 보내는 이유는 무엇입니까?

호기심으로 Wireshark DNS 패킷을 확인하고 있습니다. 호스트의 DNS 쿼리가 있고 DNS 서버의 DNS 응답이 있음을 알 수 있습니다. 모든 것이 예상대로입니다.

그러나 쿼리를 추가로 체크인하면 서버가 NS (Authoritative Name Server)도 전송 함을 알 수 있습니다. 내 질문은 : 왜?

호스트로서 나는 IP에만 관심이 있습니다. 즉,의 DNS의 주요 지점 에, IP 주소로 이름을 확인할 .

왜 호스트로서 NS 정보가 필요합니까?

— AhmedWas
소스

@ downvoter, 의견을주십시오. 그리고 내 질문이 너무 쉽다고 생각하면 적어도 대답하고 나서 공감하십시오.

— AhmedWas

철학 및 설계 투표에 의해 익명 및 둘 다 투표 까지 도 투표를 아래로하는 모든 필수 설명을 필요로하지 않습니다 . 마우스 포인터가 아래 버튼 위에있을 때 나타나는 도구 설명은 "이 질문은 연구 노력을 나타내지 않으며, 명확하지 않거나 유용하지 않습니다 . " 또한 잘 쓰여 지지 않았을 때 , 주제에 관한 내용이 없거나 세부적인 내용이 누락 된 경우에도 질문이 다운 투표를 유치 할 수 있습니다 .

— HBruijn

답변:

전통적으로 서버가 쿼리에 짧은 응답하지만, RFC 보내지 않는 이름 (1034) - (1035) 리소스 레코드가 들어있는 권한 섹션을 포함 준수 전체 응답을하는 권위있는 네임 서버 (들)을 향해 가리 킵니다.

그 이유는 아마도 DNS의 분산되고 위임 된 특성으로 인해 "진리의 근원"을 응답에 포함시키는 것이 좋은 생각 인 것 같습니다.

편집 : 그런데 : 권한 섹션을 보내는 것은 RFC를 준수하지만 모든 쿼리 응답에 필수는 아닙니다.

BIND에서이 동작은 minimal-responses yes | no;지시문 으로 조정할 수 있습니다 . 여기서 기본값은 no쿼리 응답의 권한 및 추가 섹션이 항상 채워집니다.
다른 네임 서버 CloudFlare, AWS Route 53, Infoblocks 및 아마도 다른 서버는 기본적으로 항상 최소한의 최소 응답을 보냅니다. Google의 공개 리졸버는 사용 가능한 경우 권한 섹션을 Cloudflare에 반환합니다.

내가 생각하는 실제 질의 응답이 폐지에서 (의사)의 코드를 루트를 발견으로 그 전통의 기원뿐만 아니라에서 권한 섹션을 모두 포함하는 RFC882의 페이지 15-16

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.

— HBruijn
소스

편집 및 추가 정보에 감사드립니다. 나는 당신에게 하나 이상의 UP 투표를 줄 수 있기를 바랍니다 :)

— AhmedWas

이것은 실제로 질문에 대답하지 않습니다. 우리는 이미 완전한 응답을 받았다는 것을 알고 있습니다. 문제는 이것의 이점은 무엇입니까? 표준이 이런 식으로 설계된 이유 는 무엇 입니까? 이 형태의 응답에서 "추가"정보의 가치는 무엇입니까?

— 궤도에서 가벼움 경주

@LightnessRacesin 궤도에 대한 답은 자명합니다. DNS 서버는 example.com이 abcd라고 말하지 않습니다. 누가 그렇게 말했는지 알려줍니다. 이것은 실제로 어떤 제 3자가 그것이 사실이라고 단언 할 때만 어떤 것이 사실이라는 것을 정확하게 말할 수 없기 때문에 인식 론적으로 건전합니다. 사람들이 관찰처럼 마치 의견을 제시하거나 1 차 증거처럼 결론을 내릴 때 문제를 해결하는 것이 더 어렵다는 것을 알게되었습니다.

— Monty Harder

@MontyHarder 예, 말이 되겠지만, 제가 말하는 것은 그것이 대답에 있어야한다는 것입니다.

— 궤도에서 가벼움 경주

@LightnessRacesinOrbit RFC에 항상 디자인 동기가 포함되는 것은 아닙니다. "당시 좋은 생각처럼 보였음"을 분명히하기 위해-나는 현재 RFC가 (의사에서 기원을 찾는 것을 요구하지 않더라도) 실제 쿼리 응답 외에 권한 섹션을 포함시키는 것이 왜 전통적인 이유인지 생각 합니다. ) 현재 사용되지 않는 RFC882 15-15 페이지 의 코드 "... 이름 서버가 신뢰할 수

— HBruijn

서버는 요청이 최종 클라이언트에서 오는지 또는 다른 네임 서버의 재귀 요청인지 알 수 없습니다. 다른 이름 서버 인 경우 권한 섹션을 캐시하고 나중에 해당 이름 서버를 직접 쿼리 할 수 있습니다.

나는 이것이 프로토콜의 원래 정당화라고 생각하지만 보안에 영향을 미칩니다. 응답에는 가짜 이름 서버를 나열하는 권한 섹션이 포함될 수 있으며 이는 캐시 포이즈 닝 공격에 사용되었습니다. 따라서 네임 서버는 쿼리하는 도메인의 하위 도메인에 대한 위임 레코드가 아닌 한 NS 레코드를 캐시하지 않습니다.

— 바 마르
소스

서버는 실제로 이러한 요청의 차이점을 알 수 있습니다. 플래그에는 재귀를 요청하는 비트가 약간 있습니다.

— kasperd

서버는 예를 들어 forwarders기능이 사용되는 경우 재귀 쿼리를 보낼 수 있습니다 .

— Barmar

그러나 그렇게하면 권위있는 서버는 신경 쓰지 않습니다.

— kasperd