레코드가 있는 곳
인스턴스로 라우팅된 모든 주소에는 편집 가능한 PTR이 있습니다. 패널은 인스턴스 아래에 주소당 한 행씩 나열합니다. API도 동일한 것을 노출합니다:
curl -s https://paragonvps.com/api/v1/instances/<instance-id>/addresses -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[].ptr'하나를 설정:
curl -s -X PUT https://paragonvps.com/api/v1/addresses/<address-id>/ptr -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"ptr":"mail.example.com"}'정방향 레코드가 먼저 존재해야 함
일치하는 A 또는 AAAA가 없는 이름을 가리키는 PTR은 PTR이 없는 것보다 더 나쁩니다. 수신 메일 서버는 불일치를 신호로 읽고, 일부는 그 강점으로 연결을 거부합니다. 정방향 레코드를 게시하고, 해석되는지 확인한 다음 PTR을 설정하십시오.
dig +short mail.example.com A
dig +short mail.example.com AAAA그런 다음 쌍이 양방향으로 일치하는지 확인하십시오:
dig +short -x <ipv4>
dig +short -x <ipv6>dig -x가 in-addr.arpa 또는 ip6.arpa 이름을 조합해 주므로, 손으로 서른두 개의 니블을 뒤집고 그중 하나를 잘못 넣는 것을 피할 수 있습니다.
전파
당사의 권위 있는 영역은 약 1분 내에 변경 사항을 수용합니다. 더 오래 걸리는 것은 음수 캐시입니다: PTR을 설정하기 전에 PTR을 요청한 리졸버는 SOA 최소값(역방향 영역에서 1시간) 동안 빈 응답을 보유할 수 있습니다. 우리 둘 다 그것을 단축할 수 없으며, 쿼리를 다시 시도하는 것은 그것을 증명할 뿐입니다.
IPv6
라우팅된 /64에는 이름을 붙일 수 있는 것보다 더 많은 주소가 있으며, 패널은 각각에 대한 텍스트 필드를 제공하지 않을 것입니다. 두 가지 실행 가능한 접근 방식:
- 실제로 사용하는 개별 주소에 PTR을 설정하십시오. 대부분의 사람들은 메일 발신자용으로 정확히 하나가 필요합니다.
- /64를 포함하는
ip6.arpa영역을 자체 네임서버에 위임하도록 요청하고, 그 후 원하는 대로 생성하십시오. 위임은 티켓이며, 약 하루가 걸리고, 영역에 대해 이미 응답하는 두 개의 네임서버가 필요합니다.
메일 세부 사항
아웃바운드 포트 25는 새 계정에서 닫혀 있습니다. 요청하고, 인스턴스가 무엇을 보내는지 대략 얼마나 많은지 말하면, 우리가 엽니다. 오픈 릴레이가 허용 가능한 사용 정책에서 절대 금지하는 세 가지 중 하나이기 때문에 검사가 존재합니다.
열리면 네 개의 문자열이 일치해야 합니다: 보내는 호스트 이름, PTR, HELO 이름 및 SPF 레코드가 허용하는 것. HELO를 PTR과 동일하게 만들면 소프트 거부의 가장 일반적인 원인이 제거됩니다.
swaks --to [email protected] --server localhost --helo mail.example.com적용되지 않을 때
발생 순서대로 세 가지 원인:
- 정방향 레코드가 없거나, 잘못되었거나, 아직 전파되지 않았습니다.
- 편집한 주소가 트래픽을 보내는 인스턴스와 다른 인스턴스에 속합니다.
- 데몬이 PTR을 설정한 주소가 아닌 /64의 다른 주소에 바인딩됩니다.
세 번째는 놓치기 쉽고 확인하기 쉽습니다:
ip -brief addr
ss -tlnp아웃바운드 연결의 소스 주소가 PTR을 전달하는 주소가 아닌 경우, 커널이 염두에 둔 주소를 선택하기를 기대하지 말고 데몬을 명시적으로 바인딩하십시오.