Stefano,

I really appreciate your help in this ordeal.

I copied your response to Register.  According them, RFCs are now simply
'suggestions'...  Is that true?  I thought they were already mandatory.

The one thing that is still nagging at me is the fact that James is widely
used, and Register.com is not exactly a tiny outfit.  Yet I'm the only
person in the world having this problem (????).  According to what everyone
has said, it would seem EVERY instance of James in the world sending mail to
any domain hosted by Register.com would have the same problem.  I don't see
it.  I don't know any other domains offhand that are hosted by Register.
I'd love to find out that other mx records are actually correct at Register.

In the meantime, apparently two wrongs will have to make a right.  If you
could consider adding the incorrect implementation to deal with screwups
like Register, I'd appreciate it.

Here is their response... I give up....

=================================
Thank you for contacting Register.com.

We understand your position, and sincerely apologize for any inconvenience
this may cause. However, as the email from apache stated, many services
support the aliased mx records we are currently using as the RFCs are still
suggested practices. Until such time that the RFC guidelines become
mandatory, our email services will remain in the manner they are currently
configured for our customers. You can disable the cname check on your end to
have the emails send/receive properly, however we do not have plans to make
changes to our mx records at this time.


-----Original Message-----
From: Stefano Bagnara [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 03, 2006 3:16 AM
To: James Users List
Subject: Re: "Can't find DNS for domain" when domain does exist

JWM wrote:
> Stefano,
> 
> The domain in question is: brandilyncollins.com

# host -t mx brandilyncollins.com
brandilyncollins.com mail is handled by 0 mxmail.register.com.

# host -t a mxmail.register.com.
mxmail.register.com is an alias for rcom-outblaze-com.mr.outblaze.com.
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.41
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.200
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.206
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.207
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.229
rcom-outblaze-com.mr.outblaze.com has address 205.158.62.230

So, it is clear that the mx host name for brandilyncollins.com does not 
have A or RR but instead it only provide a CNAME.

The specification is REALLY clear about this, you can see that they 
provided a full paragraph to say that an hostname used as MX record must 
NEVER be a CNAME (alias)

RFC2181 10.3: "Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value.". If I understand correctly, supporting the CNAME for the MX 
would be AGAINST the rfc.

So the problem is that RFC is extremely clear but Sendmail, postfix, 
qmail, and exim, all support the aliased MXs.
We could consider to add this option to James, too, but don't expect to 
happen soon.
"The Register" is not RFC compliant, so they are not providing a 
compliant DNS service, and you should complain again.

I added an "improvement request" in our issue tracker to remember this 
issue.

Stefano

-----------------------

here is the full 10.3 paragraph from rfc2181 (Clarifications to the DNS 
Specification)

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias.  Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach.  This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable.  It can also
have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer.  This helps avoid needless
extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias.  Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value.  This can cause extra queries, and extra network burden, on
every query.  It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed.  In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to