Home / server / Questions / 512992
Accepted
dmourati
Asked: 2013-06-04 19:03:17 +0800 CST

Dig -x equivalent for AWS Route 53

  • 772

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 amazonaws.com.

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?

domain-name-system

2 Answers

  1. Best Answer

    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 list-r53.py

#!/usr/bin/python

"""
Simple script to lsit route 53 entries

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

eg.
Contents of ~/.boto are below:
[Credentials]
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.name, rset.type, rset.resource_records, rset.ttl)

$ ./list-r53.py
========================================
Zone: serverfault.com.
    serverfault.com.: NS [u'ns-1638.awsdns-12.co.uk.', u'ns-699.awsdns-23.net.', u'ns-301.awsdns-37.com.', u'ns-1459.awsdns-54.org.'] @ 172800
    serverfault.com.: SOA [u'ns-1638.awsdns-12.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400'] @ 900
    192.168.1.1.serverfault.com.: PTR [u'sample.serverfault.com.'] @ 300
    sample.serverfault.com.: A [u'192.168.1.1'] @ 300

    Good luck.

    • 2

  2. 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 myzone.com followed by some sorting for organization.

    Similarly, cli53-to-networks makes a lists of networks for which I need to generate in-addr.arpa 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:

    #!/bin/bash
. ~/.profile 
cli53-to-hosts > /usr/local/etc/hosts 
cli53-to-networks > /usr/local/etc/h2n/h2n.conf
cd /etc/bind
h2n -N 255.255.0.0 -f /usr/local/etc/h2n/h2n.conf -H /usr/local/etc/hosts -d mydomain.com -u [email protected] -h ns1.mydomain.com -p mydomain.com

    The final result:

    mv-m-dmouratis:~ dmourati$ dig -x 50.18.205.42 @ns1.mydomain.com

; <<>> DiG 9.8.3-P1 <<>> -x 50.18.205.42 @ns1.mydomain.com
;; 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

;; QUESTION SECTION:
;42.205.18.50.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
42.205.18.50.in-addr.arpa. 86400 IN PTR bounce.mydomain.com.

;; AUTHORITY SECTION:
18.50.in-addr.arpa. 86400   IN  NS  ns1.mydomain.com.

;; Query time: 32 msec
;; SERVER: 54.218.3.75#53(54.218.3.75)
;; 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.

    • 0