Forum Linux.debian/ubuntu requêtes DNS avec nombreux échecs avec bl.blocklist.de

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
18
nov.
2021

Bonjour,

Dans mon syslog, j'ai de nombreuses occurrences de ce type:

Nov 18 12:00:36 vpsNom named[156]: SERVFAIL unexpected RCODE resolving '_.0.127.bl.blocklist.de/A/IN': 185.21.103.31#53
Nov 18 12:00:36 vpsNom named[156]: SERVFAIL unexpected RCODE resolving '1.0.0.127.bl.blocklist.de/A/IN': 46.252.24.212#53

Elles apparaissent depuis le début de la location de ce vps, soit un peu plus de 3 semaines.

Elles sont très probablement déclenchées par rspamd (elles disparaissent après "sudo service rspamd stop", et réapparaissent quelques minutes après nouveau démarrage.

Les requêtes concernent toutes bl.blocklist.de, toujours avec les deux même ip, 185.21.103.31 et 46.252.24.212.

Si je comprend bien ce que disent ces logs, c'est mon vps qui interrogent ces deux ip à propos des dns de bl.blocklist.de. Il me semble pourtant qu'au moins la seconde ip n'a pas de raison d'être interrogée à ce propos.

Dernier point: ce vps est en construction, il n'y a pour le moment que très peu de trafic email, et ces requêtes ne semblent pas liées à la réception ou à l'émission d'un email. Je n'arrive pas à comprendre ce qui les déclenche, au-delà du fait que ça semble lié à rspamd.

Bref, je n'arrive pas à comprendre ce qui se passe. Vous pouvez peut-être m'aider ?

Merci par avance et bonne journée !
Thierry

  • # des idées...

    Posté par  . Évalué à 2.

    l'adresse en 185 c'est bien un serveur de blocklist.de

    root@machine: ~# dig -x 185.21.103.31
    [...]
    31.103.21.185.in-addr.arpa. 60  IN  PTR webserver3.blocklist.de.
    [...]

    la deuxième appartient à jiffybox

    root@machine: ~# dig -x 46.252.24.212
    [...]
    212.24.252.46.in-addr.arpa. 60  IN  PTR j302527.servers.jiffybox.net.
    [...]

    le Principe de beaucoup de service de blocage par DNS, c'est de renvoyé un code selon que c'est OK ou NON avec cette IP

    ainsi il va tester cette IP et te renvoyer une valeur
    sauf que ton named ne semble pas savoir quoi en faire

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4. Dernière modification le 19 novembre 2021 à 10:32.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: des idées...

        Posté par  . Évalué à 1.

        Bonjour,

        Merci pour ces éléments qui m'aident bien à mieux comprendre comment tout ça fonctionne, notamment les DNSBL que je découvre !

        Après vérification, je pense finalement que les deux adresses ip appartiennent bel et bien à blocklist.de, car il y a un enregistrement dns A ns4.blocklist.de pour la seconde ip.

        Il me reste tout de même quelques questions…

        Il n'y a que très peu de trafic email sur mon serveur, spam compris. Ce qui m'étonne, c'est que les requêtes dns en échec, qui semblent donc déclenchées par rspamd, sont bien plus fréquentes que les réceptions de courriels. Je pensais que rspamd n'était sollicité que lors de la réception d'un email, mais ça n'a pas l'air d'être le cas. J'ai l'impression que dès qu'une connexion est demandée à postfix, même si elle échoue, rspamd est sollicité et vérifie la présence de l'ip demandeuses sur différentes services tel que blocklist.de. Apparemment, c'est même le cas lorsque c'est localhost qui demande une connexion (il y a un service qui fait ça pour vérifier régulièrement que postfix est bien en fonctionnement). Je ne sais pas si c'est le fonctionnement normal, mais il me semble que ça n'a pas de sens de demander si 127.0.0.1 est blacklisté ! Est-ce qu'il est possible de demander à postfix de ne pas solliciter rspamd (ou au moins les vérifications DNSBL) lorsque c'est localhost qui est connecté ? Et est-ce que mes hypothèses et déductions sont ok ?

        L'autre point, c'est que j'ai fait des essais avec la commande dig, comme suggéré par Bruno. Sur mon serveur en construction, la même commande avec la même ip ne renvoi rien du tout ! Comme je suis en train de migrer d'un serveur à l'autre, je dispose d'un autre serveur, chez un autre hébergeur. Sur ce second serveur, le même dig que Bruno renvoi bien la même réponse "127.0.0.13". Comment expliquer cette différence pour une même commande sur deux machines différentes ? Est-ce qu'il faut comprendre que blocklist.de refuse de répondre à l'un des deux serveurs, et si oui est que ça pourrait être lié à trop de sollicitations pour 127.0.0.1 par exemple ?

        Bonne journée,
        Thierry

        • [^] # Re: des idées...

          Posté par  . Évalué à 1.

          En fait, après quelques autres essais, les deux serveurs arrivent à obtenir la même réponse pour la requête:

          $ dig +short 62.90.217.185.bl.blocklist.de

          … mais sur les deux serveurs, parfois, il n'y a pas de réponse !

          J'ai essayé aussi avec:

          dig 1.0.0.127.bl.blocklist.de

          Il n'y a pas de "ANSWER SECTION:", mais le "statut" est "NXDOMAIN" sur les deux serveurs, ce qui semble normal. ça n'explique donc pas les statut "SERVFAIL" vus dans les logs…

          "NXDOMAIN" semble vouloir dire "ce domaine n'existe pas" alors que "SERVFAIL" signifierait "je ne suis pas mesure de répondre".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.