"""
Pourquoi le résolveur est-il si prudent, et pose-t-il au serveur faisant autorité une question dont il aurait déjà dû connaitre la réponse ? Il y a plusieurs raisons mais la principale est que le RFC originel sur le DNS, le RFC 1034, est ambigu. Il ne décrivait pas de manière parfaitement claire ce qu'il faut faire lorsqu'un nom de domaine est un ENT, un Empty Non-Terminal, c'est-à-dire un nom de domaine qui n'a pas d'enregistrements mais qui a des sous-domaines. Certains ont pensé que cela autorisait à répondre NXDOMAIN lorsque le nom demandé est un ENT.
"""

""""
Un petit mot de sécurité, maintenant qu'on approche de la fin. Si un résolveur accepte un NXDOMAIN mensonger (attaque par empoisonnement), les conséquences risquent d'être sérieuses puisque c'est un sous-arbre entier qui serait « détruit ». C'est pour cela que le RFC autorise un résolveur prudent à ne pratiquer le NXDOMAIN cut que si le NXDOMAIN a été validé avec DNSSEC. C'est ce que fait Unbound, cité plus haut.
"""

RFC proposant des options de DHCP ou des router advertisement, visant à informer les client qu'ils sont derrière un portail captif, et sur quelle URI ils doivent se rendre pour se connecter.

"Il n'existe pas encore de mise en œuvre côté clients DHCP ou RA."
Tout est dit :-D

Deux petits RFC BGP résumés par le Bortzmeyer national: le premier qui clarifie le fait que l'utilisation de l'AS 0 est pas acceptable et que si un pair l'utilise on doit mettre fin à la session avec message d'erreur 2.
Le second (https://www.bortzmeyer.org/7606.html) qui indique comment un routeur doit se comporter lorsqu'il reçoit un update de routes invalide, au lieu de fermer la session comment préconisé jusque maintenant.
Dans la plupart des cas, il faut jusque traiter cela comme un retrait des routes en question.

Ce que j'aime, c'est que "Un avantage du long délai avant la sortie de ce RFC, est que ce nouveau comportement a déjà été mis en œuvre dans la plupart des routeurs (Alcatel-Lucent SR OS, Cisco IOS, Cisco IOS XR, Juniper JUNOS, Quagga)."