3

Normally, EC2 public DNS names will resolve to internal IPs from within an EC2 region. However from one EC2 instance, we're seeing these always resolve to public IPs. We have confirmed that it is using the same amazon nameserver as other instances:

This is what we're seeing:

ubuntu@ip-10-203-XXX-XXX:~$ dig A ec2-184-73-XXX-XXX.compute-1.amazonaws.com

; <<>> DiG 9.8.1-P1 <<>> A ec2-184-73-XXX-XXX.compute-1.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44851
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ec2-184-73-XXX-XXX.compute-1.amazonaws.com. IN A

;; ANSWER SECTION:
ec2-184-73-XXX-XXX.compute-1.amazonaws.com. 603721 IN A 184.73.XXX.XXX

;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Fri Jun  7 17:45:58 2013
;; MSG SIZE  rcvd: 76

Why would this not be resolving to the internal IP?

3

1 Answer 1

1

It's obviously been a long time since this happened, so it may not be an issue anymore, but there are a couple details in your dig output that suggest some possibilities.

The long TTL clearly comes from the external DNS view. When you see this working properly, the TTL is 60 seconds. So that's definitely unexpected. The very fast query response indicates that the answer was cached, and that the resolver didn't need to perform a recursive lookup in order to serve your answer.

It's very possible that, once the TTL decrements to zero and the cache expires, that the next query will resolve correctly.

In general, this sort of issue would be good to report to AWS support on forums.aws.amazon.com.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .