ES2971623T3 - Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación - Google Patents

Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación Download PDF

Info

Publication number
ES2971623T3
ES2971623T3 ES19202773T ES19202773T ES2971623T3 ES 2971623 T3 ES2971623 T3 ES 2971623T3 ES 19202773 T ES19202773 T ES 19202773T ES 19202773 T ES19202773 T ES 19202773T ES 2971623 T3 ES2971623 T3 ES 2971623T3
Authority
ES
Spain
Prior art keywords
validation
resource
agent
group
agents
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19202773T
Other languages
English (en)
Inventor
Haya Shulman
Michael Waidner
Markus Brandt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Application granted granted Critical
Publication of ES2971623T3 publication Critical patent/ES2971623T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método para validar la propiedad de un recurso (208), concretamente un nombre de dominio, dentro de una red, que comprende seleccionar (102) un grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) de manera que las rutas de red (212a) , 212b, 212c) entre un agente de validación del grupo (214) y entidades de un grupo de una o más entidades asociadas al recurso (208) no se cruzan. El método comprende además transmitir (104) una propiedad del recurso (208) a validar y un indicador de dirección para el recurso (208) desde un agente coordinador (210) al grupo (214) de agentes de validación (204a, 204b, 204d). Además, el método comprende consultar (106) la propiedad del recurso (208) de las entidades utilizando los agentes de validación (204a, 204b, 204d) del grupo (214) para determinar las propiedades consultadas; y evaluar (108) las propiedades consultadas para validar la propiedad del recurso (208). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación
Campo
Los ejemplos se refieren a métodos para validar la propiedad de un recurso dentro de una red, así como a agentes de validación y un agente coordinador para llevar a cabo el método.
Antecedentes
A menudo existe la necesidad de evaluar la propiedad de un recurso dentro de una red. Por ejemplo, las Autoridades de Certificación (CA) a menudo requieren evaluar si un usuario que solicita un certificado (por ejemplo, al enviar una Solicitud de Firma de Certificado, CSR) es el legítimo propietario del dominio para el cual se emitirá el certificado. Esta evaluación se realiza a menudo mediante la Validación de Dominio (DV), que asume que solo el propietario legítimo del dominio es capaz de crear registros específicos dentro de los Servicios de Nombre de Dominio (DNS) del dominio o solo el propietario legítimo tiene la capacidad de crear archivos dentro del sistema de archivos o directorio accesible a través del dominio. Si bien pueden existir diferentes métodos de DV, como, por ejemplo, DV basado en correo electrónico, DV basado en WHOIS, DV basado en DNS o DV basado en HTTP/S, todos ellos dependen del DNS para validar el dominio. En la medida en que DNS es vulnerable a ataques maliciosos, también DV es vulnerable y puede existir la posibilidad de oscurecer la validación de dominio de manera que los atacantes, que no sean los propietarios legítimos del dominio, puedan recibir un certificado para el dominio. Por ejemplo, las respuestas de los Servidores de Nombres de Dominio del dominio pueden ser atacadas para que los resolutores DNS de la CA reciban una dirección IP incorrecta y así realizar la validación utilizando una dirección IP bajo el control de un atacante en lugar de utilizar una dirección IP del legítimo propietario del dominio. De manera similar, un ataque de Hombre en el Medio, donde un atacante controla un nodo en la ruta de red entre la CA y las entidades del Dominio (o incluso toda la red en la que se aloja la CA o el Dominio), puede resultar en una validación comprometida del dominio o recurso.
Los autores Henry Birge-Lee y otros de: "Bambooziing Certificate Authorities with BGP", Actas del 27° Simposio de Seguridad USENIX, 17 de agosto de 2018 (17-08-2018), páginas 833-849, proponen realizar la validación de dominio utilizando múltiples puntos de vista.
Asimismo, el autor de "Validating challenges from multiple network vantage Points", Comunidad de Soporte Let's Encrypt, 25 de agosto de 2017 (25-08-2017), páginas 1-1, publicado en Internet: URL: https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955 propone realizar la validación de dominio utilizando múltiples puntos de vista de red.
Por lo tanto, puede haber una demanda para aumentar la seguridad de los métodos para validar la propiedad de un recurso dentro de una red. Dicho objeto se logra mediante los métodos y aparatos de las reivindicaciones independientes.
Resumen
La presente invención se caracteriza por el objeto de las reivindicaciones independientes. Las modalidades preferidas están definidas por las reivindicaciones dependientes.
Breve descripción de las Figuras
Se describirán algunos ejemplos de aparatos y/o métodos a continuación, únicamente a modo de ejemplo, y con referencia a las figuras adjuntas, en las cuales
La Figura 1 muestra un diagrama de flujo de un método de la invención para validar la propiedad de un recurso en una red;
La Figura 2 ilustra un ejemplo de una red que comprende múltiples redes de operadores y agentes de validación; La Figura 3 ilustra un ejemplo del sistema para validar la propiedad de un recurso dentro de una red, el sistema que comprende un agente coordinador y al menos dos agentes de validación; y
La Figura 4 muestra otro ejemplo de un método para validar la propiedad de un recurso dentro de la red.
Descripción Detallada
Ahora se describirán más detalladamente varios ejemplos con referencia a las figuras adjuntas en las cuales se ilustran algunos ejemplos. En las figuras, los espesores de las líneas, capas y/o regiones pueden estar exagerados para mayor claridad.
Por lo tanto, si bien existen ejemplos adicionales que pueden sufrir diversas modificaciones y adoptar formas alternativas, algunos ejemplos particulares se muestran en las figuras y posteriormente se describirán en detalle. Sin embargo, esta descripción detallada no limita otros ejemplos a las formas particulares descritas. Otros ejemplos pueden abarcar todas las modificaciones, equivalentes y alternativas que se encuentren dentro del alcance de la descripción. Los mismos o números similares se refieren a elementos similares o iguales en toda la descripción de las figuras, los cuales pueden ser implementados de manera idéntica o en forma modificada al compararse entre sí, al mismo tiempo que proporcionan la misma o una funcionalidad similar.
Se entenderá que cuando se hace referencia a un elemento como "conectado" o "acoplado" a otro elemento, los elementos pueden estar conectados o acoplados directamente o a través de uno o más elementos intermedios. Si dos elementos A y B se combinan utilizando un "o", esto se entenderá como que describe todas las posibles combinaciones, es decir, solo A, solo B, así como A y B, a menos que se defina explícita o implícitamente lo contrario. Una formulación alternativa para las mismas combinaciones es "al menos uno de A y B" o "A y/o B". Lo mismo se aplica, mutatis mutandis, para combinaciones de más de dos elementos.
La terminología utilizada en el presente documento con el fin de describir ejemplos particulares no pretende limitar futuros ejemplos. Cuando se utiliza una forma singular como "un", "una" y "el/la" y no se define explícita o implícitamente que el uso de un solo elemento sea obligatorio, se pueden utilizar ejemplos adicionales con elementos en plural para implementar la misma funcionalidad. Asimismo, cuando se describe posteriormente una funcionalidad como implementada utilizando múltiples elementos, otros ejemplos pueden implementar la misma funcionalidad utilizando un solo elemento o entidad de procesamiento. Se entenderá además que los términos "comprende", "que comprende", "incluye" y/o "que incluye", cuando se utilizan, especifican la presencia de las características, enteros, pasos, operaciones, procesos, actos, elementos y/o componentes indicados, pero no excluyen la presencia o adición de una o más características, enteros, pasos, operaciones, procesos, actos, elementos, componentes y/o cualquier grupo de los mismos.
A menos que se defina lo contrario, todos los términos (incluyendo términos técnicos y científicos) se utilizan en la presente descripción en su significado ordinario en el campo al que pertenecen los ejemplos.
Los ejemplos siguientes describirán principalmente la validación de la propiedad de un dominio en Internet como un ejemplo particular de un recurso dentro de una red. Sin embargo, otras implementaciones adicionales también pueden servir para validar la propiedad de otros recursos dentro de una red, como por ejemplo dentro de Internet. La Internet es solo un ejemplo de una red que comprende recursos individuales, como nodos de red individuales, que pueden ser accedidos por diferentes protocolos de comunicación de datos, como por ejemplo el Protocolo de Internet. El enrutamiento dentro de Internet puede realizarse en función de la dirección de Protocolo de Internet de un recurso individual. Como alias de la dirección del protocolo de Internet, se pueden utilizar nombres, que generalmente se traducen en direcciones IP (resueltas) mediante servicios de nombres accesibles dentro de la red. Una red puede, al igual que Internet, dividirse en múltiples redes de operadores diferentes que son operadas por entidades legales distintas. Las redes de operadores tienen interfaces entre sí. Las rutas de red pueden conectar una red de operador con una o más redes de operadores adicionales. Una red de operadores puede ser, por ejemplo, una red que comprende un bloque de direcciones IP asignadas a una entidad legal (o gobiernos u entidades similares) que tiene el derecho de utilizar el bloque de direcciones IP y establecer una red física utilizando las direcciones IP. En otras palabras, Internet global puede estar constituido por múltiples redes de operadores diferentes que se interconectan con otras redes de operadores para permitir establecer rutas de red desde un dispositivo en la red de un primer operador hasta otro dispositivo en la red de un segundo operador.
La Figura 1 muestra un diagrama de flujo de un método de la invención para validar la propiedad de un recurso en una red. Dado que el método opera dentro de una red de entidades distribuidas, se describe el ejemplo del método ilustrado en la figura 1 junto con la figura 2, que ilustra un ejemplo para una red.
El método comprende seleccionar 102 un grupo de al menos dos agentes de validación de manera que las rutas de red entre un agente de validación del grupo y las entidades de un grupo de una o más entidades asociadas al recurso no se intersequen. Como se muestra en la figura 2, la red 200 puede comprender múltiples redes de operadores diferentes 202a a 202m. Varios agentes de validación pueden distribuirse arbitrariamente entre las redes de operadores. En el ejemplo particular ilustrado en la figura 2, se asume que los agentes disponibles 204a a 204e están presentes dentro de las redes de operadores 202a a 202e, respectivamente. Un agente disponible puede ser implementado como un componente de software que se ejecuta en un ordenador o en una entidad de procesamiento dentro de una red de operadores. Asimismo, un agente disponible también puede ser implementado como una entidad de hardware diseñada para realizar las funciones de un agente de validación como se describe a continuación. Un agente de validación es un agente disponible que ha sido seleccionado utilizando el criterio de la invención de que las rutas de red entre un agente de validación del grupo de agentes de validación y las entidades de un grupo de una o más entidades asociadas al recurso no se intersecan. El agente de validación tiene la capacidad de establecer una ruta de red hacia una entidad para ser consultada acerca de una propiedad de un recurso dentro de la red y de consultar la propiedad una vez que se haya establecido la ruta de red. La Figura 2 ilustra una aplicación en la que se debe validar la propiedad de un dominio, por ejemplo, consultando un registro CNAME de los servidores de nombres dentro del dominio. En el ejemplo de la figura 2, una autoridad de certificación (CA) 206 con el dominio CA.com debe verificar la propiedad del dominio víctima de un cliente 208. Con este fin, los agentes de validación seleccionados deben consultar los servidores de nombres dentro del dominio víctima para obtener el registro CNAME.
Dentro de la red del CA, se utiliza un agente coordinador 210 para coordinar el uso del grupo 214 de agentes de validación 204a, 204b y 204c seleccionados del grupo de agentes disponibles 204a a 204e, de manera que las rutas de red entre un agente de validación 204a, 204b y 204c del grupo 214 y las entidades de un grupo de una o más entidades asociadas al recurso no se intersequen. Suponiendo, por razones de simplificación, que hay un único servidor de nombres de dominio presente dentro del dominio 200a, las rutas de red 212a, 212b y 212c cumplen con este criterio, lo que lleva a la selección de los agentes de validación 204a, 204b y 204c del grupo 214.
Para permitir que los agentes de validación 204a, 204b y 204c del grupo 214 consulten la propiedad del recurso y establezcan rutas de red hacia entidades asociadas con el recurso, el método de la figura 1 además comprende transmitir 104 una propiedad del recurso a validar y un indicador de dirección para el recurso desde un agente coordinador al grupo de agentes de validación.
El método además comprende consultar 106 la propiedad del recurso 208 desde al menos una entidad utilizando los agentes de validación 204a, 204b y 204c del grupo 214 para determinar las propiedades consultadas.
Además, el método comprende evaluar 108 las propiedades consultadas para validar la propiedad del recurso. Seleccionar los agentes de validación de manera que las rutas de red entre los agentes de validación del grupo y las entidades desde las cuales se consulta la propiedad del recurso no se intersequen puede asegurar que incluso si un salto o nodo a lo largo de una sola ruta de red es comprometido, los agentes de validación restantes recibirán resultados válidos de sus consultas. Por ejemplo, la figura 2 asume que la red del operador 202k está bajo el control de un atacante malicioso que puede corromper la consulta, por ejemplo, dirigiendo la consulta a otra red que no sea la del legítimo propietario del dominio 208. Mientras que la ruta de red 212a está comprometida, las rutas de red 212b y 212c no están comprometidas, de manera que los agentes de validación 204b y 204d reciben resultados no corrompidos de la consulta, lo que lleva a una validación confiable de la propiedad para el dominio 208.
Si bien se puede requerir un número mínimo de al menos dos agentes de validación para ser sensibles a un atacante malicioso, el número de agentes de validación dentro del grupo puede ser elegido arbitrariamente y, por ejemplo, coordinado por el agente coordinador 210. Dependiendo de la topología de la red, ya puede ser suficiente un número de tres agentes de validación adecuadamente seleccionados para alcanzar una fiabilidad de validación superior al 90 %. Otras implementaciones, sin embargo, también pueden utilizar números más altos, como por ejemplo cuatro, cinco, seis, siete u ocho agentes de validación.
Según ejemplos adicionales del método, el grupo de agentes de validación se selecciona además de manera que al menos dos agentes de validación se localicen en diferentes redes de operadores. Un ejemplo de dicha implementación ya se ilustra en la figura 2. Una selección de los agentes de validación de esta manera puede asegurar que incluso un atacante a gran escala que pueda tener control sobre redes de operadores completas que alojen un agente de validación elegido (por ejemplo, la red de operadores 202e de la figura 2) no pueda oscurecer las consultas de todos los agentes de validación.
Según algunos ejemplos, se confirma la propiedad del recurso si una fracción predefinida de las propiedades consultadas corresponden o son iguales a una propiedad esperada. Si, por ejemplo, en el entorno de la figura 2, dos de cada tres agentes de validación obtienen la entrada CNAME que se espera que se cree en el servicio de nombres de dominio para el dominio 208 por su legítimo propietario, se puede concluir que la validación se ha realizado con éxito. Una evaluación previa de la topología de la red puede servir para asegurar que la probabilidad de que un único atacante pueda controlar saltos o redes de operadores a lo largo de más de una ruta sea insignificante. Si, por ejemplo, el propietario de un dominio crea la entrada CNAME "success" (que es la propiedad esperada) y dos de cada tres consultas CNAME resultan en la entrada "success", se puede asumir una validación exitosa.
Como ya se ha explicado anteriormente, según algunos ejemplos, la selección del grupo de al menos dos agentes de validación comprende transmitir un indicador de dirección para el recurso 208 desde el agente coordinador 210 a un grupo de agentes disponibles 204a a 204e y utilizar el indicador de dirección para determinar un grupo de una o más entidades asociadas al recurso. Además, el método comprende transmitir las rutas de red entre los agentes disponibles 204a a 204e del grupo y las entidades asociadas al recurso 208 al agente coordinador 210. Incluso en el caso de una única entidad, el número de rutas de red transmitidas por cada agente disponible puede ser mayor que uno debido a la posibilidad de que el enrutamiento dinámico dentro de la red proporcione diferentes rutas de red en diferentes intentos de acceder a la única entidad. Otros ejemplos pueden estar limitados a un único intento de acceso a una entidad por agente disponible, lo que resulta en una única ruta de red transmitida para cada agente disponible 204a a 204e. Sin embargo, si hay más de una entidad asociada al recurso, lo cual es normalmente el caso en servidores de nombres (un dominio típicamente utiliza más de un servidor de nombres para la resolución DNS), múltiples rutas de red pueden ser transmitidas para cada agente disponible que establece rutas de red hacia diferentes entidades.
El proceso de selección se finaliza seleccionando el grupo de al menos dos agentes de validación en el agente coordinador basado en las rutas de red, de manera que los agentes de validación resultantes cumplan con el requisito de que las rutas de red entre los agentes de validación del grupo y las entidades desde las cuales se consulta la propiedad del recurso no se intersequen.
Según algunos ejemplos, una comunicación entre el agente coordinador y los agentes de validación se encuentra cifrada para mejorar la seguridad, por ejemplo, mediante HTTPS.
Mientras que la figura 2 ilustra un dominio como un ejemplo particular para un recurso, otros ejemplos pueden validar otros recursos, como por ejemplo una dirección IP, un servidor de correo electrónico o un dispositivo.
La figura 3 ilustra un ejemplo de un sistema para validar la propiedad de un recurso dentro de una red, el sistema que comprende un agente coordinador 310 y al menos dos agentes de validación 320 y 330. Como se muestra en la figura 2, el sistema de la figura 3 utiliza la validación de dominio como un ejemplo particular para la validación de la propiedad de un recurso dentro de la red.
El agente coordinador 310 comprende una primera interfaz de comunicación 312 para un servicio de validación, la primera interfaz de comunicación 312 está configurada para recibir información sobre un recurso 345 dentro de una red y una propiedad del recurso 345 a ser consultada. El agente coordinador 310 además comprende una segunda interfaz de comunicación 314 para agentes de validación, la segunda interfaz de comunicación está configurada 314 para transmitir un indicador de dirección para el recurso 345 a un grupo de agentes disponibles 320, 330 y 340, y para recibir rutas de red entre los agentes disponibles 320, 330 y 340 y entidades 354 de un grupo de una o más entidades asociadas al recurso 345. En caso de validación de dominio, el indicador de dirección puede ser el nombre de dominio principal y la propiedad puede ser la entrada de un registro CNAME, por ejemplo. La primera interfaz de comunicación 312 está configurada para recibir la información utilizada para la validación desde el servicio de validación 316. En el ejemplo de la figura 3, se asume que una autoridad de certificación es el servicio de validación 316, que puede, por ejemplo, emitir una solicitud de validación al recibir una solicitud de un propietario 352 de un dominio para firmar un certificado para el dominio (Solicitud de Firma de Certificado 318).
Para seleccionar los agentes de validación de acuerdo con los criterios previamente discutidos, el agente coordinador 310 además comprende circuitos de selección configurados para seleccionar un grupo de al menos dos agentes de validación del grupo de agentes disponibles en base a las rutas de red recibidas.
La segunda interfaz de comunicación 314 está configurada además para transmitir la propiedad del recurso 345 a los agentes de validación y recibir propiedades consultadas de los agentes de validación una vez que se haya establecido el grupo de agentes de validación.
El circuito de evaluación dentro del agente coordinador 310 está configurado para concluir sobre la validación exitosa del recurso si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada, por ejemplo, al contenido esperado de un registro CNAME del servidor DNS.
Para enviar el resultado de la validación al servicio de validación solicitante 316, la primera interfaz de comunicación 312 está configurada además para indicar la validación exitosa o no exitosa al servicio de validación 316. Tanto el agente coordinador como los agentes de validación pueden ser implementados en hardware o en software.
Como se ilustra además en la figura 3, un agente de validación 320 comprende una primera interfaz de comunicación 322 para un agente coordinador, la primera interfaz de comunicación 322 está configurada para recibir el indicador de dirección para el recurso 345 en la red y la propiedad del recurso que debe ser consultada por el agente de validación 320. Una segunda interfaz de comunicación 324 está configurada para establecer una ruta de red hacia entidades 354 de un grupo de una o más entidades asociadas al recurso 345. Para poder proporcionar un criterio de selección al agente coordinador 310, la primera interfaz de comunicación 322 está configurada además para transmitir rutas de red al agente coordinador 310. Las rutas de la red pueden, por ejemplo, ser determinadas por el agente de validación 320 utilizando trazarrutas o herramientas o métodos similares. Asimismo, el agente coordinador 310 puede ser capaz de detectar en qué red de operador se encuentra para transmitir la información al agente coordinador 310 como un criterio adicional de selección. Alternativamente, el agente coordinador 310 puede ser capaz de determinar en qué red de operadores se encuentra un agente disponible, por ejemplo, mediante su dirección IP.
La segunda interfaz de comunicación también puede estar configurada para consultar la propiedad del recurso 345 desde una entidad 354 del grupo para determinar una propiedad consultada una vez que el agente de validación ha sido seleccionado para la consulta por el agente coordinador 310. Asimismo, la primera interfaz de comunicación 322 puede estar configurada además para enviar la propiedad consultada al agente coordinador 314. Para aumentar aún más la seguridad, la comunicación entre el agente coordinador 310 y el agente de validación 320 puede estar encriptada, es decir, la segunda interfaz de comunicación 314 del agente coordinador 310 y la primera interfaz de comunicación 322 del agente de validación 320 pueden intercambiar mensajes encriptados, por ejemplo, mediante HTTPS. En caso de validación de dominio, por ejemplo, la comunicación en la segunda interfaz de comunicación 324 del agente de validación 320 puede ser sin cifrar, sin embargo, dado que la comunicación con los servidores de nombres de dominio puede requerir que sea sin cifrar.
La Figura 4 ilustra otro ejemplo de un método para validar la propiedad de un recurso que puede, por ejemplo, llevarse a cabo dentro de un agente coordinador 310.
El método comprende seleccionar 410 un grupo de al menos dos agentes de validación de manera que las rutas de red entre un agente de validación del grupo y las entidades de un grupo de una o más entidades asociadas con el recurso no se intersequen. Además, el método comprende transmitir 420 una propiedad del recurso a consultar a los agentes de validación.
El método además comprende recibir 430 propiedades consultadas de los agentes de validación; y validar 440 la propiedad del recurso en base a las propiedades consultadas de acuerdo a, por ejemplo, los criterios elaborados anteriormente.
Mientras que consultar las entradas CNAME de un dominio ha sido predominantemente utilizado como un ejemplo de una propiedad consultada durante la validación de dominio, también se pueden consultar otras propiedades en implementaciones posteriores, ya que existen varios métodos para realizar la validación de dominio DV.
- DV basado en correo electrónico. Al completar un CSR, se emite un correo electrónico al contacto administrativo del dominio seleccionado por el solicitante de entre las direcciones de correo electrónico registradas para ese dominio en Whois. El correo electrónico típicamente contiene un código de validación y un enlace, que el destinatario debe hacer clic e ingresar el código para demostrar el control sobre el dominio. Si se ingresa el código correcto, el proceso continúa con la emisión del certificado.
- DV basado en WHOIS. Similar al DV basado en correo electrónico, excepto que el cliente no puede seleccionar qué correo electrónico (de entre los registrados como administrativos para el dominio) se utilizará en la validación. Durante el procedimiento de DV, el CA selecciona por sí mismo la dirección de correo electrónico y puede utilizar cualquier dirección de correo electrónico de contacto de Administrador, Registrante, Técnico o Zona que aparezca en el registro WHOIS del dominio.}
- DV basado en DNS. Al enviar un CSR, se proporciona un valor hash que debe ingresarse como un Registro de Recurso (RR) CNAME de DNS para el dominio en el archivo de zona. Por ejemplo, supongamos que el dominio del solicitante es vict.im y el dominio de las CA es ca-domain.com. Un registro CNAME puede ser hash1.www.vict.im. El CNAME hash2.ca-domain.com. El resolver DNS de la CA consulta el dominio del solicitante y verifica la presencia del registro CNAME. Si el registro correcto está presente, la CA procede a emitir el certificado solicitado.
- DV basado en HTTP/S. Tras la presentación de un CSR, se devuelve al cliente un valor hash. Se debe crear un archivo y colocarlo en la raíz del servidor web con el valor hash como nombre, de la siguiente manera: http://www.vict.im/hash-value1.txt. El contenido del archivo debe contener hash-value2 y el dominio cadomain.com. El CA realiza una solicitud HTTP/HTTPS para recuperar el archivo. Si es correcto, la CA procede a emitir el certificado.
En resumen, los ejemplos descritos en la presente descripción pueden preservar los beneficios de DV al mismo tiempo que proporcionan resistencia contra atacantes de MitM. Por lo tanto, los ejemplos de la presente descripción también pueden ser referidos como DV++. La integración de los nuevos ejemplos en los sistemas convencionales no requiere ningún cambio en la infraestructura y funcionalidad de la CA, por lo que el uso de ejemplos por parte de una CA resulta de bajo costo y esfuerzo. Un aspecto de los ejemplos es utilizar nodos distribuidos (agentes de validación) que realizan DV desde múltiples puntos de vista. La seguridad contra los atacantes MitM se logra colocando los nodos en diferentes redes, que no atraviesan rutas superpuestas.
A diferencia de un atacante de escucha criptográfica, que es un espía global, un atacante realista de MitM puede estar presente solo en algunas redes (del operador) pero no controla todo Internet. El atacante puede ser un ISP malicioso, que recopila de forma pasiva el tráfico que atraviesa sus redes de operadores. Un atacante también puede intentar activamente atraer tráfico de otras redes mediante la realización de secuestro de prefijos BGP. Los ejemplos descritos en este documento (DV++) proporcionan un mecanismo descentralizado, que puede utilizar la infraestructura existente de Internet para validar las reclamaciones de propiedad de dominio. A diferencia de la validación centralizada realizada por las Autoridades de Certificación (CA) con el DV convencional, el DV++ se basa en una jerarquía plana con varios agentes de certificación igualmente confiables. Para pasar una validación, los propietarios de dominios deben demostrar su propiedad a la mayoría de los agentes, por ejemplo, de manera completamente automatizada, respondiendo a las consultas enviadas por los agentes de validación para los registros de recursos en el dominio. Los agentes de validación están sincronizados con un agente coordinador, que también se conoce como módulo orquestador. El orquestador puede estar ubicado en la red de CA. El orquestador y los agentes pueden utilizar HTTPS para su comunicación mutua. Durante el proceso de validación de dominio, todos los agentes reciben del orquestador el dominio y el registro que deben consultar. Los agentes envían solicitudes DNS a los servidores de nombres en el dominio solicitando el registro. Tan pronto como llega la respuesta, el agente envía la respuesta al orquestador. Si, por ejemplo, más del 50 % de las respuestas llegan y coinciden, el orquestador devuelve éxito, de lo contrario, devuelve fracaso. El número de respuestas correctas de los agentes es un parámetro que el CA puede configurar.
Al enviar una solicitud DNS, cada agente selecciona de forma independiente un puerto de origen al azar, así como un TXID aleatorio. Para llevar a cabo un ataque exitoso, el atacante tiene que falsificar respuestas correctas a más del 50 % de los agentes. Esta es una tarea imposible incluso para atacantes fuertes de estados nacionales. Los agentes pueden configurarse en diferentes redes de disponibilidad física de la nube de AWS. La selección de las redes en la nube se realiza de manera que los agentes se localicen ubicados en diferentes redes, cuyas rutas no se intersequen. Para seleccionar las redes donde colocar los agentes, se puede utilizar un gráfico de nivel AS de CAIDA derivado empíricamente del año 2016. Similar a DV, la autenticación DV++ es iniciada por la CA después de recibir una solicitud de CSR por parte del solicitante. Durante este proceso, se envían consultas a los agentes, que realizan búsquedas en el dominio objetivo. Una vez que el orquestador recibe la mayoría de las respuestas, estas son procesadas.
Aunque el atacante pueda corromper algunos agentes, controlar algunas redes o rutas, no puede controlar todos los caminos y todas las redes en Internet ni corromper a todos los agentes. Por ejemplo, incluso los atacantes de naciones fuertes, como las agencias de seguridad, no controlan todas las redes y rutas de Internet.
Si se considera a un atacante que intenta pasar la autenticación de DV++ para emitir un certificado fraudulento. Para tener éxito, el atacante debe proporcionar respuestas falsificadas correctas para la mayoría de las solicitudes DNS emitidas por los agentes DV++.
Si el atacante se localiza en una red del servidor de nombres de la víctima, puede secuestrar las solicitudes en la red del servidor de nombres y enviar respuestas falsificadas a los agentes de DV++. Afortunadamente, los dominios tienen más de un servidor de nombres y los servidores de nombres se encuentran en diferentes redes; esto sigue las mejores prácticas para evitar un único punto de fallo para los dominios. Las mediciones de 1 millón de dominios principales de Alexa muestran que el número promedio de servidores de nombres por dominio es 5, y el mínimo es 2. Además, los servidores de nombres pertenecientes al mismo dominio están alojados en diferentes redes. Esto asegura que el atacante no pueda secuestrar y reemplazar las respuestas de todos los servidores de nombres.
Considerando un atacante pasivo MitM, que controla un ISP grande, y un atacante activo, que además intenta atraer tráfico de otras redes, se demuestra la robustez de la validación tal como se describe en la presente descripción. Utilizando un número diferente de agentes, se puede demostrar que incluso con 3 agentes en redes de proveedores de servicios de Internet de primer nivel, se garantiza una fuerte seguridad contra atacantes de MitM.
Además de los casos de uso presentados anteriormente, se pueden utilizar otros ejemplos de la descripción contenida en la presente descripción (DV++) para iniciar otros mecanismos con seguridad. Por ejemplo, los ataques pueden aplicarse contra los procedimientos de recuperación de contraseñas en servicios web populares. En el procedimiento de recuperación de contraseña, la contraseña o un enlace para restablecer la contraseña se envía de vuelta al correo electrónico que inició la recuperación de contraseña. Si el resolutor DNS en la red del servicio es atacado y almacena en caché un registro incorrecto (asociando el correo electrónico de la víctima a una dirección IP controlada por un atacante), la contraseña sería enviada al atacante. DV++ puede ser utilizado por los servicios web para validar el registro DNS del correo electrónico que solicita la recuperación de contraseña, bloqueando así las solicitudes maliciosas que no pasen la verificación de DV++.
Ejemplos pueden además ser o estar relacionados con un programa informático que tiene un código de programa para llevar a cabo uno o más de los métodos anteriores, cuando el programa informático se ejecuta en un ordenador o procesador. Los pasos, operaciones o procesos de los diversos métodos descritos anteriormente pueden ser realizados por ordenadores o procesadores programados. Los ejemplos también pueden incluir dispositivos de almacenamiento de programas, como medios de almacenamiento de datos digitales, que son legibles por máquinas, procesadores u ordenadores y codifican programas de instrucciones ejecutables por máquinas, procesadores u ordenadores. Las instrucciones realizan o causan la realización de algunos o todos los actos de los métodos descritos anteriormente. Los dispositivos de almacenamiento del programa pueden comprender o ser, por ejemplo, memorias digitales, medios de almacenamiento magnéticos como discos magnéticos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales legibles ópticamente. Además, otros ejemplos pueden incluir ordenadores, procesadores o unidades de control programadas para realizar las acciones de los métodos descritos anteriormente o matrices lógicas programables (FPLA) o arreglos de compuertas programables (FPGA), programados para realizar las acciones de los métodos descritos anteriormente.
La descripción y los dibujos simplemente ilustran los principios de la divulgación. Además, todos los ejemplos mencionados en la presente descripción están principalmente destinados expresamente a ser solo con fines ilustrativos para ayudar al lector a comprender los principios de la descripción y los conceptos aportados por el(los) inventor(es) para avanzar en la técnica. Todas las declaraciones en la presente descripción que mencionan principios, aspectos y ejemplos de la descripción, así como ejemplos específicos de los mismos, tienen la intención de abarcar sus equivalentes.
Funciones de varios elementos mostrados en las figuras, incluyendo cualquier bloque funcional etiquetado como "medios", "medios para proporcionar una señal", "medios para generar una señal", etc., pueden ser implementadas en forma de hardware dedicado, como "un proveedor de señal", "una unidad de procesamiento de señal", "un procesador", "un controlador", etc., así como hardware capaz de ejecutar software en asociación con el software adecuado. Cuando son proporcionadas por un procesador, las funciones pueden ser proporcionadas por un único procesador dedicado, por un único procesador compartido o por una pluralidad de procesadores individuales, algunos de los cuales o todos ellos pueden ser compartidos. Sin embargo, el término "procesador" o "controlador" no se limita exclusivamente al hardware capaz de ejecutar software, sino que puede incluir hardware de procesador de señal digital (DSP), procesador de red, circuito integrado de aplicación específica (ASIC), matriz de compuertas programable en campo (FPGA), memoria de solo lectura (ROM) para almacenar software, memoria de acceso aleatorio (RAM) y almacenamiento no volátil. Otros componentes hardware, convencionales y/o personalizados, también pueden ser incluidos.
Un diagrama de bloques puede, por ejemplo, ilustrar un diagrama de circuito de alto nivel que implementa los principios de la descripción. De manera similar, un diagrama de flujo, un diagrama de flujo, un diagrama de transición de estados, un pseudocódigo y otros similares pueden representar varios procesos, operaciones o pasos, los cuales pueden, por ejemplo, estar sustancialmente representados en un medio legible por ordenador y ser ejecutados por un ordenador o procesador, ya sea que dicho ordenador o procesador se muestre explícitamente o no. Los métodos descritos en la especificación o en las reivindicaciones pueden ser implementados por un dispositivo que tenga medios para llevar a cabo cada uno de los actos respectivos de estos métodos.
Se entiende que la descripción de múltiples actos, procesos, operaciones, pasos o funciones revelados en la especificación o reivindicaciones no debe interpretarse como que se encuentran en un orden específico, a menos que se indique explícita o implícitamente lo contrario, por ejemplo, por razones técnicas. Por lo tanto, la descripción de múltiples actos o funciones no los limitará a un orden particular, a menos que dichos actos o funciones no sean intercambiables por razones técnicas. Además, en algunos ejemplos, un solo acto, función, proceso, operación o paso puede incluirse o puede dividirse en múltiples subactos, subfunciones, subprocesos, suboperaciones o subpasos, respectivamente. Tales subactos pueden estar incluidos y formar parte de la descripción de este único acto, a menos que se excluyan explícitamente.

