Mailing List Archive

Subtle delivery issue - BROKEN DNS PTR questions.
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






--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Subtle delivery issue - BROKEN DNS PTR questions. [ In reply to ]
On Tue, Apr 3, 2012 at 8:52 AM, Ron White <exim.ml@riotm.co.uk> 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.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Subtle delivery issue - BROKEN DNS PTR questions. [ In reply to ]
On Tue, Apr 3, 2012 at 6:52 AM, Ron White <exim.ml@riotm.co.uk> 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.

Simple test: set your system resolver to use 8.8.8.8 and 8.8.4.4
instead of whatever DNS resolver it's using now.

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

SOP for doing rDNS for non 8 bit boundaries.

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

No sites should require the forward DNS and the rDNS to be the same.
It's perfectly logical to expect rDNS to resolve to something,
anything, but not to make it match forward DNS.

I still suspect it's your DNS.

Have you verified that you have clean MTU path all the way to the
hosts which are giving you problems? Is there an overzealous firewall
that blocks all ICMP (breaking path mtu discovery)?

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Subtle delivery issue - BROKEN DNS PTR questions. [ In reply to ]
Thank you for the response Todd.

On Tue, 2012-04-03 at 07:36 -0700, Todd Lyons wrote:
> On Tue, Apr 3, 2012 at 6:52 AM, Ron White <exim.ml@riotm.co.uk> 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.
>
> Simple test: set your system resolver to use 8.8.8.8 and 8.8.4.4
> instead of whatever DNS resolver it's using now.
dig @8.8.8.8 +short whub28.webhostinghub.com.
205.134.241.17
205.134.224.208
dig @8.8.8.8 +short whub28.webhostinghub.com.
205.134.224.208
205.134.241.17


>
> > 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.
>
> SOP for doing rDNS for non 8 bit boundaries.
I'm sorry Todd, I don't understand that?

>
> > 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?
>
> No sites should require the forward DNS and the rDNS to be the same.
> It's perfectly logical to expect rDNS to resolve to something,
> anything, but not to make it match forward DNS.
You don't think so?
I used to see anti-spam settings that penalised on this. In fact I think
Postfix can be set to do this:

reject_unknown_reverse_client_hostname
Reject the request when the client IP address has no
address->name mapping.
This is a weaker restriction than the
reject_unknown_client_hostname feature, which requires not only
that the address->name and name->address mappings exist, but
also that the two mappings reproduce the client IP address.
The unknown_client_reject_code parameter specifies the response
code for rejected requests (default: 450). The reply is always
450 in case the address->name lookup failed due to a temporary
problem.
This feature is available in Postfix 2.3 and later.


>
> I still suspect it's your DNS.
It's not my system where this is happening. It is a small number of
remote receiving hosts that defer or reject mail based on this.
Typically running Postfix, Barracuda or sometimes even Postini.
>
> Have you verified that you have clean MTU path all the way to the
> hosts which are giving you problems? Is there an overzealous firewall
> that blocks all ICMP (breaking path mtu discovery)?
See above.
>
> ...Todd
> --
> Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live. -- Martin Golding
>



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Subtle delivery issue - BROKEN DNS PTR questions. [ In reply to ]
On Tue, Apr 3, 2012 at 7:51 AM, exim.ml@riotm.co.uk <exim.ml@riotm.co.uk> wrote:
>> > 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.
>>
>> SOP for doing rDNS for non 8 bit boundaries.
> I'm sorry Todd, I don't understand that?

SOP means Standard Operating Practice, sorry if the acronym didn't
translate well.

When delegating reverse dns to a company, say for example our
64.14.201.0/24 assignment, the registrar can very simply point
201.14.64.in-addr.arpa to our nameservers because it's on an 8 bit
boundary. However, what if we only had 64.14.201.0/25
(64.14.201.0-64.14.201.127) and *you* had 64.14.201.128/25
(64.14.201.128-64.14.201.255). Those are not on an 8 bit boundary.
The registrar cannot give the entire 201.14.64.in-addr.arpa reverse
delegation to us, nor to you (because that would omit the other from
being able to do reverse dns). So you break it up by inserting an
extra octet using either START-END or START/NETMASK. Your buddy's
registrar uses the START-END method.

We also have 216.35.188.112/28, and our ISP delegates it to us with
START/NETMASK method:
119.188.35.216.in-addr.arpa. 3600 IN CNAME 119.112/28.188.35.216.in-addr.arpa.
112/28.188.35.216.in-addr.arpa. 3600 IN NS ns2.ivenue.com.
112/28.188.35.216.in-addr.arpa. 3600 IN NS ns1.ivenue.com.
;; Received 116 bytes from 209.1.222.247#53(dns04.savvis.net) in 1 ms

Then when your resolver chases that 112/28.188.35.216.in-addr.arpa
delegation, it gets the following result from our nameservers:
;; ANSWER SECTION:
119.188.35.216.in-addr.arpa. 2958 IN CNAME 119.112/28.188.35.216.in-addr.arpa.
119.112/28.188.35.216.in-addr.arpa. 8380 IN PTR smtp-webmail.ivenue.com.

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Subtle delivery issue - BROKEN DNS PTR questions. [ In reply to ]
On Tue, 2012-04-03 at 08:46 -0700, Todd Lyons wrote:
> On Tue, Apr 3, 2012 at 7:51 AM, exim.ml@riotm.co.uk <exim.ml@riotm.co.uk> wrote:
> >> > 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.
> >>
> >> SOP for doing rDNS for non 8 bit boundaries.
> > I'm sorry Todd, I don't understand that?
>
> SOP means Standard Operating Practice, sorry if the acronym didn't
> translate well.
>
> When delegating reverse dns to a company, say for example our
> 64.14.201.0/24 assignment, the registrar can very simply point
> 201.14.64.in-addr.arpa to our nameservers because it's on an 8 bit
> boundary.

Now that makes perfect sense! It's obvious now you say it, I can see
exactly why it's done. Penny drops in a bit of a Eureaka moment.

Thank you Todd. Really useful info.

Ron



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/