NS 레코드에 IP 주소가없는 이유는 무엇입니까?

NS 레코드의 요점은 클라이언트에게 어떤 네임 서버가 도메인 네임의 실제 IP 주소를 알 수 있는지 알려주는 것입니다. 예를 들어, 다음 쿼리는 정식 답변을 얻으려면 facebook.com요청해야한다는 것을 알려줍니다 a.ns.facebook.com.

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

이것은 시원하고 유용하게 보이지만 ANSWER섹션에 왜 권위있는 소스의 IP가 아닌 호스트 이름이 포함되어 있는지 궁금 합니다. 클라이언트가 호스트 이름이 아닌 신뢰할 수있는 소스의 실제 IP 주소를 얻는 것이 더 쉽지 않습니까?

호스트 이름을 얻으면이 호스트 이름을 IP로 확인하기 위해 다른 쿼리를 수행 한 다음이 초기 IP에 대해이 새로운 IP를 요청해야 facebook.com합니다. 비효율적이지 않습니까?

이 문제를 설명하는 RFC의 일부 단락을 가리키는 답변에 관심이 있습니다.

문제의 해결책은 접착제 레코드 란 무엇입니까?에 설명 된 DNS 접착제 레코드입니다 . .

RFC 1035 섹션 3.3.11 상태

"... 클래스는 일반적으로 강력한 힌트이지만 호스트와 통신하는 데 사용해야하는 프로토콜 제품군을 나타내지 않을 수 있습니다."

IP 주소를 반환하는 것은 호스트에 연락 할 수있는 방법을 알려주는 것이며 RFC에 반하는 것입니다.

Jason은 위에서 설명한 문제를 해결하는 DNS 메커니즘을 제공했지만 여전히 이러한 방식으로 작업이 수행 되는 이유를 살펴 보지 않았습니다 .

내가 소유 example.com하고 있다고 가정 하고 웹 사이트 컨텐츠 중 일부를 Contoso 라는 컨텐츠 전달 회사에 계약했습니다 . 그들의 플랫폼은 sub.example.com어떤 응답이 리턴되는지를 제어 할 수 있도록 네임 서버 에 위임 할 것을 요구합니다 .

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

앞서 언급했듯이 Contoso 이름 서버의 IP 주소는 지정하지 않았습니다. 우리 서버가 아는 것은 인터넷에 "우리는 관리하지 않고 sub.example.com대신 Contoso에 문의하십시오 "라고 알리는 것입니다 . 다음과 같은 이유로 매우 중요합니다.

• 우리는 Contoso.com을 소유하지 않습니다.
• Contoso가 이름 서버 IP 변경을 모든 고객과 조정하는 것을 기대할 수는 없습니다. 이것이 바로 서버가 해당 IP를 제공하는 경우 발생해야 할 일입니다.

여태까지는 그런대로 잘됐다. 1 년이 지났고 우리에게 알려지지 않은 Contoso는 CDN 네임 서버의 IP 주소를 변경하고 있습니다. DNS가가하는 방식으로 작동하기 때문에,이해야 할 업데이트입니다 A그들이 돌아가 기록 ns1.cdn과 ns2.cdn.contoso.com..

이 중요한 시점에 우리에게 가져다 : 제이슨에 의해 기술 된 접착제의 기록은 다음과 같은 DNS에 "닭이 먼저 냐 달걀이 먼저 냐"시나리오를 처리 할 수있는 google.com자신의 네임 서버는이 세상을 이야기 ns1.google.com하고 ns2.google.com. 다음 과 같은 문제를 해결하기 위해 소유하지 않은 인프라를 가리키는 글루 레코드를 작성 해서는 안됩니다 .

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

이것은 닭과 달걀 시나리오를 피할뿐만 아니라 Contoso가 그러한 네임 서버의 모든 IP 변경 을 우리와 조정하도록해야 합니다. 이것은 매우 위험하고 바람직하지 않습니다.