DNSVAULT 5.0
  • Introduction
  • Central Management
  • Fabric Management
  • Node Management
  • Service Management
    • DNS
      • Overview
      • Views
        • Zone
          • Inverse
            • Info
            • Host
            • SOA
            • NS
            • Nodes
            • Statements
            • DNSSEC
            • Logs
          • Reverse
            • Info
            • Host
            • SOA
            • NS
            • Nodes
            • Statements
            • DNSSEC
            • Logs
          • Response Policy
            • RPZ Zone
              • Info
              • Policies
              • Statements
              • Feed
        • Statements
        • Rate Limit
        • Fetch Limit
        • NXDomain Redirect
        • Bulk Upload
        • Attach Master Node
        • Attach Slave Node
        • Resource Record Service Option
        • Permission
        • Manage
      • TSIG
      • ACL
      • Servers
      • Options
      • Templates
  • Reports
Powered by GitBook
On this page

Was this helpful?

  1. Service Management
  2. DNS
  3. Views
  4. Zone
  5. Inverse

NS

PreviousSOANextNodes

Last updated 3 years ago

Was this helpful?

NS RRs appear in two places. Within the zone file, in which case they are authoritative records for the zone's name servers. At the point of delegation for either a subdomain of the zone or in the zone's parent in which case they are non-authoritative. Thus, the zone example.com's parent zone (.com) will contain non-authoritative NS RRs for the zone example.com at its point of delegation (point of delegation is the term frequently used to describe the NS RRs in the parent that delegate a zone of subdomain) and subdomain.example.com will have non-authoritative NS RRS in the zone example.com at its point of delegation. NS RRs at a point of delegation are never authoritative only NS RRs within the zone are regarded as authoritative. While this may look a fairly trivial point, is has important implications for DNSSEC