Accueil › Guides

Codes de retour DNSBL : 127.0.0.2, 127.255.255.x et NXDOMAIN

Publié le 2026-11-03 ／ Mis à jour le 2026-11-03 ／ Par Yuki Nakazawa

Une requête DNSBL qui renvoie une adresse de 127.0.0.0/8 signifie que l'IP ou le domaine est listé ; une réponse NXDOMAIN signifie qu'il ne l'est pas. Au-delà, la valeur exacte dépend de chaque liste, certaines réponses 127.x sont des codes d'erreur et non des inscriptions, et un SERVFAIL ou un délai dépassé ne vous apprend rien du tout sur l'état d'inscription.

Ce guide passe en revue les conventions consignées dans la RFC 5782 et les codes de retour que Spamhaus, SpamCop et UCEPROTECT documentent sur leurs propres pages. Il s'appuie sur ces pages officielles telles qu'elles se présentaient en novembre 2026. Les listes modifient leurs données et leurs règles : consultez la documentation de l'opérateur avant d'agir sur la base d'un résultat. Si vous avez besoin de comprendre d'abord le fonctionnement des listes de blocage, commencez par qu'est-ce qu'une DNSBL (RBL).

Les bases : ce que dit la RFC 5782 sur les codes de retour

La RFC 5782, publiée en février 2010, décrit comment interroger les listes noires et blanches DNS et à quoi ressemblent leurs réponses. C'est un document informatif (Informational), pas une spécification de la voie normative (Standards Track) : elle consigne les pratiques courantes, et le détail de l'attribution des valeurs est laissé à chaque opérateur de liste.

Comment se construit une requête

En IPv4, on inverse l'ordre des octets et on ajoute la zone de la liste. Pour vérifier 192.0.2.99 sur bl.example.com :

dig +short 99.2.0.192.bl.example.com A
dig +short 99.2.0.192.bl.example.com TXT

En IPv6, l'adresse s'écrit sous forme de 32 nibbles hexadécimaux en ordre inverse, suivis de la zone. Les listes basées sur les domaines prennent simplement le nom de domaine suivi du nom de zone ; la RFC note que les listes basées sur les noms sont bien moins répandues que celles basées sur les IP.

L'enregistrement A : listé ou non

• Listé : la liste renvoie un enregistrement A. La RFC indique que toutes les valeurs A devraient se situer dans 127.0.0.0/8, pour éviter un trafic réseau indésirable, et que la valeur est par convention 127.0.0.2.
• Non listé : il ne doit exister aucun enregistrement pour l'adresse. En termes DNS, la réponse est NXDOMAIN, c'est-à-dire que le nom n'existe pas.
• La valeur de l'enregistrement A ne doit pas être utilisée comme adresse IP. 127.0.0.2 est un indicateur, pas un serveur auquel se connecter.

L'enregistrement TXT : le motif et une URL

Selon la RFC, les DNSBL devraient publier un enregistrement TXT expliquant pourquoi une entrée est listée, et ce motif comprend souvent une URL donnant plus d'informations. Le logiciel client doit vérifier l'enregistrement A et peut vérifier l'enregistrement TXT. Le texte TXT est souvent repris dans le message d'erreur SMTP : un message de rejet peut donc contenir une URL de vérification ou de retrait qui en provient.

Pourquoi les valeurs diffèrent : sous-listes et masques de bits

Une valeur autre que 127.0.0.2 signifie généralement que la zone regroupe plusieurs sous-listes. La RFC 5782 décrit trois façons de les représenter : des sous-domaines, plusieurs enregistrements A et des valeurs codées en bits.

• Plusieurs enregistrements A : chaque sous-liste a sa propre valeur, et la liste renvoie un enregistrement A pour chaque sous-liste sur laquelle figure l'adresse.
• Masques de bits : un bit est attribué à chaque sous-liste, et la réponse est le OU logique des bits de toutes les sous-listes correspondantes. Dans l'exemple de la RFC, une adresse figurant sur les sous-listes 127.0.0.2 et 127.0.0.4 renvoie 127.0.0.6.

