본문으로 건너뛰기
azure검색
운영, 보안, 비용

Private Endpoint DNS 이름 확인 실패 (증상, 원인, 해결)

Private Endpoint 를 만들었는데 이름이 공인 IP 로 풀리거나, 403 이나 타임아웃이 나는 경우를 증상, 원인, 해결 순서로 정리합니다. nslookup 결과 읽는 법, Private DNS 영역 링크 누락, 사용자 지정 DNS 서버, 온프레미스 조건부 전달, 하위 리소스 누락, 중복 영역 문제를 다룹니다.

Private EndpointDNSprivatelink트러블슈팅nslookupDNS Private Resolver2026-10 기준, 약 9분

증상

Private Endpoint 를 만들고 PaaS 의 공용 네트워크 액세스를 끈 뒤 이런 에러가 납니다.

# 스토리지
This request is not authorized to perform this operation. (403 AuthorizationFailure)
# Key Vault
Public network access is disabled and request is not from a trusted service nor via an approved private link. (403 Forbidden)
# SQL Database
Reason: An instance-specific error occurred while establishing a connection to SQL Server.
Connection was denied because Deny Public Network Access is set to Yes.

공통점은 요청이 Private Endpoint 가 아니라 공용 엔드포인트로 갔다는 것입니다. 공용 액세스를 꺼 두었으니 거부됩니다. 네트워크 규칙을 아무리 바꿔도 DNS 가 공인 IP 를 주는 한 해결되지 않습니다. 이름 확인 원리는 Private Endpoint 와 Private DNS에 그림으로 있습니다.

먼저 확인: 이름이 무엇으로 풀리나

문제가 나는 바로 그 VM, 컨테이너, 앱 안에서 확인합니다. 내 PC 에서 확인하면 다른 DNS 경로라 의미가 없습니다.

nslookup stshopprodkrc.blob.core.windows.net
결과뜻
stshopprodkrc.privatelink.blob.core.windows.net 별칭 + 10.x.x.x정상. DNS 는 문제 아님. NSG, 방화벽, 경로 확인
privatelink 별칭 + 공인 IPPrivate DNS 영역을 못 봄 (원인 1~3)
privatelink 별칭 없이 공인 IPPrivate Endpoint 가 없거나 승인 대기, 또는 다른 하위 리소스 이름으로 접근 (원인 4)
사설 IP 인데 예전 IP영역의 A 레코드가 낡음 (원인 5)

App Service 와 Functions 는 Kudu 콘솔이나 SSH 에서 nameresolver stshopprodkrc.blob.core.windows.net 으로 확인합니다(Windows 앱). AKS 는 디버그 파드에서 nslookup 합니다.

원인과 해결

원인 1. Private DNS 영역이 질의하는 VNet 에 링크되지 않음

Private DNS 영역은 링크된 VNet 에서만 보입니다. Private Endpoint 는 허브에 만들었는데 앱은 스포크 VNet 에 있고, 영역이 허브에만 링크된 경우가 대표적입니다.

az network private-dns link vnet list -g rg-dns-prod -z privatelink.blob.core.windows.net -o table
az network private-dns link vnet create -g rg-dns-prod -z privatelink.blob.core.windows.net \
  -n link-spoke-a -v <spoke-vnet-id> -e false

해결: 스포크 VNet 을 영역에 링크하거나, 스포크의 DNS 서버를 허브의 DNS Private Resolver 인바운드 IP 로 지정합니다.

원인 2. 사용자 지정 DNS 서버가 Azure DNS 로 전달하지 않음

VNet 의 DNS 서버를 사내 DNS(예: AD DNS 서버 VM)로 바꿔 두었다면, 그 서버가 blob.core.windows.net 질의를 168.63.129.16(또는 Resolver)로 전달해야 합니다. 인터넷 DNS 로 전달하면 공인 IP 가 나옵니다.

해결: 사내 DNS 에 조건부 전달자를 추가합니다. 전달 대상 영역은 privatelink.blob.core.windows.net 이 아니라 blob.core.windows.net(공용 영역 이름) 으로 두는 것이 안전합니다. CNAME 체인의 첫 질의부터 Azure 쪽에서 풀어야 하기 때문입니다. 168.63.129.16 은 Azure VNet 안에서만 닿는 주소이므로, 사내 DNS 가 Azure VM 위에 있을 때만 직접 쓸 수 있습니다.

