dnsmasq가 사설 DNS 응답을 버린다: 원인은 rebinding 보호인가?

회사 DNS 서버는 예상한 사설 주소를 돌려주는데도 로컬 전달 리졸버를 거친 질의는 실패한다. 응답은 존재하므로 상위 영역과 레코드 자체는 배제된다. 남는 것은 리졸버가 그 응답을 클라이언트에 돌려줄지 결정하는 단계다. 그 리졸버가 dnsmasq라면 거부는 이미 로그에 있을 가능성이 크다.

응답을 받는 것과 그것을 돌려주기로 정하는 것은 서로 다른 단계다.

두 리졸버에서 같은 이름을 비교하라

애플리케이션이 실제로 어느 리졸버를 쓰는지, 어떤 호스트 이름을 묻는지 적어 두라. 그다음 상위 결과와 전달 리졸버의 같은 이름에 대한 이벤트를 비교하라. 상위 응답이 없는 경우, 캐시된 부정 응답, 로그에 남은 거부는 각각 다른 세 가지 조치를 요구한다.

직접 진단 질의에서 보이는 주소는 애플리케이션이 평소 경로로 그것을 받았다는 증거가 아니다. 두 질의는 서로 다른 리졸버에서 나올 수도 있고, 같은 리졸버라도 다른 정책 아래에서 나올 수 있다. 추측하기 전에 두 결과를 모두 적어 두라. 바로 이 단계에서 사람들이 하나를 다른 것으로 바꿔치기한다. 비교가 곧 진단의 전부다.

증상이 아니라 거부를 읽어라

dnsmasq의 stop-dns-rebind 옵션은 상위에서 들어온 조건에 맞는 사설 주소 응답을 거부하고, 그럴 때 로그에 남긴다. 이 보호에는 정당한 이유가 있다. 공개 이름이 갑자기 사설 주소로 해석되는 것이 바로 고전적인 rebinding 공격이다. 다만 의도적으로 사설인 서비스와도 부딪힌다. 이번 사례가 바로 그렇다.

무엇이든 바꾸기 전에 로그에서 거부를 찾아라. 메시지가 메커니즘의 이름을 알려 준다.

거부도 없고 상위 응답도 없다면 rebinding 보호는 원인이 아니다. 그것을 끄면 아무것도 고치지 못하고 노출만 넓어진다. 이는 원래 고장보다 나쁘다. 통제 하나를 없애고 결함을 그대로 두기 때문이다. 먼저 구체적인 로그 줄을 확인하라. 그다음 결정하라.

예외를 한 도메인으로 좁혀라

검증된 도메인에 대해 dnsmasq 설명서는 전역 스위치가 아니라 도메인으로 한정된 예외를 제공한다.

rebind-domain-ok=corp.example

위의 도메인은 예시일 뿐이다. 실제로 운영하는 관리 도메인을 쓰고, 적용 전에 이 옵션의 일치 범위를 이해하라. 접미사 규칙은 시험한 호스트 하나보다 넓게 걸린다. 라우터의 설정 생성기는 원시 지시문 대신 자체 화면으로 같은 설정을 내보낼 수도 있다. 최종 범위가 의도한 것이면 어느 쪽이든 좋다.

rebinding 탐지에 대한 예외가 하는 일은 정확히 하나다. 그 도메인의 응답을 통과시킨다.

그것은 split-DNS 전달자를 설정하지도, 도달할 수 없는 상위를 도달 가능하게 만들지도, 반환된 주소로 가는 경로를 만들지도 않는다. 각각은 저마다의 고장 특징을 지닌 별개의 요구 사항이고, 클라이언트에서도 다르게 실패한다.

경계를 없애지 않고 검증하라

호스트 이름을 전달 경로로 다시 질의하고, 그다음 서비스에 평소의 신원 확인을 붙여 연결하라. DNS 예외는 예상치 못한 인증서를 받아들일 이유가 아니며, 둘 다 브라우저 오류로 나타날 때는 혼동하기 쉽다. 이름과 서비스를 따로 시험하라. 둘 중 하나만이 언젠가 DNS 문제였다.

예외의 이유를 설정 옆에 날짜와 담당자와 함께 남겨라.

사설 서비스가 옮겨 가거나 도메인이 바뀌면 다시 점검하라. 보호를 전역으로 끄면 무관한 응답의 처리 방식까지 바뀌고, rebinding이 원인이 아니었다면 경로나 서비스의 고장은 그대로 남는다.