Claims (13)

REIVINDICACIONES
1. Un método para validar la propiedad de un recurso (208) dentro de una red, que comprende:
seleccionar (102) un grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) de manera que las rutas de red (212a, 212b, 212c) entre un agente de validación del grupo (214) y entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (208) no se intersequen;
transmitir (104) una propiedad del recurso (208) a validar y un indicador de dirección para el recurso (208) desde un agente coordinador (210) al grupo (214) de agentes de validación (204a, 204b, 204d); consultar (106) la propiedad del recurso (208) de las entidades utilizando los agentes de validación (204a, 204b, 204d) del grupo (214) para determinar las propiedades consultadas; y
evaluar (108) las propiedades consultadas para validar la propiedad del recurso (208).
2. El método de reivindicación 1, en donde el grupo (214) de agentes de validación (204a, 204b, 204d) se selecciona además de manera que al menos dos agentes de validación (204a, 204b, 204d) se localicen en diferentes redes de operadores (202a, 202b, 202d).
3. El método de la reivindicación 1 o 2, en donde se confirma la propiedad del recurso (208) si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada.
4. El método de una de las reivindicaciones 1 a 3, en donde seleccionar el grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) comprende:
transmitir un indicador de dirección para el recurso (208) desde el agente coordinador (210) a un grupo de agentes disponibles (204a, 204b, 204c, 204d, 204e);
utilizar el indicador de dirección para determinar un grupo de una o más entidades sobre las cuales se consultará acerca de una propiedad del recurso (208);
transmitir rutas de red entre los agentes disponibles (204a, 204b, 204c, 204d, 204e) del grupo y las entidades de los agentes disponibles (204a, 204b, 204c, 204d, 204e) al agente coordinador (210); y
seleccionar el grupo (214) de al menos dos agentes de validación (204a, 204b, 204d) en el agente coordinador (210) basado en las rutas de la red.
5. El método de una de las reivindicaciones anteriores, en donde la comunicación entre el agente coordinador (210) y los agentes de validación (204a, 204b, 204d) está cifrada.
6. El método de una de las reivindicaciones anteriores, en donde el recurso (208) es uno de un Dominio, un Servidor de Correo Electrónico y un dispositivo.
7. Un agente coordinador (310), que comprende:
una primera interfaz de comunicación (312) para un servicio de validación (316), la primera interfaz de comunicación (312) está configurada para recibir información sobre un recurso (345) dentro de una red y una propiedad del recurso (345);
una segunda interfaz de comunicación (314) para agentes de validación (320, 322), la segunda interfaz de comunicación (314) está configurada para transmitir un indicador de dirección para el recurso (345) a un grupo de agentes disponibles (320, 330, 340) y para recibir rutas de red entre los agentes disponibles y entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (345); circuitos de selección configurados para seleccionar un grupo de al menos dos agentes de validación (320, 330) del grupo de agentes disponibles (320, 330, 340) en base a las rutas de red recibidas, de manera que las rutas de red entre un agente de validación del grupo y las entidades sobre las que se realizarán las consultas no se intersequen;
la segunda interfaz de comunicación (314) está configurada además para transmitir la propiedad del recurso (345) a los agentes de validación (320, 330) y para recibir propiedades consultadas de los agentes de validación (320, 330); y
circuitos de evaluación configurados para concluir sobre la validación exitosa del recurso (345) si una fracción predeterminada de las propiedades consultadas corresponde a una propiedad esperada.
8. El agente coordinador de la reivindicación 7, en donde la primera interfaz de comunicación (312) está configurada además para indicar la validación exitosa o no exitosa al servicio de validación (316).
9. Un agente de validación (320, 330), que comprende:
una primera interfaz de comunicación (322) para un agente coordinador, la primera interfaz de comunicación (322) está configurada para recibir un indicador de dirección para un recurso (345) en una red y una propiedad del recurso (345); y
una segunda interfaz de comunicación, la segunda interfaz de comunicación está configurada para establecer una ruta de red hacia entidades de un grupo de una o más entidades a consultar sobre una propiedad del recurso (345); en donde
la primera interfaz de comunicación (322) está configurada además para transmitir la ruta de red al agente coordinador,
en donde la segunda interfaz de comunicación está configurada además para consultar la propiedad del recurso (345) a una entidad del grupo para determinar una propiedad consultada; y en donde
la primera interfaz de comunicación (322) está configurada además para enviar la propiedad consultada al agente coordinador.
10. Un sistema para validar la propiedad de un recurso (345) dentro de una red, que comprende:
un agente coordinador (310) según una de las reivindicaciones 7 u 8;
un primer agente de validación (320) según la reivindicación 9;
un segundo agente de validación (330) según la reivindicación 9.
11. El sistema de la reivindicación 10, en donde el primer agente de validación (320) se localiza dentro de una primera red de operadores, y en donde el segundo agente de validación (330) se localiza dentro de una segunda red de operadores.
12. El sistema de la reivindicación 10 o 11, en donde el agente coordinador (310) se localiza dentro de la red de una Autoridad de Certificación.
13. Programa informático que tiene código de programa para, cuando se ejecuta por un procesador programable, realizar el método de una de las reivindicaciones 1 a 6.
ES19202773T 2018-10-12 2019-10-11 Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación Active ES2971623T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18200254 2018-10-12

