AWS 도메인 방화벽의 빈틈: DNS 응답 IP와 접속 목적지를 함께 확인하기

이름을 허용했는데 목적지는 다른 곳일 수 있다

정산 파일을 매일 파트너에게 보내는 서버가 있다고 하자. HTTPS API는 api.partner.example로, SFTP 파일 전송은 files.partner.example로 나가야 한다. 담당자가 원하는 것은 간단하다. 파트너가 서버 주소를 바꿔도 업무는 계속하고, 그 이름을 붙인 엉뚱한 연결은 막고 싶다.

기존 웹 도메인 규칙은 HTTP의 Host나 TLS의 SNI처럼 클라이언트가 제시하는 이름을 볼 수 있다. SNI는 TLS 연결을 시작할 때 접속하려는 서버 이름을 전달하는 정보다. 그러나 그 문자열과 실제 목적지 IP가 올바른 짝인지는 별개다. SFTP처럼 통신에 도메인 이름이 실리지 않는 경우에는 이름만으로 같은 검사를 적용하기도 어렵다. 기능 개요

AWS는 2026년 10월 21일 Route 53 Resolved IP Validation을 출시했고, 10월 27일 상세 활용 글을 공개했다. Route 53 Resolver의 DNS 응답을 Network Firewall과 연결해 접속 목적지를 검사하는 기능이다. 공급자는 두 서비스가 제공되는 상용 리전에서 추가 기능 요금 없이 제공한다고 안내한다. 이것이 방화벽 운영 전체가 무료라는 뜻은 아니다. 출시 공지

이 글은 10월 28일 확인한 관리형 서비스 문서를 바탕으로 한 분석이다. AWS 계정에서 설정하거나 패킷을 전송한 실험은 아니다. 아래 도메인·주소·업무 상황은 설명용이며, 바로 배포할 방화벽 정책 파일도 아니다.

정책의 질문과 규칙의 질문은 다르다

새 기능을 하나의 “도메인 검증 스위치”로 읽으면 허용 범위가 넓어진다. 공식 개요는 두 단계를 구분한다.

검사 단계	묻는 질문	통과해도 아직 모르는 것
정책의 resolved IP validation	이 목적지 IP가 범위 안의 Resolver 응답에 있었나?	우리가 허용한 파트너 도메인의 주소인지
규칙의 resolved-domain matching	이 IP가 지정한 도메인의 응답에 있었나?	서버 인증·업무 권한·전송 내용의 적절성

정책 검사는 새 연결의 첫 패킷에서 수행되고, 도메인별 규칙은 상태 기반 규칙에서 특정 이름과 연결된 주소를 판별한다. 어떤 이름으로든 조회된 주소와 허용한 이름으로 조회된 주소는 다르다. 후자의 규칙을 사용하려면 정책 설정도 필요하다. 처리 구조

이 차이를 가상 주소 세 개로 살펴보자. 같은 지원 가용 영역에서 현재 유효한 응답 집합에 파트너 주소 203.0.113.10, 다른 도메인의 주소 198.51.100.20이 있다고 가정한다. 192.0.2.30은 이 집합에 없다. 아래 표는 다른 pass 규칙이 없고, 필요한 파트너 규칙만 허용하며 나머지를 차단하도록 구성했다는 조건이다.

연결 상황	정책의 응답 이력 검사	파트너 도메인 규칙	이 구성에서의 판단
파트너 IP로 TCP 22 SFTP 전송	통과	이름·포트 조건 일치	허용 후보. 실제 인증·전송 성공은 따로 확인
다른 도메인 IP에 파트너 SNI를 붙임	통과	파트너 주소가 아니므로 불일치	정책 통과만 믿으면 놓침. 특정 규칙과 기본 차단이 필요
조회 이력 없는 IP에 파트너 SNI를 붙임	실패	파트너 주소에도 해당 없음	정책 Drop/Reject라면 앞 단계에서 차단
파트너와 다른 사이트가 같은 IP 사용	통과	목적지 주소 조건은 일치	주소만으로 두 사이트를 구별할 수 없음

표의 두 번째 행이 가장 중요한 반례다. route53_resolved_ip: true가 있어도 “파트너 연결이 허용됐다”는 뜻은 아니다. 마지막 행은 CDN 같은 공유 주소 환경에서 생기는 별도 문제다. HTTPS에서 파트너 이름까지 요구하려면 같은 규칙에 정확한 SNI 조건을 함께 넣는 방식이 필요하다. 공식 규칙 문서는 tls.sni, startswith, endswith와 aws_route_53_resolved_domain을 조합한다. 이름 일부가 들어 있다는 조건만으로 정확한 일치를 대신해서는 안 된다. 도메인 규칙 문서

SFTP에서는 DNS 응답 IP와 TCP 포트를 묶어 주소 변경을 따라갈 수 있다는 것이 실용적 이점이다. 다만 그것이 SSH 호스트 키 확인을 대신하지는 않는다. HTTPS의 인증서 검증도 계속 필요하다. 여기서 추가한 것은 목적지 선택의 근거이며, 애플리케이션의 서버 신뢰나 사용자 권한을 모두 판정하는 기능은 아니라는 분석이다.

