The Internet is a great architecture, with two basis : IP addresses and Host Names.
The way these two aspects connect may seem complexe, but it is quite simple. Let's
go with simple steps.
The IANA ( Internet Assigned Numbers Authority ) oversees :
. the root zone of the DNS
. the Global IP addresses allocation
. The Autonomous Systems numbering allocation
The IANA and the Domain Name authority delegation
from the root zone of the DNS, domain name authority is delagated downward by the IANA, to the gtld level ( general topl level domain : .com, .net, .org, ...
from the gtld level, a domain name authority is delagated to a requiring registrar :
ex: example.com is delegated by the .com gtld to the registrar
the authority is then handed by the registrar to the customer.
example of authority delegation of the example.com domain :
The IANA and the Reverse DNS authority delegation
DNS-wise, the IANA oversees the delegation of IP address pools to the RIRs ( Regional Internet Registries : ARIN, RIPE NCC, APNIC, AFRINIC and LACNIC ).
The authority over subsets of these IP address pools is then delagated to ISPs or Tunnel Brokers.
Lastly, the authority over a sub-subset IP address pool is delagated to the customer by the FAI or the Tunnel Broker.
example of IP address authority delegation to a customer of the [G]:/48 IPv6 subnet :
Here is the whole picture :
Of course, in the case of a customer of both the example.com domain and the [G]:/48 IPv6 subnet, there is a one only customer ( ie box at the bottom of the picture ), so the picture is actually this :
But it's important to outline the fact that the domain name authority and the IP addresse pool authority delegation follow different paths.
Authority delegation from the Registrar to the Customer
First, a domain name is registered.
having registered it, we have authority over this domain. this authority is this :
you can set the (NS) records. The NS records specify which DNS Servers are responsible for a domain. We setup these NS records at the registrar's level ( Registrar's management webpage for this domain name ).
we have three options :
1. We let them pointed to a name server hosted by the Registrar. We will then manage the example.com domain from the Registrar's management page. This is the default setup, and the most usual.
2. We set them up to point to a third-party, hosted DNS server. There are free and non-free hosted DNS services on the Internet. We will manage our DNS records at this DNS host management page.
3. We set them up to point to our own, locally hosted, DNS servers. This is the rarest, and less easy to deal with case. ( See this posts for explainations about why local and authoritative DNS server is not the best choice : post 1 post 2 post 3 )
on these DNS servers ( at least 2 for redundancy ), we will register different things :
. NS records : they refer to the DNS server itself. It is a confirmation. It says ' I AM resposible for this domain. There is no error here '.
. A and AAAA records : they reply with IP addresses to name queries
. PTR records : they reply with FQDNs to IP addresses queries
. MX record, CNAME record, Ressource record, ....
Authority delegation from the ISP/Tunnel Broker to the Customer
At the ISP/Tunnel Broker level, we may get the reverse DNS delegation.
The ISP ( or Tunnel Broker ) holds too NS records. These NS records point to the Name Servers authoritative over an IP address or address scope.
Here too, we have three options :
1. We let them pointed to a name server hosted by the ISP/Tunnel Broker. We manage the [G]:/48 IPv6 scope from the ISP/Tunnel Broker management page. This is the default setup, and the most usual
2. We set them up to point to a third-party, hosted DNS server. There are free and non-free hosted DNS services on the Internet. We manage our PTR ( reverse DNS ) records from here
3. We set them up to point to our own, authoritative and locally hosted, DNS servers. This is the rarest, and less easy to deal with case. ( See this post and the two following )
This DNS server will only contain PTR records ( Reverse DNS ).
The Glue Record
In the case of a locally hosted authoritative Name Server, a question arises. Look at this sequence :
( Client ) : . Hello, I am from the outside world. What is the IP address of host1.example.com ?
( Registrar ) : . Ask ns1.example.com
( Client ) : . What is the IP address of ns1.example.com ?
( Registrar ) : . I don't know. ask ns1.example.com ...
we're in a loop here ! And the solution is glue record. A glue record, located at the registrar's level, contains the IP of the nameserver ns1.example.com. So this happens now :
( Client ) : . Hello, I am from the outside world. What IP is host1.example.com ?
( Registrar ) : . Ask ns1.example.com. It's IP address [IP]
( Client ) : . Hello [IP], what is the IP address of host1.example.com ?
( ns1.example.com ) : . host1.example.com is at [IP2]
A few more notes
In the case of IPv4, you probably have one only public IPv4 address. So delegation is useless. Eventually, you may be able to customize this Reverse DNS record at the ISP admin page.
In the case of IPv6, things get more complexe. The endpoint IPv6 address ( CPE WAN IP address, or IPv6 tunnel endpoint ) is managed the same way as the IPv4 public IP : It is at the ISP ( or tunnelbroker ) level. You may be able to customise it.
The subnet ( /64 or /48 as an example ) IPv6 addresses reverse DNS may be delagated, depending on the FAI. Hurricane Electric allows /64 or /48 IPv6 addresses Reverse DNS delegation. To have the subnet Reverse DNS delegated, you fill two (NS) records at the ISP/Tunnel Broker admin page, pointing to our DNS Server ( either hosted or local ).
Managing PTR records benefit is that your reverse DNS records are reachable fom the outside, which is necessary in some situations ( for managing an internal mail server : it's a security feature )
Usually, we don't need locally delegated DNS authority, so we keep :
DNS Server at the registrar level, or using a third-party DNS hosting.
rDNS ( Reverse DNS ) authority at the ISP level, or using a third-party DNS hosting.
Please notice that DNS delegation and rDNS delegation are separate things. We can get one delagated, and leave the other to its originating authority ( Registrar or ISP/Tunnel Broker in this case ).
Notice too that as they follow a different authority path and apply to different fields, we can use distinct third-party hosted DNS servers for the domain name and for the ISP/Tunnel Broker ( ie different NS records at the Registrar and at the ISP/Tunnel Broker's level ).
A good option for full DNS authority delegation is to use a hosted DNS. We then get the benefits of full DNS Server control, without the weights ( managing physical and IT security : Server redundency, DNS flooding and poisoning issues .... )
All said and understood, the easiest and most logical way of doing things is to have a locally-authoritative DNS server for the private subnets, and to use the Registrar DNS and the ISP/Tunnel Broker rDNS for public access services ( Web Server, FTP Server, ... )