Politique de tests de ZoneCheck pour l'AFNIC

Cette politique de tests est celle actuellement utilisée pour valider l'enregistrement des noms de domaine en .fr et .re.

Tests de la classe "generic"
Tests de la classe "nameserver"
Tests de la classe "address"
Tests de la classe "extra"

Tests de la classe "generic"

Test "dn_sntx" (MANDATORY)

Nom de domaine contenant des caractères illégaux

IETF RFC 1034 (p.11) : Labels are only composed by letters ([A-Za-z]), digits ([0-9]) or dashes ('-') (not starting or ending with), and should be less than 63 characters; domain name (labels separated by '.') should be less than 255 characters. See also [ref]: IETF RFC 1912 (2.1 Inconsistent, Missing, or Bad Data).

Test "dn_orp_hyph" (MANDATORY)

Tiret ('-') au début ou à la fin du nom de domaine

IETF RFC 1034 (p.11) : Labels are only composed by letters ([A-Za-z]), digits ([0-9]) or dashes ('-') (not starting or ending with), and should be less than 63 characters; domain name (labels separated by '.') should be less than 255 characters. See also [ref]: IETF RFC 1912 (2.1 Inconsistent, Missing, or Bad Data).

Test "dn_dbl_hyph" (OPTIONAL)

Double tiret ('--') dans le nom de domaine

IETF IDN project (internationalized domain names). The double dash ('--') will have a special meaning for the domain name encoding, so it is strongly advised not to used it. See http://www.iana.org/cctld/specifications-policies-cctlds-01apr02.htm (4. Tagged Domain Names.)

Test "one_ns" (MANDATORY)

Présence de serveurs de nom gérant le domaine

ZoneCheck : To avoid loosing all connectivity with the autoritative DNS in case of network outage it is advised to host the DNS on different networks. IETF RFC 2182 (Abstract): The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.

Test "several_ns" (MANDATORY)

Présence d'au moins deux serveurs de noms pour le domaine

ZoneCheck : To avoid loosing all connectivity with the autoritative DNS in case of network outage it is advised to host the DNS on different networks. IETF RFC 2182 (Abstract): The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.

Test "ip_distinct" (MANDATORY)

Adresses IP identiques parmi les serveurs

ZoneCheck : To avoid loosing all connectivity with the autoritative DNS in case of network outage it is advised to host the DNS on different networks. IETF RFC 2182 (Abstract): The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.

Test "ip_all_same_net" (OPTIONAL)

Serveurs de noms tous sur le même sous-réseau

ZoneCheck : To avoid loosing all connectivity with the autoritative DNS in case of network outage it is advised to host the DNS on different networks. IETF RFC 2182 (Abstract): The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.

Tests de la classe "nameserver"

Test "ip_private" (OPTIONAL)

Adresse dans un réseau privé

IETF RFC 1918 (3. Private Address Space). The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10/8, 172.16/12, 192.168/16.

Test "ip_bogon" (OPTIONAL)

Adresse faisant partie de la liste des 'bogon'

http://www.cymru.com/Bogons/. A bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks.

Tests de la classe "address"

Test "icmp" (OPTIONAL)

Réponses aux requêtes icmp

Test "udp" (MANDATORY)

Connectivité udp

IETF RFC 1035 (p.32 4.2. Transport): The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance.

Test "tcp" (MANDATORY)

Connectivité tcp

IETF RFC 1035 (p.32 4.2. Transport): The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance.

Test "aaaa" (MANDATORY)

Comportement lors de demande d'un enregistrement aaaa

Test "soa" (MANDATORY)

Présence d'un enregistrement SOA

Test "soa_auth" (MANDATORY)

Réponse faisant autorité pour le SOA

Test "given_nsprim_vs_soa" (MANDATORY)

Serveur de nom donné comme primaire est primaire

Test "soa_master_fq" (OPTIONAL)

Nom de serveur pleinement qualifié dans le 'master' du SOA

Test "soa_master_sntx" (MANDATORY)

Caractères illégaux dans le 'master' du SOA

IETF RFC 1034 (p.11): Labels are only composed by letters ([A-Za-z]), digits ([0-9]) or dashes ('-') (not starting or ending with), and should be less than 63 characters; domain name (labels separated by '.') should be less than 255 characters. See also [ref]: IETF RFC 1912 (2.1 Inconsistent, Missing, or Bad Data).

Test "soa_contact_sntx_at" (MANDATORY)

Mauvaise utilisation du caractère '@' dans le 'contact' du SOA

IETF RFC 1034 (p.9), RFC 1912 (p.3) : Email addresses are converted by using the following rule: local-part@mail-domain ==> local-part.mail-domain if local-part contains a dot in should be backslashed (for 'bind').

