Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an IP number associated with an AWS Elastic IP (EIP). I'd like to know, what DNS records in my Route 53 domain are associated with that A record's IP.

In a traditional DNS service, I would run dig -x $EIP and get back a PTR record and be done.

Amazon only allows actual PTR records by filling out some form.

Otherwise, the PTR records point to

The API for Route 53 doesn't seem to support the dig -x approach either. Moreover, the data looks like XML which will make it a bit challenging from the command line.

So, how can I get this data?

share|improve this question
What are you trying to do? – Michael Hampton Jun 4 '13 at 3:08
In this case, provide a list of hostnames/IPs currently provisioned in EC2 for the purposes of input into a periodic portscan. The scan is to audit our security and insure we know what our public facing exposure is. – dmourati Jun 4 '13 at 3:30
How often is it going to happen? This doesn't sound worth automating, especially if it's going to be difficult. You'll spend more time writing the automation than you'll ever save with it. – Ladadadada Jun 4 '13 at 6:00
up vote 2 down vote accepted

Since you say you want to use the data to run a port scan of currently running AWS nodes, why not just collect the IP information by listing your current running AWS instances?

You might have records in DNS that have no current host running, and you might have hosts running that aren't actually in DNS, so I would think an instance list would be a better 'source of truth'.

Here's an example boto script for grabbing a list of instances. boto list instances Some of of the instance parameters is the current external and internal IP addresses for the instance.

If you really want to stick to route53 methods, you can use boto to walk all records in your hosted zone. boto docs for route53 api

$ cat


Simple script to lsit route 53 entries

WARNING: (boto requires credential to be stored in a dotfile for the user)

Contents of ~/.boto are below:
aws_access_key_id = ABC123DEF456
aws_secret_access_key = NOC4KE4U


from boto.route53.connection import Route53Connection
route53 = Route53Connection()
results = route53.get_all_hosted_zones()
for zone in results['ListHostedZonesResponse']['HostedZones']:
    print "========================================"
    print "Zone:",zone['Name']
    zone_id = zone['Id'].replace('/hostedzone/', '')
    for rset in route53.get_all_rrsets(zone_id):
        print "\t%s: %s %s @ %s" % (, rset.type, rset.resource_records, rset.ttl)

$ ./
Zone: NS [u'', u'', u'', u''] @ 172800 SOA [u' 1 7200 900 1209600 86400'] @ 900 PTR [u''] @ 300 A [u''] @ 300

Good luck.

share|improve this answer
Yes, I'm starting with the instance list as you suggest, coming from ec2-describe-addresses. I'd like to verify a 1-to-1 map between DNS entries and instances. A sort of audit if you will as that's what this is, i.e., input to nmap. – dmourati Jun 6 '13 at 5:05
gave you some sample code for access to the r53 data -- pretty easy. – Joel K Jun 6 '13 at 5:27
Thanks for the update Joel. – dmourati Jun 6 '13 at 5:30
Posted my final solution. Thanks again for your help. – dmourati Jun 12 '13 at 2:30

I decided that instead of an equivalent, I really wanted dig -x working for all my amazon EIPs. Here's how I did it.

First, I created a new AWS instance for this purpose called ns1. On ns1, I installed the following:

  1. cli53
  2. r53*
  3. bind9
  4. h2n

With the software installed, I wrote a few custom shell scripts to do the lifting.

First, cli53-to-hosts generates a dynamically generated version of an /etc/hosts file. The work is done via cli53 export followed by some sorting for organization.

Similarly, cli53-to-networks makes a lists of networks for which I need to generate zones. Because these are not real zones in the global namespace, I cheated and created them at the /16 netmask level, e.g., 50.18, 107.23, etc.

With a hosts file and a list of networks to run DNS for, the h2n script (from O'Reilly's DNS and BIND book) finishes the work. It writes out a named.conf file and a seriers of zone files for the reverse dns.

All this is called out of cron nightly via a final script called configure-dns:

. ~/.profile 
cli53-to-hosts > /usr/local/etc/hosts 
cli53-to-networks > /usr/local/etc/h2n/h2n.conf
cd /etc/bind
h2n -N -f /usr/local/etc/h2n/h2n.conf -H /usr/local/etc/hosts -d -u -h -p

The final result:

mv-m-dmouratis:~ dmourati$ dig -x

; <<>> DiG 9.8.3-P1 <<>> -x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55551
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available




;; Query time: 32 msec
;; WHEN: Tue Jun 11 19:21:46 2013
;; MSG SIZE  rcvd: 93

It was certainly a good deal of work, but was strangely satisfying. I guess I'm a nut for working PTR records and could not stomach giving up a successful track record of always having them working.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.