Udemy CKA 강의 정리 199: Prerequisite - DNS

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 완전 초보자를 위해 Linux의 DNS를 소개합니다. 기본 개념에 대해 논의하고 호스트, 특히 Linux 호스트에서 DNS configuration을 탐색하는 데 도움이 되는 몇 가지 커맨드를 볼 것입니다. 이 섹션의 마지막에는 DNS와 관련된 일련의 문제가 주어지고 브라우저에서 바로 라이브 실습 실습 환경에서 문제를 해결하도록 요청하는 모의 테스트를 보게 됩니다.

Name Resolution

동일한 네트워크에 속하는 두 대의 컴퓨터 A와 B가 있으며 IP 주소 192.168.1.10 및 1.11이 할당되었습니다. 다른 컴퓨터의 IP 주소를 사용하여 다른 컴퓨터에서 한 컴퓨터를 ping할 수 있습니다. 시스템 B에 데이터베이스 서비스가 있다는 것을 알고 있으므로, 시스템 B의 IP 주소를 기억하는 대신 이름을 db로 지정하기로 결정합니다. 앞으로는 IP 주소 대신 이름 db를 사용하여 시스템 B를 ping하려고 합니다. 지금 db에 ping을 시도하면 호스트 A가 db라는 호스트를 인식하지 못하는 것을 볼 수 있습니다. 어떻게 고칠 수 있을까요? 기본적으로 시스템 A에게 IP 주소 192.168.1.11의 시스템 B에 DB라는 이름이 있다고 알려야 합니다. 시스템 A에게 "db"라고 말할 때 IP 192.168.1.11을 의미한다고 말하고 싶을 것입니다. 시스템 A의 etc/hosts 파일에 항목을 추가하여 이를 수행할 수 있습니다. 호스트가 시스템 B를 볼 IP 주소와 이름을 언급하십시오. 우리는 시스템 A에게 192.168.1.11의 IP가 DB라는 호스트라고 말했습니다. 이제 db에 대한 ping이 올바른 IP로 전송되고 성공합니다.

여기서 주목해야 할 중요한 점이 있습니다. 우리는 시스템 A에게 192.168.1.11의 IP가 db라는 호스트라고 말했습니다. 우리가 etc/hosts 파일에 넣은 것이 진실인지 아닌지는 상관 없이 호스트 A는 이를 당연하게 여깁니다. 그러나 그것이 진실이 아닐 수도 있습니다. 호스트 A는 시스템 B의 실제 이름이 db인지 확인하지 않습니다. 예를 들어, 시스템 B에서 hostname 커맨드를 실행하면 이름이 host-2라는 것을 알 수 있습니다. 그러나 호스트 A는 신경 쓰지 않습니다. 호스트 파일에 있는 내용으로 이동합니다.

시스템 B가 Google이라고 믿도록 시스템 A를 속일 수도 있습니다. www.google.com에 대한 IP 매핑을 사용하여 호스트 파일에 항목을 추가하기만 하면 됩니다. 그런 다음 Google에 핑하면 시스템 B에서 응답을 받게 됩니다. 따라서 동일한 시스템을 가리키는 두 개의 이름이 있습니다. 하나는 db이고 다른 하나는 Google입니다. 그리고 두 이름 중 하나를 사용하여 시스템 B를 읽을 수 있습니다. etc/hosts 파일에서 원하는 만큼의 서버에 대해 원하는 만큼의 이름을 가질 수 있습니다. 호스트 A에서 이름으로 다른 호스트를 참조할 때마다 ping 커맨드나 SSH 커맨드를 통해 또는 이 시스템 내의 애플리케이션이나 tool을 통해 호스트는 해당 호스트의 IP 주소를 찾기 위해 etc/hosts 파일을 찾습니다. 이러한 방식으로 호스트 이름을 IP 주소로 변환하는 것을 name resolution이라고 합니다.

DNS

