조회를 정확한 질문으로 전환
dig를 사용하여 명명된 DNS 서버에 정확한 소유자 및 레코드 유형에 대해 문의한 다음 응답을 해석할 수 있는 충분한 컨텍스트를 유지합니다. 이메일 인증의 경우 도메인에 도메인이 있는지 여부가 중심 질문인 경우는 거의 없습니다. TXT 레코드. 송신자나 검증자가 사용하는 종속성이 올바른 이름으로 존재하는지, 해당 경로를 통해 해결할 수 있는지 여부입니다.
이 가이드의 예는 ISC BIND 9.20.13 dig의 문서화된 구문을 대상으로 합니다. 이는 고정된 문서 범위이지 설치된 모든 발굴에 해당 버전이 있거나 최신 릴리스라는 주장이 아닙니다. 모든 명령은 읽기 전용 DNS 쿼리 또는 로컬 버전 확인을 제안합니다. 여기서는 아무도 처형되지 않았습니다. example.com 이름과 192.0.2.0/24 주소는 작동하는 확인자 설정이 아니라 문서 자리 표시자입니다.
이메일이 실제로 사용하는 ID로 시작하세요.
을 위한 SPF, 표시되는 보낸 사람 도메인을 자동으로 사용하는 대신 관련 SMTP ID에 사용되는 도메인을 식별합니다. 을 위한 DKIM, 서명 도메인을 가져오고 선택자 메시지 서명에서. 키 조회 소유자는 선택기를 결합합니다. _domainkey 그리고 도메인 서명. 공급업체 이름에서 선택자를 추측하지 마십시오. RFC 7208 RFC 6376
조회 _dmarc.example.com. 해당 소유자의 정책 기록을 검사할 수 있습니다. 그 자체로는 정책 발견이나 정책 발견의 완전한 구현이 아닙니다. 조정 평가. 메일 전문가에게 결과를 전달할 때 메시지 ID와 적용 가능한 정책 검색 컨텍스트를 유지하세요. DNS 가시성과 인증 결과는 관련되어 있지만 별도의 증거 필드에 속합니다. RFC 9989
소유자, 유형, 쿼리 이유 및 예상 권한을 포함하는 질문지를 작성합니다. 이러한 작은 준비는 잘못된 도메인에 대한 보기 좋게 보이는 답변이 수정 사항으로 받아들여지는 것을 방지합니다. 뒤에 마침표가 있으면 예제의 이름이 절대 DNS 이름을 명시하게 됩니다.
초기 쿼리를 재현 가능하게 만들기
제안된 로컬 명령 발굴 -v 도구 버전을 기록합니다. 제어된 쿼리 형태의 경우 다음을 사용합니다. 파기 -r @ 192.0.2.53 _dmarc.example.com . TXT. 그만큼 -r 옵션은 사용자별 발굴 기본값을 방지하는 반면, server 인수는 DNS 서버를 식별합니다. 별도로 인증된 조회를 위해서만 두 자리 표시자를 모두 교체하세요. 압축 추출을 만들기 전에 전체 출력을 유지합니다. ISC 발굴 매뉴얼
UTC 시간, 소스 네트워크 컨텍스트 및 결과에 실제로 보고된 서버를 기록합니다. 답변을 제외한 모든 것을 숨기는 명령으로 시작하지 마세요. 짧은 답변 전용 보기는 나중에 편리할 수 있지만 초기 증거에는 질문, 상태, 플래그, 답변 및 권한 섹션과 전송 관련 메시지가 보존되어야 합니다. 이러한 세부 사항은 결석, 의뢰 및 실패를 구분합니다.
추천 동반 질문은 다음과 같습니다. 파기 -r @ 192.0.2.53 example.com . TXT 그리고 dig -r @ 192.0.2.53 selector1._domainkey.example.com . TXT. 이는 구문 예이며 두 이름 중 하나에 인증 기록이 있다는 주장이 아닙니다. 승인된 조사에서 실제 이름을 선택하고 어떤 쿼리도 영역의 모든 항목에 대한 보장된 인벤토리로 처리하지 마세요.
재귀적 관찰과 권위 있는 관찰 비교
먼저 쿼리한 서버를 설정합니다. 재귀 확인자는 캐시된 데이터를 반환할 수 있습니다. 권한 있는 서버는 서비스를 제공하는 영역에 대해 응답합니다. 별도로 검증된 기관과 비교하기 위해 제안하는 형태는 다음과 같다. 파기 -r @ 192.0.2.54 _dmarc.example.com . TXT +재귀 없음. 재귀를 비활성화한다고 해서 임의의 서버가 신뢰할 수 있는 것은 아닙니다. 선택한 IP 주소만 신뢰하기보다는 응답과 위임 증거를 확인하세요. RFC 1034
재귀 결과와 신뢰할 수 있는 결과가 일치하지 않으면 둘 다 유지하십시오. 전파를 비난하기 전에 이름, 유형, 값, 응답 상태 및 타임스탬프를 비교하십시오. 감소하는 캐시된 TTL은 유익하지만 모든 관찰자에게 보편적인 만료 기한은 아닙니다. 네거티브 캐시 항목도 자체 규칙을 따릅니다. RFC 2308
답을 구조적으로 읽으십시오. 여러 개의 인용된 문자열이 하나의 TXT 리소스 레코드에 속할 수 있습니다. 여러 TXT 리소스 레코드는 조건이 다릅니다. 두 양식을 공백으로 구분된 하나의 문자열로 병합하지 마십시오. 메일 전문가가 SPF 또는 DKIM 구문을 평가하기 전에 레코드 경계를 보존하십시오. 에이 CNAME 최종 키나 정책 텍스트가 사용 가능하다는 것을 증명하는 대신 조사할 다른 이름을 도입합니다. RFC 1035
그것이 문제가 될 때만 위임을 추적하세요
제안된 쿼리 발굴 -r +추적 example.com . NS 루트의 추천을 따릅니다. 여러 네트워크 쿼리를 보내므로 이에 따라 진단 범위를 승인하세요. 서버 인수를 추가해도 전체 추적이 해당 확인자에 국한되지는 않습니다. 추적은 운영자 네트워크의 위임을 조사합니다. 원격 이메일 수신자가 내린 모든 결정을 재현하지는 않습니다. ISC 발굴 매뉴얼
추적을 검토할 때 마지막으로 성공한 조회, 접속한 서버 및 해결이 중지된 위치를 식별합니다. 한 단계의 시간 초과는 편집 권한이 아닙니다. 네임서버. 결과를 등록 기관 및 DNS 소유자의 인벤토리와 비교한 후 적절한 소유자에게 다음 조사를 할당합니다. 하나의 불완전한 추적을 마이그레이션 권장 사항으로 전환하지 마십시오.
실패 및 검증 주장을 좁게 유지
NXDOMAIN , 요청된 데이터 없이 성공적인 응답 및 SERVFAIL 다른 다음 단계가 필요합니다. 세 가지 모두를 누락된 인증 레코드로 변환하지 마십시오. 운송이 의심되는 경우 제안된 +TCP 비교는 별도의 경로에 도움이 될 수 있지만 한 번의 전송에 대한 성공이 모든 수신자가 레코드를 해결할 수 있다는 것을 증명하지는 않습니다. RFC 1035 RFC 7766
발굴 +dnssec 옵션 요청 DNSSEC 재료; 그 존재는 독립형 암호화 검증 결과가 아닙니다. 적절한 확인자 행동 및 신뢰할 수 있는 증거와 연계된 검증 결론을 유지하세요. 어떤 서버가 어떤 질문, 언제, 무엇이 불확실하게 답변했는지에 대한 간결한 진술로 조사를 마무리합니다. 이 기사에 필요한 타임스탬프가 있는 신뢰할 수 있고 반복적인 기록은 아직 누락되었습니다. 이러한 제안된 명령은 이를 대체할 수 없습니다.