DNS 확인자 및 NS 레코드 TTL

Question

DNS 확인자가 권한 있는 이름 서버에 대한 도메인/영역을 조회할 때 6개 레코드를 모두 가져와서 순환합니까?

예, 적절한 재귀 네임서버는 모든 네임서버를 고려하고 나중에 가장 빠른 네임서버를 쿼리하려고 시도합니다.

대략적인 알고리즘은 다음과 같습니다.

콜드 스타트(캐시 없음)에서 무작위로 모두 시도하고 응답 속도를 기록합니다(UDP 사례와 TCP 사례를 분리해야 할 수도 있음).
시간이 지나면 이전 답변을 바탕으로 가장 빠른 답변을 더 자주 사용하기 시작합니다.
하지만 특정 네임서버를 무한정 사용하지 않도록 주의해야 하며, 다른 네임서버도 "가끔" 시도해야 합니다. 왜? 네트워크 토폴로지뿐만 아니라 네임서버 자체도 변경될 수 있기 때문입니다. ns3특정 유리한 지점에서는 오늘이 더 빠를 수도 있지만 내일은 그럴 수도 있습니다 ns5. 따라서 가장 빠른 것을 사용해야 하지만 항상 그런 것은 아닙니다. 단지 지금 가장 빠르다고 생각하는 것보다 더 빠른 다른 것을 자동으로 발견할 수 있는지 확인하기 위한 것입니다.

리졸버가 첫 번째 NS 서버를 사용하는 경우

여기서 멈춰. 기록은 목록이 아닌 세트로 제공됩니다. 즉, DNS에는 고유한 순서가 없습니다. 물론 와이어나 디스플레이 표현에는 순서가 있지만 프로토콜에서 나오는 것은 아닙니다.

기록 세트는 가방과 같습니다. 주문 없이도 기록을 얻을 수 있습니다. 실제로 동일한 쿼리에 대해 응답에 여러 레코드가 있는 경우 많은 네임서버가 쿼리할 때마다 레코드 순서를 다르게 지정한다는 것을 알 수 있습니다. 이는 정확히 첫 번째 항목만 고려하는 클라이언트 시스템과 맞서 싸우기 위한 것입니다. 다른 사람들을 무시하십시오.

해당 권한 있는 이름 서버가 응답하지 않을 때

위의 알고리즘을 참조하세요. 세트의 네임서버 중 하나가 NS응답하지 않는 경우 "다른 네임서버 중 가장 느린 것으로 응답"하는 것과 동일한 것으로 간주할 수 있습니다. 클라이언트 DNS에는 시간 초과가 있으므로 무한히 기다리지는 않지만 이 특정 이름 서버가 너무 느리다고 표시하여 다른 이름 서버로 전환합니다. 따라서 처음에는 시스템이 해당 네임서버에 접속을 시도하고 잠시(몇 초) 기다린 후 다시 시도하고 어느 시점에서는 해당 네임서버 사용을 중지해야 하기 때문에 페널티가 발생합니다. 해당 램프 후에는 다른 네임서버를 사용하게 되며 작업 속도가 빨라집니다. 그러나 실제로 접속을 시도하여 특정 네임서버가 느리거나 응답하지 않는다는 것을 처음으로 발견해야 하는 경우 시도하지 않고는 문제를 추론할 수 없습니다.

NS 레코드에 대해 짧은 TTL을 설정해야 한다는 뜻인가요?

그럴 수도 있지만 대부분 관련이 없습니다. 왜? 귀하의 NS레코드는 도메인의 상위 영역에 게시되므로 DNS 위임을 보장합니다. 물론 모든 레코드에는 TTL이 첨부되어 있으므로 TTL과 함께 게시되지만 제어할 수 없는 영역에 게시되므로 TTL 값을 선택할 수 없습니다!

