Re: Re:[OT] CNAMEs en MX [ era Servidor de correo de backup ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ya sabes que hay gente que por ser papistas lo son más que el papa, en los rfc
no es que no haya ninguna referencia con MUST ( sería la clave de oblicación
absoluta ) es que no hay ninguna referencia que use SHOULD o SHOULDN'T ....
en el fondo es como todo, cada uno actua como considera necesario sin darles
muchas más vueltas.....
El aviso que da nslookup por ejemplo yo lo consideraría un recordatorio
agresivo más que una queja ;-))
un saludo
Victor
On Tuesday 08 April 2003 10:43, Angel Luis Mateo Martínez wrote:
> Tienes razón en lo que comentas de la duplicación de consultas con
> CNAMES y los problemas de consistencias que puede originar, que por
> cierto, he sufrido alguna vez :-(. De hecho, estoy de acuerdo.
>
> Lo que no entiendo es que en referencias sobre configuraciones de
> servidores de correo es habitual encontrar (al menos, yo me lo he
> encontrado varias veces) que el MX no debería apuntar a un CNAME, y yo
> entiendo que esta "obligación", a mi entender, no debería ser más que
> una recomendación.
>
> El mar, 08 de 04 de 2003 a las 10:20, Victor Calzado Mayo escribió:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hola
> >
> > On Tuesday 08 April 2003 09:02, Angel Luis Mateo Martínez wrote:
> > > El lun, 07 de 04 de 2003 a las 23:49, Manuel Samper escribió:
> > > > Aaggh! que patinazo. Borra eso de la IP; un registro MX siempre debe
> > > > contener un "hostname" (que debe poder resolver a una IP con un
> > > > registro A, por supuesto).
> > >
> > > Esta es una pregunta que siempre me he hecho... ¿por qué el MX debe
> > > apuntar a un registro A? ¿Por qué no debe apuntar a un CNAME?
> >
> > Realmente podrías darle dos visiones ( y es sólo una opinión ) y en el
> > fondo ambas están muy relacionadas una con otra.
> >
> > -Muchas escuelas de DNS defienden la utilización de entradas A para todo
> > evitando la utilización de CNAMES, por un lado te ahorrarías la busqueda
> > extra que necesitaras para resolver la entrada A del nombre del que es un
> > "alias" la entrada que has consultado, y por otro te asegurarías de no
> > introducir inconsistencias en un servidor DNS al modificar una entrada A
> > sin darte de cuenta de que puede tener multiples CNAMEs apuntando a ella,
> > con lo que se rompería la relación ya que tendrías un CNAME de una
> > entrada que no existe con lo que nunca se podrá resolver. Aún así el uso
> > del CNAME está muy extendido porque muchas escuelas consideran sucio el
> > uso de multiples entradas A contra una misma ip ( preguntas como ¿quién
> > se queda el PTR de la entrada? y busqueda de configuraciones más
> > limpias.... )
> >
> > -Si esto lo llevas al mundo del SMTP y la resolución de MX ( después
> > tienes un pequeño cut&paste del rfc 2821 (smtp) y una referencia del 974
> > (mail routing) aún cuando nada impide que las entradas MX puedan ser
> > CNAMEs en ambos puedes extraer las dos conclusiones anteriores, enviar
> > correo a un CNAME requiere una busqueda extra en el DNS y la
> > inconsistencia en las entradas MX puede generar mail loops que pueden
> > traer complicaciones.....
> >
> > Si te fijas en el rfc 2821 ( smtp ) incluso en sus ejemplos hacen
> > referencia al uso de CNAMEs en las entradas MX:
> >
> >
> > 2.3.5 Domain
> >
> > A domain (or domain name) consists of one or more dot-separated
> > components. These components ("labels" in DNS terminology [22]) are
> > restricted for SMTP purposes to consist of a sequence of letters,
> > digits, and hyphens drawn from the ASCII character set [1]. Domain
> > names are used as names of hosts and of other entities in the domain
> > name hierarchy. For example, a domain may refer to an alias (label
> > of a CNAME RR) or the label of Mail eXchanger records to be used to
> > deliver mail instead of representing a host name. See [22] and
> > section 5 of this specification.
> >
> > .....
> >
> > En la sección 5 tampoco se declara como estricta la necesidad de que sea
> > una entrada A....
> >
> > 5. Address Resolution and Mail Handling
> >
> > Once an SMTP client lexically identifies a domain to which mail will
> > be delivered for processing (as described in sections 3.6 and 3.7), a
> > DNS lookup MUST be performed to resolve the domain name [22]. The
> > names are expected to be fully-qualified domain names (FQDNs):
> > mechanisms for inferring FQDNs from partial names or local aliases
> > are outside of this specification and, due to a history of problems,
> > are generally discouraged. The lookup first attempts to locate an MX
> > record associated with the name. If a CNAME record is found instead,
> > the resulting name is processed as if it were the initial name. If
> > no MX records are found, but an A RR is found, the A RR is treated as
> > if it was associated with an implicit MX RR, with a preference of 0,
> > pointing to that host. If one or more MX RRs are found for a given
> > name, SMTP systems MUST NOT utilize any A RRs associated with that
> > name unless they are located using the MX RRs; the "implicit MX" rule
> > above applies only if there are no MX records present. If MX records
> > are present, but none of them are usable, this situation MUST be
> > reported as an error.
> >
> > Tampoco aclara mucho el rfc974 ( Mail routing and the domain system ),
> > aunque verás que de ahí si puedes sacar conclusiones sobre el uso de
> > CNAMEs en las entradas MX.
> >
> > Evidentemente es sólo una opinión
> >
> > un saludo
> > Victor
> >
> >
> >
> > - --
> > - --
> > Abril
> > Uno de los peores meses para andar metiendo al mundo en guerras absurdas
> > El resto de meses del mismo tipo son: Enero, Febrero, Marzo, Mayo, Junio,
> > Julio, Agosto, Septiembre, Octubre, Noviembre y Diciembre.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.1 (GNU/Linux)
> >
> > iD8DBQE+koZCEzqHF8R72ekRAuwYAJwKk11ts+jpzB9lxKsbBiJ14zOHdgCgnzD0
> > xhb2/EM6WardwGHqzi8zX5Q=
> > =PgCz
> > -----END PGP SIGNATURE-----
- --
- --
Abril
Uno de los peores meses para andar metiendo al mundo en guerras absurdas
El resto de meses del mismo tipo son: Enero, Febrero, Marzo, Mayo, Junio,
Julio, Agosto, Septiembre, Octubre, Noviembre y Diciembre.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+ktCMEzqHF8R72ekRAqJLAKClsPoDXV/vzG7ZKvew544gSVlV1ACcCnQg
jyQfYtIMX8EEBTDEV1nZG5U=
=m0Xt
-----END PGP SIGNATURE-----
Reply to: