DNS 조회 순서는 어떻게 결정됩니까?

예를 들어 도메인 이름 domain.com을 등록하고 등록자 서버
ns1.domain.com 에 네임 서버 레코드를 추가 했습니다.
ns2.domain.com.
ns3.domain.com.

우리가 domain.com 을 찾는 것보다 . 우리는 3 명의 이름 서버 주소를 얻습니다.
1. 해당 서버 중 어떤 서버가 추가로 요청되며 그 이유는 무엇입니까?
2. 존 파일에서 NS 레코드의 순서가 중요합니까?
3. RFC 에서 결정 됩니까?

안타깝게도 여기서의 대답은 "의존"입니다. 도메인에 따라 달라지는 요인은 도메인과 소유 서버 설정 방법 및 로컬 DNS 설정 방법에 따라 다릅니다.

예를 들어, 반환 된 NS 레코드와 관련하여 : 해당 레코드가 반환되는 순서를 임의로 지정할 수 있으므로 요청할 때마다 순서가 다를 수 있습니다. 반면, 모든 DNS 구현에서 수행되는 것은 아니므로 정적으로 정렬 된 목록을 얻을 수도 있습니다. 요점은 당신이 확신 할 수 없다는 것입니다.

다음으로 일부 DNS 구현은 각 NS를 병렬로 쿼리하고 먼저 응답하는 것을 사용합니다. 다른 사람들은 각각을 맞고, 몇 건의 요청 중에서 가장 빠른지를 결정하고 그 요청을 사용합니다. 아니면 그냥 라운드 로빈 수 있습니다.

DNS에는 여러 개의 RFC가 있으며, 내가 찾은 더 유용한 것 중 두 가지는 다음과 같습니다.

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

나는 이것이 당신이 취할 수있는 결정적인 것이없는 대답이 아닌 것을 알고 있지만, 위의 주어진 주어진 도메인에 대한 행동을 결정하는 유일한 방법은 테스트하는 것입니다.

전 세계 ISP와 같이 클라이언트 수준에서 가장 일반적인 구현은 다음과 같습니다.

1. 광대역 가입자와 같은 누군가가 ISP의 DNS 서버에 foo.example.com에 대한 A 레코드를 확인하도록 요청합니다.
2. ISP는 자체 캐시를 확인하고 해당 레코드가 캐시되고 여전히 "새로 고침"으로 간주되면 캐시를 통해 즉시 반환됩니다. ( 이것은 모든 DNS 캐시가 작동하는 방식이므로, 해당 사이트의 DNS 서버를 불필요하게 부담하지 않아도됩니다. )
3. 해당 레코드가 캐시되지 않았거나 캐시가 "stale / outdated"로 간주되면 ISP는 최신 레코드를 다시 해결해야한다는 것을 알고 있습니다.
4. 이제 ISP는 최신 레코드에 대해 쿼리 할 네임 서버를 알아야합니다.
5. ISP는 도메인에 대한 신뢰할 수있는 네임 서버의 캐시 된 목록을 확인하는 것으로 시작합니다 (이는 ns1.example.com, ns2.example.com 등). 해당 레코드가 여전히 새로운 것으로 간주되면 8 단계로 건너 뜁니다.
6. 캐시 된 네임 서버 레코드가 만료 된 것으로 간주되거나 해당 도메인에 대한 캐시 된 레코드가없는 경우 ISP는 TLD의 루트 네임 서버 (예 : .com 도메인 인 경우 .com 레지스트리)를 조회하여 example.com의 최신 네임 서버 이름 / IP 쌍. ( 도메인이 일반적인 com / net / etc TLD에 속하는 경우 "dig @ b.gtld-servers.net example.com"을 통해 TLD의 루트 네임 서버가 도메인에 대해 알고있는 것을 확인할 수 있습니다. TLD는 해당 루트 서버를 쿼리해야합니다. )
7. TLD의 루트 네임 서버는 항상 사용자가 지정한 순서대로 네임 서버를 반환 합니다. 무작위 화는 진행되지 않습니다. 또한 각 네임 서버의 IP를 반환합니다. 이것을 "GLUE"라고하며 인터넷에서 도메인에 대한 정보를 알기 전에 네임 서버 호스트 이름을 IP로 확인하는 방법의 "chicken and egg"문제를 해결할 수 있습니다. 또한, 가장 큰 것들 인 com / net / etc 레지스트리와 같은 대부분의 경우 2 일의 캐시 시간을 사용하므로 "도메인 X의 네임 서버 목록은 무엇입니까?" 요청. 이것은 새로운 네임 서버가 전 세계적으로 알려져 있다고 안전하게 말할 수있을 때까지 2 일을 기다려야한다는 공통 지식의 원천입니다.
8. ISP가 example.com의 이름 서버 및 해당 IP (예 : ns1.example.com, ns2.example.com, ns3.example.com)를 알고 있으면 ISP는 이제 해당 목록에서 임의 서버를 선택 하고 쿼리를 보냅니다. ( 이것은 훌륭하며 문제의 사이트의 모든 DNS 서버를 불필요하게 망치지 않아도되며 항상 나열된 첫 번째 네임 서버를 쿼리하지는 않으므로로드 밸런싱을 추가로 지원합니다. )
9. ISP가 지정된 시간 초과 기간 내에 해당 이름 서버로부터 응답을받지 못하면 목록에서 다른 이름 서버를 쿼리합니다.
10. 응답이 있으면 ISP는 이제 자체 로컬 캐시에 저장합니다. 캐시 상태를 유지하는 기간은 얼마입니까? DNS 서버가 반환 한 각 레코드에는 "소프트 만료"시간 (초)이 있으며, 이는 쿼리 클라이언트 (예 : ISP의 DNS 서버 등)가 해당 레코드를 고려하기 전에 해당 레코드를 캐시 할 수있는 시간입니다. 여전히 사용 가능하지만 구식 일 가능성이있는 경우, 가능하면 변경되지 않았는지 확인하기 위해 새로운 쿼리가 발생해야합니다. " 각 개별 네임 서버의 "SOA"(권한 시작) 레코드에 지정된 "하드 만료"시간도 있습니다 ( "dig @ ns1.example.com example.com -t soa"를 통해 자신의 이름을 볼 수 있음). 해당 서버에서 반환 한 모든 레코드에 대한 전역 "하드 제한"을 지정합니다. 그 후에 캐시는 캐시 된 레코드를 삭제해야합니다 (네임 서버가 다운 되어도 레코드를 다시 조회 할 수없는 경우에도). 일반적으로 소프트 만료는 30 분에서 5 시간 사이이며 하드 만료는 일반적으로 1-3 주 사이입니다.
11. 그 철저한 작업 후에 ISP는 마침내 최신 DNS 레코드를 가지고 그것을 쿼리 광대역 가입자에게 돌려 줄 수 있습니다.

