프로그래밍

cert-manager 삽질기 : propagation check failed... returned REFUSED for _acme-challenge ...

2kindsofcs 2020. 10. 27. 11:42

내가 하려던 것은 A라는 주소로 접속하면 B라는 주소로 리디렉션 되도록 쿠버네티스와 cert-manager 등을 이용해서 처리하는 것이었다. 

그런데 설정 파일들이 다 멀쩡한데 propagation check failed 에러가 떴다.

거의 동일한 형태의 설정 파일로 테스트를 했을 때는 멀쩡히 잘 되었는데, (C라는 주소로 입력하면 D라는 주소로 리디렉션 되도록) 

왜 이런 에러가 나는지 도통 알 수가 없었다.

결과적으로 --dns01-recursive-namserver 와 --dns01-recursive-nameservers-only 이 2개의 플래그를 쓰는 것으로 해결되기는 했다. 

Setting Nameservers for DNS01 Self Check

cert-manager will check the correct DNS records exist before attempting a DNS01 challenge. By default cert-manager will use the recursive nameservers taken from /etc/resolv.conf to query for the authoritative nameservers, which it will then query directly to verify the DNS records exist.

If this is not desired (for example with multiple authoritative nameservers or split-horizon DNS), the cert-manager controller exposes two flags that allows you alter this behavior:

--dns01-recursive-nameservers Comma separated string with host and port of the recursive nameservers cert-manager should query.

--dns01-recursive-nameservers-only Forces cert-manager to only use the recursive nameservers for verification. Enabling this option could cause the DNS01 self check to take longer due to caching performed by the recursive nameservers.

cert-manager 저장소의 소스코드를 다운받아서 살펴봤지만, 딱히 "아 이녀석이구나!" 싶은 부분은 없었다.
한참 코드를 보다가, 다시 원점으로 돌아와서 공식 문서를 다시 봤다. 

 

 (for example with multiple authoritative nameservers or split-horizon DNS), the cert-manager controller exposes two flags that allows you alter this behavior:

 

recursive nameserver란 여러 dns 서버 중 하나인데 유저가 웹브라우저에 url을 입력했을 때 그 url을 먼저 받는다.

만약 해당 url에 대응하는 IP를 알고 있으면 (캐시에 있으면) IP를 바로 리턴하겠지만,

만약 없다면 root server, TLD server, authoritative nameserver와 요청을 주고받아서 IP를 알아낸 뒤 리턴할 것이다.

(그리고 이렇게 알아낸 IP는 캐시해둔다.)

 

authoritative nameserver는 이름에서도 짐작되듯이 한마디로 정말 답을 알고 있는 네임서버다.

DNS 쿼리에 대한 온전한 답을 제공한다.

어디서 캐시해둔 거나 누구한테 물어본 걸 전해주는 게 아니라 얘가 그냥 정말 답을 알려주는 거다. 

 

Route 53에 들어가서 호스팅 영역 정보를 다시 확인했다.

호스팅 영역 세부 정보의 이름 서버와 문제가 된 도메인의 NS 레코드의 값/트래픽 라우팅 대상이 달랐다.

4개의 이름 서버 주소가 각각 있는데, 1개는 동일한데 나머지 3개가 달랐다. 

AWS 문서를 찾아보니 아니나다를까, 호스팅 영역 세부 정보에 보이는 이름 서버는 authoritative nameserver였다.

Route 53 name servers are the authoritative name servers for every domain that uses Route 53 as the DNS service. The name servers know how you want to route traffic for your domain and subdomains based on the records that you created in the hosted zone for the domain. (Route 53 name servers store the hosted zones for the domains that use Route 53 as the DNS service.) 

결국 cert-manager는 잘못된 authoritative nameserver에 DNS 쿼리를 날린 것이다. 그래서 아래 두 줄을 추가하니까 해결되었던 것이다.

- --dns01-recursive-nameservers="8.8.8.8:53"
- --dns01-recursive-nameservers-only

참고로 8.8.8.8:53은 구글의 public dns server다.

즉 잘못된 authoritative nameserver에 dns 쿼리를 날리는 게 아니라 구글의 public dns server에 dns 쿼리를 날려서,

이 친구가 준 값을 써서 해결이 된 것으로 보인다. 

 

어우 속이 다 시원하네.

 

 

 

관련 링크들) 

https://umbrella.cisco.com/blog/what-is-the-difference-between-authoritative-and-recursive-dns-nameservers

 

What is the difference between authoritative and recursive DNS nameservers?

Which type of domain name system (DNS) servers form the foundation of the internet? Why is DNS called the "phone book" of the internet? Read on to find out

umbrella.cisco.com

https://cert-manager.io/docs/configuration/acme/dns01/

 

DNS01

Automatically provision and manage TLS certificates in Kubernetes

cert-manager.io

https://letsencrypt.org/docs/challenge-types/

 

Challenge Types - Let's Encrypt - Free SSL/TLS Certificates

Auf Deutsch ansehen Ver en español Voir en Français לעבור לעברית 日本語で表示する 한국어로 보기 Просмотреть на русском 使用简体中文阅读本网页。 使用正體中文閲讀本網頁。 Last updated: Fe

letsencrypt.org

 

 

반응형