%EB%8A%94%20%EC%A3%BC%EC%86%8C%EB%A5%BC%20%EB%B0%98%ED%99%98%ED%95%98%EC%A7%80%20%EC%95%8A%EC%A7%80%EB%A7%8C%20%22%EA%B8%B4%22(ANY%2C%20TCP)%20%EC%BF%BC%EB%A6%AC%EB%8A%94%20%EC%A3%BC%EC%86%8C%EB%A5%BC%20%EB%B0%98%ED%99%98%ED%95%A9%EB%8B%88%EB%8B%A4..png)
이건 동료야Ask우분투이 질문을 할 만큼 충분히 알기 전에 이 질문을 게시했습니다.
(우분투 18.04 기준입니다.)
디버그 출력을 관찰하여 systemd-resolved다음과 같은 쿼리를 실행할 수 있습니다.
host foo.mycompany.com
그리고 무슨 일이 일어나고 있는지 확인하세요. systemd-resolvedUDP를 통한 쿼리가 내 로컬 DNS 서버(내 라우터에 있음)로 연기된다는 것입니다. 반환된 응답은 캐시 항목이 생성되도록 유도 systemd합니다 NODATA.
그러나 내가 이렇게 하면:
host -a foo.mycompany.com
쿼리가 ANY요청되면 디버그 출력에는 UDP 응답 패킷이 잘려서 TCP 쿼리로 대체된다는 것이 명확하게 표시됩니다. 반환되면 systemd분명히 유효한 주소가 표시되고긍정적인캐시 항목.
host -a연결된 문제를 확인할 수 있지만 결론은 도메인 이름을 조회하면 일부 도메인 이름만 (잠시 동안) 작동하게 된다는 것입니다.
이 동작의 원인이 무엇인지 모르겠습니다. 나는 그것이 그것 자체와 아무 관련이 없다고 생각합니다 systemd-resolved. 왜냐하면 그것을 우회하고 내 컴퓨터에서 라우터 DNS로 직접 이동하면 결과는 동일하기 때문입니다(물론 디버그 추적을 볼 수는 없지만). 나는 아니에요생각하다내 라우터가 문제의 일부였습니다. 동료도 같은 효과를 볼 수 있었기 때문입니다(그는 내 집에 없었습니다).
답변1
내 생각에는 일부 중간 캐싱 서버(예: 내 홈 라우터에 있는 서버)가 RFC1918("개인") 주소를 반환하려고 하지 않는 것이 무슨 일인지 판단한 것 같습니다. 따라서 대부분의 소프트웨어(브라우저 등)에서 수행되는 짧은 쿼리는 이러한 캐시를 활용하지만 서버는 "찾을 수 없음"과 동일한 결과를 반환합니다. 따라서 로컬 서버는 그것이 옳은 일이라고 생각하기 때문에 항목을 systemd캐시합니다 .NODATA
중간 서버는 쿼리를 캐시하지 않으므로 ANY로컬 서버는 권한 있는 서버로부터 응답을 받습니다.
또는 그런 것. 실제로 이러한 것들이 어떻게 작동하는지 아는 사람이 이를 더 잘 설명할 수 있는 경우를 대비하여 이 질문에 대한 답변을 보류하고 있습니다.