Publications (1)

Publication Number Publication Date
ES2971623T3 true ES2971623T3 (es) 2024-06-06

Family

ID=63915180

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19202773T Active ES2971623T3 (es) 2018-10-12 2019-10-11 Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación

Country Status (3)

Country Link
US (1) US11700263B2 (es)
EP (1) EP3637739B1 (es)
ES (1) ES2971623T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11571626B2 (en) 2020-11-02 2023-02-07 Microsoft Technology Licensing, Llc Software ownership validation of optical discs using secondary device
US11934393B2 (en) * 2021-01-12 2024-03-19 Sap Se Input validation API using machine learning and database input validation framework

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1259882A1 (en) * 2000-03-27 2002-11-27 Network Security Systems, Inc. Internet/network security method and system for checking security of a client from a remote facility
US7457823B2 (en) * 2004-05-02 2008-11-25 Markmonitor Inc. Methods and systems for analyzing data related to possible online fraud
US9002923B2 (en) * 2008-07-01 2015-04-07 Thomson Licensing Transparent web proxy
EP2317733A1 (en) * 2009-10-29 2011-05-04 British Telecommunications public limited company Communications system
US8370902B2 (en) * 2010-01-29 2013-02-05 Microsoft Corporation Rescuing trusted nodes from filtering of untrusted network entities
US9300625B1 (en) * 2013-01-02 2016-03-29 Amazon Technologies, Inc. Network address verification
US9712381B1 (en) * 2014-07-31 2017-07-18 Google Inc. Systems and methods for targeted probing to pinpoint failures in large scale networks
US20170279681A1 (en) * 2016-03-28 2017-09-28 Facebook, Inc. Methods and Systems for Distributed Testing of Network Configurations for Zero-Rating
US9774626B1 (en) * 2016-08-17 2017-09-26 Wombat Security Technologies, Inc. Method and system for assessing and classifying reported potentially malicious messages in a cybersecurity system
US20190158276A1 (en) * 2017-11-17 2019-05-23 Simmonds Precision Products, Inc. Encryption key exchange with compensation for radio-frequency interference
US10608868B2 (en) * 2017-11-29 2020-03-31 International Business Machines Corporation System and method for proactive distributed agent based network diagnosis

