Invité: Dave Piscitello, Comité consultatif pour les questions de sécurité et de stabilité de l’Internet

Enregistrement Audio: [Français] (stream server)

Presentation: DNS Response Modification (Anglais) (PDF, 335K)

Video de la séance sur Adobe Connect: http://icann.na3.acrobat.com/p50348028/ : Activez ce lien pour visualiser la présentation. Pour suivre la présentation sur votre écran et entendre en meme temps les commentaires qui l’accompagnent, lancez le fichier sonore mp3 en même temps que vous faites démarrer la présentation.

Description: le but de cette présentation est de détailler les conséquences d’une modification de réponse à la requête du nom de domaine pour le détenteur du nom de domaine, les opérateurs de ce DNS et les utilisateurs de l’Internet ainsi que d’analyser l’abus possible, par des personnes malveillantes, de cette pratique. L’accent sera mis sur l’explication des conséquences et des répercussions inattendues pour les utilisateurs, les détenteurs de ces noms de domaine et ceux qui font confiance à ces messages réponse avisant de l’inexistence du domaine et envoient un rapport d’erreur d’erreur ou le prennent en compte dans la gestion administrative du nom de domaine.

Dans son 32e rapport préliminaire, le Comité de Securité et Stabilité de l’ICANN (SSAC pour Security and Stability Advisory Commitee) décrit la pratique en matiére de réponse à la requête d’ un nom de domaine indiquant une modification et donnée soit par des agents autorisés, soit par des parties tierces. Dans le premier cas, un agent autorisé reçoit une requête DNS pour un nom de domaine. L’agent autorisé établit que le nom de domaine demandé dans la requête n’existe pas dans le fichier racine qu’il héberge pour le régistrant mais plutôt que d’envoyer un message en retour de réponse DNS indiquant que le nom demandé est inexistant, l’agent autorisé envoit en retour une réponse indiquant que le nom existe et contenant une adresse IP dirigeant vers le nom de requête que l’agent choisit lui-même. Dans le second cas, un tiers opérant un ‘resolver’ itératif reçoit une réponse DomainNX générée par un serveur de nom de domaine autorisé et modifie subrepticement le contenu, en substituant le message signalant que le nom n’existe pas par un message qui indique que le nom existe et en insérant une adresse IP dirigeant vers le nom choisi par ce tiers. Ce phénomène est indifféremment appelé re-direction de sous-domaine, re-direction de DomaineNX, ré-écriture du domaine NX et exploitation commerciale des messages d’erreurs. Ces noms indiquent que cette pratique a des retombées commerciales et est sujette à controverse.

Host: Dave Piscitello, Security and Stability Advisory Committee

Audio: [English],[Español],[Français] (stream server)

Presentation: DNS Response Modification (PDF, 335K)

Video of the Adobe Connect Session: [http://icann.na3.acrobat.com/p50348028/] This is a recording of the visual part of the presentation. To follow the presentation in real time, please listen to the audio file simultaneously.

Description: The aim of this presentation is to describe the effects of DNS response modification on domain name registrants, DNS operators and Internet users, and to explore possible exploitation of the practice by bad actors. The focus will be on explaining the effects of and unintended consequences to users, domain registrants, and those who rely on non-existent domain responses for error reporting and administrative purposes.

In their preliminary report number 32, the SSAC describes the practise of DNS response modification by entrusted agents or third parties. In the first case, an entrusted agent receives a DNS query for a name. The entrusted agent determines that the name in the query does not exist in the zone file it hosts for the domain registrant but rather than returning a DNS response indicating a non-existent name, the entrusted agent returns a response indicating the name exists and containing an IP address mapping for the queried name of the agent's choosing. In the second case, a third party operating an iterative resolver receives NXDomain responses generated by an authoritative name server and silently alters the contents, changing the non-existent name response to one that signals name exists and inserting an IP address mapping for the queried name of the third party's choosing.

This behaviour is known by various labels: subdomain redirection, NXDomain redirection, NXDomain rewriting, NXDomain hijacking, subdomain hijacking, error resolution, and error marketing. These labels illustrate that the practice has commercial significance and is controversial."