Test "soa_contact_sntx" (MANDATORY)

Caractères illégaux dans le contact du SOA

IETF RFC 1034 (p.9), RFC 1912 (p.3) : Email addresses are converted by using the following rule: local-part@mail-domain ==> local-part.mail-domain if local-part contains a dot in should be backslashed (for 'bind').

Test "soa_serial_fmt_YYYYMMDDnn" (OPTIONAL)

Numéro de série de la forme aaaammjjnn

RFC 1912 (p.3). The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number).

Test "soa_expire" (MANDATORY)

Champ 'expire' du SOA entre 604800 s et 60480000 s

Politique du registre AFNIC : Le registre demande que les champs du SOA soient à l'interieur d'un interval défini : le champ 'expire' doit être entre 604800 s et 60480000 s , le champ 'minimum' entre 180 s et 604800 s , le champ 'refresh' entre 3600 s et 172800 s , et enfin le champ 'retry' entre 900 s et 86400 s .

Test "soa_minimum" (OPTIONAL)

Champ 'minimum' du SOA entre 180 s et 604800 s

Politique du registre AFNIC : Le registre demande que les champs du SOA soient à l'interieur d'un interval défini : le champ 'expire' doit être entre 604800 s et 60480000 s , le champ 'minimum' entre 180 s et 604800 s , le champ 'refresh' entre 3600 s et 172800 s , et enfin le champ 'retry' entre 900 s et 86400 s .

Test "soa_refresh" (OPTIONAL)

Champ 'refresh' du SOA entre 3600 s et 172800 s

Politique du registre AFNIC : Le registre demande que les champs du SOA soient à l'interieur d'un interval défini : le champ 'expire' doit être entre 604800 s et 60480000 s , le champ 'minimum' entre 180 s et 604800 s , le champ 'refresh' entre 3600 s et 172800 s , et enfin le champ 'retry' entre 900 s et 86400 s .

Test "soa_retry" (OPTIONAL)

Champ 'retry' du SOA entre 900 s et 86400 s

Politique du registre AFNIC : Le registre demande que les champs du SOA soient à l'interieur d'un interval défini : le champ 'expire' doit être entre 604800 s et 60480000 s , le champ 'minimum' entre 180 s et 604800 s , le champ 'refresh' entre 3600 s et 172800 s , et enfin le champ 'retry' entre 900 s et 86400 s .

Test "soa_retry_refresh" (MANDATORY)

Champ "retry' du SOA inférieur à celui du 'refresh'

IETF RFC 1912 (p.4). The 'retry' value is typically a fraction of the 'refresh' interval.

Test "soa_expire_7refresh" (MANDATORY)

Champ 'expire' est au moins 7 fois celui du 'refresh'

Test "soa_ns_cname" (OPTIONAL)

Champ 'master' du SOA n'est pas un alias

IETF RFC 1912 (p.7) : Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.

Test "soa_vs_any" (MANDATORY)

Cohérence entre enregistrements SOA et any

Test "soa_coherence_serial" (MANDATORY)

Cohérence du numéro de série avec celui du serveur primaire

Test "soa_coherence_contact" (MANDATORY)

Cohérence du contact administratif avec celui du serveur primaire

Test "soa_coherence_master" (MANDATORY)

Cohérence du champ 'master' du SOA avec celui du serveur primaire

Test "soa_coherence" (MANDATORY)

Cohérence du SOA avec celui du serveur primaire

Test "ns" (MANDATORY)

Présence d"un enregistrement ns

Test "ns_auth" (MANDATORY)

Réponse autoritaire pour le ns

Test "given_ns_vs_ns" (MANDATORY)

Cohérence avec la liste des serveurs de noms donnée

Test "ns_sntx" (MANDATORY)

La syntaxe du ns réprésente un nom/domaine valide

IETF RFC 1034 (p.11): Labels are only composed by letters ([A-Za-z]), digits ([0-9]) or dashes ('-') (not starting or ending with), and should be less than 63 characters; domain name (labels separated by '.') should be less than 255 characters. See also [ref]: IETF RFC 1912 (2.1 Inconsistent, Missing, or Bad Data).

Test "ns_cname" (MANDATORY)

L'enregistrement ns n'est pas un alias

IETF RFC 1912 (p.7): Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.

Test "ns_vs_any" (MANDATORY)

Cohérence entre enregistrements ns et any

Test "ns_ip" (MANDATORY)

Enregistrement ns peut être résolu

Test "ns_reverse" (OPTIONAL)

Existance du nom correspondant à l'adresse IP du serveur

