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:

  • Near real-time propagation of updated domain information
  • Fault-tolerant clustering of DNS servers
  • No fixed limit to the number of zones supported by a single cluster
  • Tight coupling to the SRS repository, including the SRS interfaces for adding/changing/deleting objects and SRS security

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:

  • New York
  • San Jose
  • Hong Kong
  • London

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:

  • Asia/Pacific
  • Central region of the United States
  • Europe

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.

C17.6. Billing and collection systems. Technical characteristics, system security, accessibility. 

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.

Billing Process:

  • Each registrar would provide a letter of credit on which the DotOrg Foundation can draw in the event of non-payment of domain registrations.
  • On behalf of the DotOrg Foundation, Registry Advantage will monitor the volume of registrations daily and make a report available to the Foundation. If the monetary value of registered names exceeds 80% of the letter of credit, the Foundation will contract the registrar. The registrar can increase the letter of credit or make a pre-payment to maintain an acceptable credit balance. Once the credit limit has been reached, the registry will shut off such registrar’s ability to register further names. This would prevent the registry from having to delete unpaid names or for registrants to rely on a registrar that may be experiencing financial problems.
  • Registry Advantage will send bills to registrars on a monthly basis for the previous month’s registrations.  At the end of the billing period, the registry will compile registration data for each registrar and create an invoice.  The data would be available either by the registry sending paper or electronic documents to the registrar, or by posting the data on a secure FTP site.
  • Registrars are expected to pay the invoice in full upon receipt. Upon receipt of payment, the registry will update such registrar’s account and send confirmation of the registrar's credit balance.
  • In some cases, registrars may make partial payments pending minor disputed amounts relating to a small number of names. In these situations, the registry would coordinate with the registrar to answer questions and obtain payment for outstanding invoice amounts.
  • If a registrar were not to pay, the registry would shut off such registrar’s ability to register names. The letter of credit could be drawn on to pay outstanding amounts and in extreme cases, the registry will have the right to delete the names in question if no payment can be obtained.

 

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:

  • Setting up and administrating registrar accounts (e.g. a registrar would have a master login account and can grant additional accounts to select employees).
  • Registration transactions, similar in functionality to those provided via the RRP or EPP interfaces.
  • Registration transaction reports and on-line account statements.

Sub-contract

  • The DotOrg Foundation is sub-contracting with Registry Advantage to carry out invoicing and collections responsibilities.
  • Registry Advantage will be responsible for invoicing registrars, collecting from them, and sending the collections to the DotOrg Foundation’s account.

The letter of credit from each registrar would be held by the DotOrg Foundation.

 

  << Previous Question Next Question >>