This is a misapplication or misunderstanding of the purpose of the document you are reading.
If your SMTP server uses your own public IP address
This is about a server that uses your own public IP address. AWS IPs do not meet that criterion.
The instructions you followed are for IP address space that you control, or that has been delegated to you by your ISP. They are not applicable to elastic IP addresses. You "don't need to use Route 53," as shown in the quote below -- in this case -- would have been more correctly written here as you can't use Route 53 in this case.
Most of the document does not apply to IP addresses owned/controlled by AWS. The only AWS-allocated public IP addresses that are configurable with custom reverse-DNS are elastic IP addresses, and a different process applies (from the same document) --
If you are using an Elastic IP address for your server, you can configure the reverse DNS record of your Elastic IP address by submitting a Request to Remove Email Sending Limitations (root account credentials required), and you don't need to use Amazon Route 53.
Allocate an elastic IP and and configure an A record, such as smtp.example.com using that Elastic IP... then you can use the request form and AWS support will configure the reverse records for you, matching the A record.
The example IP (192.168.1.2) looks like an internal IP address, is this correct, or should I use the SMTPs public IP?
The example is not applicable to you, but you would always use the public IP address on the Internet. Private addresses are not relevant outside your network.
Why did amazon remove the last two digits from the IP in the hosted zone?
That is how reverse DNS is implemented, when you control an entire block of the size we casually refer to as "Class-C" (a CIDR /24, mask 255.255.255.0, 256 addresses). The reverse record for 203.113.0.1 is 1.0.113.203.in-addr.arpa, which is hostname "1" in the "0.113.203.in-addr.arpa" zone. But not applicable, here.
I answered a similar question on Stack Overflow.
If the DNS server is authoritative for the DNS domain, then there is no way to get him to send DNS requests to this domain to other servers.
This is one of reasons why the best practices recommended not to use the public domain name.
You have only two options with this configuration:
- Publish an authoritative server outside the domain and delegate it (really bad idea).
- Organize the creation on internal authoritative DNS server static copies of external records (as you suggested)
Best Answer
It's not a problem.
Any normal search for
10.in-addr.arpa.will follow the normal chain down from the root and end up at IANA's blackhole name servers. So the only queries for that name that should reach your servers are those specifically and deliberately sent there. If someone gets a problem because of that, they have only themselves to blame.