From HEXONET Wiki
Line 151: | Line 151: | ||
= Document Downloads = | = Document Downloads = | ||
Download: {{Template:Pdf|howTo_Nameserver_en.pdf| Virtual Nameserver Howto}} | Download: {{Template:Pdf|howTo_Nameserver_en.pdf| Virtual Nameserver Howto}} | ||
+ | |||
+ | |||
+ | = FAQs & Troubleshooting = | ||
+ | |||
+ | == What information do I need to provide to investigate a particular behaviour == | ||
+ | Because our system uses anycast, we need to know which of our PoPs your queries are going to: the IP address itself isn’t enough, since it’s shared across many locations. So any dig or nslookup command will not give the information that we need to debug where the problem is. | ||
+ | |||
+ | The following command line tools should be used: | ||
+ | |||
+ | * MTR → https://www.youtube.com/watch?v=1g64C4t4zGI | ||
+ | * traceroute -A https://www.youtube.com/watch?v=YzyHXHJl_mU | ||
+ | * dig yourdnsnamehere.com +nsid → https://www.youtube.com/watch?v=UAlzss-9sH0 | ||
+ | * dig soa yourdnsnamehere.com +nsid | ||
+ | |||
+ | Providing this information when you open a Support ticket will help us handle your request and find a solution a lot faster. | ||
+ | |||
+ | |||
+ | == Why is my traffic ending up in another node? == | ||
+ | |||
+ | Our Anycast networks use BGP to distribute traffic to different upstream providers around the world. These upstream providers range from Tier 1 level, the likes of Cogent, NTT, GTT, or others, and lower tiers which are local in a continent or a country, and traffic via Internet Exchanges which is either by using their route servers or through direct peering. | ||
+ | |||
+ | A BGP relationship is best effort by default, and once traffic leaves the premise it will be in the *total* control of upstream providers. Some upstream providers have pre-defined agreements that will influence the route the traffic will take once our packet leaves our network. | ||
+ | |||
+ | Due to loss of control of traffic once passed on to upstream providers, DNS clients traffic might be forwarded to nodes that are quite far in both terms of network connectivity and geographical distance. | ||
+ | |||
+ | For instance, a client in North America could see their DNS query routing towards a node in South Africa, when in fact the query should have been directed towards the many nodes available in North America. | ||
+ | |||
+ | Many providers will change their internal routing configuration after we contact them if we find an issue, but big players in the market like Hurricane Electric, never do so. Whilst we stopped our direct peering with them, many of our upstream providers use them as one of their own upstream connections. | ||
+ | |||
+ | Our DNS team continuously tracks those issues and contact suppliers where possible. Most of the time those issues get resolved, however it always takes time. We also employ the use of BGP communities where applicable, to influence how our upstreams route traffic. |
Revision as of 09:07, 24 June 2021
Our brand new DNS service
HEXONET has recently upgraded its entire DNS service, with the support of our colleagues in the CentralNic Registry DNS team. Old servers have been retired and a brand new, state-of-the-art Anycast network has taken their place. 13 nodes in 5 continents, with hundreds of servers split in 3 separate clouds ensure that your domains resolve fast and securely all over the world. Our average response time has dropped from 131 to 28 milliseconds, a level of performance that most providers can barely dream of.
DNS is a fundamental piece of a domain offering and we believe all customers should have access to a solid and secure DNS infrastructure.
This is why we are retiring our old Premium DNS offering and are making this new DNS service our standard option for all domains registered through HEXONET.
Beginning April 1st, we will no longer charge for any Premium DNS subscription and it will not be possible to activate new Premium DNS subscriptions.
Resellers and Customers will still be able to manage these zones as before through our API and interfaces. Over the coming weeks, we will be removing all references to Premium DNS from our interfaces and making it easier for you to manage all your DNS zones together. During this transition period you might see references to Premium DNS and receive renewal notices for Premium DNS zones, but no charges will be applied.
To learn more about DNS management via the Control Panel, go to DNS in Control Panel.
How to use HEXONET DNS Service
Create new DNS zone
You can create a new DNS zone with the following command
COMMAND = CreateDNSZone DNSZONE = (DNS zone name)
Create new DNS zone for a domain not registered with HEXONET
It is possible to use the HEXONET DNS service to host domains registered with other Registrars (also referred to as "external zones"). This service is currently offered at no charge until the end of 2021. Resellers should, however, be aware that charges will apply starting from January 1st, 2022.
To create an external zone, use the optional flag EXTERNAL=1
COMMAND = CreateDNSZone DNSZONE = (DNS zone name) EXTERNAL = 1
Create new DNS zone for a domain that is about to be transferred HEXONET
It is possible to create a zone in the HEXONET DNS system in preparation for an incoming domain transfer to HEXONET.
To create this type of zone, use the optional flag DOMAINTRANSFER=1
COMMAND = CreateDNSZone DNSZONE = (DNS zone name) DOMAINTRANSFER = 1
Please note that if the domain transfer is not completed within 14 days from the creation of the zone, the zone is automatically deleted from the HEXONET DNS system.
Get a list of all DNS zones
You can query a list of all DNS zone with the following command
COMMAND = QueryDNSZoneList
Get a list of all Premium DNS zones
You can query a list of all Premium DNS zone with the following command
COMMAND = QueryDNSZoneList PROPERTIES = PREMIUMDNS PREMIUMDNSCLASS = *
Get information on a DNS zone
You can query all information regarding a DNS zone with the following command
COMMAND = StatusDNSZone DNSZONE = (DNS zone name)
Add and manage records
You can add and manage records for a DNS zone with the following command
COMMAND = UpdateDNSZone DNSZONE = (DNS zone name) ADDRR0 = (add new record) DELRR0 = (remove record)
Enable DNSSEC
You can enable DNSSEC on DNS zones using the following command
COMMAND = UpdateDNSZone DNSSEC-MODE = AUTO DNSZONE = (DNS zone name)
Once enabled, you must input the DS and KEY records into the respective domain. You can get the DS and KEY record information by executing the following command
[COMMAND] COMMAND = StatusDNSZone DNSZONE = (DNS zone name) EOF [RESPONSE] CODE = 200 DESCRIPTION = Command completed successfully PROPERTY[DNSSEC-DS-SHA-1][0] = 20407 8 1 040772816032dc2a675d7f74725d747e47c45185 PROPERTY[DNSSEC-DS-SHA-256][0] = 20407 8 2 a1dd1c5c5d78cd71477472ec5a3eeeaee65ecbc461b63ecd4630fd44d9492028 PROPERTY[DNSSEC-KEY][0] = 257 3 8 AwEAAbfEdVJVqSuGwU8XEAtUWtODHv2CNPAwDKATFs0V17O2/Qe+vSUPadWNISqhSr7wAVrNxdNbOPxzw/iF8xN84GN3hArecKhX/+Yb6fSsucqkwd8fuloU+jTBAl4dq7LRM5DbqdLrN6MUyq1p2h86lP9pXjEaeTYtZ0i8zeV7IyG4d/q+FTNG+1Daw90YIvyFdek1HnNd9pXRSeYhdB8GyxZAGPPID0NBk5/L/nY3mCTi7ezQ7UsdVuB/W53sjlSgjgfFnxsqanN0XK87liuZ8fSMi84CPRTqoYglIBUVxHtTlZIN7Xg72g5HsNzX3EEQfcvkB4h62CcBKX3AIron3zc= PROPERTY[DNSSEC-KEY-TAG][0] = 20407 PROPERTY[DNSSEC-MODE][0] = AUTO ... EOF
To input the records into the domain, execute the following command
COMMAND = ModifyDomain ADDSECDNS-DS0 = (DNSSEC-DS from StatusDNSZone, you can choose either SHA-1 or SHA-256) ADDSECDNS-KEY0 = (DNSSEC-KEY from StatusDNSZone) DOMAIN = (domain name)
Disable DNSSEC
You can disable DNSSEC on a DNS zone with the following command
COMMAND = UpdateDNSZone DNSSEC-MODE = DISABLED DNSZONE = (DNS zone name)
Zone Commands
HEXONET's DNS service platform was designed to dramatically simplify the management of DNS. More Information
- How to use HEXONET's DNS with your domains
- DNSSEC API Command Extensions
- HEXONET's extended DNS Solutions
Document Downloads
Download: Virtual Nameserver Howto
FAQs & Troubleshooting
What information do I need to provide to investigate a particular behaviour
Because our system uses anycast, we need to know which of our PoPs your queries are going to: the IP address itself isn’t enough, since it’s shared across many locations. So any dig or nslookup command will not give the information that we need to debug where the problem is.
The following command line tools should be used:
- MTR → https://www.youtube.com/watch?v=1g64C4t4zGI
- traceroute -A https://www.youtube.com/watch?v=YzyHXHJl_mU
- dig yourdnsnamehere.com +nsid → https://www.youtube.com/watch?v=UAlzss-9sH0
- dig soa yourdnsnamehere.com +nsid
Providing this information when you open a Support ticket will help us handle your request and find a solution a lot faster.
Why is my traffic ending up in another node?
Our Anycast networks use BGP to distribute traffic to different upstream providers around the world. These upstream providers range from Tier 1 level, the likes of Cogent, NTT, GTT, or others, and lower tiers which are local in a continent or a country, and traffic via Internet Exchanges which is either by using their route servers or through direct peering.
A BGP relationship is best effort by default, and once traffic leaves the premise it will be in the *total* control of upstream providers. Some upstream providers have pre-defined agreements that will influence the route the traffic will take once our packet leaves our network.
Due to loss of control of traffic once passed on to upstream providers, DNS clients traffic might be forwarded to nodes that are quite far in both terms of network connectivity and geographical distance.
For instance, a client in North America could see their DNS query routing towards a node in South Africa, when in fact the query should have been directed towards the many nodes available in North America.
Many providers will change their internal routing configuration after we contact them if we find an issue, but big players in the market like Hurricane Electric, never do so. Whilst we stopped our direct peering with them, many of our upstream providers use them as one of their own upstream connections.
Our DNS team continuously tracks those issues and contact suppliers where possible. Most of the time those issues get resolved, however it always takes time. We also employ the use of BGP communities where applicable, to influence how our upstreams route traffic.