“누군가 조회한 주소”를 공유하는 범위

DNS Firewall rule group은 이 기능에서 어느 VPC의 DNS 응답을 참고할지 정하는 역할도 한다. 그룹 자체에 DNS 차단 규칙이 없어도 사용할 수 있다. 정책을 설정하는 Network Firewall과 그룹을 관리하는 Route 53 Resolver DNS Firewall은 같은 화면의 같은 규칙 목록이 아니다. 시작 절차

연결한 VPC들의 응답은 공유 집합에 들어간다. 방화벽을 통과하지 않는 VPC라도 그룹에 연결돼 있으면 응답을 보탤 수 있다. 실제 검증은 가용 영역(AZ) 범위에도 묶인다. 따라서 결과를 “이 프로세스가 이 이름을 직접 조회했다”는 증명으로 읽으면 안 된다. 응답 집합과 AZ 범위

예를 들어 결제망과 실험용 VPC가 같은 그룹을 편의상 공유한다고 하자. 실험용 VPC의 조회가 정책 검사에서 유효한 목적지를 넓힐 수 있다. 독자가 정할 대상은 도메인 목록뿐 아니라 응답을 제공할 VPC의 목록이다. AWS도 서로 무관한 방화벽 배포에 같은 그룹을 재사용하지 말라고 권한다. 이 사례는 그 권고를 조직 구조에 적용한 가상 판단이다. 구성 권고

또한 이 기능을 켰다고 외부 DNS, DoH, DoT 사용이 자동 차단되지는 않는다. DNS 질의 자체의 허용 정책과 연결 목적지 검사는 함께 설계해야 한다. 특히 공개 리졸버 주소가 DNS 응답 집합에 들어갔다고 그곳을 통한 이름 조회까지 신뢰할 이유는 없다. AWS 활용 글의 Best practices

Alert로 시작해도 새 규칙이 모두 관측 모드가 되지는 않는다

도입에서 가장 주의할 조합은 정책 Action=Alert와 resolved-domain 규칙의 동시 추가다. Alert는 정책 단계의 검증 실패로 연결을 막지 않는 설정이다. 기존 규칙과 기본 차단까지 무효화하는 전체 방화벽의 관측 모드는 아니다.

더 구체적인 예외도 있다. 현행 문제 해결 문서는 미지원 AZ에서는 resolved-domain 규칙이 검사하는 트래픽을 정책 Action이나 규칙의 action과 관계없이 drop한다고 명시한다. 따라서 먼저 해당 범위에서 DnsAzUnavailableFlows가 0인지 확인하고, 그다음 도메인 규칙을 추가해야 한다. 특정 클라이언트를 정책의 source 범위에서 뺐다는 이유로 규칙까지 안전하게 빠졌다고 생각해서도 안 된다. 미지원 AZ 동작 · 범위 설정의 적용 단계

분산 배포에서는 클라이언트와 방화벽 엔드포인트의 AZ가 맞아야 한다. 중앙 검사 구조라면 클라이언트의 AZ 정보를 전달하는 Transit Gateway에 직접 연결된 방화벽을 검토한다. 단순히 경로 어딘가에 Transit Gateway가 있다는 뜻으로 확대하지 않는다. AZ별 구성 권고

문서를 업무 변경 순서로 바꾸면 다음과 같다. 실제 콘솔을 실행해 검증한 절차가 아니라, 공식 설정 위치와 관측 조건을 연결한 도입 계획이다.

순서	볼 위치·정보	다음 단계로 갈 조건
1. 대상 한정	DNS Firewall rule group의 Associated VPCs, 클라이언트 DNS 경로	관련 VPC만 포함하고 Resolver로 질의하는지 확인
2. 정책 관측	Network Firewall 정책의 Route 53 Resolved IP validation: Alert, source 범위, expiry 동작	flow 로그가 들어오고 대상 연결이 실제 검사됨
3. AZ·캐시 확인	DnsAzUnavailableFlows, DnsUnresolvedFlows, 정상 업무 시간대의 flow	미지원 AZ 문제 해결, 기존 캐시의 재조회와 정상 연결 확인
4. 규칙을 작게 추가	도메인·프로토콜·포트, 기존 pass 규칙과 기본 동작	정상 파트너는 통과, 다른 목적지는 의도대로 차단
5. 정책 강제 전환	Action을 Drop/Reject로 바꾸기 전 관측표	남은 실패의 원인·예외·담당자와 되돌릴 기준이 설명됨

AWS는 캐시 갱신을 위해 약 24시간 Alert 관측을 권한다. 이는 모든 앱이 24시간 뒤 반드시 새로 조회한다는 보증이 아니다. 야간 정산만 실행하는 앱이라면 그 업무 주기가 관측에 포함돼야 한다는 것이 이 글의 제안이다. 공식 시작 절차

TTL, 장기 연결, 고정 IP는 서로 다른 예외다