Also Published As

Publication number Publication date
US11700263B2 (en) 2023-07-11
US20200296109A1 (en) 2020-09-17
EP3637739A1 (en) 2020-04-15
EP3637739C0 (en) 2023-12-06
EP3637739B1 (en) 2023-12-06

Similar Documents

Publication Publication Date Title
US20230035336A1 (en) Systems and methods for mitigating and/or preventing distributed denial-of-service attacks
US20240129290A1 (en) Authenticated name resolution
EP3844657B1 (en) Distributed data authentication and validation using blockchain
Brandt et al. Domain validation++ for mitm-resilient pki
US7930428B2 (en) Verification of DNS accuracy in cache poisoning
Ahmed et al. IPv6 neighbor discovery protocol specifications, threats and countermeasures: a survey
US10951577B2 (en) Device and method for resolving domain names
Wachs et al. A censorship-resistant, privacy-enhancing and fully decentralized name system
Ambrosin et al. Security and privacy analysis of national science foundation future internet architectures
US9973590B2 (en) User identity differentiated DNS resolution
US20180115520A1 (en) Dark virtual private networks and secure services
Schmid Thirty years of DNS insecurity: Current issues and perspectives
ES2971623T3 (es) Método para validar la propiedad de un nombre de dominio, agente coordinador y agente de validación
CN109067768B (zh) 一种域名查询安全性的检测方法、系统、设备和介质
Bates et al. Forced perspectives: Evaluating an SSL trust enhancement at scale
Zou et al. Survey on domain name system security
CN103747005B (zh) Dns缓存投毒的防护方法和设备
Scaife et al. OnionDNS: A seizure-resistant top-level domain
Abdou et al. Server location verification (SLV) and server location pinning: Augmenting TLS authentication
Grothoff et al. NSA’s MORECOWBELL: knell for DNS
Rajendran et al. Domain name system (dns) security: Attacks identification and protection methods
JP6763605B2 (ja) データ通信システム、キャッシュｄｎｓ装置及び通信攻撃防止方法
CN118435556A (zh) 在零信任访问模型中限制对受保护资源的发现
Bator et al. Security of the DNSSEC protocol and its impact on online privacy protection
ROSTAMPOUR Deploying DNS Security Extensions