Test "ns_matching_reverse" (OPTIONAL)

Vérification du nom correspondant à l'adresse IP du serveur

(Only if "mail_by_mx_or_a" = "MX") Test "mx" (MANDATORY)

Enregistrement mx présent

IETF RFC 1912 (p.7). Put MX records even on hosts that aren't intended to send or receive e-mail. If there is a security problem involving one of these hosts, some people will mistakenly send mail to postmaster or root at the site without checking first to see if it is a "real" host or just a terminal or personal computer that's not set up to accept e-mail.

(Only if "mail_by_mx_or_a" = "MX") Test "mx_auth" (MANDATORY)

Réponse autoritaire pour le mx

(Only if "mail_by_mx_or_a" = "MX") Test "mx_sntx" (MANDATORY)

Syntaxe du mx représente un nom de machine valide

IETF RFC 1034 (p.11): Labels are only composed by letters ([A-Za-z]), digits ([0-9]) or dashes ('-') (not starting or ending with), and should be less than 63 characters; domain name (labels separated by '.') should be less than 255 characters. See also [ref]: IETF RFC 1912 (2.1 Inconsistent, Missing, or Bad Data).

(Only if "mail_by_mx_or_a" = "MX") Test "mx_cname" (MANDATORY)

L'enregistrement mx n'est pas un alias

IETF RFC 974. MX records shall not point to an alias defined by a CNAME.

(Only if "mail_by_mx_or_a" = "MX") Test "mx_no_wildcard" (UNKNOWN SEVERITY "i")

Absence de joker pour l'enregistrement mx

(Only if "mail_by_mx_or_a" = "MX") Test "mx_ip" (MANDATORY)

Enregistrement mx peut être résolu

(Only if "mail_by_mx_or_a" = "MX") Test "mx_vs_any" (MANDATORY)

Cohérence entre enregistrements mx et any

Test "correct_recursive_flag" (MANDATORY)

Serveur de nom réellement récursif

Test "not_recursive" (OPTIONAL)

Serveur de nom n'autorisant pas la récursion

ZoneCheck. Si vous configurez le serveur de noms pour répondre aux requêtes récursives, cela implique que vous acceptez que n'importe qui l'utilise pour résoudre n'importe quel type de requêtes. Cela permet notamment l'utilisation de votre serveur pour amplifier des attaques par déni de service et c'est donc très déconseillé. Voir http://www.afnic.fr/actu/nouvelles/general/NN20060404.

(Only if "recursive_server" = "true") Test "loopback_delegation" (OPTIONAL)

Délégation du 'loopback'

IETF RFC 1912 (p.13 4.1. Boot file setup): These are set up to either provide nameservice for "special" addresses, or to help eliminate accidental queries for broadcast or local address to be sent off to the root nameservers. All of these files will contain NS and SOA records just like the other zone files you maintain.

(Only if "recursive_server" = "true") Test "loopback_host" (MANDATORY)

'loopback' resolvable

IETF RFC 1912 (p.13 4.1. Boot file setup): These are set up to either provide nameservice for "special" addresses, or to help eliminate accidental queries for broadcast or local address to be sent off to the root nameservers. All of these files will contain NS and SOA records just like the other zone files you maintain.

(Only if "recursive_server" = "true") Test "root_servers" (MANDATORY)

Existence de la liste des root servers

(Only if "recursive_server" = "true") Test "root_servers_ns_vs_icann" (MANDATORY)

Liste des root servers identique à celle de l'ICANN

IETF RFC 2870 (p.1): The Internet Corporation for Assigned Names and Numbers (ICANN) has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards.

(Only if "recursive_server" = "true") Test "root_servers_ip_vs_icann" (OPTIONAL)

Adresses IP des "root servers" identiques à celles de l'ICANN

IETF RFC 2870 (p.1): The Internet Corporation for Assigned Names and Numbers (ICANN) has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards.

Tests de la classe "extra"

Test "mail_mx_or_addr" (OPTIONAL)

Domaine capable de recevoir du courrier (mx, a, aaaa)

(Only if "mail_delivery" != "nodelivery") Test "mail_delivery_postmaster" (OPTIONAL)

Envoie d'un e-mail au "postmaster"

IETF RFC 1123 (p.51 5.2.7 RCPT Command: RFC 821 Section 4.1.1). A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster".

Test "mail_hostmaster_mx_cname" (MANDATORY)

L'enregistrement mx du "hostmaster" n'est pas un alias

IETF RFC 974. MX records shall not point to an alias defined by a CNAME.

Test "mail_delivery_hostmaster" (MANDATORY)

Envoie d'un e-mail au "hostmaster"