원인 3. 온프레미스에서 접근

온프레미스 PC 와 서버는 Azure Private DNS 영역을 직접 볼 수 없습니다.

해결: 허브에 DNS Private Resolver 를 만들고, 온프레미스 DNS 에서 blob.core.windows.net, database.windows.net, vaultcore.azure.net 같은 공용 영역 이름을 Resolver 인바운드 엔드포인트 IP 로 조건부 전달합니다. VPN 이나 ExpressRoute 경로로 그 IP 에 53 포트가 열려 있어야 합니다 (허브 스포크).

원인 4. 하위 리소스용 Private Endpoint 가 없음

스토리지 계정의 Blob 용 Private Endpoint 만 만들고 ADLS Gen2 경로(dfs.core.windows.net)나 Files(file.core.windows.net)로 접근하는 경우입니다. Foundry 리소스처럼 여러 FQDN 을 쓰는 서비스도 마찬가지입니다. 또 Private Endpoint 연결이 승인 대기(Pending) 이면 CNAME 이 생기지 않을 수 있습니다.

해결: 쓰는 하위 리소스마다 Private Endpoint 와 해당 Private DNS 영역을 만들고, 연결 상태가 Approved 인지 확인합니다.

az network private-endpoint-connection list --id $(az storage account show -n stshopprodkrc --query id -o tsv) \
  --query "[].{name:name, status:properties.privateLinkServiceConnectionState.status}" -o table

원인 5. A 레코드가 낡음, 영역이 둘

  • Private Endpoint 를 지우고 다시 만들면 사설 IP 가 바뀝니다. A 레코드를 손으로 넣었다면 예전 IP 를 가리킵니다.
  • 같은 이름의 Private DNS 영역(privatelink.blob.core.windows.net)이 여러 구독에 있고 각각 다른 VNet 에 링크되면, VNet 마다 다른 답이 나옵니다. 한 VNet 에 같은 이름의 영역 두 개를 링크할 수는 없어서, 새 영역을 링크하려다 실패하기도 합니다.

해결: DNS 영역 그룹(private-endpoint dns-zone-group)으로 레코드를 자동 관리하고, 영역은 connectivity 구독에 한 벌만 둡니다. Azure Policy 의 DeployIfNotExists 로 새 Private Endpoint 가 중앙 영역에 등록되게 합니다.

원인 6. 캐시

DNS 를 고친 뒤에도 클라이언트와 중간 DNS 서버가 예전 답(공인 IP)을 TTL 동안 기억합니다.

해결: Windows ipconfig /flushdns, Linux 는 resolvectl flush-caches, 앱은 재시작(연결 풀과 DNS 캐시를 가진 런타임이 많음). 사내 DNS 서버의 캐시도 비웁니다.

DNS 가 정상인데도 안 될 때

nslookup 이 사설 IP 를 주는데도 연결이 안 되면 이제 네트워크 차례입니다.

  1. NSG: Private Endpoint 서브넷의 NSG 는 서브넷의 Private Endpoint 네트워크 정책을 켜야 적용됩니다. 켰다면 출발지에서 443(또는 1433, 5432)을 허용하는지 확인합니다.
  2. UDR 과 방화벽: 스포크에서 허브 방화벽을 거친다면 방화벽 규칙과 돌아오는 경로가 대칭인지 봅니다.
  3. 포트: Azure SQL 은 연결 정책(Redirect)에 따라 1433 외에 11000~11999 포트가 필요할 수 있습니다. Private Endpoint 경유는 보통 Proxy 로 동작하지만 문서를 확인합니다.
  4. Network Watcher 의 연결 문제 해결로 출발지에서 사설 IP:포트까지 시험합니다.

예방 체크리스트

  • privatelink 영역은 중앙 한 벌, 모든 VNet 이 링크되거나 Resolver 를 DNS 로 사용
  • Private Endpoint 는 DNS 영역 그룹으로 생성 (손으로 A 레코드 넣지 않기)
  • 쓰는 하위 리소스 목록을 설계 문서에 적기 (blob, dfs, file, queue ...)
  • 온프레미스 조건부 전달은 공용 영역 이름 기준
  • 변경 뒤 앱 안에서 nslookup 으로 확인하는 절차를 런북에

공식 문서

이 문서에서