Jorge Godoy wrote: > "Andre Pli" <[EMAIL PROTECTED]> writes: > > >>Porque usar sempre A e não CNAME? >>Isso foi uma conveção feita pelo pessoal, ou está ecrito mesmo na >>documentação dos servidores de DNS ou no servidores de email (qmail, >>sendmail, postfix). > > > É uma convenção, evita loops e exige menos tráfego já que há apenas uma > requisião ao servidor DNS.
Realmente, ai existe um problema maior do que uma convencao, que acabou gerando outra convencao hehe. Existe um conflito entre a RFC1912 http://www.faqs.org/rfcs/rfc1912.html Que diz: Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged: podunk.xx. IN MX mailhost mailhost IN CNAME mary mary IN A 1.2.3.4 [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files. Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names. E a propria RF 1034 que diz o acima mencionado na proprio RFC 1912. Entao uma diz que nao deve haver em qualquer situacao registro MX que aponte pra CNAME (nem como outros RR, como NS...), e a outra diz que "nao deveria haver" para evitar resolucao adicional do servidor DNS, ou seja descobrir pra onde o CNAME resolve alem de saber que trata-se de um CNAME (no minimo 1 query recursiva a mais). Por outro lado a RFC 1123 http://www.faqs.org/rfcs/rfc1123.html na secao 5.2.2 diz que os registros MX *nao* devem ser CNAME ou qq outro tipo de apelido, mas um pouco antes e um pouco abaixo menciona que esse comportamento deve apenas ser evitado. Ahn, entao essa RFC contradiz com ela mesmo, dando a entender antes que deve-se evitar CNAME no MX e depois dizendo que isso nao deve jamais acontecer. Ja a RFC 974 que diz sobre roteamento de e-mail (e que devemos dar mais atencao portanto) diz que pode existir mas deve ser evitado, e que alem de CNAME o registro MX pode ser um WKS (Well Known Service). http://www.faqs.org/rfcs/rfc974.html Mas entao atente que essa RFC e de Janeiro de 1986. E em Outubro de 1989, 3 anos depois, a RFC 1123 http://www.faqs.org/rfcs/rfc1123.html Torna o registro WKS "deprecated" (descontinuado), mas nao ha revisao sobre a RFC 974 que saiba que WKS e descontinuado nem que tenha qualquer informacao mais valiosa sobre o uso de CNAME. Bom neh? Entao temos uns bons pares de RFCs se contradizendo, o que nao e de todo mal quando percebe-se que as vezes uma emsma RFC se contradiz sobre esse assunto hehe (ou seja pode ser pior...). O resultado? Bom, alguns dizem que em alguns aspectos o Qmail nao cumpre a RFC (mas qual delas?) e em outros aspectos e o Postfix que nao cumpre, ou o Sendmail (mesma pergunta...), bem-vindo a Internet neh? Quem tiver coragem que tente organizar a bagunca... Mas na pratica alguns provedores simplesmente negam-se a entregar e-mail se o seu registro MX nao for uma entrada A, (AOL era assim, UOL/BOL ja tiveram esse comportamento tbm, nao sei se ainda o tem hj pois eu nunca deixo um MX apontando pra CNAME). Ou seja alguns geram problema, outros nao. Em todos os casos os que geram problema e quando MX nao eh uma entrada A. Entao pra evitar, sugiro adotar a convencao de apenas usar registros A no MX. >>E você saberia dizer como eu configuro um servidor de qmail como MX >>secundário?? Ridiculamente simples. Basta adicionar o dominio no rcpthosts ou no morercpthos do seu qmail/control/ do servidor secundario. Ele aceitara todas as mensagens desse dominio, e tentara entrega-las assim que o MX com maior prioridade (menor valor do campo pri no registro MX) estiver disponivel, mantendo-as na fila ate que isso aconteca. > > > Desculpe, eu *abomino* o Qmail. > > > Sds, -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" _______________________________________________ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br