1.2.3.4.list.dsbl.org를 확인할 수 없습니다.

1.2.3.4.list.dsbl.org를 확인할 수 없습니다.

역사: 모든 것은 이 로그 항목으로 시작됩니다.

postfix/smtpd[10001]: warning: x.x.x.x.list.dsbl.org: RBL lookup error: Host or domain name not found. Name service error for name=x.x.x.x.list.dsbl.org type=A: Host not found, try again

수동으로 해결하려고 시도했지만 시간이 초과되었습니다. Google의 공개 DNS 서버를 사용하려는 시도는 잘 작동했으며 여기서 드라마가 시작됩니다.

localhost로부터의 재귀를 허용하도록 바인딩을 구성한 다음 DNS 서버를 이름 서버 /etc/resolv.conf로 사용 하도록 전환했습니다. 127.0.0.1또한 Google의 공용 DNS 서버를 전달자로 지정하려고 시도했지만 존재하지 않았습니다(루트 서버 요청). 결과는 동일합니다.

1.2.3.4.list.dsbl.org를 살펴보세요.

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org ;;전역 옵션: +cmd ;;답변 얻기: ;; ->>HEADER<<- opcode: QUERY, 상태: SERVFAIL, id: 12810;; 플래그: qr rd ra; 쿼리: 1, 답변: 0, 권한: 0, 추가: 1

;;의사 섹션 선택:; EDNS: 버전: 0, UDP: 4096;;문제 섹션:;1.2.3.4.list.dsbl.org. 안에

;;쿼리 시간: 0ms;;서버: 127.0.0.1#53(127.0.0.1);;시간: 2017년 1월 4일 수요일 12:55:36 UTC;;MSG 크기 rcvd: 50

3~4초 지나면 실패합니다. Google의 공개 DNS를 사용해 보세요.

1.2.3.4.list.dsbl.org @8.8.8.8을 파헤쳐 보세요.

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> 1.2.3.4.list.dsbl.org @8.8.8.8 ;;전역 옵션: +cmd ;;답변 얻기: ;; ->>HEADER <<- opcode: QUERY, 상태: SERVFAIL, id: 62982;; 플래그: qr rd ra; 쿼리: 1, 답변: 0, 권한: 1

;;의사 섹션 선택:; EDNS: 버전: 0, UDP: 512;;문제 섹션:;1.2.3.4.list.dsbl.org. 안에

;;쿼리 시간: 28ms;;서버: 8.8.8.8#53(8.8.8.8);;시간: Wed Jan 4, 2017 12:57:28 UTC 2017;;MSG 크기 rcvd: 50

이것이 작동하지만

somedomain.com을 살펴보세요.

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a somedomain.com ;;전역 옵션: +cmd ;;답변 얻기: ;; ->>HEADER<<- Opcode: QUERY, status: NOERROR, id: 35713;; 플래그: qr rd ra; 쿼리: 1, 답변: 1, 권한: 2, 추가: 5

;;의사 섹션 선택: EDNS: 버전: 0, UDP: 4096;;문제 섹션:;somedomain.com. 안에

;;답변 부분: somedomain.com. 69.172.201.153에서 300

;;신뢰할 수 있는 부분: somedomain.com. 172800 IN NS Sell.internetraffic.com. somedomain.com. 172800 IN NS buy.internetraffic.com.

;;추가 섹션: buy.internetraffic.com. 172800 IN A 64.96.240.54 buy.internetraffic.com. 172800 IN A 64.96.241.73 Sell.internetraffic.com. 172800 IN A 176.74.176.176 Sell.internetraffic.com. 176.74.176.175에서 172800

;;쿼리 시간: 49ms;;서버: 127.0.0.1#53(127.0.0.1);;시간: 2017년 1월 4일 수요일 12:56:30 UTC 2017;;MSG 크기 rcvd: 176

각주:Google의 DNS를 사용해야만 /etc/resolv.conf로컬에서 제대로 작동합니다. postfix를 다시 시작하면 파일이 복사되지만 /var/spool/postfix/etc/resolv.conf여전히 호스트에 대해 동일한 로그를 확인할 수 없습니다.

내가 무엇을 놓치고 있나요?

답변1

DSBL은 2008년 말에 중단되었습니다. 오랫동안(1년?) DNS가 여전히 쿼리를 해결했습니다.

일부 이전 지침은 블랙리스트/도메인을 참조할 수 있지만 이 목록은 오래 전에 사라졌고 DNS 요청이 더 이상 해결되지 않으므로 구성하지 않는 것이 좋습니다.

Google DNS에는 알려진 문제를 해결하는 바로가기/최적화 기능이 있으며 도메인이 블랙리스트 또는 일종의 RPZ 구성에 있을 수 있습니다. 대규모 작업에서는 Non 문제를 해결하기 위해 여전히 과도하게 구성된 주소에 대해서도 동일한 작업을 수행합니다. -존재하는 도메인은 귀중한 리소스를 차지합니다.

요청을 필터링하기 위해 유사한 블랙리스트가 생성되고 최종 결과는 최상위 루트 이름 서버(TLD)에 리소스를 절약하기 때문에 일부 유사한 구성도 "좋은" 네티즌이 되는 것의 일부입니다.

Google 맞춤설정 아이디어를 강화하면 맞춤 코드가 있는 것으로 알려져 있으며, 성능이라는 이름으로 RR에서 지나치게 낮은 TTL을 무시하는 등 일부 "특이한" 기능이 있는 것으로 알려져 있습니다. (그 이후로 BIND는 내 기억이 맞다면 RR에 허용되는 더 낮은 TTL을 정의하는 전역 옵션을 만들었습니다.)

귀하의 서버가 블랙리스트가 구성된 상태에서 이렇게 오랫동안 살아남았는지 모르겠습니다. dsbl.org해당 주소가 사용을 중지했을 때 이메일 서버 지연으로 인해 블랙리스트 구성에서 해당 주소를 제거해야 했기 때문입니다.

요청 시 BIND에서 도메인을 블랙리스트에 추가합니다.

영역 파일은 다음 위치에 있습니다./etc/bind/rpz.db

*.list.dsbl.org CNAME   *.

named.conf정의된 내부 보기에 영역 파일 추가 :

zone "rpz" {
  type master;
  file "/etc/bind/rpz.db";
  allow-query { your_internal_network; };
};

다음에 추가 named.conf.options:

options {
   ...
   response-policy { zone "rpz"; };
}

또한보십시오:

Bind9의 대형 영역 파일: 광고 차단

BIND를 전달자 전용(루트 프롬프트 없음), 암호화 + RPZ 블랙리스트/화이트리스트로 구성

다양한 수준의 도메인에 RPZ 구성 바인딩

답변2

DSBL이 사라졌습니다. DSBL이 사라져서 다시 돌아올 가능성이 매우 낮습니다. 메일 서버 구성에서 이를 제거하십시오.

관련 정보