소수의 시스템으로 구성된 소규모 네트워크 내에서 etc/hosts 파일의 항목을 쉽게 사용할 수 있습니다. 각 시스템에서 모두 다른 시스템을 지정합니다. 과거에는 그렇게 했습니다. 환경이 커지면 이러한 파일과 항목을 관리하는 것이 너무 어려워집니다. 서버 중 하나의 IP가 변경되면 모든 호스트에서 항목을 수정해야 합니다. 따라서 이 모든 항목을 중앙에서 관리할 단일 서버를 두기로 결정했습니다. 우리는 그것을 DNS 서버라고 부릅니다. 자체 etc/hosts 파일 대신 호스트 이름을 IP 주소로 확인해야 하는 경우에 모든 호스트가 해당 서버를 조회하도록 지정합니다.

호스트를 DNS 서버로 지정하려면 어떻게 해야 할까요? DNS 서버의 IP는 192.168.1.100입니다. 모든 호스트에는 etc/resolv.conf에 DNS resolution configuration 파일이 있습니다. DNS 서버의 주소를 지정하여 항목을 추가합니다. "nameserver"라고 말하고 192.168.1.100을 가리키면 됩니다. 이것이 모든 호스트에 configuration되면 호스트가 알지 못하는 호스트 이름을 발견할 때마다 DNS 서버에서 조회합니다. 호스트의 IP가 변경되는 경우 DNS 서버를 업데이트하기만 하면 모든 호스트가 앞으로 새로운 IP 주소를 확인할 수 있습니다. 더 이상 모든 호스트의 etc/hosts 파일 항목이 필요하지 않습니다. 그러나 이것이 호스트 파일에 항목을 가질 수 없다는 의미는 아닙니다. 당신은 여전히 호스트파일 항목을 가질 수 있습니다. 예를 들어 필요에 따라 테스트 서버를 프로비저닝한다고 가정해 보겠습니다. 다른 사람들이 이름으로 서버를 확인할 필요가 없다고 생각하므로, DNS 서버에 추가할 필요가 없습니다. 이 경우 호스트의 etc/hosts 파일에 항목을 추가하여 이 서버를 확인할 수 있습니다. 이제 서버를 확인할 수 있지만 다른 시스템에서는 그렇게 할 수 없습니다. 따라서 시스템은 etc/hosts 파일과 원격 DNS 서버에서 호스트 이름 대 IP 매핑을 사용할 수 있습니다. etc/hosts 파일과 DNS에 각각 하나씩 항목이 있으면 어떻게 될까요? 내 로컬 파일에 항목이 192.168.1.115로 설정되어 있고 누군가 동일한 호스트에 대한 항목을 DNS 서버의 192.1.68.116에 추가했습니다. 이 경우 호스트는 먼저 로컬 etc/hosts 파일에서 그런 다음 이름 서버를 확인합니다. 따라서 로컬 etc/hosts 파일에서 항목을 찾으면 해당 항목을 사용합니다. 그렇지 않은 경우 DNS 서버에서 해당 호스트를 찾습니다. 하지만 그 순서는 바뀔 수 있습니다. 순서는 etc/nsswitch.conf 파일의 항목으로 정의됩니다.

보시다시피 호스트 항목이 있는 줄은 보면 순서대로 첫 번째 files이고 그 다음이 dns입니다. 파일은 etc/hosts 파일을 의미하고 DNS는 DNS 서버를 의미합니다. 따라서 모든 호스트 이름에 대해 호스트는 먼저 etc/hosts 파일을 살펴보고 찾을 수 없으면 DNS 서버를 찾는다는 의미입니다. 이 순서는 파일에서 이 항목을 편집하여 수정할 수 있습니다. 이 순서에 따라 호스트는 테스트 서버를 192.168.1.15로 확인합니다.

목록에 없는 서버에 ping을 시도하면 어떻게 됩니까? 예를 들어 www.facebook.com에 ping을 시도합니다. etc/hosts 파일에 facebook.com이 없고 DNS 서버에도 없습니다. 따라서 그 경우에는 실패합니다.

