1.1.1.1은 누가 운영하는가? 신뢰하기 전에 DNS 주소 확인하기

1.1.1.1을 VPN의 DNS 필드에 붙여 넣었고 페이지가 열렸으며, 이제 튜토리얼이 확인된 것처럼 보인다. 그 관찰은 느껴지는 것보다 좁다: 애플리케이션이 다르게 동작했고, 그 변경은 아직 누가 질의에 응답했는지, 왜 예전 설정이 실패했는지에 대해 아무것도 말하지 않는다. 복사한 튜토리얼은 잘 알려진 공용 주소를 “VPN의 DNS”라고 부르곤 하는데, 이는 도달 가능성이 아니라 소유권에 관한 주장이다. 주소가 무엇을 나타내는지 확인하는 데는 오 분이 걸리고, 잘못된 이유로 하는 영구 변경을 막는다.

작동하는 설정은 정체성이 아니다

설정 필드의 주소는 하나의 종단점이고, 종단점에는 운영자가 있다. 이 두 사실은 별개이며, 사람들이 건너뛰는 것은 두 번째다. 가장 자주 복사되는 쌍의 경우 답은 공개되어 있다: Cloudflare는 1.1.1.1과 1.0.0.1을 자사 확인자 주소로 공개하고, 자사의 공식 주소 참조 문서에 이를 나열한다. 그래서 운영자의 이름은 별도 튜토리얼이 아니라 주소 옆에 있어야 한다.

터널이 켜진 상태에서 그 쌍을 입력한다고 해서 VPN 회사가 그 운영자가 되지 않고 트래픽이 익명이 되지도 않는다. 질의는 주소 범위를 공개한 회사를 향해 여러분의 컴퓨터를 떠나며, 그 회사는 평판이 좋을 수 있지만 튜토리얼이 암시한 당사자는 아닐 수 있다. 지침의 라벨과 현실의 운영자는 서로 다른 주장이다. 어느 쪽도 그 사이의 네트워크 경로를 누가 운영하는지 말해 주지 않는다.

주소 쌍이나 암호화된 종단점을 확인하려면 확인자 자체가 공개한 참조를 사용하라. 다른 공급업체의 추천은 정당할 수 있으며, “추천함”, “경유함”, “운영함”은 여전히 서로 다른 세 가지 관계를 뜻한다.

기록에 필요한 세 가지를 비교하라

검토 준비가 된 기록은 세 가지 질문을 분리한다: 누가 질의를 받아야 하는지, 교환이 평문인지 암호화되었는지, 어느 경로가 이를 실어 나를지다. 공급업체 이름으로는 두 번째나 세 번째를 채울 수 없고, 국가 라벨로는 어느 것도 채울 수 없다. 변경 전에 세 항목을 적고 나중에 비교하라. 그 항목들은 서로 바꿀 수 없으며, 이를 하나로 취급하는 것이 추측이 문서가 되는 방식이다.

작동하는 설정을 문서화된 결정으로 바꾸는 것은 비교다. 비교가 없으면 다음 사람은 아무 이유도 붙지 않은 주소를 물려받는다. 아래 표의 세 번째 열을 먼저 읽어라, 대부분의 자신 있는 설명이 실제로 멈추는 곳이기 때문이다.

표는 의도적으로 짧다. 요점은 각 항목이 서로 다른 질문에 답하며, 단일 필드가 세 가지를 모두 채우지 않는다는 것이다.

로컬 포워더는 실제 업스트림을 숨긴다

라우터를 DNS로 쓰도록 설정된 장치는 포워더를 가리킨다. 그 주소는 질의의 다음 수신자를 식별할 뿐, 결국 응답하는 확인자를 가리키지 않는다. 로컬 스텁 확인자는 같은 추가 단계를 더한다, 그리고 모든 상태 출력에 나타나기 때문에 실제와 혼동하기 쉽다.

스텁은 같은 출력에도 나열되는 업스트림으로 전달하며, 보통 더 아래에 있다. 운영자에 대해 무엇이든 결론 내리기 전에 체인 전체를 읽어라, 첫 줄이 답 전체는 아니기 때문이다. 그렇지 않으면 안내 데스크를 회사라고 부르는 셈이다.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

두 번째 명령은 확인자가 에코 이름을 공개한 경우 이를 사용해 자신이 보는 출발지 주소를 보고한다. 세 번째는 응답한 서버를 지목하는데, 이는 종종 여러분이 설정한 주소가 아니다. 운영자를 적기 전에 세 출력을 모두 비교하라.

암호화된 DNS는 무엇이 보이는지를 바꾸지, 누가 보는지를 바꾸지 않는다

DNS over HTTPS와 DNS over TLS는 클라이언트와 확인자 사이의 교환을 보호한다. 확인자는 여전히 요청받은 모든 이름을 읽는다, 응답하는 것이 일이기 때문이다. 달라지는 것은 누가 교환을 지켜볼 수 있는지다: 로컬 네트워크는 평문 질의의 흐름이 아니라 하나의 종단점에 대한 연결을 본다.

달라지지 않는 것은 신뢰 관계이며, 이는 여전히 그 종단점을 운영하는 조직을 가리킨다. 자체 보안 DNS 설정이 있는 브라우저는 운영체제 확인자를 완전히 우회할 수 있다. 이 둘을 두 번 적용된 하나의 설정이 아니라 서로 어긋날 수 있는 두 구성으로 다루어라.

사설 이름은 다시 자체 결정이 필요하다. 업무 터널은 선택된 도메인을 조직 확인자로 라우팅할 수 있고, 이를 공용 서비스로 바꾸면 내부 조회가 깨지거나 내부 이름이 잘못된 당사자에게 노출될 수 있다. 어댑터 전체의 설정을 바꾸기 전에 도메인 정책을 확인하라.

관찰을 좁게 유지하라

비교할 때는 예전 구성을 보존하고 한 번에 하나의 설정만 바꿔라. 애플리케이션, 작업, 확인자 정책, 그리고 재연결 후에도 공용 및 허용된 사설 이름이 여전히 해석되는지를 기록하라. 두 가지 변경이 들어간 비교는 어느 것도 증명하지 못한다. 결과는 다음 사람이 찾을 수 있는 곳, 설정 바로 옆에 적어라.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

애플리케이션이 작동하기 시작하면 증거가 허락하는 만큼만 주장을 작게 유지하라. 그 변경은 한 번의 테스트에 도움이 되었을 뿐, 이전 확인자가 악의적으로 행동했는지, 터널이 고장 났는지, 다른 장치도 같은 교체가 필요한지는 말해 주지 않는다. 오래 남는 결과는 운영자와 목적을 설명할 수 있는 구성이다.