전파 기한을 변경 계획으로 대체
DNS TTL은 캐시된 정보가 언제 재검토되는지 결정하는 데 도움이 됩니다. 모든 수신기가 교체품을 사용하기 시작하는 전 세계의 한 순간을 계획하지 않습니다. SPF 정책이나 DKIM 열쇠. 서로 다른 확인자가 서로 다른 시간에 이전 답변을 얻었고, 권한 있는 서버가 모두 새 데이터를 제공하지 않을 수 있으며, 애플리케이션이 자체 조회 및 재시도 동작을 가질 수 있습니다.
유용한 변경 계획은 권위 있는 출판과 후속 관찰을 분리합니다. " DNS 호스트가 편집 내용을 수락했습니다"는 "관련 권한 있는 서버가 의도한 답변을 반환합니다"보다 이전 단계입니다. 두 문 모두 1분 전에 보낸 메시지에 대해 특정 메일 수신자가 사용한 내용을 설정하지 않습니다. DNS 고정된 시간이 걸린다는 일반적인 약속보다는 각 마일스톤에 대한 증거로 타임라인을 시작하세요.
어떤 TTL이 관찰되고 있는지 이해
신뢰할 수 있는 리소스 레코드에는 게시된 데이터와 연결된 TTL이 있습니다. 캐시된 응답은 일반적으로 캐시된 데이터의 남은 수명을 보고하므로 두 재귀 확인자가 나머지 TTL이 다른 동일한 텍스트를 반환할 수 있습니다. 이러한 값은 다양한 캐시 상태를 설명합니다. 이는 레코드의 의도된 구성에 대한 두 개의 경쟁 선언이 아닙니다. RFC 1035 , 섹션 4.1.3; RFC 1034 , 섹션 6.2.1.
기존 레코드의 TTL이 긴 경우 해당 값을 줄이면 이미 이전 답변을 저장한 캐시로 역방향으로 도달하지 않습니다. 실질적인 변경에 앞서 축소를 계획하고 이전 캐싱 기간을 고려하도록 하십시오. 유지 관리 계획의 일부로 처리하기 전에 낮은 TTL이 실제로 제공되고 있는지 확인하세요. 이는 계획 지침일 뿐 모든 캐시를 관찰했다는 증거는 아닙니다.
별칭 체인은 고유한 종속성을 추가합니다. 별칭 레코드와 대상의 레코드 세트는 서로 다른 TTL과 연산자를 가질 수 있습니다. 고객 측의 짧은 TTL CNAME 이미 캐시된 대상 키를 동시에 새로 고치도록 강제하지 않습니다. 타이밍을 설명하기 전에 두 이름을 모두 적어 두십시오.
이전 답변과 새 답변을 별도로 모델링합니다.
가상의 SPF 업데이트를 고려해보세요. mail.example.com. 확인자 A는 TTL이 3,600초인 09:50에 이전 정책을 가져옵니다. 10:00에 권한 있는 운영자는 게시된 TTL을 300으로 변경합니다. 10:10에 운영자는 정책을 대체합니다. 확인자 A의 이전 항목은 다른 동작 없이 원래 캐시 수명 동안 10시 50분까지 계속 사용할 수 있습니다. 10시 10분 이후에 처음으로 확인하는 두 번째 확인자는 이미 대체 항목을 반환할 수 있습니다.
이 작업 예제는 측정이나 보장된 만료 일정이 아닌 산술을 발명한 것입니다. 그 교훈은 TTL을 10:00에 낮춰도 Resolver A의 09:50 항목을 다시 작성하지 않는다는 것입니다. 운영 워크시트에는 이전 데이터, 이전 TTL, 당국에서 TTL 변경이 관찰된 시간, 콘텐츠가 변경된 시간 및 후속 샘플링된 확인자 응답이 유지되어야 합니다.
DKIM 순환의 경우 새 게시를 위해 별도의 마일스톤을 유지합니다. 선택자, 가용성 확인, 이를 사용하는 서명 시작 및 이전 선택기 폐기. DNS 캐시 산술만으로는 이전에 보낸 메일 확인이 언제 완료되는지 결정할 수 없습니다. 보낸 사람의 대기열, 재시도 및 보존 요구 사항도 순환 결정에 속합니다. RFC 6376 , 섹션 3.1 및 3.6.
부정적인 답변 및 중단 동작 포함
새로 생성된 이름에는 시간이 지나면서 이전의 긍정적인 기록이 없을 수도 있습니다. 대신 해석기는 이전 NXDOMAIN 또는 NODATA 결과를 보유할 수 있습니다. 부정적인 응답의 SOA 기반 수명은 새로 게시된 TTL과 다른 값입니다. TXT 레코드. 따라서 새 TXT TTL을 변경해도 이전에 캐시된 부재는 지워지지 않습니다. RFC 2308 , 섹션 3 및 5.
간단한 만료 스토리에는 명시적인 표준 예외도 있습니다. RFC 8767 만료된 항목을 정식으로 새로 고칠 수 없는 경우 오래된 데이터 제공을 허용합니다. 발생 여부는 확인자 및 오류 조건에 따라 다릅니다. 단지 0이 아닌 작은 TTL이 있다는 이유만으로 반환된 답변이 최신이라고 가정하지 마십시오. RFC 8767 , 섹션 4–5.
이러한 경우에는 임의의 추가 대기 기간이 필요하지 않고 조사 방식이 변경되어야 합니다. 당국이 동의하지 않는 경우 출판 일관성을 수정합니다. 부정적인 응답이 지속되면 원래 질문과 SOA 컨텍스트를 검사하십시오. 권한에 접근할 수 없는 경우 이미 올바른 TXT 레코드를 반복적으로 편집하기보다는 가용성을 복원하거나 조사하십시오.
릴리스 질문에 답하는 관찰을 선택하세요.
변경하기 전에 관련 기관 및 선택된 반복 경로로부터 정확한 기록과 해당 TTL을 캡처합니다. 그런 다음 동일한 끝점에 대해 동일한 소유자, 유형 및 클래스를 반복합니다. 가능한 경우 영향을 받는 환경과 관련된 경로를 포함하십시오. 여러 공개 확인자는 모든 메일 수신자의 인구 조사가 아닌 샘플로 남아 있습니다.
제안된 쿼리는 다음과 같습니다. @RESOLVER_IP mail.example.com 파헤쳐 보세요. TXT, 와 짝을 이루다 @AUTH_IP mail.example.com 알아보세요. TXT +재귀 없음. UTC 타임스탬프를 사용하여 전체 응답을 저장하고 사용하기 전에 모든 자리 표시자에 라벨을 지정합니다. 로컬 캐시 플러시는 해당 로컬 캐싱 경로만 변경합니다. 원격 수신기의 재귀 캐시를 지울 수 없으므로 전역 완료 제어가 아닙니다.
결과를 정확하게 보고합니다. 어떤 기관이 동의하는지, 어떤 샘플링된 해석기가 새 값을 반환하는지, 어떤 관찰이 누락되어 있는지를 알려줍니다. 그런 다음 의도한 서비스를 통해 제어된 메시지를 보내고 실제 인증 ID와 수신자 결과를 검사합니다. 이 초안에서는 DNS 쿼리나 메시지 테스트가 수행되지 않았습니다. TTL, 응답 유형, 권한 및 관찰 시간을 포함한 필수 확인자 비교는 열린 상태로 유지됩니다.