이론 편에서 우리는 DNS의 전체 프로토콜 원리를 기본적으로 이해했지만 다음과 같은 의문이 있을 수 있다.

왜 내가 신청하고 싶은 도메인 이름이 다 없어졌지?

DNS 도메인 이름도 등록해야 하는데 왜 그런가요?

방금 신청한 도메인 이름을 어떻게 자신의 사이트에 연결합니까?

뒤에서 묵묵히 분석해 주는 도메인 이름 서버를 어떻게 볼 수 있습니까?

어떤 파일로 많은 사이트를 방문할 수 있다고 하던데 사실입니까?

신뢰할 수 있는 도메인 서버는 어떻게 된 것입니까? 설마 일부 도메인 서버가 나쁜 짓을 할 수 있습니까?

내가 지금 사용하고 있는 도메인네임 서버가 고장 났는지 어떻게 알았지?

......

나는 이 문제들에 하나하나 대답할 준비가 되어 있지 않다. 그러나 나를 믿어라. 본문을 읽고 위의 문제의 답안에 대해 너는 명확한 인식을 가지게 될 뿐만 아니라, DNS에 관한 다른 여러 가지 문제를 해결할 수 있을 것이다.

도메인 이름 등록, 바인딩

우선 명확하게 말하자면, 모든 사람이 도메인을 등록할 수 있다.대부분의 경우 우리는 최고급 도메인 이름(예를 들어selfboot.cn, 구글.com 등)을 등록하기를 희망한다. 그 2급 도메인 이름은 기억하기 어렵다(예를 들어github가 블로그를 위탁 관리하는 도메인 이름:username.github.io).어떤 최고급 도메인 이름(예를 들어.tk 도메인 이름)은 무료의 1년 도메인 이름 시용을 제공하지만, 절대 대부분은 자신의 도메인 이름에 대해 비용을 지불해야 한다(일반적으로 연간 비용을 지불해야 하며, 그리 비싸지도 않다).도메인을 등록하려면 먼저 도메인 등록 업체를 찾아야 한다. 국내의 비교적 유명한 것은 DNSpod 등이 있고 외국의 것은 godady 등이 있다.도메인을 등록한 적이 있다고 믿는 사람들은 절대 다수의 우리가 생각할 수 있는 자신이 좋아하는 도메인은 이미 주인이 있고 그렇게 사람들의 관심을 끌지 않는 도메인만 우리에게 선택할 수 있다는 것을 안다.그래서 도메인을 등록할 때 자신이 도메인을 생각할 때마다 누군가가 등록한 것을 나타내는 것을 발견하면 그것은 너무 정상적이다. 이것은 당신의 취향이 비교적 정상적이라는 것을 의미한다.
여기서 한 가지 개인적인 건의는 도메인을 선택한 후에 쉽게 바꾸지 말라는 것이다. 왜냐하면 도메인을 바꾸는 비용이 매우 높기 때문이다. (지금은 타오바오에 천만 위안을 주어도 다른 도메인으로 바꾸지 않을 것 같다.)그러니 공짜 도메인을 쓰지 않는 것이 좋다. 언제 쓰지 못하게 할지 모르기 때문이다.너는 세상에 공짜는 없다는 관점을 믿어야 한다.넓혀보면 돈을 내서 서비스를 사면 마음이 든든하다.
다음에 당신은 자신의 사이트나 블로그를 자신이 선택한 도메인 이름에 걸기를 원할 수도 있습니다. 이것은 사실 매우 간단합니다. 도메인 이름 해석을 제공하는 서비스 업체를 찾아서 해당하는 도메인 이름 해석 기록을 작성하기만 하면 됩니다.대부분의 경우, 당신이 도메인을 등록한 서비스 업체는 도메인 이름 해석 서비스를 무료로 제공할 것이다.
현실에서 대부분의 사람들은 개인 블로그를 가질 수 있다. 이전에 우리는 모두 블로그 플랫폼(예를 들어 CSDN)에 의존하거나 VPS를 사서 자신의 블로그를 위탁 관리했다.그러나 Github가 Blog 서비스를 내놓으면서 많은 프로그래머들이 블로그를 위탁 관리하고 있다.Github Blog는 개인 도메인 이름 바인딩을 지원하며 자세한 바인딩 문서를 제공합니다. Adding a CNAME file to your repository.만약 당신의 블로그가username을 통과할 수 있다고 가정합니다.github.io 방문, 다음은 CNAME로 Github에게 당신의 블로그에 어떤 도메인이 연결되어 있는지 알려주고(예를 들어selfboot.cn) 도메인 해석 업체에 해석 기록을 추가하면 됩니다. 다음 그림은 제 개인 블로그가 DNSpod에 대한 해석 기록입니다.
지금 selfboot를 방문하면cn시 DNSpod은 Github에서 제공하는 IP 주소로 요청을 분석합니다.이후 Github 위의 블로그 위탁 관리 서버는 모든 사용자의 CNAME 기록에서 이번 요청의 도메인 이름에 대응하는 블로그 프로젝트 주소, 예를 들어 xuelangZF를 찾았다.github.io, 그리고 블로그 내용으로 돌아갑니다.

