¿Cuáles son los nombres de zona válidos o los nombres de servicios válidos para los registros srv?

¿Cuáles son los nombres de zona válidos o los nombres de servicios válidos para los registros srv?

He estado siguiendo algunas guías/preguntas sobre cómo usar registros A y registros SRV para asignar un dominio a una IP y un puerto específicos como 1.1.1.1:1889:

https://stackoverflow.com/questions/11433570/how-to-use-srv-or-any-other-record-do-redirect-a-domain

https://stackoverflow.com/questions/19015138/how-to-redirect-dns-to- Different-ports

En preguntas como las anteriores, recomiendan utilizar registros SRV. La única parte que no tengo clara es cómo determinar el servicenombre correcto a usar en mi registro SRV. Por ejemplo, digamos que tengo estos registros

mysql.example.com.  86400 IN A 1.1.1.1
mongo.example.com.  86400 IN A 1.1.1.1
www.example.com.  86400 IN A 1.1.1.1
mosquitto.example.com.  86400 IN A 1.1.1.1
_mysql._tcp.example.com. 86400 IN SRV 10 20 3306 mysql.example.com.
_mongo._tcp.example.com. 86400 IN SRV 10 20 27017 mongo.example.com.
_http._tcp.example.com. 86400 IN SRV 10 20 3306 www.example.com.
_mqtt._tcp.example.com. 86400 IN SRV 10 20 3306 mosquitto.example.com.

¿Son los _mysql, _mongo, _http and _mqttnombres de servicio correctos para usar en mis registros SRV? Adiviné completamente estos nombres de servicios porque no pude encontrar un sitio web que enumere todos los nombres de servicios aceptables que se pueden usar.

Respuesta1

Los primeros navegadores web no siguen SRVningún registro, por lo que incluso si puedes diseñarlos, son inútiles.

Ahora se presenta el proceso genérico para saber qué contiene cualquier registro, tomándolo SRVcomo ejemplo.

La IANA es la guardiana de las cosas, así que visitahttps://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4donde puedes ver SRVque está definido en RFC 2782

Allí se define así:

Aquí está el formato del SRV RR, cuyo código de tipo DNS es 33:

   _Service._Proto.Name TTL Class SRV Priority Weight Port Target

con entonces respectivamente:

Servicio

   The symbolic name of the desired service, as defined in Assigned
   Numbers [STD 2] or locally.  An underscore (_) is prepended to
   the service identifier to avoid collisions with DNS labels that
   occur in nature.

y

prototipo

   The symbolic name of the desired protocol, with an underscore
   (_) prepended to prevent collisions with DNS labels that occur
   in nature.  _TCP and _UDP are at present the most useful values
   for this field, though any name defined by Assigned Numbers or
   locally may be used (as for Service).  The Proto is case
   insensitive.

La referencia [STD 2] es RFC 1700, pero RFC 3232 la dejó obsoleta para crear una base de datos en línea de posibles valores... que nuevamente es administrada por la IANA.

Ahora está ahí:https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtmly tenga en cuenta que es básicamente lo que encuentra en un archivo /etc/servicesen cualquier cuadro de Unix.

Entonces, retomando sus ejemplos ( SRVaunque sus números de puerto son incorrectos en varios registros representados):

  • mysqlDe hecho, está definido para el puerto, 3306por lo que es válido como nombre de servicio y, por lo tanto, en un SRVregistro.
  • para port 27017, el nombre del servicio es mongodb, no mongo(pero ¿los clientes de Mongo respetan SRVlos registros?)
  • httpDe hecho, está definido para el puerto, 80por lo que es un nombre de servicio válido (y httpspara el puerto 443).
  • mqttse define como nombre de puerto válido, para el puerto 1883. Pero la misma pregunta anterior: ¿los clientes utilizan SRValgún registro?

Tenga en cuenta también que existen varios SRVregistros en la naturaleza que no siguen lo anterior. Si se pueden publicar, "funcionan", es decir, nada impedirá su resolución a nivel de DNS, incluso si no utilizan un nombre de servicio registrado como se indicó anteriormente, siempre y cuando alguna aplicación, por supuesto, los lea.

Por ejemplo, puede encontrar muchos ejemplos en _sip._tlso _sipfederationtls._tcpen línea, que son incorrectos: tlsno es un protocolo válido ysipfederantiontls no es un nombre de servicio válido (y de hecho es demasiado largo, ya quehttps://www.rfc-editor.org/rfc/rfc6335.html#section-5.1especifica que debe tener como máximo 15 caracteres). Por lo tanto, alguna herramienta/UI puede impedir la creación de esos registros en un archivo de zona, y algunos servidores de nombres pueden negarse a cargarlos, pero en la mayoría de los casos funcionarán (si las aplicaciones los consumen).

información relacionada