Le point essentiel est que la RFC elle-même indique qu'il n'existe aucune convention largement utilisée pour faire correspondre les noms de sous-listes à des valeurs. Une même valeur peut avoir des sens différents selon les listes. Interprétez toujours un code de retour avec la zone qui l'a produit, à la lumière de la documentation de cette liste. La RFC précise aussi que le logiciel client devrait pouvoir appliquer des masques de bits et des tests de plages de valeurs aux valeurs renvoyées.

Spamhaus ZEN illustre bien le style à réponses multiples. Sa documentation indique qu'une requête produit généralement plusieurs réponses distinctes dans la même réponse DNS, une par jeu de données sur lequel l'IP est listée, avec un code de retour différent pour chacun. Voir deux ou trois codes à la fois est donc normal.

Codes de retour des principales listes de blocage

Le tableau ci-dessous reprend les codes de retour que les opérateurs documentent sur leurs pages officielles.

• Spamhaus : ZEN regroupe la SBL, la CSS, la XBL et la PBL et ne couvre que les adresses IP ; les domaines se vérifient sur la DBL. La DBL utilise 127.0.1.0/24 et la liste Zero Reputation Domains utilise 127.0.2.0/24. Comme la DBL répond toujours 127.0.1.255 à une requête sur une IP, elle ne peut pas servir à vérifier des IP. Pour la signification de chaque liste Spamhaus et la manière de demander un retrait, voir notre guide de retrait Spamhaus.
• SpamCop : la FAQ officielle indique 127.0.0.2 comme réponse signalant une IP listée. Elle recommande aussi de laisser aux utilisateurs l'accès aux e-mails filtrés, par exemple en les étiquetant ou en les déplaçant dans un dossier séparé, plutôt que de les rejeter purement et simplement. Le retrait est traité dans notre guide de retrait SpamCop.
• UCEPROTECT : la page d'utilisation DNS énumère les trois noms de zone mais ne décrit pas les valeurs de retour. Elle indique que la méthode DNS n'est vraiment utile que pour les petits et moyens serveurs de messagerie et suggère rsync pour les systèmes qui effectuent plus de 100 000 requêtes par jour. Les niveaux sont expliqués dans notre guide UCEPROTECT Level 2 et 3.
• Barracuda : ses valeurs de retour ne sont pas traitées ici. Consultez les pages de Barracuda Central.

127.255.255.x et résolveurs publics : des réponses qui ne sont pas des inscriptions

Spamhaus réserve 127.255.255.0/24 aux codes d'erreur. Ils peuvent être renvoyés pour n'importe quelle zone, et la FAQ officielle précise qu'ils ne doivent pas être interprétés comme une inscription de l'objet interrogé.

Pourquoi les résultats des résolveurs publics ne sont pas fiables

La FAQ de Spamhaus indique que, lorsque vous interrogez via de grands résolveurs publics, vous obtenez dans la plupart des cas une réponse « non listé » (NXDOMAIN). Autrement dit, une IP listée peut sembler propre. La même FAQ cite l'utilisation d'Amazon, Quad9, Google, Cloudflare ou d'un autre résolveur public comme la cause la plus fréquente du problème inverse, lorsqu'une liste semble bloquer tout Internet.

Certains résolveurs réécrivent aussi les réponses NXDOMAIN et renvoient une adresse IP pour des noms qui n'existent pas. Un serveur de messagerie peut prendre cela pour une inscription. La FAQ suggère de configurer le serveur de messagerie pour ignorer toute réponse hors de 127.0.0.0/8, d'exploiter votre propre résolveur, ou de contacter votre FAI ou votre fournisseur DNS. Pour savoir quel résolveur vous utilisez réellement, la FAQ propose cette vérification :

dig txt whoami.fastly.net

