|Proposal Home | Attachments|
Proposal by Questions:
C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9 | C10 | C11 | C12 | C13 | C14 | C15 | C16 | C17 | C18 | C19 | C20 | C21 | C22 | C23 | C24 | C25 | C26 | C27 | C28 | C29 | C30 | C31 | C32 | C33 | C34 | C35 | C36 | C37 | C38 | C39 | C40 | C41 | C42 | C43 | C44 | C45 | C46 | C47 | C48 | C49 | C50 |
C17.4. Zone file generation. Procedures
for changes, editing by registrars, updates. Address frequency, security,
process, interface, user authentication, logging, data back-up.
On behalf of the DotOrg Foundation, Registry Advantage will operate a world-class DNS infrastructure to support the .org registry operations. In order to overcome the limitations of BIND, DotOrg Foundation will use the proprietary DNS server application developed and deployed by Registry Advantage. The important features of this technology include:
The design of this DNS infrastructure allows per-domain updates to the registry database from authorized parties. These updates are initiated through the registrar's SRS interfaces or through the registrar secure web based account management interface. Once a registrar makes a successful change to a domain involving DNS-related information, the database will insert an update message into a queue for the cluster master. The cluster master then uses a secure network protocol to distribute the updates throughout all other clusters of DNS servers. In this manner, changes can be propagated from the database to all DNS servers with a frequency of under five minutes. The process of distributing these updates to satellite DNS sites is described in greater detail in Attachment N.
Figure C17.4.1 Zone Generation
This per-domain update mechanism eliminates the need for traditional zone file generation to actively manage the DNS.
All updates will be logged by both the database and the DNS application; these logs will periodically be crosschecked to verify consistency. These logs will also be backed up on a daily basis (see Escrow Services in Section C17.7 below) and can be used to restore the DNS system to its state at a previous moment in time, and provide an audit trail. In addition, traditional BIND compatible zone files will be generated on a daily basis and archived to tape as part of the data escrow process. This also allows for high level inter-day changes to be easily identified, in addition to the SRS audit logging.
Since the DNS information is automatically updated in near real time, no access to the DNS zone information is allowed outside of the SRS repository. All changes to the DNS data must be made through SRS to ensure access security and proper change tracking by registrars. The daily zone files generated are for backup and referential purposes only (see below) and are stored in a restricted file system that only Registry Advantage authorized personnel have access to.
In order to ensure the stability of its DNS infrastructure, Registry Advantage will also deploy several backup DNS servers running BIND. Although these systems will not generally be used to answer DNS queries, in the event of a catastrophic failure of the principal .org DNS infrastructure, Registry Advantage will use the BIND-based DNS servers in a failover mode. Traditional zone file generation will be required to keep these servers up to date, and this zone file generation will occur on a once daily basis as described above. These zone files are validated using secure cryptographic hashes and digital signatures before they are loaded into the backup BIND servers. Once the ongoing stability of the Registry Advantage infrastructure has been established, these backup servers may be phased out.
C17.5. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them. If you propose to employ the VeriSign global resolution and distribution facilities described in subsection 5.1.5 of the current .org registry agreement, please provide details of this aspect of your proposal.
Registry Advantages distributes zone data to all DNS points of presence within five minutes.
As described in Question C17.4 and Attachment N, Registry Advantage will utilize a DNS infrastructure that does not rely on zone files as used in BIND and other traditional DNS server software. In order to provide end-users with a reliable and responsive DNS infrastructure, Registry Advantage will deploy DNS servers in a number of locations, including those referenced in C17.1:
Additionally, Registry Advantage will deploy DNS servers at its secondary site and will use an RFP process to select at least three additional locations for DNS servers. Sites would be selected in order to improve the overall geographic and network diversity for the .org DNS service. It is currently anticipated that one of these locations will be deployed in each of the following regions:
At any given time, the DNS cluster at either the primary site in New York or the secondary site will act as the “master” cluster. (The master cluster is the one adjacent to the active database and shared registry service, so if the New York site is providing the active shared registry service, the DNS cluster in New York will be the master.)
The master will be responsible for keeping distributed logs, issuing warnings to operators, initializing new servers in the other clusters, and zone data propagation. In the event of catastrophic master failure, the satellite clusters will still continue to operate. It will be possible to retrieve configuration information from them once the master is rebuilt.
The master will also distribute updated zone information to the satellite clusters. All communications between the master and satellite clusters will be encrypted for security. Updates received by an individual node within a satellite cluster will be distributed to the rest of the servers within that cluster. As indicated in C17.4, Registry Advantage will tune communications parameters so that changes generally propagate to all clusters within five minutes.
Registry Advantage’s system employs advanced DNS software developed at Register.com, which achieves accelerated response times, rapid zone information updates, and improved fault tolerance. (Please refer to C17.1 for detail) In developing this software, Register.com leveraged its considerable experience in providing authoritative DNS services for over three million domain names and specifically designed this software to create a highly scalable and available DNS infrastructure. Registry Advantage has built on this base of knowledge in creating its infrastructure and software to support the .org registry.
As indicated in C17.4, this entire DNS infrastructure will be backed up by a parallel system of DNS servers running BIND. Once a day, zone files will be generated (from the same location as the master DNS cluster) and distributed to all BIND servers via a secure, authenticated network layer protocol such as SSL. After performing integrity checks on the received data, BIND will reload on these remote systems in a staggered manner so that no fewer than half are active and ready to respond to queries at any given moment.
Billing of registrars is critical to the financial stability of the registry. There are strict processes in place to ensure the least amount of disruption to registrars and the maximum security to the registry.
The DotOrg Foundation will sub-contract with Registry Advantage to provide billing and collection services. The decision to sub-contract this service to Registry Advantage was made due to Registry Advantage’s extensive experience operating billing and collection systems for existing registries and registrars. The Foundation will audit its sub-contractor to ensure appropriate billing practices.
To minimize the potential for disruptions caused by changes to billing procedures during the transition, the Foundation will adopt a billing procedures that are similar to those used by VeriSign, albeit with some improvements to accessibility and reporting capabilities. As is the case for the existing .org registry, registrars will receive monthly invoices, have secure access to reports through an Account Management Interface (AMI) and maintain letters of credit on file with the registry. There will be no requirement for registrars to pay using credit or debit cards and hence risk incurring additional processing fees or interest charges from credit card companies and banks.
Figure C17.6.1 Letter of Credit Process
Figure C17.6.2 Billing Process
Account Management Interface (AMI)
AMI will provide a secure web-based portal with the following functions:
The letter of credit from each registrar would be held by the DotOrg Foundation.
|<< Previous Question||Next Question >>|