The internet is glued together by interpretation of text files. Nameservers (primary and secondary) are only authoritative for their own zones. Glue records are not authoritative records for the zones they point to. Out of context arbitrary or assumed definitions of correctness are not practical and realistic.
DNS glues the internet
DNS means ‘Domain Name Service’. DNS maps names to usable network addresses and allows the same name to be used when a network address changes.
NS refers to either a host that provide DNS services, to a particular type of DNS record or generically to any DNS record. Context determines meaning.
The following section currently (as of December 2023) appears on the main page of Hostfurl web site and is specifically for Hostfurl customers.
Same DNS nameservers to point to, even if moved to a different physical server
You get three authoritative nameservers to point to for glue NS records. All three nameservers will list a fourth Hostfurl authoritative nameserver that is also your SOA nameserver. This allows flexibility. Some naive DNS analysers erroneously believe glue NS records are required to be complete. One naive analyser specifically points to a section (5.4.1 of RFC 2181) as proving error, but in fact proves the opposite as glue records are specifically excluded when proving DNS configuration correctness. If you believe this is a mistake then please do not sign up for an account.
Why is this approach preferred for flexibility?
With this approach Hostfurl can change customer servers around to different physical servers without customers even knowing or noticing, including synchronising late changes during transition. A customer does not need to do anything with their glue DNS records
If the full set of DNS NS records is included as glue records, then changeover requires additional planning and synchronisation and so introduces additional work for Hostfurl and customers as well as unnecessary delays, stress and anxiety.
Can a customer add in the supposedly missing record anyway?
Yes. One way, among many, to find it is with command
dig NS your.domain. Just add in the single host name that does not start with ns1, ns2 or ns3.
If Hostfurl is managing DNS registrar records on behalf of the customer then the customer needs to ask Hostfurl to add in the additional record.
At the technical level involved, making assessments of ‘correctness’ is unfortunate. A better approach is does it work and are problems introduced. The answer is yes it does work and no, problems are not introduced .
There is a massive irony. The internet is famed for its resilience. If the Internet refused to honour DNS records because of differences between glue records and authoritative records then the Internet would demonstrate massive failures because the Internet is constantly in transition. Section 5.4.1 of RFC 2181 deliberately emphasises a set of practices that probably evolved over many years and helped to grow Internet reliability and resilience: use glue records as pointers to complete authoritative records, nothing more.
It is odd that analysis sites point out what they allege is missing, given it is so easy for them to find it. How can something be missing when it is so trivial to find it?
It points to another irony. There is no way a DNS analyser can determine if glue records are supposedly complete and even if glue a record include the SOA NS, until they consult one of the authoritative servers pointed to by glue records! So they reliably get complete records using glue records and then allege records are incorrect!
A better definition of correctness, in context
- Is there at least one glue NS record?
- If the NS domain is used for the name server host name (so called ‘vanity’ domain), is there at least one matching glue A record in the same zone file?
- Is the glue NS record listed in authoritative record zone files as an NS record?
- Does the authoritative record include an SOA record? This can also point to a glue NS record
- Continue with evaluating other records
DNS glue records are formally defined at the end of section 5.4.1 of RFC 2181, but not clearly. A version is that glue records contain sufficient records (NS only or NS and A/AAAA) to allow a nameserver to determine the authoritative source of name server records for its sub domain as a zone.
There is no requirement that glue records need to provide a complete set of NS records.
Glue records are specially excluded from proving DNS configuration correctness and there are specific rules to lower the priority of use of glue records when other authoritative records are available, even more so when there is a conflict with authoritative records.
Incomprehensibly, the definition includes ‘stray’ records as glue records. There is no definition of a stray record. Maybe a stray record as a catch all name for any record type which is not mentioned by a standard. It may also be a name for records of the pointed to zone (a.example.com) in the zone doing the pointing (example.com) which will be ignored because by declaring the pointed to zone (a.example.com) with NS records, the pointing zone (example.com) now has no authority for such records, such as CNAME (b.a.example.com to any other DNS name) and MX records (for a.example.com).
Primary and Secondary Nameservers
A zone is what NS and SOA records name and the complete set of records for a zone is called a zone file. Using a single text file to maintain zone records is still a core practice. The web interface common in DNS managers still writes to single text files per zone.
The label NS means ‘name service’ or ‘name server’, implying a source of authoritative records that map names to network addressable records. The precise meaning of NS in a sentence is contextually driven, as mentioned in the start above.
The terms ‘host’ refers to any network addressed device. A host can be a client or server or both. A clients make requests and a server answers the request. A client is not required to have a DNS record but nowadays it is rare for any client not to have DNS records, even indirectly at a NAT (Network Address Translation) level.
Given the popularity of the ‘primary’ and ‘secondary’ nomenclature in DNS, it is surprising there does not appear to be any considered formal definition of primary and secondary in standards. There is no need for it. A secondary name server is a host to which a NS zone record points to but is not also pointed to by a SOA record. A primary name server is a host to which both NS and SOA zone records points to. A SOA record has to specify a NS host.
SOA means ‘start of authority’. Both primary and secondary name server zone files are authoritative, but only for their own named zone. Zone files are not authoritative for other zones to which they have glue NS (and possibly glue A/AAAA records) for. Such glue record simply point to where there is zone authority. Primary name servers transfer copies of zone files to secondary name servers but in a binary form, not text form. Real zone text files can be found on primary nameservers, used by BIND software. How do we know? Hostfurl commonly edits these files directly, increases a zone file serial number (a SOA record field), triggers a zone reload which in itself triggers a transfer of updated zone files (in binary format) to secondary name servers and their reload.
The following only applies where Hostfurl hosts customer DNS. This is enabled by pointing NS glue records to Hostfurl name servers. If Hostfurl manages DNS registrar records (such as with an automated purchase of a domain name through Hostfurl) then DNS glue records are automatically setup.
Customers do not need to edit DNS for standard use cases. One case where DNS editing is necessary is where web main domain is hosted elsewhere (such as on a CDN) or a customer has multiple web sites on sub domains hosted elsewhere. Link to guide to be provided.
Hostfurl allows customers to edit their own zone text files through a web interface. Customers are not allowed to directly manually edit their zone text files. SOA records are not allowed to be customer edited.
If customers messes up their DNS they can lodge a support ticket and Hostfurl will fix it.
Messing up DNS can make web and email unusable within a few hours, sometimes within a few minutes. It is important not to panic. Emails are not deleted and in most cases undelivered emails will remain in queues for delivery for up to three days. Web sites are not deleted.
Customer account support will still work because it does not use customer domain name for access. If you have forgotten your customer account password and so cannot get a change password link by email to log into your customer account, you can contact Hostfurl by contact form. Hostfurl will quickly verify problem, provide a temporary DNS fix and let you know by an alternate email if provided.
Even if DNS is messed up, the customer web interface server account will still work but not with the customer domain name for access. An IP address or the general server name can be used. Hence, if a customer is experienced enough, they can fix up messed up DNS themselves.
After DNS is fixed up it can take up to to two days for fixes to be fully propagated.