-----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-----