(여기에는 해당 레코드에 대해 복잡하거나 완전히 완료되지 않은 토론이 있습니다. 예를 들어 "어느 것이 실제로 권위가 있는지"라는 질문과 함께 부모와 자식의 두 부분으로 존재하는 것과 같습니다 . 부모의 레코드 NS에 대한 TTL이 1주일인 경우 NS귀하의 영역에 있는 동일한 NS레코드의 TTL은 1초입니다. 재귀 네임서버는 일반적으로 위임의 하위 부분이 권한이 있다는 결론에 도달할 수 있으므로 실제로는 여러 DNS 구현에서 1초가 승리합니다. "부모 중심"입니다. 즉, 부모 측에서 데이터를 사용하므로 1주일이 걸립니다.

TTL은 항상 절충안이 됩니다. 어떤 사람들은 TTL이 매우 낮을 때 더 잘 작동한다는 결론을 즉각적으로 내립니다. 이는 어떤 경우에는 사실이고 다른 경우에는 그렇지 않습니다. 캐시는 좋은 것입니다. 캐시가 없으면(일명: 충분히 큰 TTL을 사용하지 않는 경우) 작은 문제에 대해 탄력적이지 않습니다. 캐시가 이름을 이미 만료했기 때문에 모든 것이 사라질 것입니다.

또한 TTL 값은 모든 네임서버를 따라 순환하고 시간 초과를 시도하고 가장 빠른 네임서버로 수렴하는 위의 알고리즘에 전혀(또는 거의) 영향을 미치지 않습니다.

따라서 TLD 네임서버(해당 TLD 아래의 모든 도메인에 대한 레코드를 호스트하는) 또는 다양한 권장 사항에서 발생하는 상황을 살펴보면 TTL이 1일 또는 2일인 레코드를 NS자주 볼 수 있습니다 .NS

확인자 DNS가 응답하지 않는 NS 및 해당 TTL과 어떻게 작동하는지에 대한 조언이 있습니까?

각 확인자는 자체적으로 수행합니다. :-) 이는 실제로 프로토콜에 의해 지정되지 않으며 구현 세부 사항입니다. 설치할 수 있는 소스 코드를 연구할 수 있지만 대규모 공용 재귀 DNS 공급자로부터 이에 대한 세부 정보를 수집할 수는 없을 것입니다.

여기에서 자세한 내용을 확인할 수 있습니다.

RFC 1034 §5.3.3은 일부 정보도 제공합니다. (또한 잊어버린 한 가지 경우를 고려한다는 점에 유의하세요. 특정 네임서버는 여러 개의 IP 주소를 가질 수 있습니다. 오늘날에도 IPv4와 IPv6는 하나씩 항상 있어야 합니다. 각각에 대해 동일한 시간 내에 결과를 얻을 수 있다는 보장은 없습니다.)

서버의 이름과 주소 외에도 최상의 서버를 먼저 사용하고 모든 서버의 모든 주소가 라운드 로빈 방식으로 사용되도록 SLIST 데이터 구조를 정렬할 수 있습니다. 정렬은 로컬 네트워크의 주소를 다른 주소보다 선호하는 간단한 기능일 수도 있고, 이전 응답 시간 및 타율과 같은 과거 이벤트의 통계를 포함할 수도 있습니다.

3단계에서는 응답을 받을 때까지 쿼리를 보냅니다. 전략은 각 전송 사이에 시간 초과를 두고 모든 서버의 모든 주소를 순환하는 것입니다. 실제로는 멀티홈 호스트의 모든 주소를 사용하는 것이 중요하며, 너무 공격적인 재전송 정책은 동일한 이름 서버에 대해 경합하는 여러 확인자에서 사용될 때, 때로는 단일 확인자를 위해 경합하는 경우 실제로 응답 속도를 느리게 합니다. SLIST에는 일반적으로 시간 초과를 제어하고 이전 전송을 추적하는 데이터 값이 포함되어 있습니다.

RFC 1035 §7.2에는 다음과 같은 내용이 있습니다.