도메인 이름 확인

우리는 한 도메인의 해석 과정에서 여러 대의 도메인 서버가 우리에게 도움을 줄 수 있다는 것을 알고 있다. 그러면 우리는 어떻게 이런 배후의 공신들을 볼 수 있겠는가?먼저 DNS에 대한 두 개의 일반적인 명령을 소개합니다.

dig, nslookup

(Domain Information Groper)는 UNIX/BSD 시스템이 자체로 가지고 있는 DNS 진단 도구로 사용이 매우 유연하고 편리하다.
검색selfboot.cn의 A 레코드와 간단한 결과를 반환합니다.

$ dig selfboot.cn -t A +short
192.30.252.153
192.30.252.154

dig을 사용하면 다음과 같은 IP 도메인 이름도 조회할 수 있습니다.

$ dig -x 192.30.252.153 +short
pages.github.com.

페이지가 반환되었습니다.github.com, 블로그 주소를 방문하면selfboot.cn시, 사실은 Github의 페이지 서버 (도메인 이름은 페이지.github.com) 가 백엔드에서 이 블로그의 내용을 되돌려줍니다. (CNAME에 따라 어느 블로그를 되돌려줄지 결정합니다.)
nslookup도 DNS 진단 도구로 거의 모든 플랫폼에서 이 도구를 가지고 있으며 사용도 간단명료하고 man 조회 매뉴얼을 사용할 수 있다.

경로 질의 해결

다음은dig 명령으로 루트 도메인에서 지정한 도메인 이름 사이를 지나갈 수 있는 모든 도메인 서버를 보십시오. dig 옵션을 사용하면 됩니다.

dig selfboot.cn +trace @8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> selfboot.cn +trace @8.8.8.8
;; global options: +cmd
.            474418    IN    NS    j.root-servers.net.
.            474418    IN    NS    g.root-servers.net.
......
.            474418    IN    NS    l.root-servers.net.
.            474418    IN    NS    m.root-servers.net.
;; Received 496 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms

cn.            172800    IN    NS    a.dns.cn.
......
cn.            172800    IN    NS    e.dns.cn.
cn.            172800    IN    NS    ns.cernet.net.
;; Received 292 bytes from 2001:500:1::803f:235#53(2001:500:1::803f:235) in 382 ms

selfboot.cn.        86400    IN    NS    f1g1ns2.dnspod.net.
selfboot.cn.        86400    IN    NS    f1g1ns1.dnspod.net.
;; Received 83 bytes from 203.119.25.1#53(203.119.25.1) in 816 ms

selfboot.cn.        14400    IN    A    192.30.252.153
selfboot.cn.        14400    IN    A    192.30.252.154
selfboot.cn.        600    IN    NS    f1g1ns1.dnspod.net.
selfboot.cn.        600    IN    NS    f1g1ns2.dnspod.net.
;; Received 125 bytes from 115.236.137.40#53(115.236.137.40) in 31 ms

처음에 13대의 최고급 도메인 이름 서버의 NS 기록을 볼 수 있다(중간에 기록을 줄이고 줄 수를 줄여 관찰하기 편리하고 더욱 분명하게 한다). 다음은 최고급 도메인 이름cn이다.권위 있는 도메인 이름 서버 (출력 생략), 그 다음은 selfboot.cn의 NS 기록, 즉 DNSpod의 두 개의 NS 기록, 마지막으로 f1g1ns2.dnspod.net에서 selfboot를 찾았습니다.cn의 A 기록.
seveas는 시각화된 경로 조회 도구를 제공합니다: dnsgraph. 도메인과 지정한 도메인에 대한 모든 가능한 경로를 온라인으로 그릴 수 있습니다.
물론 실제 조회 과정에서 대부분의 경우 우리는 로컬 캐시나 로컬 도메인 서버 캐시에서 필요한 도메인 기록을 직접 찾을 수 있고 매번 루트 도메인 서버에 요청을 한 다음에 반복하거나 조회 과정을 반복할 필요가 없다.

DNS 결함

도메인 이름 시스템의 설계는 매우 이상적이고 아름답지만, 여전히 약간의 흠이 있어서, 우리에게 약간의 어려움을 가져다 줄 수 있다.

도메인 이름 강탈

