Anexo:Tipos de registros DNS
Esta lista de tipos de registros DNS es una vista general de los registros de recursos permitidos en los archivos de zona del Sistema de nombres de dominio (DNS). También contiene pseudo-registros de recursos.
Registros de recurso
editar| Tipo | Id. de tipo (decimal) | RFC |
Descripción | Función |
|---|---|---|---|---|
| A | 1 | RFC 1035[1] | Registro de dirección | Devuelve una dirección IPv4 de 32 bits, la más utilizada para asignar nombres de host a una dirección IP del host, pero también se utiliza para DNSBLs, almacenando máscaras de subred en RFC 1101, etc. |
| AAAA | 28 | RFC 3596[2] | Registro de dirección IPv6 | Devuelve una dirección IPv6 de 128 bits, la más utilizada para asignar nombres de host a una dirección IP del host. |
| AFSDB | 18 | RFC 1183 | Registro de base de datos AFS |
Ubicación de los servidores de bases de datos de una célula AFS. Este registro es comúnmente utilizado por los clientes de AFS para ponerse en contacto con células AFS fuera de su dominio local. Un subtipo de este registro es utilizado por el sistema de archivos DCE / DFS obsoleto. |
| APL | 42 | RFC 3123 | Lista de prefijos de direcciones | Especifica listas de rangos de direcciones, por ejemplo en formato CIDR, para varias familias de direcciones. Experimental. |
| CAA | 257 | RFC 6844 | Autorización de la Autoridad de Certificación | Limita las autoridades de certificación aceptables para un host/dominio |
| CDNSKEY | 60 | RFC 7344 | DNSKEY hijo | Copia hija del registro DNSKEY, para la transferencia al padre |
| CDS | 59 | RFC 7344 | DS hijo | Copia hija del registro DS, para la transferencia al padre |
| CERT | 37 | RFC 4398 | Registro de certificado | Almacena PKIX, SPKI, PGP, etc. |
| CNAME | 5 | RFC 1035[1] | Registro de nombre canónico | Alias de un nombre a otro: la búsqueda de DNS continuará reintentando la búsqueda con el nuevo nombre. |
| DHCID | 49 | RFC 4701 | Identificador DHCP | Se utiliza junto con la opción FQDN para DHCP |
| DLV | 32769 | RFC 4431 | Registro de validación "lookaside" DNSSEC | Para publicar anclajes de confianza DNSSEC fuera de la cadena de delegación de DNS. Utiliza el mismo formato que el registro de DS. RFC 5074 describe una forma de utilizar estos registros.RFC 5074 describe una manera de utilizar estos registros. |
| DNAME | 39 | RFC 2672 | Nombre de delegación | Alias para un nombre y todo sus sub-nombres, a diferencia de CNAME, el cual es un alias para único el nombre exacto. Como un CNAME registro, el DNS lookup continuará por retrying el lookup con el nombre nuevo. |
| DNSKEY | 48 | RFC 4034 | Registro de clave DNS | El registro clave utilizado en DNSSEC. Utiliza el mismo formato que el registro KEY. |
| DS | 43 | RFC 4034 | Firmante de delegación | El registro utilizado para identificar la clave DNSSEC de una zona delegada |
| IPSECKEY | 45 | RFC 4025 | Clave IPsec |
Registro clave que puede ser utilizado con IPsec |
| KEY | 25 | RFC 2535[3] y RFC 2930[4] | Registro clave | Se utiliza sólo para SIG(0) (RFC 2931) y TKEY (RFC 2930).[5] RFC 3445 eliminó su uso para las claves de aplicación y limitó su uso a DNSSEC.[6] RFC 3755 designa DNSKEY como el reemplazo dentro de DNSSEC.[7] RFC 4025 designa IPSECKEY como el reemplazo para su uso con IPsec.[8] |
| KX | 36 | RFC 2230 | Registro de Intercambiador de claves | Se utiliza con algunos sistemas criptográficos (sin incluir DNSSEC) para identificar un agente de administración de claves para el nombre de dominio asociado. Tenga en cuenta que esto no tiene nada que ver con la seguridad de DNS. Es de estado informativo en lugar de estar en las normas IETF. Siempre ha tenido un despliegue limitado, pero todavía está en uso. |
| LOC | 29 | RFC 1876 | Registro de ubicación | Especifica una ubicación geográfica asociada con un nombre de ámbito |
| MX | 15 | RFC 1035[1] y RFC 7505 | Registro de intercambio del correo | Mapean un nombre de dominio a una lista de agentes de transferencia del mensaje para ese dominio |
| NAPTR | 35 | RFC 3403 | Puntero de Autoridad de nombrado |
Deja regular-expresión-basó reescribir del ámbito nombra cuáles entonces pueden ser utilizados tan URIs, nombres de ámbito más lejano a lookups, etc. |
| NS | 2 | RFC 1035[1] | Registro de servidor de nombres | Delega un DNS zona para utilizar los servidores de nombre autoritarios dados |
| NSEC | 47 | RFC 4034 | Registro de siguiente-Seguro | Parte de DNSSEC—utilizó para probar un nombre no existe. Utiliza el mismo formato como el (obsoleto) NXT registro. |
| NSEC3 | 50 | RFC 5155 | Registro NSEC Versión 3 | Una extensión a DNSSEC aquello deja prueba de inexistencia para un nombre sin permitting zonewalking |
| NSEC3PARAM | 51 | RFC 5155 | parámetros NSEC3 | Registro de parámetro para uso con NSEC3 |
| PTR | 12 | RFC 1035[1] | Registro de puntero | Puntero a un nombre canónico. A diferencia de un CNAME, DNS procesando parones y justo el nombre está regresado. El uso más común es para implementar una consulta reversa DNS, pero otros usos incluyen tales cosas como DNS-SD. |
| RRSIG | 46 | RFC 4034 | Firma DNSSEC | Firma para un DNSSEC-conjunto récord asegurado. Utiliza el mismo formato como el SIG registro. |
| RP | 17 | RFC 1183 | Persona responsable | Información sobre la persona responsable(s) para el ámbito. Normalmente una dirección de correo electrónico con el @ reemplazado por un . |
| SIG | 24 | RFC 2535 | Firma | Registro de firma utilizado en SIG(0) (RFC 2931) y TKEY (RFC 2930).[7] RFC 3755 designó RRSIG como la sustitución para SIG para uso dentro de DNSSEC.[7] |
| SOA | 6 | RFC 1035[1] y RFC 2308[9] | Inicio de registro de [una zona de] autoridad | Especifica información autoritaria sobre un DNS zona, incluyendo el servidor de nombre primario, el correo electrónico del administrador de ámbito, el número de serial del ámbito, y varios temporizadores que relacionan a refreshing la zona. |
| SRV | 33 | RFC 2782 | Localizador de Servicios | Registro de ubicación de servicio generalizado, utilizado para protocolos más nuevos en vez de crear protocolo-registros concretos como MX. |
| SSHFP | 44 | RFC 4255 | Huella digital de clave SSH pública |
Registro de recurso para editorial SSH público anfitrión clave fingerprints en el DNS Sistema, para ayuda en verificar la autenticidad del anfitrión. RFC 6594 define ECC SSH llaves y SHA-256 hashes. Ver el IANA SSHFP RR registro de parámetros para detalles. |
| TA | 32768 | Autoridades de Confianza DNSSEC |
Parte de una propuesta de despliegue para DNSSEC sin un firmado de la raíz DNS. Ver la base de datos IANA y Weiler Spec para detalles. Utiliza el mismo formato que el DS registro. | |
| TKEY | 249 | RFC 2930 | Registro de clave de transacción |
Un método de proporcionar keying material para ser utilizado con TSIG aquello está encriptado bajo la llave pública en un acompañante CLAVE RR.[10] |
| TLSA | 52 | RFC 6698 | Certificado de asociación TLSA | Un registro para DNS-Autentificación basada de Nombró Entidades (DANE). RFC 6698 define "El TLSA DNS registro de recurso suele asociar un TLS certificado de servidor o llave pública con el nombre de ámbito donde el registro está encontrado, por ello formando un 'TLSA asociación de certificado'". |
| TSIG | 250 | RFC 2845 | Firma de transacción | Puede soler autenticar actualizaciones dinámicas cuando proviniendo un cliente aprobado, o para autenticar respuestas cuando proviniendo un servidor de nombre recursivo aprobado similar a DNSSEC.[11] |
| TXT | 16 | RFC 1035[1] | Registro de texto | Creado originalmente para albergar texto a ser leído por humanos, a partir de la RFC 1464 puede contener información adicional para ser leída por ordenadores, como por ejemplo encriptación oportunística,[12] Sender Policy Framework, DomainKeys Identified Mail, DMARC, DNS-SD entre otras. |
| URI | 256 | RFC 7553 | Identificador Uniforme de Recursos | Puede ser utilizado para relacionar un nombre de host con una URI. |
Otros tipos y pseudo registros de recurso
editarOtros tipos de los registros sencillamente proporcionan algunos tipos de información (por ejemplo, un registro HINFO da una descripción del tipo de ordenador/OS que usa el equipo), u otros entregan datos utilizados en características experimentales. El campo "tipo" es también utilizado en el protocolo para varias operaciones.
| Código | Número | RFC que define |
Descripción | Función |
|---|---|---|---|---|
| * | 255 | RFC 1035[1] | Todo los registros en caché |
Regresa todos los registros de todos los tipos sabidos al servidor de nombre. Si el servidor de nombre no tiene cualquier información en el nombre, la petición será enviada encima. Los registros regresaron no puede ser completo. Por ejemplo, si hay ambos un Un y un MX para un nombre, pero el servidor de nombre ha sólo el Un récord cached, sólo el Un registro será regresado. A veces referido a tan "CUALQUIERA", por ejemplo en Windows nslookup y Wireshark. |
| AXFR | 252 | RFC 1035[1] | Transferencia de Zona autoritaria | Transferir el archivo de zona entero desde el servidor de nombre maestro a servidores de nombre secundario. |
| IXFR | 251 | RFC 1996 | Transferencia de Zona incremental | Pide una transferencia de zona de la zona dada pero solo las diferencias desde un número de serie anterior. Esta petición puede ser ignorada y se envía una respuesta completa (AXFR) si el servidor con autoridad es incapaz de cumplir la petición debido a configuración o carencia de los deltas requeridos. |
| OPT | 41 | RFC 6891 | Opción | Esto es un "tipo de registro pseudo DNS" necesario para permitir EDNS |
Tipos de registros obsoletos
editarEl progreso ha vuelto obsoletos algunos de los tipos de registros definidos originalmente. De los registros listados en IANA, algunos tienen uso limitado, por varias razones. Algunos están marcados como obsoletos en la lista, algunos son para servicios muy oscuros, algunos son para versiones más viejas de los servicios, y algunos tienen notas especiales que dicen que no "están bien".
- Dejada obsoleta por RFC 973: MD(3), MF (4), MAILA (254)
- Registros para publicar listas de suscriptores de listas de correos en el DNS: MB(7), MG(8), MR(9), MINFO(14), MAILB (253). El intento, como se especificó en el RFC 883, era que MB reemplazara el comando SMTP VRFY, MG reemplazara el comando SMTP EXPN, y MR reemplazara el error SMTP "551 Usuario No Local". Más tarde, el RFC 2505 recomendó que ambos comandos el VRFY y EXPN fueran inutilizados, haciendo el uso de MB y MG improbable de ser adoptado.
- Declarado "para no confiar en" por RFC 1123 (con información adicional en [rfc:1123 RFC 1127]): WKS(11)[13]
- Equivocaciones: NB(32), NBSTAT(33) (de RFC 1002); los números son ahora están asignados a NIMLOC y SRV.
- Hechos obsoletos por RFC 1035: NULL(10) (RFC 883 definía "consultas de término" (opcode 2 y quizás 3) las cuales utilizaban este registro, el RFC 1035 más tarde reasignó el opcode 2 para ser "estado" y reservó el opcode 3.)
- Definido como parte del IPv6 temprano pero degradado a experimental por RFC 3363: A6(38), Más tarde degradado a histórico en RFC 6563.
- Hechos obsoletos por actualizaciones DNSSEC (RFC 3755): NXT(30). Al mismo tiempo, el ámbito de aplicabilidad para KEY y SIG también fue limitado a no incluir uso de DNSSEC.
- Parte de la primera versión de DNSSEC (RFC 2065).
- No en uso actual por cualquier aplicación notable: HINFO(13), RP(17), X25(19), ISDN(20), RT(21), NSAP(22), NSAP-PTR(23), PX(26), EID(31), NIMLOC(32), ATMA(34), APL(42)
- Definido por el borrador de internet de Fregadero de Cocina, pero que nunca llegó a estado RFC: SINK(40)
- Una versión temprana más limitada del registro LOC: GPOS(27)
- Reservado por IANA, ningún RFC los documentó y el soporte fue eliminado de Bind a principios de los 90s: UINFO(100), UID(101), GID(102), UNSPEC(103)
- SPF(99) (de RFC 4408) fue especificado como parte del Sender Policy Framework como alternativa para almacenar datos SPF en registros TXT, utilizando el mismo formato. Más tarde se encontró que la mayoría de los despliegues de SPF carecen de soporte apropiado para este tipo de registro, y el soporte para él fue descontinuado en RFC 7208.[14][15]
- RP(17) puede ser utilizado para alguna información legible-por-humano con respecto a un punto de contacto diferente para un equipo, subred, u otra etiqueta de nivel de dominio específica separada de las que se usan en el registro SOA.
Lectura adicional
editar- "Registro de parámetros DNS IANA". Recuperada en «IANA DNS Parameters registry». Consultado el 25 de mayo de 2008.
- "La guía de Google a los Registros DNS". Recuperada en «Google's Guide to DNS Records». Consultado el 9 de diciembre de 2010.
Referencias
editar- ↑ a b c d e f g h i Paul Mockapetris (November 1987). «RFC 1035: Domain Names - Implementation and Specification». Network Working Group of the IETF (Internet Engineering Task Force). p. 12.
- ↑ «RFC 3596: DNS Extensions to Support IP Version 6». The Internet Society. October 2003.
- ↑ RFC 2535, §3
- ↑ RFC 3445, §1.
- ↑ RFC 2931, §2.4.
- ↑ RFC 3445, §1.
- ↑ a b c RFC 3755, §3.
- ↑ RFC 4025, Abstract.
- ↑ The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.
- ↑ RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR RFC 2535."
- ↑ RFC 2845, abstract
- ↑ McManus, Patrick (27 de marzo de 2015). «Opportunistic Encryption For Firefox» (html) (en inglés). Archivado desde el original el 26 de junio de 2018. Consultado el 24 de julio de 2018. «When the browser consumes that response header it will start to verify the fact that there is a HTTP/2 service on port 443. When a session with that port is established it will start routing the requests it would normally send in cleartext to port 80 onto port 443 with encryption instead. There will be no delay in responsiveness because the new connection is fully established in the background before being used. If the alternative service (port 443) becomes unavailable or cannot be verified Firefox will automatically return to using cleartext on port 80. Clients that don't speak the right protocols just ignore the header and continue to use port 80.»
- ↑ RFC 1123 section 2.2, 5.2.12, 6.1.3.6
- ↑ Kucherawy, M. (July 2012).
- ↑ Kitterman, S. (April, 2014).