기능을 켜기 전 얻은 주소를 앱이 아직 쓰고 있다면 정상 목적지도 새 응답 집합에 없을 수 있다. 반대로 이 기능의 resolved IP cache는 DNS 레코드의 TTL보다 오래 응답을 유지한다. “TTL이 지났으니 이전 주소는 즉시 차단된다”는 모델은 맞지 않는다. 이미 열린 연결의 캐시 만료에는 DNS expiry exception policy가 적용되고, 캐시에서 만료된 목적지로 새 연결을 만드는 문제와 구분해야 한다. 정책 설정 · 캐시 관련 진단

정산 전송이 오래 걸리는 팀은 전송 중 만료 시 Continue를 택할지, 연결 중단을 받아들일지 결정해야 한다. Continue는 이 만료 이유만으로 기존 연결을 끊지 않는 선택이지, 이후 모든 목적지를 허용하는 선택이 아니다. 재접속 후 파일 중복이나 누락이 없는지도 업무 쪽에서 확인해야 한다.

DNS를 쓰지 않는 합법적인 고정 IP 목적지는 bypass destination 범위를 검토할 수 있다. 하지만 bypass는 정책 단계만 면제하며 도메인 규칙을 면제하지 않는다. 반대로 일반 stateful pass 규칙도 앞선 정책 검사의 실패를 면제하지 않는다. 예외를 적을 때는 “허용” 한 단어 대신 어느 단계에서 무엇을 건너뛰고 어느 규칙은 남는지 적어야 한다. 정책 범위와 bypass · 검사 순서

로그 한 값으로 성공이나 공격을 단정하지 않는다

route53_resolved_ip는 연결의 원래 진행 방향에서 검사한 결과다. true를 서버 신원이나 최종 허용의 증거로 쓰면 앞선 표의 다른 도메인 사례를 놓친다. false도 공격이라는 결론이 아니다. 아직 채워지지 않은 캐시, 미지원 AZ, 경로 문제 등을 지표와 대조해야 한다. 해석할 필드가 없는 오류도 있으므로 누락을 임의로 true나 false로 채우지 않는다. 로그 필드 정의

정책의 Alert 설정만으로 독립된 alert 로그가 생기는 것도 아니다. flow 로그의 검증 값과 DnsUnresolvedFlows, DnsAzUnavailableFlows, DnsResolutionErrorFlows를 함께 본다. alert 로그는 해당 규칙·기본 action이 기록하도록 설정됐는지 따로 확인한다. 정책 상태가 ACTIVE라도 비동기로 발견한 설정 오류가 DescribeFirewallPolicy의 Errors에 남을 수 있다. 설정 저장 성공과 실제 검사 준비를 나눠 확인할 이유다. 모니터링과 설정 오류

다음은 운영 값을 넣기 전의 빈 도입 기록지다. 관측하지 않은 칸은 미확인으로 남긴다. 복사해 쓰거나 텍스트 파일로 저장할 수 있다.

업무·담당자 / 정상 연결이 필요한 시간대:
클라이언트 source 범위 / DNS 경로 / 클라이언트와 검사 지점의 AZ:
DNS Firewall 그룹 / 연결된 VPC 전체 / 관련 없는 VPC 제외 확인:
허용 도메인·프로토콜·포트 / 공유 IP에서 추가로 요구할 이름 조건:
정책 Action / 규칙 순서·기본 동작 / 기존의 넓은 pass 규칙:
정상 전송·다른 목적지·미조회 IP·재접속 각각의 관측:
flow 검증 값 / 최종 action / AZ·미해결·해석 오류 지표:
고정 IP 예외의 정책 단계 / 별도로 남는 규칙 / 예외 만료일:
캐시 만료 중 연결 처리 / 중단 후 업무 복구 확인:
강제 전환 조건 / 중단 기준 / 복원할 기존 정책·규칙 버전:

이 기록지에서 정상 전송의 실패 원인이 아직 미확인이라면 차단 전환을 미룰 근거가 된다. 미지원 AZ에서 문제가 생겼다면 Action만 Alert로 되돌리는 것으로 resolved-domain 규칙의 차단을 없앨 수 없다. 해당 규칙과 경로를 포함한 복원 범위를 따로 정해야 한다. 반대로 잘못된 목적지가 통과하면 정책 통과 여부만 보지 말고 넓은 pass 규칙·특정 도메인 조건·기본 동작을 함께 확인한다.

주소가 바뀌는 파트너와 SFTP를 주고받거나, TLS 이름 조건에 목적지 근거를 더하려는 팀에는 이번 기능을 검토할 이유가 있다. 채택 기준은 설정을 켰다는 사실보다 정상 업무가 유지되고, 의도하지 않은 목적지가 어느 단계에서 막히는지 설명할 수 있는가다.

주소 갱신이 늦어지는 원인부터 확인해야 한다면 DNS TTL과 실제 응답 경로 진단을 이어 읽을 수 있다. 서버 인증은 인증서 신뢰 경로 분석에서 별도로 살펴본다. 다음 정책 변경 때 이 기록지를 다시 쓰려면 상단 저장 기능을, 후속 글은 보안 주제 모음과 RSS를 이용할 수 있다.