TTL이 DNS 레코드에 엉망이되면 어떻게됩니까?

누군가가 귀하의 DNS 컨트롤에 액세스하여 도메인에서 100 년의 TTL을 설정하고 IP가 모호한 웹 사이트를 가리키면 어떻게됩니까?

(그리고 당신은 물론 너무 늦게 그것을 발견)

Ryan은 귀하의 질문에 대한 한 가지 해석에 대한 훌륭한 답변을 제공했습니다. 그러나 우리의 목표 청중과 사람들이이 문제에 가장 잘 대처할 수있는 상황을 고려할 때, 나는 다른 질문에 대답 할 것입니다.

나쁜 TTL이 문제가 될 때 회사는 무엇을 하는가?

몇 가지 옵션이 있습니다. 가장 먼저 문제 벡터를 식별하고 제거해야합니다. 자신을 반복하는 문제를 통제 할 수 없을 때 손해를 가하는 것은 무의미합니다.

1. 기다림. 중요한 기록이 아니라면 기다릴 수 있습니다. Ryan이 설명했듯이 "최대 손상"은 68 년이 아니라 실제로 7 일이 될 것입니다. 포지티브 캐시 항목 (BIND, JunOS 등)의 최대 수명 동안 가장 일반적인 기본값입니다. 이것이 정확하지 않은 경우에도 서버가 프로세스를 강제로 다시 시작하는 일상적인 보안 업데이트를 수신하기를 바랍니다. 여러 대형 클러스터의 운영자라고 말하면 MSO 가이 값을 의도적으로 더 큰 값으로 설정할 가능성이 없습니다. 더 많은 외부 문의 (우리가 싫어하는)를 생성하는 역할 만합니다. 덜 인기있는 소프트웨어를 사용하는 회사 나 자신을 싫어하는 운영자를 위해 다음 단계로 넘어 가야 할 수도 있습니다.
2. 귀찮은 DNS 캐시 운영자. 캐시 ASAP에서 기록을 삭제해야하는 경우, 유일한 선택은 생각할 수있는 가장 큰 재귀 DNS 공급자에게 연락하기 시작하는 것입니다. 이러한 회사 중 일부는 고객을 무시하기에 너무 작은 회사라고 생각하거나 처리 요청을 최소화하기 위해 캐시 제거 정책을 자체적으로 설정하는 회사를 무시할 것입니다. 후자의 경우, 아마도 계획된 시간에 문제를 해결하고 해결할 것입니다. 당신 회사는 결국이 문제를 스스로 만들었습니다.
3. ISP 고객이 ISP를 성가 시게하십시오. 며칠이 지났고 대형 ISP가 캐시 된 레코드를 무시하는 경우 고객 중 한 명이 불만을 제기하고 해당 회사 내부의 티켓을 생성하도록하십시오. 이것은 그들이 무시하기 어렵지만, 그들의 관점에서 당신이 이것을 당신 자신에게 한 것처럼, 당신의 작전 팀과의 호의를 얻지 못할 것입니다. 이것이 반복되는 경우, 아마 당신을 침략하기 위해이 티켓을 취소하기 시작할 것입니다.
4. 파트너에게 DNS 레코드를 우회하도록 조언하십시오. 파트너가 사용하는 미션 크리티컬 DNS 레코드이고 위의 옵션 중 어느 것도 허용되지 않는 경우 (즉, 분 단위로 수익이 발생하는 경우) 회사는 파트너와 협력하여 문제를 우회 할 수 없습니다. 이들이 로컬 캐시를 제어하지 않으면, 이는 일반적으로 DNS 레코드를 사용하는 프로그램을 수정할 필요가 없으므로 영향을받는 시스템의 호스트 테이블에 항목을 삽입하여 수행됩니다. 이는 수익 손실이 데이터를 소비하는 일부 소수의 회사와 연계 된 경우 에만 가능합니다. 다른 모든 경우에는 처음 세 가지 옵션이 붙어 있습니다.

글쎄, 내가보고있는 모든 바인드 구성 매뉴얼에서 TTL은 부호있는 32 비트 정수이며 초 단위로 표현되어 이론적으로 최대 2 ^ 31을 제공합니다. 그것은 말한다

유효한 TTL의 범위는 0-2147483647 초입니다.

또는 약 68 년. 따라서 처음에는 100 년으로 설정할 수 없습니다.

68 년으로 설정했다고 가정하겠습니다. 무슨 일이 일어날 지 분명합니다. DNS 레코드에서 매우 긴 TTL을 존중 한 DNS 확인자는 가능한 한 오랫동안 캐시를 캐시합니다. 일부 DNS 확인자는 TTL을 전혀 존중하지 않고 원하는 캐싱 정책 만 구현합니다.

우리가 최대 값에 단일 하드 숫자를 넣을 수없는 이유는 여러 공급 업체가 만든 여러 가지 DNS 구현이 있고 모두 약간 다른 변수를 사용하기 때문입니다. 예를 들어 Juniper JunOS에서 실행되는 DNS 서버는 TTL에서 최대 604800 초 (7 일) 만 진행됩니다.