우선, 일부 도메인 이름은 등록자에게 제한이 없고, 다른 일부 도메인 이름은 누가 하나의 도메인 공간 중의 이름을 얻을 수 있는지에 제한이 있다.예를 들어 프로 도메인 이름은 적당한 전문가에게 분배되지만 문제는 누가 프로입니까?분명히 의사, 엔지니어는 전문이지만, 이발사, 파이프공은?
도메인 이름도 되팔릴 수 있다.황소들은 대량의 도메인을 대량으로 등록한다.그래서 지금 네가 자신의 사이트 특징에 맞는 도메인을 등록하기는 매우 어렵다.
이 문제는 사실 아직 심각한 편은 아니지만, 더욱 심각한 것은 아래의 두 문제다.

DNS 납치

우리는 도메인 이름 서버가 지역 내의 사용자 분석 요청에 대해 책임을 지는 것을 알고 있지만, 도메인 이름 서버가 실제 책임을 지는지 감독하는 메커니즘이 없다.도메인 이름 서버의 권한이 우리 안에 갇혀 있지 않기 때문에 진지하게 국민을 위해 봉사할 수도 있고, 사슴을 말이라고 할 수도 있다.그래서 일부 깡패들의 도메인 이름 서버는 일부 도메인 이름의 해석 결과를 고의로 변경하여 사용자를 잘못된 목표 주소로 인도했다.이것은 DNS 납치라고 하는데 주로 사용자가 특정한 사이트에 접근하는 것을 막거나 광고 페이지로 안내하는 데 쓰인다.
다음은 내가 사용하는 도메인 이름 서버가 이런 나쁜 짓을 했는지 확인하는 간단한 명령만 있으면 된다.

➜  ~  nslookup google.com
Server:        10.8.4.4
Address:    10.8.4.4#53

Non-authoritative answer:
Name:    google.com
Address: 120.196.0.5

나의 DNS 서버 주소는 10.8.4.4인데, 그가 나에게 구글을 알려주었다.com의 주소는 120.196.0.5이므로 나는 믿지 않는다.그래서 +trace 보니 Google 주소가 아니었습니다.DNS 납치에 대해 도메인 이름 서버를 간단히 교체할 수 있습니다. Google이 제공하는 8.8.8.8.다음은 8.8.8.8로 ww.google을 분석해 보겠습니다.com에서 정확한 주소를 볼 수 있습니다.

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

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

DNS 속임수

DNS 납치는 도메인 이름 서버를 간단하게 전환하면 돌아갈 수 있지만 whois 120.196.0.5 를 만나면 쉽게 돌아갈 수 없다.다음에 우리는 서로 다른 도메인 이름 서버로 fb의 IP 주소를 보았는데 결과는 모두 같은 주소로 되돌아왔다. 보기에는 마치 진짜인 것 같지만 보기에만 그렇다.

$ nslookup facebook.com
Server:        10.8.4.4
Address:    10.8.4.4#53

Non-authoritative answer:
Name:    facebook.com
Address: 159.106.121.75

$ nslookup facebook.com 8.8.8.8
Server:        8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:    facebook.com
Address: 159.106.121.75

이 주소는 fb의 서버 주소가 아니다.사실 Google은 이 주소를 살펴보았는데 괜찮은 번역문을 발견했습니다. 보아하니 이 주소는 2011년부터 특별한 의미가 있는 것 같습니다.
DNS 사기는 쉽게 말하면 가짜 DNS 응답으로 사용자 컴퓨터를 속여 이 가짜 주소를 믿게 하고 진정한 DNS 응답을 포기하는 것이다.호스트에서 DNS 요청을 보내면 응답을 기다리기 시작합니다. 만약 정확한 (DNS 요청과 같은 번호를 가진) 응답 패키지가 있다면, 응답을 믿고 조금 늦게 도착한 응답을 버릴 것입니다.
DNS 사기를 실시하는 관건은 특정한 시퀀스 번호가 있는 응답 패키지를 위조하고 요청을 하는 호스트에 먼저 도착하도록 하는 것이다.개인적으로는 좀 어렵지만 골간망 노드를 가진 조직에게는 손바닥을 뒤집는 것처럼 쉽기 때문에 이렇게 많은 사이트들이 이미 함락되었다.그러나 인터넷에 떠도는 hosts 파일을 사용하면 본 컴퓨터에서 많은 사이트의 IP 주소를 캐시하여 일부 사이트와 통신할 수 있다.하지만 hosts 파일을 통해 크로스 더 그레이트 파이어 월을 완전히 할 수는 없다. 왜냐하면 다른 수단이 많기 때문이다.
관련 읽기
DNS cache poisoning DNS Spoofing vs DNS Cache Poisoning Reset the DNS cache in OS X 인위적 네트워크 고장 DNS 사기 원리 및 작업 공정 분석 DNS 오염과 납치의 개인적인 소견