SLIST의 초기화를 완료하기 위해 확인자는 자신이 가지고 있는 모든 기록 정보를 SLIST의 각 주소에 연결합니다. 이는 일반적으로 주소의 응답 시간에 대한 일종의 가중 평균과 주소의 타격 평균(예: 주소가 요청에 응답한 빈도)으로 구성됩니다. 특정 서버의 응답 시간과 타격 평균은 주소마다 상당히 다를 수 있으므로 이 정보는 네임 서버 기준이 아닌 주소 기준으로 유지되어야 합니다. 또한 이 정보는 실제로 확인자 주소/서버 주소 쌍에만 해당되므로 주소가 여러 개인 확인자는 각 주소에 대해 별도의 기록을 유지하려고 할 수 있습니다. 이 단계의 일부는 그러한 기록이 없는 주소를 처리해야 합니다. 이 경우 예상 왕복 시간은 5~10초가 최악의 경우이며 동일한 로컬 네트워크에 대한 추정치는 더 낮습니다.

위임을 따를 때마다 확인자 알고리즘이 SLIST를 다시 초기화합니다.

이 정보는 사용 가능한 이름 서버 주소의 부분 순위를 설정합니다. 주소가 선택될 때마다 다른 모든 주소를 시도할 때까지 해당 주소가 다시 선택되지 않도록 상태를 변경해야 합니다. 각 전송의 시간 초과는 응답의 변동을 허용하기 위해 평균 예측 값보다 50-100% 더 커야 합니다.

또한 이에 대해 더 구체적으로 마무리하려면 다음을 수행하십시오.

imperva의 이 글에 설명된 대로

귀하가 참조한 이 문서에서는 중단이 발생했을 때 Dyn 네임서버를 사용하는 사람들에게 발생한 문제에 대해 설명합니다. 그렇다면, 그렇습니다. Dyn 네임서버만 사용한다면 문제가 발생합니다. 다른 영역을 사용하기 위해 영역을 변경하더라도 NS레코드 TTL은 변경 사항이 즉시 표시되지 않음을 의미합니다. 그러나 실제로 이는 TTL에 대해 많은 것을 말해주지 않고 단지 DNS 관리에 관해 많은 것을 말해 줍니다. 중요한 영역에 대해 탄력성을 갖고 싶다면 단일 DNS 공급자를 사용하지 말고 여러 공급자를 사용하십시오(물론 서로 간의 조정이 필요함). 공급자 X와 Y를 임의로 혼합하고 일치시킬 수는 없으며 DNSSEC를 통해 혼합하는 경우 훨씬 더 복잡하지만 가능합니다. 그렇게 하면 위에서 신속하게 작성된 알고리즘 때문에 5개 중 2개가 특정 공급자에 문제가 있어서 네임서버가 완전히 응답하지 못한다고 해도 다른 공급자가 부하를 받아 도메인이 작동하도록 할 것입니다. 방문자에 대한 새로운 쿼리가 나올 때마다 추가 지연이 있을 수 있으며(모든 재귀 네임서버는 5개 중 2개가 다운되었기 때문에 특정 네임서버로 전환해야 한다는 사실을 즉시 이해할 수 없기 때문입니다), 또한 나머지 3개는 더 많은 쿼리로 인해 더 많은 지연이 발생할 수 있습니다. (DNS는 기본적으로 로드 밸런싱을 수행하므로 이론적으로 각 네임서버는 대략 동일한 양의 쿼리를 가져옵니다.) 그래도 응답은 제공됩니다.

추신: 요청되지는 않았지만 때로는 명확하지 않기 때문에 특정 레코드 세트의 모든 레코드는 동일한 TTL을 가져야 합니다. TTL은 레코드별로 이루어지지만 지정된 레코드 세트에서 동일해야 합니다. 즉, (이름, 레코드 유형) [및 클래스]의 지정된 튜플에 대해 의미하지만 IN클래스 외에는 누구도 사용하지 않습니다.

Answer 1

