networking - and - ¿Cómo superar las restricciones CNAME del dominio raíz?
dns cname records and a records (8)
CNAME ''un registro raíz no está técnicamente en contra de RFC, pero tiene limitaciones, lo que significa que es una práctica que no se recomienda.
Normalmente, su registro raíz tendrá múltiples entradas. Digamos, 3 para sus servidores de nombres y luego uno para una dirección IP.
Por RFC:
Si un CNAME RR está presente en un nodo, no debe haber otros datos;
Y por el documento IETF ''Errores comunes de operación y configuración DNS'':
A menudo, administradores inexpertos lo intentan como una forma obvia de permitir que su nombre de dominio también sea un host. Sin embargo, los servidores DNS como BIND verán el CNAME y se rehusarán a agregar otros recursos para ese nombre. Como no se permite que otros registros coexistan con un CNAME, las entradas NS se ignoran. ¡Por lo tanto, todos los hosts en el dominio podunk.xx también son ignorados!
Referencias
- http://tools.ietf.org/html/rfc1912 sección ''2.4 Registros CNAME''
- http://www.faqs.org/rfcs/rfc1034.html sección ''3.6.2. Alias y nombres canónicos
Estamos hospedando muchas aplicaciones web para nuestros clientes. Como es obvio que quieren usar sus propios dominios para referirse a esas aplicaciones, generalmente quieren que cualquier usuario que escriba http://www.customer1.com o http://customer1.com vaya a su aplicación web.
La situación a la que nos enfrentamos es que necesitamos tener la flexibilidad para cambiar las direcciones IP en el futuro cercano. Y no queremos confiar en que el cliente realice el cambio de registro A en sus dominios. Así que pensamos que el uso de CNAMES funcionará, pero a medida que descubramos que CNAME no funcionará para el dominio raíz.
Básicamente:
customer1.com IN CNAME customer1.mycompanydomain.com //this is invalid as the RFC
www.customer1.com IN CNAME customer1.mycompanydomain.com //this is valid and will work
Queremos poder cambiar la dirección IP de customer1.mycompanydomain.com o el registro A y nuestros clientes seguirán este registro sobre el que tenemos control.
en nuestro DNS se verá así:
customer1.mycompanydomain.com IN A 5.5.5.1
¿algunas ideas?
Debe poner un punto al final del dominio externo para que no piense que se refiere a customer1.mycompanydomain.com.localdomain;
Así que solo cambia:
customer1.com IN CNAME customer1.mycompanydomain.com
A
customer1.com IN CNAME customer1.mycompanydomain.com.
Gracias a Sipwiz y MrEvil. Desarrollamos un script PHP que analizará la URL que ingresa el usuario y pegará www hasta la parte superior. (por ejemplo, si el cliente ingresa a kiragiannis.com , se lo redireccionará a www.kiragiannis.com ). De modo que nuestro cliente señala su raíz (por ejemplo, customer1.com a A registro A donde está nuestro redirector web) y luego www CNAME al registro A real administrado por nosotros.
Debajo del código en caso de que estés interesado en nosotros en el futuro.
<?php
$url = strtolower($_SERVER["HTTP_HOST"]);
if(strpos($url, "//") !== false) { // remove http://
$url = substr($url, strpos($url, "//") + 2);
}
$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
$urlPagePath = substr($url, strpos($url, "/"));
$url = substr($url, 0, strpos($url,"/"));
}
$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));
if(strpos($url, ".") !== false) { // get rid of subdomain(s)
$url = substr($url, strrpos($url, ".") + 1);
}
$url = "http://www." . $url . $urlLast . $urlPagePath;
header( "Location:{$url}");
?>
La razón por la cual esta pregunta aún surge a menudo es porque, como mencionaste, de alguna manera alguien que se presume importante escribió que los nombres de dominio RFC sin subdominio frente a ellos no son válidos. Sin embargo, si lees detenidamente el RFC, verás que esto no es exactamente lo que dice. De hecho, RFC 1912 establece:
No te excedas con CNAME. Úselos al renombrar hosts, pero planee deshacerse de ellos (e informe a sus usuarios).
Algunos hosts DNS proporcionan una forma de obtener una funcionalidad similar a CNAME en la zona ápice (el nivel de dominio raíz, para el nombre de dominio desnudo) utilizando un tipo de registro personalizado. Tales registros incluyen, por ejemplo:
- ALIAS en DNSimple
- ANAME en DNS Made Easy
- ANAME en easyDNS
- CNAME en CloudFlare
Para cada proveedor, la configuración es similar: apunte la entrada ALIAS o ANAME para su dominio apex a ejemplo.domain.com, tal como lo haría con un registro CNAME. Dependiendo del proveedor de DNS, un valor vacío o @ Name identifica la zona ápice.
ALIAS o ANAME o @ example.domain.com.
Si su proveedor de DNS no es compatible con dicho tipo de registro y no puede cambiar a uno que sí lo haga, deberá usar la redirección de subdominios, que no es tan difícil, según el protocolo o el software del servidor que necesite hacerlo. .
Estoy totalmente en desacuerdo con la afirmación de que solo lo hacen los "administradores aficionados" o esas ideas. Es un simple "¿Qué necesitan hacer el nombre y su servicio?" tratar, y luego adaptar su configuración DNS para servir esos deseos; Si sus servicios principales son web y correo electrónico, no veo ninguna razón válida por la que dejar caer CNAME de una vez sea un problema. Después de todo, ¿quién preferiría @ subdomain.domain.org sobre @ domain.org? ¿Quién necesita "www" si ya está configurado con el protocolo en sí? No es lógico suponer que el uso de un nombre de dominio raíz no sea válido. http://no-www.org/
Mi empresa hace lo mismo con varios clientes donde alojamos un sitio web para ellos, aunque en nuestro caso es xyz.company.com en lugar de www.company.com. Conseguimos que establezcan el registro A en xyz.company.com para que apunte a una dirección IP que les asignamos.
En cuanto a cómo podría hacer frente a un cambio en la dirección IP, no creo que haya una solución perfecta. Algunas ideas son:
Use un equilibrador de carga NAT o IP y proporcione a sus clientes una dirección IP que le pertenezca. Si la dirección IP del servidor web necesita cambiar, puede hacer una actualización en el NAT o balanceador de carga,
Ofrezca un servicio de alojamiento DNS también y haga que sus clientes alojen su dominio con usted para que pueda actualizar los registros A,
Haga que sus clientes configuren su registro A en un servidor web principal y utilicen un redireccionamiento HTTP para las solicitudes web de cada cliente.
No sé cómo se están saliendo con la suya, ni qué efectos secundarios negativos pueden tener, pero estoy usando Hover.com para alojar algunos de mis dominios, y recientemente configuré el vértice de mi dominio como CNAME allí. Su herramienta de edición de DNS no se quejó en absoluto, y mi dominio se resuelve felizmente a través del CNAME asignado.
Esto es lo que Dig me muestra para este dominio (dominio real ofuscado como midominio.com):
; <<>> DiG 9.8.3-P1 <<>> mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mydomain.com. IN A
;; ANSWER SECTION:
mydomain.com. 394 IN CNAME myapp.parseapp.com.
myapp.parseapp.com. 300 IN CNAME parseapp.com.
parseapp.com. 60 IN A 54.243.93.102
Sipwiz tiene razón, la única forma de hacerlo correctamente es el enfoque híbrido HTTP y DNS. Mi registrador es un revendedor de Tucows y ofrece el reenvío del dominio raíz como un servicio de valor agregado gratuito.
Si su dominio es blah.com, le preguntarán dónde desea que se reenvíe el dominio y usted ingresará en www.blah.com. Asignan el registro A a su servidor apache y automáticamente agregan blah.com como DNS vhost. El vhost responde con un error HTTP 302 al redirigirlos a la URL correcta. Es simple de script / setup y puede ser manejado por low end; de lo contrario, se descartaría el hardware.
Ejecute el siguiente comando para un ejemplo: curl -v eclecticengineers.com
Veo que readytocloud.com está alojado en Apache 2.2.
Hay una manera mucho más simple y más eficiente de redirigir el sitio que no es www al sitio www en Apache.
Agregue las siguientes reglas de reescritura a las configuraciones de Apache (ya sea dentro del host virtual o fuera. No importa):
RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]
O bien, las siguientes reglas de reescritura si desea una asignación de 1 a 1 de las URL desde el sitio que no es www al sitio www:
RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]
Tenga en cuenta que el módulo mod_rewrite debe cargarse para que esto funcione. Por suerte, readytocloud.com se está ejecutando en un cuadro de CentOS, que carga por defecto mod_rewrite.
Tenemos un servidor cliente que ejecuta Apache 2.2 con poco menos de 3.000 dominios y cerca de 4.000 redireccionamientos, sin embargo, la carga en el servidor ronda alrededor de 0.10 - 0.20.