I am trying to set up a hosting company. The hosting company is going to have a client with the domain widgets.de
The name of my company is hostingcompany.de. The name servers I am setting up are called ns1.hostingcompany.de and ns2.hostingcompany.de
In the zone file for widgets.de, I have
NS ns1.hostingcompany.de.
NS ns2.hostingcompany.de.
In the zone file for hostingcompany.de, I have
hostingcompany.de 300 IN NS ns-110.awsdns-13.com
hostingcompany.de 300 IN NS ns-1130.awsdns-15.com
ns1.hostingcompany.de. 300 IN A 34.65.125.52
ns2.hostingcompany.de. 300 IN A 52.43.124.76
Also, I created two more hosted zones per Amazon's guidance
124.43.52.in-addr.arpa.
NS ns-2035.awsdns-62.co.uk.
SOA ns-2035.awsdns-62.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
34 PTR ns1.hostingcompany.de
and
76.124.43.in-addr.arpa.
NS ns-799.awsdns-35.net.
SOA ns-2435.awsdns-62.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
52 PTR ns2.hostingcompany.de
However, this is not working. When I try to submit these zone files, RIPE rejects them saying that ns1.hostingcompany.de and ns2.hostingcompany.de do not exist as objects. I think I have to do something with PTR records, but I don't know what.
PTR records are usually necessary if you are running a DNS or SMTP server to provide some proof that you are legitimate. I found this article to be quite illuminating.
I think the answer to this question is found towards the bottom of the link in the question. You have to fill out a form and AWS will create the PTR record for you. Creating a hosted zone in Route 53 for the pointer record does not appear to have any effect. Nothing in the RFC prohibits the owner of the public IP address from allowing a customer to create a PTR record for that public IP address. Although AWS could allow customers to create PTR records for their Elastic IP addresses, they do not.
There are a lot of articles discussing how you need to create your own hosted zones for the PTR records, such as but not limited to Amazon's own article the question linked to. You can definitely do this for private IP addresses if you are running a DNS server for a private network. However, if you are running a publicly available DNS or SMTP server on a public IP address, more vetting is required.
In order to verify that the records are set up correctly, you have to get an answer to:
dig -x 34.65.125.52 (must answer ns1.hostingcompany.de)
Unless you do this, the TLD registrar will not accept your nameserver, and your SMTP mail will probably be rejected as spam.
In addition to the above, another problem was that these lines should also be included in the zone file for hostingcompany.de
hostingcompany.de. 300 IN NS ns1.hostingcompany.de.
hostingcompany.de. 300 IN NS ns2.hostingcompany.de.
It is still unclear to me why the top level domain requires that the domains own nameservers are listed as being nameservers for its own domain, but this does appear to be a requirement for some top-level domains. After correcting the above problems, everything works.
I spent a long time trying to track down the above problems, and it did not seem to be documented anywhere, so I hope this helps someone. I also found this RFC to be quite interesting and informative. It is always good to read stuff written by the authorities.