DNS 확인자가 권한 있는 이름 서버에 대한 도메인/영역을 조회할 때 6개 레코드를 모두 가져와서 순환합니까?

예, 적절한 재귀 네임서버는 모든 네임서버를 고려하고 나중에 가장 빠른 네임서버를 쿼리하려고 시도합니다.

대략적인 알고리즘은 다음과 같습니다.

콜드 스타트(캐시 없음)에서 무작위로 모두 시도하고 응답 속도를 기록합니다(UDP 사례와 TCP 사례를 분리해야 할 수도 있음).
시간이 지나면 이전 답변을 바탕으로 가장 빠른 답변을 더 자주 사용하기 시작합니다.
하지만 특정 네임서버를 무한정 사용하지 않도록 주의해야 하며, 다른 네임서버도 "가끔" 시도해야 합니다. 왜? 네트워크 토폴로지뿐만 아니라 네임서버 자체도 변경될 수 있기 때문입니다. ns3특정 유리한 지점에서는 오늘이 더 빠를 수도 있지만 내일은 그럴 수도 있습니다 ns5. 따라서 가장 빠른 것을 사용해야 하지만 항상 그런 것은 아닙니다. 단지 지금 가장 빠르다고 생각하는 것보다 더 빠른 다른 것을 자동으로 발견할 수 있는지 확인하기 위한 것입니다.

리졸버가 첫 번째 NS 서버를 사용하는 경우

여기서 멈춰. 기록은 목록이 아닌 세트로 제공됩니다. 즉, DNS에는 고유한 순서가 없습니다. 물론 와이어나 디스플레이 표현에는 순서가 있지만 프로토콜에서 나오는 것은 아닙니다.

기록 세트는 가방과 같습니다. 주문 없이도 기록을 얻을 수 있습니다. 실제로 동일한 쿼리에 대해 응답에 여러 레코드가 있는 경우 많은 네임서버가 쿼리할 때마다 레코드 순서를 다르게 지정한다는 것을 알 수 있습니다. 이는 정확히 첫 번째 항목만 고려하는 클라이언트 시스템과 맞서 싸우기 위한 것입니다. 다른 사람들을 무시하십시오.

해당 권한 있는 이름 서버가 응답하지 않을 때

위의 알고리즘을 참조하세요. 세트의 네임서버 중 하나가 NS응답하지 않는 경우 "다른 네임서버 중 가장 느린 것으로 응답"하는 것과 동일한 것으로 간주할 수 있습니다. 클라이언트 DNS에는 시간 초과가 있으므로 무한히 기다리지는 않지만 이 특정 이름 서버가 너무 느리다고 표시하여 다른 이름 서버로 전환합니다. 따라서 처음에는 시스템이 해당 네임서버에 접속을 시도하고 잠시(몇 초) 기다린 후 다시 시도하고 어느 시점에서는 해당 네임서버 사용을 중지해야 하기 때문에 페널티가 발생합니다. 해당 램프 후에는 다른 네임서버를 사용하게 되며 작업 속도가 빨라집니다. 그러나 실제로 접속을 시도하여 특정 네임서버가 느리거나 응답하지 않는다는 것을 처음으로 발견해야 하는 경우 시도하지 않고는 문제를 추론할 수 없습니다.

NS 레코드에 대해 짧은 TTL을 설정해야 한다는 뜻인가요?

그럴 수도 있지만 대부분 관련이 없습니다. 왜? 귀하의 NS레코드는 도메인의 상위 영역에 게시되므로 DNS 위임을 보장합니다. 물론 모든 레코드에는 TTL이 첨부되어 있으므로 TTL과 함께 게시되지만 제어할 수 없는 영역에 게시되므로 TTL 값을 선택할 수 없습니다!