resolv.conf 파일에 다른 항목을 추가하여 Facebook을 알고 있는 이름 서버를 가리킬 수 있습니다. 예를 들어 8.8.8.8은 Google에서 호스팅하는 인터넷에서 사용할 수 있는 널리 알려진 공용 이름 서버로 인터넷의 모든 웹사이트에 대해 알고 있습니다. 이와 같이 여러 개의 이름 서버를 호스트에 configuration할 수 있지만 네트워크의 모든 호스트에 configuration해야 합니다. 모든 호스트에 configuration된 네트워크 내에 nameserver가 이미 있습니다. 따라서 이 경우 알 수 없는 호스트 이름을 인터넷의 공용 이름 서버로 전달하도록 DNS 서버 자체를 구성할 수 있습니다. facebook.com과 같은 외부 사이트를 ping할 수 없어야 합니다.

Domain Names

지금까지 우리는 Web, DB, NFS 등과 같은 이름으로 시스템을 읽으려고 했습니다. 하지만 방금 www.facebook.com에서 Facebook에 ping을 시도했습니다. 끝에 www와 .com이 있는 이 이름은 무엇입니까? 도메인 네임이라고 하며 호스트에 대해 했던 것처럼 공용 인터넷에서 기억할 수 있는 이름으로 IPS가 변환하는 방식입니다. 이제 점으로 구분된 이 형식을 사용하는 이유는 유사한 항목을 함께 그룹화하기 위한 것입니다. 도메인 이름의 마지막 부분인 .coms, .nets, .edu, .org 등은 웹사이트의 의도를 나타내는 최상위 도메인입니다. 상업용 또는 일반용 .com, 네트워크용 .net, 교육 기관용 .edu, 비영리 기관용 .org.

한 가지를 예로 살펴보겠습니다. Google의 경우 점은 루트입니다. 그것이 모든 것이 시작되는 곳입니다. .com은 최상위 도메인입니다. Google은 Google에 할당된 도메인 이름이고 www는 하위 도메인입니다. 하위 도메인은 Google에서 항목을 추가로 그룹화하는 데 도움이 됩니다. 예를 들어 Google의 지도 서비스는 maps.google.com에서 사용할 수 있습니다. 따라서 map은 하위 도메인입니다. Google의 스토리지 서비스는 drive.google.com에서 사용할 수 있습니다. 모바일 앱은 apps.google.com에서 사용할 수 있습니다. Google의 이메일 서비스는 mail.google.com에서 사용할 수 있습니다. 필요에 따라 이들 각각을 많은 하위 도메인으로 추가로 나눌 수 있습니다. 따라서 트리 구조가 형성되는 것을 볼 수 있습니다.

조직 내에서 이러한 도메인 이름(예: apps.google.com)에 도달하려고 하면 요청이 먼저 조직의 내부 DNS 서버에 도달합니다. 앱이나 Google이 누구인지 모르기 때문에 요청을 인터넷으로 전달합니다. 인터넷에서 apps.google.com을 제공하는 서버의 IP 주소는 여러 DNS 서버의 도움을 받아 확인할 수 있습니다. route DNS 서버는 요청을 보고 .coms를 제공하는 DNS 서버를 가리킵니다. .com DNS 서버는 우리의 요청을 보고 우리를 Google에 전달합니다. 그리고 Google의 DNS 서버는 앱의 애플리케이션을 제공하는 서버의 IP를 제공합니다. 향후의 모든 확인 속도를 높이기 위해 조직의 DNS 서버는 일정 시간(일반적으로 몇 초에서 최대 몇 분) 동안 이 IP를 캐싱하도록 선택할 수 있습니다. 이렇게 하면 매번 전체 프로세스를 다시 거칠 필요가 없습니다. 그래서 그것은 이제 확인 가능합니다.

당신의 회사는 어떻습니까? 회사도 비슷한 구조를 가질 수 있습니다. 예를 들어 회사의 이름을 mycompany.com으로 지정하고 각 용도에 대해 여러 하위 도메인을 가질 수 있습니다. 외부용 웹사이트용 www, 조직의 메일에 액세스하기 위한 mail.mycompany.com, 저장소에 액세스하기 위한 drive, 급여 애플리케이션에 액세스하기 위한 pay 또는 company.com, HR 애플리케이션에 액세스하기 위한 hr 등이 있습니다. 이들 모두는 조직의 내부 DNS 서버에서 구성됩니다. 이 모든 것을 논의한 이유는 etc/resolv.conf 파일의 다른 항목을 이해하기 위해서입니다. 이 파일은 호스트에 사용할 DNS 서버를 구성한 파일입니다. 이를 통해 Web과 같은 이름만으로 조직의 서버를 확인할 수 있었습니다. 이제 web.mycompany.com 또는 db.mycompany.com 등과 같은 더 많은 표준 도메인 이름을 도입했습니다.

