Aller au contenu principal

5. Enregistrement de ressources NSEC

L'enregistrement de ressources (RR) NSEC (Next SECure, suivant sécurisé) est utilisé pour prouver l'absence d'un nom de propriétaire (owner name) ou d'un type d'enregistrement de ressources donné dans une zone signée. Le NSEC RR y parvient en énumérant le nom de propriétaire suivant, dans l'ordre canonique de la zone.

Le format du RDATA de l'enregistrement NSEC est le suivant :

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                      Next Domain Name                         /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                       Type Bit Maps                           /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le RDATA de l'enregistrement NSEC est représenté et encodé comme suit :

  • le nom de domaine suivant (NEXT DOMAIN NAME) est le nom de propriétaire suivant, dans l'ordre canonique de la zone (ce nom DOIT être différent du nom du propriétaire de ce NSEC RR), représenté sous forme de nom de domaine canonique (wire format) ;
  • la carte de bits de type (TYPE BIT MAPS) identifie l'ensemble des types d'enregistrements de ressources associés au nom du propriétaire du NSEC RR. La carte de bits de type est encodée sous forme de bitmap compact, dont le format est décrit à la section 5.1.

5.1. Champ carte de bits de type du RDATA NSEC​

La carte de bits de type est encodée sous la forme d'une séquence d'un ou plusieurs blocs de fenêtre (window block). La structure de chaque bloc de fenêtre est la suivante :

    +--------+--------+--------+--------+--------+--------+
    |  Window|  Bitmap Length |        Bitmap            |
    +--------+--------+--------+--------+--------+--------+

où :

  • Window est un entier non signé de 8 bits identifiant les 8 bits de poids fort du code de type (c'est-à-dire le quotient du code de type divisé par 256) ;
  • Bitmap Length est un entier non signé de 8 bits identifiant la longueur (en octets) du bitmap dans ce bloc de fenêtre, comprise entre 1 et 32 ;
  • Bitmap est un bitmap de Bitmap Length octets couvrant les codes de type au sein de cette fenêtre. Chaque bit du bitmap correspond à un code de type ; le bit 0 (bit de poids fort) correspond au code de type Window × 256 et le bit 7 (bit de poids faible) correspond au code de type Window × 256 + 7.

La carte de bits de type DOIT contenir le bit correspondant à chaque type RR associé au nom du propriétaire du NSEC RR. Si le nom du propriétaire est associé à plusieurs types RR, ces types doivent tous être représentés dans la carte de bits de type.

La carte de bits de type DOIT être disposée dans l'ordre croissant du champ Window, et NE DOIT PAS contenir de blocs de fenêtre se chevauchant ou dépassant 32 octets de longueur.

Le validateur du NSEC RR utilise la carte de bits de type pour vérifier :

  • l'existence d'un type RR donné pour le nom du propriétaire du NSEC RR (preuve d'existence de type) ;
  • l'absence d'autres noms dans l'intervalle d'ordre canonique entre le nom du propriétaire du NSEC RR et le nom de domaine suivant (preuve d'absence de nom).

5.2. Champ nom de domaine suivant du RDATA NSEC​

Le champ NEXT DOMAIN NAME DOIT contenir le nom de propriétaire situé immédiatement après le nom du propriétaire du NSEC RR dans l'ordre canonique (canonical order) de la zone. Le champ NEXT DOMAIN NAME du dernier NSEC RR de la zone DOIT contenir le nom du propriétaire du premier NSEC RR de la zone (c'est-à-dire un retour au début de la zone).

Cela sert à prouver, lorsqu'un validateur demande un nom inexistant, que ce nom n'est pas dans la zone : le validateur trouve un NSEC RR dont le nom du propriétaire est, dans l'ordre canonique, avant le nom demandé, et dont le NEXT DOMAIN NAME est, dans l'ordre canonique, après le nom demandé.

5.3. Format de présentation NSEC​

Le format de présentation (presentation format) du NSEC RR est le suivant :

  • le nom de domaine suivant est représenté sous forme textuelle de nom de domaine en forme canonique (c'est-à-dire sans compression) ;
  • la carte de bits de type est représentée par une liste de types d'enregistrements de ressources séparés par des espaces (par exemple RRSIG NSEC SOA NS A). Les types inconnus utilisent la notation RFC 3597.

Exemple :

    example.com. 3600 IN NSEC www.example.com. A RRSIG NSEC

5.4. Considérations particulières pour le NSEC RR​

Le NSEC RR révèle l'existence des noms dans la zone, ce qui peut soulever des préoccupations liées à la confidentialité. Le NSEC RR DOIT être généré par le signataire responsable de la zone, et DOIT être signé à l'aide d'une clé cohérente avec le DNSKEY de la zone.

Le validateur DOIT, lorsqu'il prouve l'absence d'un nom ou d'un type, vérifier que l'intervalle d'ordre canonique indiqué par le NSEC RR ne contient effectivement pas le nom ou le type dont l'absence est prouvée.

Navigation entre sections :