[Pdns-users] Reverse Lookup zone subnetted

[Alan Hodgson]

On Fri, 2019-07-19 at 14:52 +0000, bryantz-pdns at zktech.com wrote:
> Alan
> 
> Where we are getting into issues is that customers we host e-mail
> servers for are having issues as some email service providers appear
> to be forcing their reverse lookups directly against our powerdns
> servers.
> 
>  I don't know why they are doing this, but we get complaints that
> because we only host the fake reverse lookup to handle the forward
> from our upstream data center. These servers think there is no
> reverse lookup. 
> 
> Did we make a mistake with using powerdns where it does not support
> recursive queries. We thought this would be great for security and
> performance, but now it looks like it is biting us as we can't pass
> the query to our upstream to get passed back. 
> 
> 

I'm not sure why you're seeing problems. You should get rid of the
multiple PTR records and see if that helps. 1 IP address, 1 PTR - lots
of software will query PTR and only use the first result, and you can't
control ordering. And actually, I'm looking at your forward zone and
mail.granddial.com doesn't have an A record, it's also a CNAME. I would
suggest that your single PTR should point to the one true name of the
server, which in this case appears to be customermail.granddial.net.

Otherwise I don't see how remote servers would even find your servers
to query unless they're following the CNAME, so your problem as
described doesn't seem to make sense. You might need to track down
further what's really happening. I guess in the worst case you could
just ask your upstream to put real PTR records in their reverse zone
for any hosted mail servers instead of CNAMEs.

Having separate authoritative and recursive DNS is best practice and
also has nothing to do with any issues you're seeing, I don't think. I
mean I don't see how running BIND in this situation would have any
different result. Any real queries coming in wouldn't have the
recursion desired flag set anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190719/2e8d335d/attachment.html>