Public Reverse DNS entries for Multiple domains

  • Thread starter Thread starter Rob Huseman
  • Start date Start date
R

Rob Huseman

I would appreciate some help in understanding how to
accomplish a task. I have read through most of the
microsoft documentation on reverse DNS and do not
understand how to apply it to my specific situation. I
have a public DNS server that only serves to provide our
public DNS for our domain and for several customer
domains. While we have our own mail server, our customers
also have their own mail servers. We accept their mail
into our public smpt server and then relay it into their
networks. The problem now comes with the new policy of
many mail servers that they will not accept mail unless
the sending server has the reverse dns that correlates
properly to the sending server. We need for our server (I
think) to have multiple identities on the reverse DNS
response. I have already had the proper settings created
by our ISP and the reporting agencies (dnsreport.com,
dnsstuff.com) all show that reverse DNS is working back to
our server. I have created what I thought to be the
proper setup for the pointers... but all of the public
utilities still say we are not configured correctly. So,
I need for our domain and for several customer domains to
properly respond with the reverse lookups. Does not seem
like it should be that difficult... but everything I have
read seems to be more concerned with single domain lookups
being resolved and nothing refers to an ISP style
implementation where we need to handle this for several
different domains. Any help would be greatly appreciated.
 
Rob Huseman said:
I would appreciate some help in understanding how to
accomplish a task. I have read through most of the
microsoft documentation on reverse DNS and do not
understand how to apply it to my specific situation. I
have a public DNS server that only serves to provide our
public DNS for our domain and for several customer
domains. While we have our own mail server, our customers
also have their own mail servers. We accept their mail
into our public smpt server and then relay it into their
networks. The problem now comes with the new policy of
many mail servers that they will not accept mail unless
the sending server has the reverse dns that correlates
properly to the sending server.
Click to expand...

Here is the KEY and the root of a common misconception.
Your "email server" has ONE name (as an email server) and this does
not necessarily relate to the email domains it services -- it cannot relate
(easily) to more than one in any case.

ISPs do this successfully, all the time.

The server (machine) has a name and an IP. The reverse records must
point from the IP back to the SERVER name.

If you set it up to receive email, then the "email domain names" can be
totally unrelated to the above. The EMAIL server will have a name it
reports when SENDING email, and that must be the server name above
which is included in the reverse record.

Example: My email server is mail2.learnquick.com, with reverse record.
My server handles incoming email for learnquick.com AND for learnquick.org
(and other email domains we won't list.)

When I configured that server, it was told to "report" itself as
mail2.learnquick.com
but this could just as easily have been "mailserver12.MyISP.com" IF the
appropriate records were configured this way.

The confusion arises from confusing the TWO functions of an email server:
Receiving email
Sending email.
 
In Rob Huseman <[email protected]> posted a question
Then Kevin replied below:
: I would appreciate some help in understanding how to
: accomplish a task. I have read through most of the
: microsoft documentation on reverse DNS and do not
: understand how to apply it to my specific situation. I
: have a public DNS server that only serves to provide our
: public DNS for our domain and for several customer
: domains. While we have our own mail server, our customers
: also have their own mail servers. We accept their mail
: into our public smpt server and then relay it into their
: networks. The problem now comes with the new policy of
: many mail servers that they will not accept mail unless
: the sending server has the reverse dns that correlates
: properly to the sending server. We need for our server (I
: think) to have multiple identities on the reverse DNS
: response. I have already had the proper settings created
: by our ISP and the reporting agencies (dnsreport.com,
: dnsstuff.com) all show that reverse DNS is working back to
: our server. I have created what I thought to be the
: proper setup for the pointers... but all of the public
: utilities still say we are not configured correctly. So,
: I need for our domain and for several customer domains to
: properly respond with the reverse lookups. Does not seem
: like it should be that difficult... but everything I have
: read seems to be more concerned with single domain lookups
: being resolved and nothing refers to an ISP style
: implementation where we need to handle this for several
: different domains. Any help would be greatly appreciated.

Did you create the Reverse lookup zone, with the name of the CNAME that it
is delegated to you by?
Different ISPs use different ways of creating the delegated CNAME some use
the netblock ID some use the Netblock name. Example:
Say your Public Netblock is 192.168..1.0/29 (I know this is private but you
get the picture) there are two usual ways they do thisIt may be:
0/29.1.168.192.in-addr.arpa.
or
0.1.168.192.in-addr.arpa.
Make this the name of your actual reverse lookup zone. then the PTR records
are delegated to you by a CNAME like this, depending on the way it is
delegated:

For 192.168.1.1
in your 0/29.1.168.192.in-addr.arpa zone you create the PTRs like this:
1 PTR server.domain.com

or in the 0.1.168.192.in-addr.arpa. zone:
1 PTR server.domain.com

And so on for each delegated name.
If you look at the output from www.dnsstuff.com reverse lookup you should be
able to figure out what name the zone was delegated by, you don't give your
IP so I cannot tell you exactly.

But if it is the same domain that is your email in this post. (assinet.com)
The entire subnet is delegated to you, create this reverse lookup zone:
243.21.208.in-addr.arpa.
Then these two PTR records for your mail servers.
10 PTR mail.assinet.com
15 PTR ts-wks-01.assinet.com

Here is how your DNS is answering now:
Answer:
208.21.243.10 PTR record: ntfs1.10.243.21.208.in-addr.arpa. [TTL 3600s]
[A=208.21.243.10]
Answer:
No PTR records exist for 208.21.243.15.
 
RH> We accept their mail into our public smpt server and
RH> then relay it into their networks. The problem now
RH> comes with the new policy of many mail servers that
RH> they will not accept mail unless the sending server
RH> has the reverse dns that correlates properly to the
RH> sending server.

Which (a) is a daft policy that achieves nothing in the end, and (b) has
nothing to do with your previous sentence where you state that your concern is
your machines _receiving_ mail, not sending it.

RH> I have already had the proper settings created by our
RH> ISP and the reporting agencies (dnsreport.com,
RH> dnsstuff.com) all show that reverse DNS is working back
RH> to our server. I have created what I thought to be the
RH> proper setup for the pointers... but all of the public
RH> utilities still say we are not configured correctly.

Those two sentences contradict each another. Either the agencies say that
things are working, or they say that things are not configured correctly.
Which is it ?

RH> everything I have read seems to be more concerned with
RH> single domain lookups being resolved and nothing refers
RH> to an ISP style implementation where we need to handle
RH> this for several different domains.

That's because your notion of "an ISP style implementation" is an incorrect
one. Whilst several entities are foolish enough to employ reverse lookups,
and even double reverse lookups, on SMTP Relay client IP addresses, none are
quite daft enough to impose the further restriction that the domain name, to
which the client IP address maps, be anything to do with anything else.
 
Back
Top