FQDN's and mail MX's

Jim Reid jim at rfc1035.com
Sat May 27 09:05:46 UTC 2000


>>>>> "Ray" == Ray Bush <rbush at scryptography.com> writes:

    >> >>>>> "Ray" == Ray Bush <rbush at scryptography.com> writes:
    >> 
    Ray> Please help us settle a bit of an arguement here.  Should (as
    Ray> in does it need to be) mail mx's be fully qualified domain
    Ray> names?
    >>  Didn't you try reading RFC1034? I quote:
    >> 
    >> MX a 16 bit preference value (lower is better) followed by a
    >> host name willing to act as a mail exchange for the owner
    >> domain.
    >> 
    >> To the RDATA part of an MX record should have a hostname after
    >> the preference value. That hostname needs to have an A record
    >> somewhere else in the zone file (or in somebody else's zone
    >> file if it belongs\

    Ray> So there is no matching PTR record need? 

Whether there's a PTR record or not for the hostname is irrelevant to
the specification of an MX record. Please re-read RFC1034 and RFC1035.
The target of an MX record *must* exist as an A record. That's it.

    Ray> Is there a chance of problems when there is no such matching
    Ray> PTR record?  If so what kinds of problems may occur?

Some idiot mail software might like to do a reverse lookup and get
upset if there's no PTR record or the name returned by a PTR record is
different from the name that was supplied when the sending system said
HELO at the start of the SMTP session. If so, they're broken and
that's their problem, not yours.

Having said that, hostnames should have corresponding PTR records for
their IP addresses in the appropriate reverse zones. There's no
requirement in the DNS for this. However it's the Right Thing to do.
Every IP address you use should have exactly one PTR record which
contains the fully qualified domain name of the host that has that IP
address. [Again this is not demanded by the DNS, but is simple common
sense.] And anyway some network services - like the Unix r- protocols
- do a forward lookup of the name returned by the reverse lookup in a
half-hearted attempt to authenticate the client host that's
connecting.

    Ray> If say there is a PTR record but it maps to a different name
    Ray> (that does have an A  record).

See above.

    Ray> Perhaps FQDN is not the right term as i do not consider a
    Ray> name to be in that category when the forward A record does
    Ray> not match the PTR record.  Am i incorrect in my usage?

Yes. A FQDN is a name - any name - that is complete. The name doesn't
even have to represent a hostname. "scryptography.com." is a FQDN. It
might even be a hostname. "26.40.213.24.in-addr.arpa." is also a FQDN.



More information about the bind-users mailing list