Si vous appliquez un filtrage DNSBL sur votre propre serveur de messagerie, assurez-vous aussi qu'il ne rejette pas les e-mails dès qu'il reçoit une réponse 127.255.255.x. Spamhaus qualifie cela d'erreur de configuration.

NXDOMAIN, SERVFAIL ou délai dépassé

Chaque réponse DNS comporte un code de réponse (RCODE), défini dans la RFC 1035. Lorsque vous lisez un résultat DNSBL, distinguez le RCODE de la valeur de l'enregistrement A.

La RFC 5782 ne dit pas comment les clients doivent traiter une liste qui échoue ou ne répond pas. Interpréter un SERVFAIL ou un délai dépassé comme listé ou comme non listé est une erreur. Réessayez plus tard ou interrogez par un autre chemin.

Utiliser les entrées de test pour vérifier qu'une liste fonctionne

La RFC 5782 exige que les listes IPv4 contiennent une entrée pour 127.0.0.2 et n'en contiennent pas pour 127.0.0.1. Les listes IPv6 utilisent ::FFFF:7F00:2 (listé) et ::FFFF:7F00:1 (non listé), et les listes de domaines utilisent les noms réservés TEST (listé) et INVALID (non listé).

dig +short 2.0.0.127.zen.spamhaus.org A
dig +short 1.0.0.127.zen.spamhaus.org A

Si la première requête renvoie un code d'inscription (une valeur 127.x autre que 127.255.255.x) et la seconde ne renvoie rien, les requêtes sur cette liste fonctionnent. Si la première renvoie 127.255.255.x, votre chemin de requête est refusé. La RFC indique que les clients devraient vérifier périodiquement les entrées de test et ne pas utiliser une liste dont les entrées de test sont incorrectes. Elle note aussi que des opérateurs qui fermaient une liste ont parfois supprimé toutes les entrées, ou installé un joker qui liste toutes les adresses. Si 127.0.0.1 ressort aussi comme listé, soupçonnez la liste ou votre chemin de requête, et non votre propre IP.

Une méthode pratique pour lire votre propre résultat

1. Choisissez la bonne IP ou le bon domaine. Utilisez l'IP indiquée dans le message de rejet, ou l'IP du serveur d'envoi relevée dans les lignes Received des en-têtes du message.
2. Vérifiez plusieurs listes à la fois. Notre vérificateur de listes noires interroge les principales listes en une seule passe.
3. Lisez chaque code avec sa zone. Un code d'inscription dans 127.0.0.0/8 (autre que 127.255.255.x) signifie listé ; vérifiez ce que signifie cette valeur sur cette liste. Une réponse 127.255.255.x, un SERVFAIL ou un délai dépassé signifie que l'état reste inconnu.
4. Consultez l'enregistrement TXT et la page de vérification de l'opérateur. De nombreuses listes renvoient un motif ou une URL. Considérez la page de vérification de l'opérateur comme le résultat qui fait foi.
5. Corrigez la cause, puis suivez la procédure de retrait de la liste. Chaque opérateur décide si et quand il retire une inscription. Si la cause persiste, l'inscription revient généralement.

Pour la démarche de dépannage complète lorsque des e-mails sont rejetés, voir e-mail bloqué par une liste noire. Si vous avez besoin d'aide pour interpréter les résultats ou trouver la cause, vous pouvez nous consulter au sujet du retrait.

Questions fréquentes

Pages officielles consultées

Les informations de cet article ont été vérifiées sur les pages officielles ci-dessous à la date de publication. Les politiques et le fonctionnement peuvent changer sans préavis : consultez les pages officielles avant de vous fier à une information importante.

• RFC 5782: DNS Blacklists and Whitelists
• RFC 1035: Domain Names - Implementation and Specification (RCODE)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus: ZEN Blocklist
• Spamhaus: Domain Blocklist (DBL)
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• UCEPROTECT: Using DNS Lookups

Guides associés

Tous les guides →