0

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?

dmourati
  • 25,540
  • 2
  • 42
  • 72
  • What are you trying to do? – Michael Hampton Jun 04 '13 at 03: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 04 '13 at 03: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 04 '13 at 06:00

2 Answers2

2

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.

Community
  • 1
Joel K
  • 5,853
  • 2
  • 30
  • 34
  • 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 06 '13 at 05:05
  • gave you some sample code for access to the r53 data -- pretty easy. – Joel K Jun 06 '13 at 05:27
  • Posted my final solution. Thanks again for your help. – dmourati Jun 12 '13 at 02:30
0

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 demetri@mydomain.com -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.

dmourati
  • 25,540
  • 2
  • 42
  • 72