전 글에서 Nginx를 통해서 https를 설정하던 과정에서 이 https와 DNS는 아무런 관계가 없는지. https 는 인증되는것이 왜 오래 걸리는지 등의 여러가지 궁금증이 생기게 되었고 이김에 DNS와 https등 모든것에 대해 한번 제대로 알아보는 시간을 가지면 좋을 것 같아 정리를 하게 되었다
DNS(Domain Name System)
- 사람이 읽을 수 있는 도메인을 머신이 읽을 수 있는 IP로 변환
DNS 서버 유형
- DNS 리커서
- 웹 브라우저/어플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버
- 클라이언트의 DNS 쿼리를 충족시키기 위하 추가 요청
- 도메인 정보가 없다면 DNS 레코드를 조회하기 위해 재귀적인 검색을 수행
- 권한 있는 네임 서버에 도달할 때 까지 여러 DNS서버에 차례로 요청을 보내서 필요한 IP주소를 찾는다
- 캐싱을 통해서 동일한 요청에 대해 반복적으로 네트워크를 오가며 조회하지 않고 일정 시간 저장해두다가 제공한다
- 루트 이름 서버
- 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환하는 첫번째 단계
- TLD 이름 서버
- TLD(최상위 도메인) 서버는 특정 IP 주소 검색의 다음 단계.
- 호스트 이름의 마지막 부분을 호스팅한다(example.com의 com)
- 권한 있는 이름 서버
- 최종 이름 서버
- 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면 요청한 호스트 이름의 IP주소를 초기 요청을 한 DNS 리커서에게 돌려준다
- 실제로 DNS 리소스 레코드를 보유하고 담당하는 서버이다.
- 다른 웹 자원에 액세스하는데 필요한 IP주소에 도달하도록 요청할 수 있께 한다
- DNS 레코드의 최종 원천이다.
- 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버. 그래서 권한의 의미인 authoritative가 붙는다
- foo.example.com 또는 blog.cloudflare.com과 같은 하위 도메인에 대한 쿼리인 경우 -> 권한 있는 이름 서버 다음의 시퀀스에 추가되어 하위 도메인의 CNAME 레코드 저장을 담당한다
DNS 조회의 8단계:
- DNS 서버 정보 설정:
- 클라이언트(사용자)가 네트워크에 접속하면 ISP(통신사)에서 DNS 서버의 IP 주소를 자동으로 설정해 줍니다. 모든 DNS 서버는 루트 네임 서버의 주소를 알고 있어서, 어디서든 도메인 정보를 찾아낼 수 있습니다.
- 도메인 입력:
- 사용자가 웹 브라우저에 example.com을 입력하면, 이 도메인 이름을 찾기 위한 쿼리가 인터넷으로 보내집니다. 이 쿼리는 DNS 재귀 확인자(Resolver)라는 서버가 받아 처리합니다.
- 루트 네임 서버 요청:
- 재귀 확인자는 도메인의 정보를 찾기 위해 DNS 루트 이름 서버(예: .)에 먼저 쿼리를 보냅니다. 루트 네임 서버는 최상위에 있는 서버로, 각 도메인에 대한 정보를 알 수 있는 TLD 서버의 주소를 제공합니다.
- TLD 서버 주소 받기:
- 루트 서버는 요청한 도메인(example.com)의 최상위 도메인(TLD) 서버인 .com TLD 서버의 주소를 알려줍니다.
- TLD 서버에 요청:
- 이제 재귀 확인자는 .com TLD 서버에 쿼리를 보냅니다. 이 요청을 통해 example.com 도메인 정보를 가지고 있는 권한 있는 이름 서버(Authoritative Name Server)의 주소를 알아냅니다.
- 권한 있는 이름 서버 주소 받기:
- TLD 서버는 example.com의 권한 있는 이름 서버(Authoritative Name Server)의 IP 주소를 DNS 재귀 확인자(Resolver)에게 알려줍니다. 이 서버가 example.com에 대한 최종 정보를 보유하고 있습니다.
- 도메인 이름 서버에 최종 쿼리:
- 재귀 확인자는 example.com의 이름 서버에 쿼리를 보냅니다. 여기에서 example.com에 대한 정확한 IP 주소를 받아옵니다.
- 브라우저에 IP 주소 전달:
- 확인자는 example.com의 IP 주소를 처음 요청한 클라이언트(브라우저)에 응답합니다. 이제 브라우저는 해당 IP 주소를 가지고 웹 페이지 요청을 할 준비가 되었습니다.
- HTTP 요청 전송:
- 브라우저는 DNS 조회로 얻은 IP 주소로 HTTP 요청을 보냅니다. 이 요청은 웹 서버가 웹 페이지를 반환하도록 요청하는 단계입니다.
10.웹 페이지 받기: - 마지막으로, 해당 IP의 웹 서버는 브라우저에 요청한 웹 페이지를 반환합니다. 브라우저는 이 페이지를 화면에 렌더링합니다.
출처: DNS란 무엇입니까? | DNS 작동 원리(Cloudflare)
DNS 캐싱이란?
- 데이터를 임시 저장하여, 데이터 요청에 대해 성능과 신뢰성을 높이는 것입니다
- DNS 캐싱은 요청하는 클라이언트와 가까운 곳에 데이터를 저장함으로써, DNS 쿼리를 조기에 확인할 수 있고 DNS 조회 체인의 추가 쿼리를 피할 수 있으므로, 로드 시간이 향상되고 대역폭/CPU 소비가 줄어듭니다. DNS 데이터는 다양한 위치에 캐시될 수 있으며, 각 위치는 TTL(Time-To-Live)에 의해 정의된 설정 시간 동안 DNS 레코드를 저장
그렇다면 내가 DNS를 등록하는 과정은 어떻게 될까?
- 도메인 이름 등록 요청
- 등록자는 사용하고자 하는 도메인 이름(예: example.com)을 등록하기 위해 등록 대행자(Registrar, 예: Gabia, AWS Route53 등)에 도메인 등록을 요청하고, 수수료를 지불한다
- 도메인 이름 등록
- 등록 대행자는 등록소(Registry)를 통해 도메인 이름을 등록합니다.
- 등록소는 도메인의 소유자를 기록하고, 다른 사용자가 동일한 도메인을 사용할 수 없도록 보호합니다.
- TLD 서버에 등록
- 등록소는 TLD 서버에 해당 도메인의 정보를 등록합니다. 예를 들어, example.com을 등록할 경우, .com TLD 서버에 이 도메인에 대한 정보를 추가합니다.
- 이때 권한 있는 이름 서버(Authoritative Name Server)의 정보도 함께 등록됩니다. 예를 들어, example.com의 권한 있는 이름 서버가 ns1.gabia.net이면, TLD 서버는 이 정보를 기억하여 example.com을 조회하는 사용자가 요청할 때 ns1.gabia.net으로 연결할 수 있게 합니다.
- 권한 있는 이름 서버에 레코드 설정
- 권한 있는 이름 서버에는 도메인의 구체적인 정보를 저장하는 레코드(record)가 설정된다
- example.com 도메인에 대해 IP 주소나 메일 서버 등의 정보가 필요할 때 이 서버에서 최종적인 정보를 제공
- 이 정보를 설정하는 작업은 레코드 추가라고 하며, 각 도메인에 필요한 정보가 포함
레코드란?
레코드는 도메인에 대한 구체적인 정보(예: IP 주소, 메일 서버 등)를 저장하는 데이터입니다. 각 레코드는 타입이 있으며, 이를 통해 다른 DNS 서버와 클라이언트가 해당 도메인에 대해 필요한 정보를 얻을 수 있습니다.
레코드의 종류와 예시
1. A (Address) 레코드:
**- 역할: 도메인을 특정 IP 주소와 연결합니다.
- 예시: example.com A 93.184.216.34 (여기서 example.com => 93.184.216.34)
2. NS (Name Server) 레코드: - 역할: 도메인의 권한 있는 이름 서버를 지정합니다.
- 예시: example.com NS ns1.gabia.net (여기서 example.com 도메인에 대한 정보를 ns1.gabia.net 서버가 제공할 수 있음을 나타냅니다.)
3. CNAME (Canonical Name) 레코드: - 역할: 도메인을 별칭으로 지정하여 다른 도메인에 연결합니다.
- 예시: www.example.com CNAME example.com (여기서 www.example.com은 example.com의 별칭으로 연결됩니다.)
4. MX (Mail Exchange) 레코드: - 역할: 도메인의 메일 서버를 지정하여 이메일을 수신할 서버를 정의합니다.
- 예시: example.com MX 10 mail.example.com
정리해보자면
- 도메인 등록 절차는 등록 대행자 → 등록소 → TLD 서버 → 권한 있는 이름 서버로 이어지며, 각 서버에 필요한 정보가 기록된다
- 최종적으로 권한 있는 이름 서버에 레코드를 설정하여 도메인에 대한 구체적인 정보를 저장하고, 이를 통해 DNS 조회가 이루어집니다.
레코드 TTL
- TTL은 레코드가 DNS 캐시에 얼마나 오랫동안 유지될지를 정의하며, 레코드가 특정 시간 동안 변경되지 않는다는 보장을 제공하여 DNS 조회 성능을 향상시킨다.
TTL 역할
- DNS 조회 속도 개선:
- TTL을 통해 클라이언트와 재귀 DNS 서버는 레코드를 캐시에 저장하고 일정 시간 동안 이를 재사용
- 서버 부하 감소:
- 권한 있는 이름 서버에 대한 요청 수를 줄임
- 유연한 업데이트 주기:
- TTL 값을 조정하여 변경 주기와 캐싱 기간을 유연하게 관리
TTL 길이
- TTL을 길게 설정하면 성능이 향상되고 서버 부하가 감소
But, 변경 반영 속도가 느려 유연성이 떨어진다. - TTL을 짧게 설정하면 변경 사항이 빠르게 반영
But, 네트워크 트래픽과 서버 부하가 증가할 수 있다
그렇다면 HTTPS설정과 도메인과 관련이 있는것인가?
- 결론: 관련이 있다
먼저 위의 과정을 통해서 DNS 설정을 마치고 나면 도메인이 특정 IP주소로 연결될 수가 있다
도메인 설정이 완료가 되고 나면 이 도메인을 대상으로 SSL/TLS 인증서를 발급받을 수 있다. 이 발급 과정에서 도메인 소유 확인을 CA가 요구하여 DNS 설정이나 이메일 확인등을 요구하게 된다!
(Let’s Encrypt와 같은 무료 인증서 발급 서비스는 도메인 설정이 끝난 후 ACME 프로토콜을 통해 DNS를 확인하고 인증서를 발급해 줍니다.)
도메인의 인증서가 발급이 되면 웹서버에 인증서를 설정하여 HTTPS를 활성화한다.
HTTPS가 왜 필요한가?
HTTPS란?
HTTPS(HyperText Transfer Protocol Secure)는 웹에서 안전한 통신을 위해 사용되는 암호화된 통신 프로토콜
- HTTP에다가 SSL/TLS 등 암호화 계층을 추가하여 보안을 강화하는 것이다
장점
- 데이터 보호
데이터가 암호화하고 전송- 사용자, 결제 정보등이 유출되는것을 방지
- 데이터 무결성 보장
- 전송중에 변경/손상 여부 확인- 메세지 인증 코드(MAC)을 통해 무결성 확인한다
- 서버 신뢰성
- 서버의 신뢰성 보장한다!- 클라이언트가 서버의 신원을 확인하는데 사용된다!
Let's Encrypt는 어떻게 HTTPS 설정을 하는것일까?
너무 자세하게 이해하고싶지는 않다...
- 인증서 요청: 사이트 소유자가 Let’s Encrypt와 같은 인증 기관(CA)에 SSL/TLS 인증서를 요청합니다. 이를 위해 certbot 같은 ACME 클라이언트를 사용해 요청을 보냅니다.
- 도메인 소유권 확인: Let’s Encrypt는 해당 도메인의 소유자인지를 확인하기 위해 ACME(Automated Certificate Management Environment) 프로토콜을 사용합니다. 확인 방법은 두 가지입니다:
- HTTP-01 챌린지: 요청자가 도메인의 특정 위치에 인증 파일을 생성하여 소유권을 증명합니다.
- DNS-01 챌린지: 도메인의 DNS 설정에 특정 TXT 레코드를 추가하여 소유권을 증명합니다.
- 인증서 발급: 도메인 소유권이 확인되면, Let’s Encrypt는 해당 도메인에 대한 SSL/TLS 인증서를 발급합니다.
- 자동 갱신: Let’s Encrypt 인증서는 90일 동안 유효하며, 만료 전에 ACME 클라이언트가 자동으로 인증서를 갱신할 수 있습니다.
sudo certbot --nginx -d example.com- --nginx: certbot이 Nginx 서버 블록을 자동으로 구성하도록 지정합니다.
- -d example.com: 인증서를 발급받을 도메인 이름을 지정합니다.
HTTP-01 챌린지 설정 및 검증:
- certbot은 Nginx 설정을 일시적으로 변경하여 http://example.com/.well-known/acme-challenge/... 경로에 파일을 생성 => 도메인 소유권을 확인
도메인 소유권 확인 완료 => 인증서 발급해준다
AWS Route53의 HTTPS등록방식?
- 보통 AWS Certified Manager를 통해서 본인의 DNS에 대한 인증서를 발급신청을 한다
- 그러면 인증서에서
이런 Create record in route53이 있다
Route53에서 CNAME 레코드를 사용하여 만드는데 이 이유는 도메인 소유권을 확인하기 위해서이다.
CNAME 레코드는 도메인 소유자가 해당 도메인에 대한 제어권을 가지고있음으로 CA에 증명하기 위한 방법인 DNS-01 챌린지이다.
CNAME 레코드를 사용한 도메인 소유권 확인 과정
- 인증서 요청
- 특정 도메인에 대한 인증서를 요청하면 ACM은 해당 도메인 소유권 검증을 위해 DNS-01 챌린지를 한다
- CNAME 레코드 생성 요청 (인증 기관이 요청한 도메인과 연관된 특정 문자열 포함)
- 소유권 확인
- 도메인 소유자가 해당 CNAME 레코드를 DNS설정에 추가하고 인증기관이 이 레코드를 확인하면 소유권을 확인하여 인증서를 발급한다
- CNAME 레코드 유지 -> 소유권을 인증하는데 사용되며 인증서 갱신시에도 동일한 방식으로 사용된다!
왜 CNAME 레코드?
- 편리하다: 기타 인프라에 접근 없이 도메인 소유권 확인 가능하다
- 자동 인증/ 갱신을 지원 -> 자동화할 수 있다
- 유연하다 -> HTTP 접근 권한 설정이나 파일 생성이 필요없다!
Https 설정이 되고나면 기존 클라이언트가 접근하는 방식이 달라지나?
- DNS 확인 과정 (재귀 확인자와의 상호작용)
- 용자가 브라우저에 https://example.com을 입력하면, 클라이언트는 먼저 example.com의 IP 주소를 알아내기 위해 재귀 DNS 확인자(DNS Resolver)에게 도메인 이름 조회 요청을 보냅니다.
- 재귀 확인자는 도메인의 IP 주소를 얻기 위해 다음과 같은 과정을 거칩니다:
- 루트 네임 서버 → TLD 서버 (.com 서버) → 권한 있는 네임 서버(NS)로부터 example.com의 IP 주소를 얻어옵니다.
- DNS 확인이 완료되면 클라이언트는 example.com의 IP 주소를 받게 됩니다. 이제 서버에 연결하여 HTTPS 통신을 시작할 수 있습니다.
- HTTPS 연결 과정 (SSL/TLS Handshake)
- 클라이언트는 얻은 IP 주소를 통해 example.com 서버에 HTTPS 연결을 시도합니다.
- 서버는 SSL/TLS 인증서를 클라이언트에 전송하여 본인이 인증된 도메인이라는 사실을 증명합니다.
- 클라이언트는 서버의 인증서 유효성을 확인하고, 확인이 완료되면 대칭 암호화를 위한 세션 키를 생성하여 서버와 공유합니다.
- 서버는 받은 세션 키를 통해 암호화된 통신을 설정하고, 이제 HTTPS 연결이 완료되어 안전한 데이터 전송이 시작됩니다.
정리하면서...
- 생각보다 깊게 파고드니 옛날 컴퓨터 네트워크를 공부하던때가 떠올랐다. 그때 좀만 제대로 공부해놓을껄... 난 왜 몰랐을까 하는 후회와 이제부터라도 제대로 해야겠다는 생각을 하게되었다!
