Aller au contenu principal

1. Definitions (Définitions)

1. Definitions (Définitions)

Ce document donne intentionnellement plus de définition aux rôles des serveurs "Master", "Slave" et "Primary Master", ainsi qu'à leur énumération dans les NS RRs et au champ SOA MNAME. Dans ce sens, les définitions de types de serveurs suivantes peuvent être considérées comme un ajout à [RFC1035], et sont destinées à être cohérentes avec [RFC1996]:

Slave
Un serveur autoritatif qui utilise AXFR ou IXFR pour récupérer la zone et qui est nommé dans le NS RRset de la zone.

Master
Un serveur autoritatif configuré pour être la source de données AXFR ou IXFR pour un ou plusieurs serveurs esclaves.

Primary Master
Serveur maître à la racine du graphe de dépendance AXFR/IXFR. Le maître primaire est nommé dans le champ SOA MNAME de la zone et optionnellement par un NS RR. Par définition, il n'y a qu'un seul serveur maître primaire par zone.

Un nom de domaine identifie un nœud dans la structure arborescente de l'espace de noms de domaine. Chaque nœud a un ensemble (éventuellement vide) de Resource Records (RRs). Tous les RRs ayant les mêmes NAME, CLASS et TYPE sont appelés Resource Record Set (RRset).

Le pseudocode utilisé dans ce document est uniquement à des fins d'exemple. S'il est constaté qu'il ne correspond pas au texte, le texte doit être considéré comme faisant autorité. Si le texte est jugé ambigu, le pseudocode peut être utilisé pour aider à résoudre l'ambiguïté.

1.1 Comparison Rules (Règles de comparaison)

1.1.1. Deux RRs sont considérés comme égaux si leurs champs NAME, CLASS, TYPE, RDLENGTH et RDATA sont égaux. Notez que le champ time-to-live (TTL) est explicitement exclu de la comparaison.

1.1.2. Les règles de comparaison des chaînes de caractères dans les noms sont spécifiées dans [RFC1035 2.3.3].

1.1.3. Le wildcarding est désactivé. C'est-à-dire qu'un wildcard ("") dans une mise à jour ne correspond qu'à un wildcard ("") dans la zone, et vice versa.

1.1.4. L'aliasing est désactivé: Un CNAME dans la zone correspond à un CNAME dans la mise à jour, et ne sera pas suivi autrement. Toutes les opérations UPDATE sont effectuées sur la base de noms canoniques.

1.1.5. Les types de RR suivants ne peuvent pas être ajoutés à un RRset. Si les règles de comparaison suivantes sont respectées, une tentative d'ajout du nouveau RR entraînera le remplacement du RR précédent:

SOA
Comparer uniquement NAME, CLASS et TYPE -- il n'est pas possible d'avoir plus d'un SOA par zone, même si l'un des champs de données diffère.

WKS
Comparer uniquement NAME, CLASS, TYPE, ADDRESS et PROTOCOL -- un seul WKS RR est possible pour ce tuple, même si les masques de services diffèrent.

CNAME
Comparer uniquement NAME, CLASS et TYPE -- il n'est pas possible d'avoir plus d'un CNAME RR, même si leurs champs de données diffèrent.

1.2 Glue RRs (RRs de colle)

Dans le but de déterminer si un nom de domaine utilisé dans le protocole UPDATE est contenu dans une zone spécifiée, un nom de domaine est "dans" une zone s'il est possédé par le nom de domaine de cette zone. Voir la section 7.18 pour plus de détails.

1.3 New Assigned Numbers (Nouveaux numéros attribués)

  • CLASS = NONE (254)
  • RCODE = YXDOMAIN (6)
  • RCODE = YXRRSET (7)
  • RCODE = NXRRSET (8)
  • RCODE = NOTAUTH (9)
  • RCODE = NOTZONE (10)
  • Opcode = UPDATE (5)