(여기에는 해당 레코드에 대해 복잡하거나 완전히 완료되지 않은 토론이 있습니다. 예를 들어 "어느 것이 실제로 권위가 있는지"라는 질문과 함께 부모와 자식의 두 부분으로 존재하는 것과 같습니다 . 부모의 레코드 NS에 대한 TTL이 1주일인 경우 NS귀하의 영역에 있는 동일한 NS레코드의 TTL은 1초입니다. 재귀 네임서버는 일반적으로 위임의 하위 부분이 권한이 있다는 결론에 도달할 수 있으므로 실제로는 여러 DNS 구현에서 1초가 승리합니다. "부모 중심"입니다. 즉, 부모 측에서 데이터를 사용하므로 1주일이 걸립니다.

TTL은 항상 절충안이 됩니다. 어떤 사람들은 TTL이 매우 낮을 때 더 잘 작동한다는 결론을 즉각적으로 내립니다. 이는 어떤 경우에는 사실이고 다른 경우에는 그렇지 않습니다. 캐시는 좋은 것입니다. 캐시가 없으면(일명: 충분히 큰 TTL을 사용하지 않는 경우) 작은 문제에 대해 탄력적이지 않습니다. 캐시가 이름을 이미 만료했기 때문에 모든 것이 사라질 것입니다.

또한 TTL 값은 모든 네임서버를 따라 순환하고 시간 초과를 시도하고 가장 빠른 네임서버로 수렴하는 위의 알고리즘에 전혀(또는 거의) 영향을 미치지 않습니다.

따라서 TLD 네임서버(해당 TLD 아래의 모든 도메인에 대한 레코드를 호스트하는) 또는 다양한 권장 사항에서 발생하는 상황을 살펴보면 TTL이 1일 또는 2일인 레코드를 NS자주 볼 수 있습니다 .NS

확인자 DNS가 응답하지 않는 NS 및 해당 TTL과 어떻게 작동하는지에 대한 조언이 있습니까?

각 확인자는 자체적으로 수행합니다. :-) 이는 실제로 프로토콜에 의해 지정되지 않으며 구현 세부 사항입니다. 설치할 수 있는 소스 코드를 연구할 수 있지만 대규모 공용 재귀 DNS 공급자로부터 이에 대한 세부 정보를 수집할 수는 없을 것입니다.

여기에서 자세한 내용을 확인할 수 있습니다.

RFC 1034 §5.3.3은 일부 정보도 제공합니다. (또한 잊어버린 한 가지 경우를 고려한다는 점에 유의하세요. 특정 네임서버는 여러 개의 IP 주소를 가질 수 있습니다. 오늘날에도 IPv4와 IPv6는 하나씩 항상 있어야 합니다. 각각에 대해 동일한 시간 내에 결과를 얻을 수 있다는 보장은 없습니다.)

서버의 이름과 주소 외에도 최상의 서버를 먼저 사용하고 모든 서버의 모든 주소가 라운드 로빈 방식으로 사용되도록 SLIST 데이터 구조를 정렬할 수 있습니다. 정렬은 로컬 네트워크의 주소를 다른 주소보다 선호하는 간단한 기능일 수도 있고, 이전 응답 시간 및 타율과 같은 과거 이벤트의 통계를 포함할 수도 있습니다.

3단계에서는 응답을 받을 때까지 쿼리를 보냅니다. 전략은 각 전송 사이에 시간 초과를 두고 모든 서버의 모든 주소를 순환하는 것입니다. 실제로는 멀티홈 호스트의 모든 주소를 사용하는 것이 중요하며, 너무 공격적인 재전송 정책은 동일한 이름 서버에 대해 경합하는 여러 확인자에서 사용될 때, 때로는 단일 확인자를 위해 경합하는 경우 실제로 응답 속도를 느리게 합니다. SLIST에는 일반적으로 시간 초과를 제어하고 이전 전송을 추적하는 데이터 값이 포함되어 있습니다.

RFC 1035 §7.2에는 다음과 같은 내용이 있습니다.