이 프로세스는 모든 레코드 조회에 대해 반복됩니다. 그러나 첫 번째 쿼리 만 전체 작업을 수행합니다. 그 후에 네임 서버 IP가 캐시되고 ISP의 캐싱 DNS 서버에 대한 후속 쿼리는 8 단계로 빠르게 넘어갈 수 있습니다.

이제 8 단계의 무작위 화는 레코드 레벨에서 작동합니다. 해당 ISP의 광대역 가입자가 다음 레코드에 대해 물었다 고 가정 해 보겠습니다.

• foo.example.com
• example.com
• www.example.com
• MX example.com (ISP 고객은이 레코드를 요구해서는 안되지만 단지 예일뿐입니다)

각 레코드는 독립적으로 캐시되고 조회되는 별도의 "엔티티"로 처리됩니다. 따라서 가입자와 ISP가 도메인을 발견 한 적이 없으며 캐시 된 레코드가 전혀 없습니다. 조회는 다음과 같습니다.

• ns1.example.com을 통한 foo.example.com, ISP 캐시에 저장
• ISP 캐시에 저장된 ns3.example.com을 통한 example.com
• ns2.example.com을 통한 www.example.com, ISP 캐시에 저장
• ns3.example.com을 통한 MX example.com, ISP 캐시에 저장

캐시 된 레코드가 소프트 만료 될 때마다 프로세스가 반복되므로 해당 레코드에 대한 후속 요청이 동일한 서버를 다시 사용한다는 사실조차 모릅니다.

따라서 모든 DNS 서버가 서로 완전히 동기화되어 모든 서버의 모든 DNS 레코드를 완벽하게 미러링 하는 것이 가장 큰 목표 입니다. 당신은 결코 는 DNS 클라이언트가 타격 될 서버 알지 당신은 어떤 순서든지에 의존 할 수 없다. 그와 같은 일은 없다.

또한 Adam C가 언급했듯이 서버 수준 (example.com) DNS 서버 자체는 NS 레코드를 반환하고 그 순서를 무작위로 지정할 수 있습니다. 일반 DNS 서버가 DNS 구현이 불량 할 때 항상 NS 레코드를 랜덤 화하는 것은 매우 일반적입니다. 그러나 ROOT TLD 네임 서버 (앞서 언급 한)는 목록을 무작위로 배정하지 않으며, 도메인을 해결할 때 목록이 실제로 중요합니다. 그래서 가장 많은 이유 구현은 항상 동일한 서버에 충돌하여 과부하가 걸리지 않도록 네임 서버 목록에서 임의의 서버를 선택합니다.

이것이 DNS의 작동 방식과 기억해야 할 사항에 대한 입문서입니다.

• 한마디로 : 모든 DNS 서버를 하나의 서버처럼 취급하여 서버에서 발생할 수있는 모든 쿼리에 동등하게 응답 할 수 있도록하는 것이 인생 최고의 목표입니다 .

면책 조항 : DNS 관리보다 인생의 목표가 높을 수도 있지만 별도로 판매되므로 상상력을 발휘하십시오. ;-)