Create and manage private Domain Name System (DNS) zones .
Private DNS allows you to use your own private DNS domain names and fully manage the associated zones and records to provide hostname resolution for your applications running within and between virtual cloud networks (VCNs ), as well as your on-premises or other private network. Private DNS also provides DNS resolution across networks (for example, another VCN within the same region, cross region, or external network). Private DNS can be managed in the OCI DNS API and Console.
Resources used in private DNS
- Private DNS Zones: Private DNS zones contain DNS data only accessible from within a virtual cloud network (VCN) such as private IP addresses. A private DNS zone has similar capabilities to an internet DNS zone, but provides responses only for clients that can reach it through a VCN. Each zone belongs to a single view.
- Private DNS Zone Records: Different record types are supported for global and private DNS. See Supported Resource Records.
- Private DNS Views: A private DNS view is a collection of private zones. The same zone name can be used in multiple views, but zone names within a view must be unique.
Private DNS Resolver: A VCN-dedicated private DNS resolver contains the configuration that determines responses to DNS queries within the VCN. Views on the resolver determine the zone and record data applicable for resolution. Resolver endpoints on the resolver provide additional ingress and egress to the default ingress on 169.254.169.254. For more information, see Private DNS resolvers.
- Private DNS Resolver Endpoint: Use resolver endpoint resources to set up ingress and egress in the VCN. Resolver endpoints consume IP addresses in the subnet you create it in. A corresponding VNIC is created for each resolver endpoint.
- VCN: When you create a VCN, a dedicated resolver is also automatically created.
- Subnet: A subnet within a VCN is used when creating resolver endpoints. IP addresses from the subnet are consumed for listening and forwarding addresses.
- Network Security Group (NSG): Optionally, you can configure a list of network security groups for resolver endpoints. NSGs control ingress and egress traffic to and from the resolver endpoint.
See Private DNS resolvers. in the Networking documentation for more information about VCN resources.
Some private DNS resources, such as zones and views, are "protected". Protected resources are managed automatically by Oracle. You can view protected resources, but your ability to modify them is limited. All VCN-dedicated resolvers are protected. Protected resources do not count towards your service limits or quotas.
Each VCN-dedicated resolver has a protected default view. You can add your own zones to the default view, but there are restrictions on zone names to avoid collisions with protected zones. If a resolver is deleted, and its default view contains non-protected zones, then the default view will be converted to a non-protected view instead of being deleted. You can create and attach a view to a resolver in addition to the default view, so that their zones are resolvable in the VCN.
Configuration and Resolution
You can create a full or partial domain tree. A view can be used by any number of resolvers , and share private DNS data across VCNs within the same region. You can use these zones for split-horizon DNS because the same zone name can be used on a private zone and an internet zone. Different answers can be served for public queries and private queries from within your VCN.
The resolver listens on 169.254.169.254 by default. You can choose to define resolver endpoints for additional ingress and egress. A listening resolver endpoint consumes one IP address for listening within the specified subnet . A forwarding resolver endpoint consumes two IP addresses - one for listening and one for forwarding. Before you create a resolver endpoint, ensure that there are enough available IP addresses in your subnet. IPV6 is not currently supported.
Add rules to define the logic for answering queries. Currently, the only supported rule type is FORWARD. This rule conditionally forwards a query to a destination IP based on client IP or target QNAME . The destination IP address can be for an on-premise setup, private network, or listening resolver endpoint in a different VCN.
- Each attached view is evaluated in order. The default view is evaluated last, if not explicitly included in the list.
- Resolver Rules are evaluated in order.
- The query is resolved to the internet.
For example, if a query name is included by a zone in a private view and the name does not exist in the zone, the zone will return an authoritative NXDOMAIN response.
Ingress and egress between VCNs or between VCNs and on-premises networks require connectivity. Establishing a connection might require a local peering gateway (LPG ) or a remote peering gateway (RPG ) between VCNs. Connection between a VCN and on-premise networks require either FastConnect or an IPSec tunnel (IPSec VPN).
VCN security lists and any referenced NSGs need to allow the required traffic. DHCP on the security list needs to be enabled for ingress and egress and include the corresponding resolver endpoint's IP address. Security rules for listening endpoints need to allow connectionless UDP ingress on destination port 53, connectionless UDP egress on source port 53, and TCP ingress on destination port 53. Security rules for forwarding endpoints need to allow connectionless UDP egress on destination port 53, connectionless UDP ingress on source port 53, and TCP egress on destination port 53.
Custom DNS Zones Within a VCN
Private DNS zones are grouped into views . All VCN dedicated resolvers have a default view which is created automatically. To create a custom DNS zone that resolves from within a VCN, either create the private zone in the dedicated resolver's default view, or create the zone in a new view and add it to the dedicated resolver's list of attached views. See Help Center/Configure private DNS zones views and resolvers for a detailed guide on how to set this up.
Create private zones with the same names as public names on the Internet. Then, add the zones to one of the VCN resolver's views. Within the VCN, the names resolve based on the private DNS configuration. The same names serve different answers depending on where the request originates.
Shared Private DNS Zones Within a Region
VCNs within the same region can resolve requests from each other's private views. For example, let's say you want to implement this solution with VCN A and VCN B. Add VCN A's dedicated resolver's default view to VCN B's dedicated resolver's attached views. Then, add VCN B's dedicated resolver's default view to VCN A's dedicated resolver's attached views.
The same private zone or collection of private zones can be reused across multiple VCNs. This solution can reduce DNS configuration duplication. Create a view and add one or more private zones to the view. For each VCN, add the new view to the VCN's dedicated resolver's list of attached views. See Help Center/Configure private DNS zones views and resolvers for a detailed guide on how to set this up.
DNS Resolution Between VCNs
Send requests between VCNs using resolver endpoints. The VCNs can exist in different regions. This solution requires either a local or remote peering gateway (LPG /RPG ). To send traffic from VCN A to VCN B, add a listening endpoint to VCN B's resolver. Then, add a forwarding endpoint to VCN A's dedicated resolver. Create a rule on VCN A's dedicated resolver that forwards traffic through VCN A's forwarding endpoint to the address of VCN B's listening endpoint. To send traffic in both directions between the VCNs, add a forwarding and listening resolver endpoint to each dedicated resolver and add a rule on each dedicated resolver. See A-Team Chronicles/Private DNS Implementation for a detailed guide on how to set this up.
Connectivity Between a VCN And On-Premises Name Servers
Requests can be sent between a VCN and on-premises name servers in either direction. This solution requires connectivity between the VCN and the on-premises network using either FastConnect or an IPSec tunnel (IPSec VPN). To send traffic to a VCN, add a listening endpoint to its dedicated resolver and send traffic to its address. To send traffic from a VCN, add a forwarding endpoint to its dedicated resolver and a rule that forwards traffic through the endpoint to the address of the on-premises name server. See A-Team Chronicles/Private DNS Implementation for a detailed guide on how to set this up.
Advanced Use Cases
VCNs can be set up for more than one use case. A single VCN could be both peered with another VCN, and configured to connect to an on-premises name server. Forwarding can also be chained across multiple VCNs.
Supported Resource Records
The Oracle Cloud Infrastructure DNS service supports many resource record types. The following list provides a brief explanation of the purpose of each supported record type for private DNS. For public DNS, see Public DNS Supported Resource Records. Avoid entering confidential information when entering record data. The RFC links direct you to further information about the record types and data structure.
Note About RDATA
OCI normalizes all RDATA into the most machine readable format. The returned presentation of your RDATA may differ from its initial input.
The RDATA for the CNAME, DNAME, and MX record types may contain one or more absolute domain names. If the specified RDATA for one of these record types does not end in a dot or period to represent the root, the period will be added.
www.example.com --> www.example.com.
You can use various DNS libraries to normalize your RDATA before input.
|Go||DNS Library in Go|
Private DNS Resource Record Types
- An address record used to point a hostname to an IPv4 address. For more information about A records, see RFC 1035.
- An address record used point a hostname at an IPv6 address. For more information about AAAA records, see RFC 3596.
- A Certification Authority Authorization record allows a domain name holder to specify one or more Certification Authorities authorized to issue certificates for that domain. For more information about CAA records, see RFC 6844.
- A Canonical Name record identifies the canonical name for a domain. For more information about CNAME records, see RFC 1035.
- A Delegation Name record has similar behavior to a CNAME record, but allows you to map an entire subtree beneath a label to another domain. For more information about DNAME records, see RFC 6672.
- A Mail Exchanger record defines the mail server accepting mail for a domain. MX records must point to a hostname. MX records must not point to a CNAME or IP address. For more information about MX records, see RFC 1035.
- A Pointer record reverse maps an IP address to a hostname. This behavior is the opposite of an A Record, which forward maps a hostname to an IP address. PTR records are commonly found in reverse DNS zones. For more information about PTR records, see RFC 1035.
- A Service Locator record allows administrators to use several servers for a single domain. For more information about SRV records, see RFC 2782.
- A Text record holds descriptive, human readable text, and can also include non-human readable content for specific uses. It is commonly used for SPF records and DKIM records that require non-human readable text items. For more information about TXT records, see RFC 1035.
Required IAM Policies
To work with private DNS, a user needs sufficient authority (by way of an IAM policy). If your user is in the Administrators group, you have the required authority. If your user is not in the Administrators group, then a policy like this will allow a specific group to manage private DNS:
Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'
If you're new to policies, see Getting Started with Policies and Common Policies. For more details about policies for private DNS, see DNS Policy Reference.
Private DNS Tasks
Setting up Private DNS
Private DNS Tasks
To create a VCN with a dedicated DNS resolver, see Overview of VCNs and Subnets and DNS in Your Virtual Cloud Network for more information.