7. SOA RRs
Trois problèmes mineurs concernant l'enregistrement de ressource Start of Zone of Authority (SOA) nécessitent quelques clarifications.
7.1. Placement of SOA RRs in authoritative answers (Placement des SOA RR dans les réponses autoritativ)
RFC1034, dans la section 3.7, indique que la section d'autorité d'une réponse autoritative peut contenir l'enregistrement SOA pour la zone dont la réponse a été obtenue. Lorsqu'il discute de la mise en cache négative, RFC1034 section 4.3.4 fait référence à cette technique mais mentionne la section supplémentaire de la réponse. Le premier est correct, comme le suggère l'exemple montré dans la section 6.2.5 de RFC1034. Les enregistrements SOA, s'ils sont ajoutés, doivent être placés dans la section d'autorité.
7.2. TTLs on SOA RRs (TTL sur les SOA RR)
Il peut être observé que dans la section 3.2.1 de RFC1035, qui définit le format d'un enregistrement de ressource, la définition du champ TTL contient une phrase jetable qui stipule que le TTL d'un enregistrement SOA devrait toujours être envoyé comme zéro pour empêcher la mise en cache. Cela n'est mentionné nulle part ailleurs et n'a généralement pas été implémenté. Les implémentations ne devraient pas supposer que les enregistrements SOA auront un TTL de zéro, ni ne sont tenues d'envoyer des enregistrements SOA avec un TTL de zéro.
7.3. The SOA.MNAME field (Le champ SOA.MNAME)
Il est assez clair dans les spécifications, mais semble avoir été largement ignoré, que le champ MNAME de l'enregistrement SOA devrait contenir le nom du serveur primaire (master) pour la zone identifiée par le SOA. Il ne devrait pas contenir le nom de la zone elle-même. Cette information serait inutile, car pour la découvrir, il faut commencer par le nom de domaine de l'enregistrement SOA — c'est-à-dire le nom de la zone.