이제 웹을 ping하면 더 이상 응답을 받을 수 없습니다. 물론 이것은 우리가 web에 ping을 시도하고 있지만 내 DNS 서버에서 web이라는 이름에 대한 기록이 없기 때문입니다. 대신 web.mycompany.com이므로 web.mycompany.com을 사용해야 합니다. 이제 회사 외부의 누군가가 웹 서버에 액세스하려는 경우 web.mycompany.com을 사용해야 한다는 것을 이해할 수 있습니다.

그러나 우리 회사 내에서 우리는 웹 서버의 이름을 web으로 간단히 지정하기를 원합니다. 가족의 다른 구성원을 이름으로 부르는 것과 같습니다. 내 web.mycompany.com을 확인하도록 web을 지정하려면 어떻게 해야 합니까? "web이라고 하면 web.mycompany.com을 의미합니다."라고 말하고 싶을 것입니다. 이를 위해서는 search라는 호스트의 etc/resolv.conf 파일에 항목을 만들고 추가할 도메인 이름을 지정하면 됩니다. 다음에 web에 ping을 시도하면 실제로 web.mycompany.com을 시도하는 것을 볼 수 있습니다. 이제 호스트는 이와 같이 쿼리에 도메인을 지정한 경우 검색 도메인을 제외할 만큼 충분히 지능적입니다.

이와 같은 추가 search 도메인을 제공할 수도 있습니다. 따라서 "web"이라고 하면 web.mycompany.com 또는 web.prod.mycompany.com을 의미합니다. 따라서 호스트 이름을 찾을 때 호스트는 이러한 모든 도메인 이름을 검색하려고 시도합니다.

Record Types

마지막으로 레코드 유형에 대한 설명입니다. 그렇다면 레코드는 DNS 서버에 어떻게 저장됩니까? 호스트 이름에 IP를 저장한다는 것을 알고 있습니다. 그것은 A 레코드로 알려져 있습니다. IPv6을 호스트 이름에 저장하는 것을 quad-A records라고 합니다. 한 이름을 다른 이름에 매핑하는 것을 CNAME 레코드라고 합니다. 예를 들어 음식 배달 서비스와 같이 동일한 애플리케이션에 대해 여러 개의 별칭이 있을 수 있습니다. CNAME 레코드가 사용되는 곳입니다. 이름 대 이름 매핑입니다. 더 많은 것이 있지만 지금은 그것이 우리가 살펴볼 전부입니다.

Networking Tools

ping이 항상 DNS 확인을 테스트하는 올바른 tool은 아닐 수 있습니다. nslookup과 같은 몇 가지 다른 툴도 있습니다. nslookup을 사용하여 DNS 서버에서 호스트 이름을 쿼리할 수 있습니다. 그러나 nslookup은 로컬 etc/hosts 파일의 항목을 고려하지 않는다는 점을 기억하십시오. 따라서 웹 애플리케이션에 대한 로컬 etc/hosts 파일에 항목을 추가하고 해당 웹 애플리케이션에 대해 nslookup을 시도하면 찾을 수 없습니다. 웹 애플리케이션에 대한 항목이 DNS 서버에 있어야 합니다. Nslookup은 DNS 서버만 쿼리합니다.

$ nslookup www.google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.18.4
Name:   www.google.com

dig도 마찬가지입니다. dig는 DNS 이름 확인을 테스트하는 또 다른 유용한 tool입니다. 서버에 저장된 것과 유사한 형식으로 자세한 내용을 반환합니다.

$ dig www.google.com

; <<>> DiG 9.11.3-1 ...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8738
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         63      IN      A       216.58.206.4

;; Query time: 6 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)