¿Comodín sin punto (* -foo.example.com) para vincular?

Parece que no hay forma de decir bindque *-foo.example.comdebería resolverse, por ejemplo. 10.1.2.3, Mientras que *-bar.example.comel resuelve 10.2.3.4. ¿Hay algún trabajo alrededor? ¿Pueden algunos nombres, por ejemplo. resolver con un programa externo? ¿O debería cambiar binda eg. PowerDNS ?

Estoy tratando de evitar comprar otro certificado SSL comodín. (Con los certificados comodín, como *.example.com, no es posible permitir puntos en la *parte).

Especificar todos *-fooo *-barnombres en el archivo de zona no es una opción, ya que necesito poder crear ambos tipos de direcciones sobre la marcha.

domain-name-system bind wildcard-subdomain

— tuomassalo
fuente

¿No hay forma de agregar los dominios a la zona también sobre la marcha? Nunca he visto comodines parciales utilizados con bind. Sin embargo, no puedo decir con certeza que no sea posible.

— David Houde

@DavidHoude: Me temo que agregar sobre la marcha no es una opción, ya que cualquier consulta anterior a la adición "contaminará" los servidores de nombres con una respuesta no válida. Eso crea problemas que son bastante raros pero un poco desagradables de resolver. (Por supuesto, el tiempo se solucionará el problema.)

— tuomassalo

Te $GENERATEayuda?

— Celada

@DavidHoude: puede usar la actualización dinámica, pero como señala el póster original, entonces se encuentra con la situación en la que un resolutor de almacenamiento en caché puede haber almacenado en caché una respuesta negativa antes de agregar el registro. Para tratar de mitigar que podría reducir el ttl de almacenamiento en caché negativo a un valor muy bajo, pero no todos los resolutores respetan escrupulosamente los ttls y algunos imponen un mínimo práctico, por lo que los resultados pueden ser frustrantemente variables.

— Michael McNally

@Celada: la *parte puede ser cualquier [a-z]cadena (con restricciones de longitud, por supuesto). Entonces, en mi caso $GENERATEno ayuda. Sin embargo, gracias por el consejo: puede ser útil para alguien que encuentre esta página.

— tuomassalo

Respuestas:

La razón por la que no funciona es porque no es un comportamiento definido dentro de los RFC. Debe implementarse como una extensión del software que está utilizando. RFC4592 consolida la definición de un registro comodín con bastante firmeza:

2.1.1 Nombre de dominio comodín y etiqueta de asterisco

Un "nombre de dominio comodín" se define teniendo su
etiqueta inicial (es decir, más a la izquierda o menos significativa) en formato binario:
  0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

Tenga en cuenta el término etiqueta aquí. Una etiqueta es la entidad separada por puntos. Si tiene algo más que el asterisco en la etiqueta, no es un comodín.

Estás un poco atrapado aquí. Al trabajar dentro de DNS, necesita ese punto que está tratando de evitar. Todo lo demás son extensiones del software del servidor y la implementación específica.

— Andrew B
fuente

Muy bien contestado.

— Michael McNally

RFC 6125 evita tener un certificado genérico para subdominios anidados. RFC 4592 y RFC 1034 evitan tener * -xxx.domain.com como entrada DNS.

Por lo tanto, solo tiene dos alternativas (que no es bueno cuando intenta automatizar):

Cree un certificado por subdominio (existen alternativas gratuitas pero pueden ser complicadas dependiendo de su plataforma).
Cree una entrada DNS completa por sub-servicio (que no serán sub-subdominios).

— Diez
fuente