SPF 레코드의 변경 사항을 전파하는 데 시간이 걸립니까?

16

도메인에 대한 SPF 레코드를 설정하고 있는데 예상 한 결과를 얻지 못했습니다. 내가 일종의 실수를 저지르는 것이 가능할 수도 있지만, 먼저 묻고 싶습니다. SPF 레코드의 변경 사항이 전파되는 데 시간이 걸립니까?

domain-name-system  spf  latency 
— 다니엘 그리 콤
소스
2
일부 DNS 캐시는 TTL을 무시하고 원하는 시간 동안 레코드를 캐시합니다. 깨진 DNS 캐시가 제어 할 수없는 컴퓨터에서 실행되고 있기 때문에이 문제는 해결되지 않습니다.
— cas
@cas DNS에 대한 TTL의 전체 개념이 불완전하고 순진하기 때문에 서버가 실제로 손상되지 않았습니다. 남용 및 트래픽 수준을 제어 할 수있는 유일한 방법입니다. 이것은 서버가 업스트림 서버에서 긴 TTL을 통과 한 경우 서버가 올바른 TTL을 무시한다는 의미는 아닙니다.
— JamesRyan
1
@JamesRyan 많은 ISP DNS 리졸버가 자신이 전달한 TTL을 완전히 무시합니다. 더 긴 TTL이 제공되는 경우가 아니라 표준에 따라 작동하지 않는 경우입니다.
— EEAA
@EEAA 아니오 실제 표준을 사용할 수없는 표준과 비공식적 규범이 필요를 통해 자리를
— 잡는 사례입니다
3
모든 DNS 변경 사항을 전파하는 데 시간이 걸리며 SPF 레코드에는 특별한 것이 없습니다. 그것들은 나머지 DNS와 똑같은 방식으로 전파됩니다.
— Barmar

답변:

13

예. 영역을 편집하는 방법에 따라 캐싱 또는 기타 지연이있을 수 있습니다 ( nsupdate일부 웹 프런트 엔드가 결국 영역을 업데이트하기 위해 무언가를 수행하는 데이터베이스와 대화하는 경우). 완료 (마스터 DNS 서버가 변경 사항을 푸시하거나 슬레이브가 대신 업데이트를 위해 해당 서버를 주기적으로 폴링하도록 구성 할 수 있음), 신뢰할 수있는 DNS 서버 또는 이전 TXT레코드로 인해 이전 레코드를 캐시했을 수있는 다른 항목을 쿼리하는지 여부 클라이언트에서 쿼리하므로 마스터 서버가 이미 알고있는 변경 사항을 알지 못합니다.

사용 nslookup또는 dig쿼리를 다른 서버로 (또한 확인 SOA일련 번호, 그것은 당신이 오래된 데이터를 찾고, 아니라면 변화에 충돌 있어야합니다).

% dig +short @8.8.8.8 -t TXT google.com
"v=spf1 include:_spf.google.com ~all"
% dig +short @8.8.8.8 -t SOA google.com
ns2.google.com. dns-admin.google.com. 103585632 900 900 1800 60

TTL의 TXT기록은 알고에 중요한 일이 될 수있다; 전체 dig출력에 포함되어야합니다.

— 깡패
소스
흥미 롭군 TXT 레코드의 TTL은 14400 (4 시간)이지만 여전히 Google을 통해 가져 오면 변경 사항이 상당히 빠르게 나타납니다 (1 분 이내). 귀하의 digGoogle 서버를 통해 가져올 명령은 내가하지만, 필요한 것입니다 : 감사합니다.
— Daniel Griscom
2
@DanielGriscom "8.8.8.8"은 단일 머신이 아니라 글로벌 클러스터입니다. 매번 다른 리졸버를 사용하는 것이 좋을 수 있으며 각 리졸버는 캐시를 개별적으로 프라이밍해야 할 수도 있습니다.
— CVn
9

우선, DNS 레코드는 적어도 능동적 인 의미에서 "전파"되지 않습니다. 레코드는 다양한 계층에서 캐시되며 레코드 업데이트 지연은 캐시 된 레코드가 만료되어 업스트림 서버에서 새로 페치 될 때까지 대기하여 발생합니다.

이제 SPF 레코드는 DNS TXT 레코드이므로 업데이트하는 데 시간이 걸릴 수 있습니다.

— EEAA
소스
캐시 된 레코드의 계층에서 지연 대기가 IS 전파됩니다!
— JamesRyan
3
@JamesRyan 전파 는 레코드가 확산 되는 데 적극적인 동기 가 있음을 의미합니다 . 그렇지 않습니다. DNS에 익숙하지 않은 많은 사람들은 활성화 된 전파가 있다고 가정합니다. 이것이 제가이 부분을 포함 시켰으며 "활성화 된"부분을 인증 한 이유입니다.
— EEAA
1
@JamesRyan 동의하지 않습니다.
— EEAA
2
이것이 바로 "전파"라는 용어의 사용을 검증 한 이유입니다. 나는 DNS RFC의 말을 이해하고 전파의 의미를 이해합니다. 너무 많은 사람들이 그것이 의미하지 않는 것을 의미한다고 가정하기 때문에 나는 그 용어를 명확히하고있었습니다.
— EEAA
1
@JamesRyan 당신은 항상 명확하게 답변을 편집 할 수 있습니다.
— EEAA
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.