SLIST의 초기화를 완료하기 위해 확인자는 자신이 가지고 있는 모든 기록 정보를 SLIST의 각 주소에 연결합니다. 이는 일반적으로 주소의 응답 시간에 대한 일종의 가중 평균과 주소의 타격 평균(예: 주소가 요청에 응답한 빈도)으로 구성됩니다. 특정 서버의 응답 시간과 타격 평균은 주소마다 상당히 다를 수 있으므로 이 정보는 네임 서버 기준이 아닌 주소 기준으로 유지되어야 합니다. 또한 이 정보는 실제로 확인자 주소/서버 주소 쌍에만 해당되므로 주소가 여러 개인 확인자는 각 주소에 대해 별도의 기록을 유지하려고 할 수 있습니다. 이 단계의 일부는 그러한 기록이 없는 주소를 처리해야 합니다. 이 경우 예상 왕복 시간은 5~10초가 최악의 경우이며 동일한 로컬 네트워크에 대한 추정치는 더 낮습니다.

위임을 따를 때마다 확인자 알고리즘이 SLIST를 다시 초기화합니다.

이 정보는 사용 가능한 이름 서버 주소의 부분 순위를 설정합니다. 주소가 선택될 때마다 다른 모든 주소를 시도할 때까지 해당 주소가 다시 선택되지 않도록 상태를 변경해야 합니다. 각 전송의 시간 초과는 응답의 변동을 허용하기 위해 평균 예측 값보다 50-100% 더 커야 합니다.

또한 이에 대해 더 구체적으로 마무리하려면 다음을 수행하십시오.

imperva의 이 글에 설명된 대로

귀하가 참조한 이 문서에서는 중단이 발생했을 때 Dyn 네임서버를 사용하는 사람들에게 발생한 문제에 대해 설명합니다. 그렇다면, 그렇습니다. Dyn 네임서버만 사용한다면 문제가 발생합니다. 다른 영역을 사용하기 위해 영역을 변경하더라도 NS레코드 TTL은 변경 사항이 즉시 표시되지 않음을 의미합니다. 그러나 실제로 이는 TTL에 대해 많은 것을 말해주지 않고 단지 DNS 관리에 관해 많은 것을 말해 줍니다. 중요한 영역에 대해 탄력성을 갖고 싶다면 단일 DNS 공급자를 사용하지 말고 여러 공급자를 사용하십시오(물론 서로 간의 조정이 필요함). 공급자 X와 Y를 임의로 혼합하고 일치시킬 수는 없으며 DNSSEC를 통해 혼합하는 경우 훨씬 더 복잡하지만 가능합니다. 그렇게 하면 위에서 신속하게 작성된 알고리즘 때문에 5개 중 2개가 특정 공급자에 문제가 있어서 네임서버가 완전히 응답하지 못한다고 해도 다른 공급자가 부하를 받아 도메인이 작동하도록 할 것입니다. 방문자에 대한 새로운 쿼리가 나올 때마다 추가 지연이 있을 수 있으며(모든 재귀 네임서버는 5개 중 2개가 다운되었기 때문에 특정 네임서버로 전환해야 한다는 사실을 즉시 이해할 수 없기 때문입니다), 또한 나머지 3개는 더 많은 쿼리로 인해 더 많은 지연이 발생할 수 있습니다. (DNS는 기본적으로 로드 밸런싱을 수행하므로 이론적으로 각 네임서버는 대략 동일한 양의 쿼리를 가져옵니다.) 그래도 응답은 제공됩니다.

추신: 요청되지는 않았지만 때로는 명확하지 않기 때문에 특정 레코드 세트의 모든 레코드는 동일한 TTL을 가져야 합니다. TTL은 레코드별로 이루어지지만 지정된 레코드 세트에서 동일해야 합니다. 즉, (이름, 레코드 유형) [및 클래스]의 지정된 튜플에 대해 의미하지만 IN클래스 외에는 누구도 사용하지 않습니다.

DNS 확인자 및 NS 레코드 TTL

답변1

관련 정보