On Tue, Apr 3, 2012 at 8:52 AM, Ron White <exim.ml@???> wrote:
> I've been working with a client running Exim on a cheap shared host who
> has been having some odd delivery issues. Normally I don't get too
> involved in these, but it was interesting. It only affects some
> recipients some of the time and the only reason I can find for the
> inconstancy is what appears to be a bit of a hooky DNS set up.
>
> Can someone just give me a logic check here?
>
> The host concerned has a PTR record, it's a bit of a mess, but it's
> there:
> dig -x 205.134.224.208
>
> 208.224.134.205.in-addr.arpa. 17019 IN CNAME
> 208.128-255.224.134.205.in-addr.arpa.
> 208.128-255.224.134.205.in-addr.arpa. 65020 IN PTR
> whub28.webhostinghub.com.
>
> So this basically gives back hostname: whub28.webhostinghub.com.
>
> However, digging this gives two A records/IP's back rotating on a round
> robin:
>
> dig +short whub28.webhostinghub.com.
> 205.134.241.17
> 205.134.224.208
> dig +short whub28.webhostinghub.com.
> 205.134.224.208
> 205.134.241.17
> dig +short whub28.webhostinghub.com.
> 205.134.241.17
> 205.134.224.208
>
> I think this may be a problem with PTR resolution because if the reverse
> lookup for a connecting IP gives the name whub28.webhostinghub.com, but
> the matching double check on that back to an IP gives two records back
> will the average mail resolver see both of these and satisfy the check,
> or will it take the top one only and spot the mismatch between the
> original connecting IP and the RrDNS?
>
> Basically, is this OK or is it sub optimal/likely to break any RFC's?
> To me it looks like a cheap attempt at load balancing / redundancy in
> DNS - but it is probably perfectly legal, even if it may break RrDNS for
> some receiving mail engines.
>
> Any input, reasoning greatly appreciated.
>
> Warm regards
> Ron
>
>
>
>
Hi Ron,
I believe the behavior you are seeing is a 'feature' of DNS that was
intended for Load Balancing, I think this RFC explains or is at least
related to the functionality:
http://tools.ietf.org/html/rfc1794
I don't think this configuration breaks DNS by its very existence, but in
my experience with DNS administrators it seems trivially easy to do by
mistake.
