Generally what they care about is that the rDNS result resolves back to the original IP. So a typical setup would look like this:
www.example.com
and www.yourdomain.example
both resolve to 192.0.2.1.
- The PTR for 192.0.2.1 is
myhost1.yourdomain.example
.
myhost1.yourdomain.example
resolves to 192.0.2.1.
I believe most spam filters consider that to be an appropriate rDNS configuration.
If, however, you have separate IP addresses for each website and mail server running on your box so that email from example.com
and yourdomain.example
appear to come from different IP addresses (and that would be a really bizarre email setup), then the forward and reverse DNS for that domain/IP combination should just point back to each other:
example.com
email comes from 192.0.2.2
- PTR for 192.0.2.2 is
example.com
.
example.com
resolves to 192.0.2.2
Jeff, I disagree, load balancing does not imply redundancy, it's quite the opposite in fact. The more servers you have, the more likely you'll have a failure at a given instant. That's why redundancy IS mandatory when doing load balancing, but unfortunately there are a lot of solutions which only provide load balancing without performing any health check, resulting in a less reliable service.
DNS roundrobin is excellent to increase capacity, by distributing the load across multiple points (potentially geographically distributed). But it does not provide fail-over. You must first describe what type of failure you are trying to cover. A server failure must be covered locally using a standard IP address takeover mechanism (VRRP, CARP, ...). A switch failure is covered by resilient links on the server to two switches. A WAN link failure can be covered by a multi-link setup between you and your provider, using either a routing protocol or a layer2 solution (eg: multi-link PPP). A site failure should be covered by BGP : your IP addresses are replicated over multiple sites and you announce them to the net only where they are available.
From your question, it seems that you only need to provide a server fail-over solution, which is the easiest solution since it does not involve any hardware nor contract with any ISP. You just have to setup the appropriate software on your server for that, and it's by far the cheapest and most reliable solution.
You asked "what if an haproxy machine fails ?". It's the same. All people I know who use haproxy for load balancing and high availability have two machines and run either ucarp, keepalived or heartbeat on them to ensure that one of them is always available.
Hoping this helps!
Best Answer
Here is our solution that we use on a Management Webserver (not exactly the solution you requested, but we decided that this would be tho only working solution in our case)
Steps to reproduce:
transport.py
file provided by pywinrm in order to make kerberos work with the script provided below. (Unfortunately I can't seem to find the line anymore... sry) (You can skip this it you want to authenticate via username and password. Kerberos delegation is still needed if you have to authenticate to the dns server. You can only skip this if you open up winRM on the DNS server (NOT RECOMENDED!))kinit -f -t /path/to/krb5.keytab -k username@DOMAIN ; LANG=\"C.UTF-8\" ; /the/script/provided/below.py -m mywinrmhost.example.org -c "dnscmd.exe dns dns server.example.org /recordadd example.org entire.example.org /CreatePTR newentrie 10.20.30.40"