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

Responder a