Instances in the same VPC can resolve each other by hostname without any setup. Every subnet has a DNS resolver on its second address after the network address, and every instance uses it. The resolver answers names in its own VPC itself, and relays every other query according to the VPC’s DNS policy.
The resolver handles a query from an instance like this:
- If the hostname is in this VPC, the resolver answers.
- If not, and the DNS policy relays, the upstream servers answer.
- If not, and the DNS policy doesn’t relay, the query is refused.
Key concepts
| Concept | Meaning |
|---|---|
| Internal hostname | Every instance has a hostname derived from its primary private IPv4 address in the internal domain. An instance at 10.0.1.20 answers to ip-10-0-1-20.internal. Because internal is on every instance’s DNS search list, the short name ip-10-0-1-20 works too. |
| Per-VPC resolution | Each VPC resolves only its own instances’ hostnames. Two instances in different VPCs can have the same hostname without conflict, and neither VPC can resolve the other’s. |
| DNS policy | Decides what happens to queries the resolver can’t answer itself: whether they’re relayed at all, and to which upstream servers. A DNS policy belongs to a project, not to one VPC. A project can have several, and one policy can serve several VPCs. If a policy has relaying turned off, every query outside the VPC is refused. |
| Default policy | Each project has exactly one default policy. The platform creates it with your first VPC in the project, pointing at a public resolver with relaying on. Every VPC you create attaches to the project’s default policy at the time. |
What you can do
- Manage DNS policies: create policies, change their servers, attach one to a VPC, change the project default, delete one.