Overview
The intent here is to provide a DDNS service via the existing AD-integrated DNS services in the NETID domain services. Organizations which have an existing delegated OU can move existing DNS zones to this service, gaining delegated administration or dynamic DNS capabilities if they don’t currently have them or reduce costs by getting out of the business of running their own DNS service.
Key Terms
Adapted from various sources:
- DNS Zone. A DNS namespace which encompasses all DNS records within a given naming scope.
- DNS Server. A DNS server hosts one or more DNS zones.
- DNS record. A record that provides name to IP mapping. DNS records have various types, reflecting the kind of service provided by the host represented by the DNS record.
DNS Zones
Good candidate DNS zones are those which:
- Where the hosts represented do not need PTR records
- Do not need service from outside the UW network boundaries (AS 73 and AS 14221) or which can co-locate the public view of their DNS zone with the campus DNS service. In other words, UWW must be authoritative for the DNS zone; the NS record for the zone must point to the NETID DNS servers. Those who need a public view of their zone would need to manage that view via the campus DNS service and might have a NS record pointed at the campus DNS servers from a public view.
- Have all their computers joined to the NETID domain, in order to take advantage of DDNS capabilities. NOTE: While this qualification makes it a good candidate, lack of NETID domain membership isn’t a hard requirement–it just means customers will need to manually manage their own DNS changes (yes, we know that self-service DNS is an improvement compared to the campus DNS service, but that isn’t the selling point we are emphasizing)
- Do not need delegated administration or have existing staff that are capable of performing Microsoft DNS administration
DNS servers
While it is possible to host AD-integrated DNS zone additionally on secondary member servers, there’s not much reason to do so. This would requires additional servers that would likely not have any other use/purpose. There’s minimal incremental risk to hosting additional DNS zones on domain controllers, and benefits in cost reduction (no additional servers required) and availability.
Management delegation
The UWWI service will only accept DNS zones from existing delegated OU customers. Management of DNS zones will be delegated to the delegated OU customer requesting the zone, by way of a group we manage.
For consistency, we should use a standard naming convention for these groups, such as u_windowsinfrastructure_<zone>_dnsadmins. Use of sadm accounts here is required. At least two admins are required.
Additional considerations
Client computer resolvers that plan to register/deregister their DNS records should continue to use their existing DNS servers. Those DNS servers will correctly identify the UWWI DNS servers as authoritative and direct the registration/deregistration to them.
DNS admins agree to notify UWWI when they wish to make a major change to their DNS zone, such as making another DNS service authoritative.
Support/Availability
We provide the DNS service, delegated OU customers provide the administration and expertise about their DNS zone. Support expectations follow from this vision.
DNS services are generally available 24×7. Incidents affecting the entire DNS service would be covered 24/7 with same resolution timeframe as domain service incidents. Support for incidents or problems affecting less than the entire DNS service would be addressed (on the next business day || 24/7) and limited to ensuring that the DNS service is available and that the DNS zone is configured correctly.
Requests for a new zone would be fulfilled within 2 business days, with an aim of creating the new zone and delegating to the customer. What they do with the zone beyond that is generally beyond our responsibility. Given the complexity and significance of DNS, we expect that other requests have the potential to take quite a bit of coordination and time. The expectation there is that we will provide a very minimal amount of consulting limited to our service design.
The group delegated management of a DNS zone is responsible for creating and maintaining DNS records in that zone and for support/troubleshooting.
Pending Questions
Should we have the delegated group be nested under the delegated OU? e.g. u_windowsinfrastructure_pottery_mypot.uw.edu_dnsadmins
Do we need a plan for when a customer falls below 2 admins? Threaten a charge or something?
Plan
- Finalize design with UWWI Eng.
- Get SO/SM comment and approval to proceed
- Send request for comment out to UWWI Discuss + those who voted for BYODDNS topic
- Review/incorporate comments, finalize design
- Implementation (proceed to other cards in backlog for this theme)
Outcome
This proposal has not been implemented based on the belief that the solution does not meet enough customer needs.