|
(i) General description of proposed facilities and
systems. Describe all system locations. Identify the specific types of
systems being used, their capacity and interoperability, general
availability and level of security of technical environment. Describe in
appropriate detail buildings, hardware, software systems, environmental
equipment and Internet connectivity.
|
(i) General Description of Proposed Facilities and Systems
Highlights
* Highly reliable scalable registry solution through redundancy of all systems.
* High availability through 14 name server sites by June 30, 2005, and 19 name
server locations by December 31, 2005 - each with multiple name servers.
* Diverse architecture between name server locations to increase reliability,
to reduce risk of attacks and to reduce vendor dependency.
* State-of the art registry and name server facilities.
* Track record of administering the .de TLD for ten years, with over eight
million domains in October 2004.
* Long relations with carefully selected vendors and resellers ensure
exceptional service response times, fast delivery and replacement schedules,
and trouble-free test system delivery.
DENIC operates modern, high security facilities worldwide. Each of the sites
complies with DENIC's rigorous facility standards. The .net infrastructure will
be located in the same facilities as the .de infrastructure, and the new
dedicated .net RSL as well as the additional NSLs (see part 2-5-b-vi:
Geographic Network Coverage) will comply to the exact same high standards.
In this section, DENIC will describe its current service locations for .de,
which will also be used for .net, as well as additional locations dedicated to
operating the .net TLD.
Detailed descriptions are provided:
* Registry Service Locations (RSL) - see part 2-3-b-iii: Description of
Facilities
* Name Server Locations (NSL) - see part 2-5-b-vi: Geographic Network Coverage
* Service and Support Location - see part 2-5-b-vi: Geographic Network Coverage
1. Connectivity
An overview of DENIC's internal and Internet connectivity is provided in part 2-
3-b-iii: Description of Facilities.
2. Registry Service Location System Architecture
DENIC is strongly committed to best-in-class availability of its registry
services and has installed highly scalable, secure and redundant high
performance systems.
Being a not-for-profit cooperative, DENIC uses all revenues for operating,
maintaining and upgrading all infrastructure - resulting in higher levels of
investment than those of a for-profit company.
(a) RSL Network and Server Architecture
RSL layer structure
As shown in Figure 1, DENIC employs a highly stable and secure network and
server architecture with five distinct layers at both of its RSLs. Each layer
is serving a special purpose and in itself laid out redundantly. Should a
system at one location fail, its counterpart in the other location takes over.
Architecture Redundancy and Security
Having all systems installed in a redundant, load-balancing fashion allows
DENIC to deploy additional machines to scale performance. Like all other parts,
network components and paths are built redundantly. DENIC prefers to use all
resources on an equal basis, so these systems have been configured with high-
availability.
Each security layer of an RSL is connected to both inter-RSL matrix switches
for redundancy (see Figure 2).
All parts of the network have been hardened against malicious attempts through
means of access lists, optimized scheduler configuration and appropriate
Management access is closely monitored.
The feature summary of all layers is illustrated in Figure 3.
(i) External Routing Layer
The outermost layer takes care of Internet connectivity and routing. Packets
come in from the Border Gateway Protocol (BGP) peers and transit providers,
other packets leave the system. Two routers, one at each RSL site, take care of
packet forwarding and filtering. This layer also uses a third location, DE-CIX -
Germany's most important IP exchange point - where DENIC has deployed two
routers in two sub-locations for peering connections only. The components are
described in Figure 4.
The feature summary of Layer 1 is shown in Figure 5.
(ii) Perimeter Network Layer
The Perimeter Network Layer contains the perimeter defense packet filters
(Juniper Netscreen). They make sure that only desired packets can pass to the
third layer and vice versa.
The feature summary of Layer 2 is shown in Figure 6.
(iii) Service Provisioning Layer
This layer has a redundant pair of F5 load balancers, terminating all public
service network addresses on their outside interfaces.
The load balancers distribute the requests to the servers of both RSLs
according to the configured scheduling schema.
1. Load Balancers
Bandwidth: 250 kreq/s (vendor information)
220 kreq/s (tested)
10-15 kreq/s average (estimated from .de experience)
System load: 1-5%
The feature summary of Layer 3 is shown in Figure 7.
2. Registry Provisioning Front-End
The Registry Provisioning Front-End consists of several servers dealing with
incoming transaction requests.
For .net an EPP server, an RRP proxy, and potentially a web based registration
front-end for registrars will be provided.
EPP Servers, RRP Proxies hardware:
Processor 2 AMD/Opteron CPUs at 2.4 GHz
Memory 4 GB
Disk for system SW Local (RAID1)
Disk for data Local (RAID1)
Interfaces 1 Gbps Ethernet
Software Registry Provisioning Front-end Applications (EPP
server)
RRP Proxy Software (RRP proxy)
DENIC will migrate the .net TLD to a thick model based on the widely accepted
EPP protocol while offering central RRP proxy servers at its registry
locations. Registrars may continue to use RRP during the transition from
VeriSign to DENIC for a limited time.
DENIC's RRP proxy accepts incoming RRP-requests, translates them to EPP and
forwards them to the EPP-backend in the Data Provisioning Layer.
3. Registry Information Front-End
In the Registry Information front-end, DENIC currently deploys whois servers
and will add CRISP servers in the near future.
The whois service accesses DENIC's central database - via the Layer 4 firewall
and a Layer 5 mediator - so whois data is always up-to-date. Details regarding
DENIC's whois implementation are described in part 2-5-b-xii: Whois.
Whois Server
DENIC's whois runs on a cluster of servers in each RSL. Load is carefully
monitored, additional servers can be added easily as needed.
Processor 1 UltraSPARC III at 900 MHz
Memory 4 GB
Disk for system SW Local (RAID1)
Disk for data Local (RAID1)
Interfaces 100 Mbps Ethernet 4.8 GByte/s System Bus Throughput
1.2 GByte/s I/O-Bandwidth
Software Whois Server
Crisp Server
DENIC will soon start to evaluate, define, implement and deploy CRISP (RfCs
3981-3983) parallel to whois. The server requirements are similar to those of
the whois service. Exact system specifications will be decided upon
introduction of the service.
4. Communication Servers
DENIC deploys web, FTP and e-mail servers in the Service Provisioning.
Web / FTP Servers
DENIC uses two Web / FTP and two e-mail servers distributed over both RSLs with
a load balanced setup.
Processor 2 UltraSPARC IIIi at 1.3 GHz
Memory 4 GB
Disk for system SW Local (RAID1)
Disk for data Local (RAID1)
Interfaces 1 Gbps Ethernet
Software Web Server, FTP Server (web servers)
SMTP Server (e-mail server)
The feature summary of the servers in Layer 3 is shown in Figure 8.
(iv) Internal Network Layer
This layer separates the service from the Data Provisioning Layer, guarding the
back-end application and the database systems from all unauthorized access
attempts. Only few access relations are permitted, like from a whois server to
its database application server. The same close control applies to outgoing
packets.
Feature Summary
Extensive Redundancy / High Availability
* Packet filters in HA configuration
* Redundant links to switches
Advanced Security
* State-of-the-art packet filtering
* Stateful inspection
* Typical-attack defenses
* Tight policies
(v) Data Provisioning Layer
Systems in this layer make the registry databases accessible to the Service
Provisioning Layer applications. This layer is home to the interfacing
applications, the request processing systems, and the database systems
themselves.
1. Application Servers
The application servers in Layer 5 generally host several similar applications.
These high performance servers can be extended by adding additional components
to the hardware. They are not load balanced but operated in failover and
cluster configurations.
Processor 4 Ultra SPARC III at 1.2 GHz
Memory 16 GB
Disk for system SW Local (RAID1)
Disk for data Local (RAID1), HDS, SAN
Interfaces 1 Gbps Ethernet 9.6 GByte/s System Bus Throughput
1.2 GByte/s I/O-Bandwidth
Software List Generators, EPP-Backend, Whois-Backend
Registry Provisioning Backend
All .net requests coming in via RRP-, EPP- and a possible web based
registration server are converted to EPP in Layer 3 and forwarded to the Data
Provisioning Layer to be processed by the EPP-Backend on the application
servers described above.
Registry Information Backend
In the Registry Information Backend DENIC currently provides whois and will add
CRISP backends in the near future.
List Generation Servers
The application servers also host a variety of list generation applications:
* Zone File Generation - see part 2-5-b-vii: Zone File Generation
* Report Generation - see part 2-5-b-xix: Support and part 2-5-b-ix:
Billing and Collection
* Escrow - see part 2-5-b-xi: Escrow.
2. Database and Replication Servers
Database and Replication Servers are described in detail in part 2-5-b-v:
Database Capabilities.
(b) RSL Out of Band Management Network
Covering both RSLs and all NSLs, DENIC has implemented an out-of-band (OoB)
management network. This network is shielded from the outside world, without a
routing or packet forwarding path from/to the Internet or any of the layers 1-5
above.
Geographically remote parts of the management network are always connected
through encrypted VPN tunnels. This has two advantages: first, all
communication is encrypted, second, VPN tunnels become independent of physical
connectivity. As long as the sites can reach each other and exchange IPsec
packets, VPN connectivity is available.
The OoB management network connects administrative interfaces of all networking
and infrastructure components and makes them accessible to a group of
management servers.
(c) RSL Storage Area Network
At DENIC the SAN connects the database servers to a high-end storage subsystem
supplied by Hitachi Data Systems, designed to allow all changes to be done
without any interruption of services and applications.
The SAN infrastructure is designed with no single-point-of-failure (SPOF). A
redundant SAN infrastructure, based on high-end storage subsystems, guarantees
a designed-in availability of >99.999%. Due to the two location strategy it
also prevents loss of data in case of a disaster at the primary site.
Figure 9 shows the SAN Infrastructure at DENIC and the distribution of
components between the two RSLs.
The SAN components have the characteristics described in Figure 10.
Feature Summary SAN
Availability of Services
* State-of-the-art infrastructure based on High-End-Storage, redundant SAN-
fabrics, components and server systems from leading vendors
* Redundant access to data through dual-path server connection, mirrored or
replicated data on two (or more) locations and a redundant physical
infrastructure
* Opportunity to add capacity, connectivity, servers and physical connections
with no downtime
* Enterprise service and support strategy with 24/7/365 hardware monitoring and
maintenance on Gold and Platinum-Level for all critical components in
combination with solution support through external system provider
Guarantee of Security
* Best-in-class security standards through use of security features like LUN-
Mapping, Zoning and WWN-Binding within the SAN
* Use of the exceptionally secure Fiber Channel protocol
3. Name Server Locations System Architecture
The NSLs have been re-implemented in 2004 with robustness, performance and
extensibility in mind. At normal query rates, no component of an NSL is under
more than 5% system load, thus providing for at least a fifteen fold increase
of query and/or packet rates in peak times or during DOS attacks.
(a) NSL Production Architecture Overview
The NSL production architecture is described in detail in part 2-5-b-ii:
Stability and Performance.
(b) NSL Management Architecture
In the NSL Management Layer, DENIC maintains a separate IP connection to a
qualified and reliable transit provider. The line is being terminated by a VPN
device keeping up encrypted tunnels to the VPN tunnel hubs at the RSLs. Through
this VPN connection the site's management network is connected to the RSLs' OoB
management network. Management interfaces are reachable through this VPN
connection only, there is no connection to the public Internet.
VPN traffic is filtered and monitored thoroughly. An NSL's management
interfaces can only be accessed from the management servers and from within the
NSL itself. This way, a compromised machine at one NSL does not pose a threat
to any other NSL. The architecture of DENIC's NSL Management Layer is shown in
Figure 11.
(i) Central NSL Management within RSL OoB Management Network
DENIC's OoB management network has been described in detail above as part of
the RSL architecture. The central NSL management is located within this RSL OoB
network.
As NSLs are more exposed than RSLs, security is the prime concern. This is
achieved by encrypting management traffic and allowing management access from a
high-availability pair of NSL Management servers that take care of
monitoring/reconfiguring the components and distributing service information
like zone files.
Central NSL Management Servers
Processor 2 Intel CPUs at 3 GHz
Memory 16 GB
Disk for system SW local (RAID1)
Disk for data local (RAID1)
Interfaces two 1 Gbps Ethernet
Software Zone Distribution, Monitoring, Log collection, MRTG,
Nagios, NSL Management
(ii) NSL OoB Management Layer
Loghost
The loghost serves as an admin access point for the NSL. Its tasks are:
* Collect system logs
* Update zone files on name servers
* Serve as backup for monitoring
* Serve as backup for real time updates to routers / load balancers.
All name servers within the NSL can replace the loghost, so in case of a
loghost failure, one of them will take over.
Console Server
The NSLs console server allows DENIC's engineers to reach the serial console
ports of all components at the NSL. Console functionality has been enabled on
all servers, too, to be able to correct configuration problems in case the
machines do not boot up properly or fail.
Remote Power Switches
DENIC has added remote-controlled power switches to the NSL. In case of a
problem that cannot be solved through network or console access, every
component can be remotely power-cycled.
The components in the NSL OoB Management Layer have the characteristics
illustrated in Figure 12.
Feature Summary NSL OoB Layer
Extensive Redundancy / High Availability
* Redundant VPN tunnels
* Additional emergency access via modem
* Redundant access paths via Console and Ethernet
Excess Capacity
* External line burstable to 100 Mbps
Advanced security
* State-of-the-art packet filtering
* Stateful inspection
* Tight policies (in and out) to shield against insider attacks
5. Network Management
(a) RSL Out-of-band management
All network equipment is managed out-of-band only. All machines have been
equipped with appropriate filters and access lists to only allow management
access (telnet, ssh, SNMP, http) via their dedicated management interface.
Access is only allowed from a small range of addresses within the RSL
management network. This prevents external as well as unauthorized internal
access.
Console server access is also only available from this small range of IP
addresses.
Every RSL location uses a VPN tunnel gateway to build encrypted tunnels to the
management network. Most of the time, VPN traffic will stay on DENIC's own
network. Only in case of a link failure, traffic will traverse transit or
peering providers' networks.
(b) NSL Out-of-Band Management
Maintenance, configuration and internal monitoring of a machine can only be
done over its management interface.
For security reasons the NSL OoB management network cannot be reached from the
public Internet; it is only reachable from the RSLs' OoB management networks
via secure VPN tunnels (see Figure 13).
Even so, configuration and monitoring of an NSL's machines can only be
performed from the NSL management machines. This policy is enforced by strictly
filtering the VPN tunnel traffic on both the RSL and the NSL sides.
(c) NSL Emergency Operation and Limits
In case of a VPN or transit provider failure disabling VPN access, the service
delivery network will be undisturbed and the site will still deliver service.
DENIC's engineers can reach the site through a modem connection to the NSL's
console server. This does not provide a way to update the information on the
site's servers (e. g. DNS zone data), but it can be used as an emergency device
for analysis and - if the data goes out of sync - shutting down the NSL's
services.
A failed NSL will not pose a problem for DNS services - neither with anycast
nor with unicast setups. For anycast NSLs, once removed from the global routing
table, another anycast NSL will pick up the traffic. The same holds with
unicast NSLs, as DNS has been designed to just skip slow or unresponsive
servers and query the ones that are working well.
6. DENIC Test Systems
In order to effectively and securely introduce new hardware and services, DENIC
is operating a sophisticated test infrastructure. Both for RSL as well as for
NSLs, a complete dedicated setup is installed in DENIC's headquarter location.
(a) RSL Test Architecture
(i) Internal Test Infrastructure
In its primary location DENIC has installed a complete RSL infrastructure,
accessible for authorized DENIC developers, system administrators, and QA staff
only (see Figure 14). Details about DENIC's four stage database environment are
described in part 2-5-b-v: Database Capabilities.
(ii) Registrar Test Infrastructure
Once cleared by the intensive internal testing new developments are entering
the registrar testing phase. Registrar testing is performed on dedicated
systems in the production network. Network components are shared with the
productive systems. All testing on database servers happens strictly on
dedicated and completely separate test systems absolutely equivalent to the
production architecture.
(b) NSL Test Architecture
To allow testing of new features, rolling out new services or observing the
results of configuration changes, DENIC hosts a lab NSL, fully featured in
every respect, so that every change to NSL setups can be tested in a real
production-like environment without impacting public services.
Once upgrades or changes have proven their positive outcome in the lab setup,
they are deployed to the "real" NSLs. Since the lab NSL resembles a production
NSL - independent Internet routing, VPN tunneling, all equipment - the results
obtained here are valid for the "real world". |
|
|
(ii) Stability of resolution and performance
capabilities, including: response times and packet loss targets;
availability of authoritative name servers; processes, tools and automated
monitoring to ensure accuracy of zone data for resolution; diversity of
DNS infrastructure; diversity and redundancy of network and DNS
infrastructure to handle bandwidth congestion and network failures of ISPs
and host providers.
|
(ii) Stability of Resolution and Performance Capabilities
Highlights
* Inter location diversity
* Intra location redundancy
* Scalability through anycast setup
* DNS quality measures
* Independent monitoring
1. DNS Infrastructure
The full range of DENIC's DNS infrastructure is described in detail in
* Part 2-3-b-iii: Description of Facilities (Connectivity)
* Part 2-5-b-i: Facilities and System (NSL System Architecture).
(a) Name Server Locations (NSLs)
NSLs are designed to provide name server services for every incoming query.
DENIC operates all its name servers compliant to the Best Current Practices for
root name servers RFC2870. Specifically, DENIC complies with
* technical requirements (paragraph 2)
* location security requirements (paragraph 3.1)
* network security (paragraph 3.2)
* protocol security (paragraph 3.3)
defined in the aforementioned RFC2870.
Currently, NSLs exist at eleven locations around the world and deliver DNS
service for the .de TLD. For .net DENIC will have 14 name server locations -
the eleven existing .de locations plus three additional locations in North
America - operational by June 30, 2005, and 19 locations by December 31, 2005.
Details about planned .net name server locations and the implementation
schedule are described in part 2-5-b-vi: Geographic Network Coverage.
All NSL setups have been installed at professional high-quality hosting sites
with extensive backup systems for cooling, electricity and security. DENIC has
contracted its current eleven name server sites to ten different hosting
companies, ensuring an unmatched provider diversity. Their specifications match
those of the COLT Internet Service Center (ISC) described in part 2-5-b-iii:
Description of Facilities. NSLs are placed with are DENIC eG, DE-CIX, B-CIX,
Deutsche Telekom, VIX, Netnod, AMS-IX, LINX, MCI Worldcom and Savvis.
Details about DENIC's multi-vendor strategy are described in part 2-7-ii:
Multiple Suppliers.
(b) NSL Connectivity
(i) Internet Connectivity
DENIC has estimated typical traffic levels at about 1-2 Mbps. Connectivity can
be bursted to at least 100 Mbps to cater for high-load scenarios. In some
places, DENIC will also accept peering connections from interested parties also
hosted in the same hosting facility or connected to an Internet exchange point
nearby.
DENIC has chosen the hosting and connectivity providers for their proven
professionalism, stability and experience. Assessing the long term stability of
the provider was a key component in order to ensure that the provider would not
vanish from the market. This way, DENIC profits from those providers improving
their own networks.
(ii) Internal Connectivity
The .net name servers at the NSL co-located to the primary RSL are connected
to each other and the DECIX routers via the DENIC LAN backbone. All other name
server sites can be reached for management purposes from each of the RSLs via a
secure VPN.
These second and completely separate connections to the name server locations
are used for network management purposes, including remote administration of
name servers, updating zone files, maintenance and monitoring of systems. The
VPN access is built to allow for abundant excess capacity to always ensure fast
and secure management access to the name server locations.
(c) Diversity of NSL Architecture
(i) NSL Architecture Overview
The NSLs are designed with robustness, performance and extensibility in mind.
At normal query rates, no component of an NSL will be under more than 5% system
load, thus providing for enough excess capacity for query and/or packet rates
in peak times or during DOS attacks.
DENIC employs two major principles for its name server setup in order to ensure
absolute stability: intra-location setup equivalence and inter-location setup
diversity. Thus, redundant components within one location are absolutely
equivalent, while setups between locations differ.
At each of its initially eleven worldwide locations DENIC will deploy three
identical name servers. Server redundancy thus exists within one location as
well as between the NSLs. This setup results in a high availability worldwide
and fast response times, with outages being virtually inconceivable.
Across its locations DENIC uses three different server hardware types and
employs both unicast and anycast technology in the network layer. Altogether
five location architectures are currently deployed by DENIC, see Figure 1.
On top of the diversity in hardware DENIC has installed three different name
server implementations in all of its NSLs. One of these implementations is
productive, with the other two serving as backup. Should security
vulnerabilities be discovered (DENIC stays in close contact with vendors and
incident response teams), one of the backup implementations can immediately be
started and ensure the availability of that specific NSL. As different types of
software are running in the different NSLs, DENIC's NSLs cannot be attacked in
their entirety.
The additional .net NSLs will be integrated into DENIC's diversified NSL setup
strategy. Figure 2 shows the NSL architecture for the anycast setup. The
unicast setup differs only by deploying a load balancer instead of the router
in the External Network Layer.
In summary, the NSL architecture sports the features described in Figure 3.
(ii) External Network Layer
Most of the NSL infrastructure is identical for both anycast and unicast
setups. There are multiple service machines installed, to which service
requests are given load-balanced. If one machine or service instance fails, it
will be removed from the load balancing sets. The basic difference lies only in
the setup of the external network layer.
1. Unicast NSL
Unicast NSLs are connected to the Internet through an upstream provider. Figure
4 illustrates the External Network Layer which consists of a load-balancer that
terminates the service IP addresses and forwards service requests to the
appropriate machines in the Service Provisioning Layer.
The components in the load-balanced external network layer have the following
characteristics:
Load Balancer
Forwarding Rate: 250 kreq/s (vendor information)
220 kreq/s (tested)
System Load: 1-3% (estimated from .de experience)
2. Anycast NSL
Anycast NSLs have been designed to insert themselves into the global network.
The services here run on addresses from a freely routable IP network, one and
the same for each anycast NSL. This network is being inserted into the global
Internet routing table by Border Gateway Protocol (BGP) announcements from the
router that makes up an anycast NSL's External Network Layer. The service
addresses are not being terminated on the router, but are being routed, in a
load distributing fashion, to the service machines in the Service Provisioning
Layer.
As all anycast instances share the same name, only six different names for
authoritative servers exist. This reduces the space occupied by name entries in
DNS response packets, leaving more room for address records (additional data)
while still not exceeding the 512 octet limit.
The anycast setup for the External Network Layer of NSLs is shown in Figure 5,
excl. management access.
The components in the anycast External Network Layer have the following
characteristics:
Anycast Router
Bandwidth: (no vendor information provided)
400 Mbps sustained (maximum tested, no service impact)
1 Mbps sustained, 3 Mbps peak (estimated from .de
experience)
Forwarding Rate: 500 kpps (vendor information)
350 kpps (tested with small packets, no service impact)
System Load: 1-5% (estimated from .de experience)
3. External Network Layer - Type Differences and Common Features
An anycast NSL may vanish and reappear in the Internet routing tables without
the public noticing, provided the remaining systems are still performing.
While the number of unicast NSLs is limited, owing to DNS/UDP response packet
sizes, adding an anycast NSL does not change the list of DNS servers for the
TLD, so DENIC is free to increase the number of anycast NSLs as they become
necessary.
In summary, the NSL External Network Layer sports the features described in
Figure 6.
(iii) Service Provisioning Layer
Intra-Location Equivalence
Each of the NSLs is initially equipped with three active name servers and one
loghost. Within one location all name servers have exactly the same hardware
and software setup. This intra-location equivalence ensures location stability
and facilitates easy administration and maintenance. Should the need for
increased DNS resolution capacity occur, DENIC will deploy additional name
servers in the NSLs - each of which can host a maximum of eight name servers.
Inter-Location Diversity
To minimize the entire NSL construct's sensibility to operating system,
application or hardware-induced problems, different types of server hardware
and operating systems are installed in different NSLs alongside varying
versions of the application software. The differences include:
* three different server hardware types and operating systems
* three different DNS-Software implementations (BIND8, BIND9, NSD)
* IPv4 and IPv6.
This multilevel diversity increases the stability of the entire name server
system, reduces the risk of attacks as well as vendor dependency. Concrete
advantages of application layer diversity are:
Hardware
* If a problem with one hardware platform occurs, the whole system nevertheless
stays operational
* Reduced dependency from one hardware vendor
* The system has increased stability against attacks
* Increased ease of hardware upgrades.
Software
* Diverse software is harder to attack in its entirety
* Software errors have less impact on the system as a whole
* Upgrades and patches are easier to implement.
The induced performance differences between the NSLs are compensated for
through installation of a different number of service machines in different
NSLs - depending on the hardware and software setup.
The name servers in the Service Provisioning layer have the characteristics
described in Figure 7.
In summary, the NSL Service Provisioning Layer sports the features shown in
Figure 8.
2. Stability and Performance of DENIC's Resolution Capabilities
(a) Stability of DNS Resolution
Current DNS Resolution Volume of DENIC and Ability to Handle .net DNS Volume
Figure 9 to Figure 13 show the development of DNS requests to DENIC's .de name
servers over the past year on a requests per minute scale.
Figure 9: DNS Requests in a One-Year Period (2004)
Figure 10: DNS Requests in a One-Month Period (November 2004)
Figure 11: DNS Requests in a Two--Day Period (November 29 to December 1,
2004)
Figure 12: DNS Requests in a One-Day Period (December 1, 2004)
Figure 13: DNS Requests in a Two--Hour Period (December 1, 2004: 2 p.m.-4
p.m.)
As described in part 2-5-b-vi: Geographic Network Coverage DENIC will expand
its NSL network for .net by eight additional locations to then 19 locations
worldwide - increasing DNS resolution capabilities even further.
Given the tremendous experience, the demonstrated ability to handle large DNS
request volumes, and the committed investment volumes DENIC believes to have
proven beyond any doubt its ability to handle the .net DNS request volume as
well.
Name Server Availability
DENIC's "multiple name server per location" concept and inter-location setup
diversity ensure highest availability of DENIC's DNS resolution capabilities.
DENIC therefore commits to a total DNS resolution uptime of 99.999% for .net.
For a complete set of SLAs please refer to DENIC's suggestion in Appendix D:
Performance Specifications.
(b) Response Times for DNS Requests
Currently DENIC serves the .de community with response times for DNS resolution
requests of less than ten milliseconds (excluding round trip time) for more
than 98% of DNS queries. DENIC commits to the same value for .net.
For .net DENIC will have 14 NSLs by June 30, 2005 and 19 NSLs by December 31,
2005 distributed around the world, thus providing excellent DNS infrastructure
to minimize round trip times from every location in the world.
(c) Packet Loss Targets
DENIC has the following internal targets for packet loss:
* << 1% packet loss in DENIC internal infrastructure at normal load
* < 1% packet loss in DENIC internal infrastructure at ten times normal load
As packet loss can occur anywhere in the connection, DENIC can not make any
commitment regarding the actual packet loss within any connections, as the
user's connectivity generally represents the bottleneck.
DENIC uses the results provided by the RIPE NCC's dnsmon project as
representative source for packet loss measurement, see .de domain data at
http://dnsmon.ripe.net.
3. Accuracy of Zone Data
DENIC's high DNS data quality has been documented in several studies, for
instance in an ITU paper (http://www.itu.int/itudoc/itu-
t/workshop/cctld/cctld046.pdf). Men & Mice, a well known Iceland based DNS
consultant, has conducted several TLD surveys proving high .de DNS data quality
(see http://www.menandmice.com/6000/6350_eu_survey.html), too.
These positive reports about DENIC's zone accuracy and DNS quality are the
fruit of extensive checks of data and zone files and continuous monitoring of
all transaction and update processes.
Specifically DENIC uses the following checking mechanisms:
* Pre-delegation checks for accuracy of each domain (working connection to name
server)
* Sanity checks of generated zones
Additionally DENIC monitors all steps in generating and distributing zone files
to the NSLs around the world.
(a) Pre-Delegation Checks
Pre-delegation checks are mandatory for every .de domain. Upon registration,
update, or renew, DENIC will check whether the registered domain is technically
supported. A negative result will bring the domain into "expirable" status. The
registrar will be informed of the expiration date (four weeks) until which the
registrar can correct the delegation data. Failure to do so results in the
deletion of the domain. This process prevents lame delegations and is one
reason for DENIC being able to provide an outstanding zone quality of the .de
zone.
For .net pre-delegation checks will not be mandatory but offered as an
additional service free of charge to registrars. Pre-delegation checks can be
performed for every <create>, <update> or <renew> command for a domain object.
The checks may either be passed successfully, with a warning or an error
result. If the registrar has chosen to sign up for the optional checks, all
errors need to be fixed before the command will be processed by DENIC.
DENIC is offering an online interface for checking conformance with the
requirements at http://zonecheck.denic.de/ as well as the software (AFNIC's
zonecheck) and configuration for download.
(b) Sanity Checks
Besides pre-delegation checks DENIC will improve its domain name registration
service quality furthermore with the following sanity checks:
* Name server operators can request a list with all domains delegated to their
name server(s).
* Everyone can inform DENIC about technical issues in regarding a domain
delegation. DENIC will carry out the pre-delegation test and inform the
relevant registrar if the test result is not positive.
(c) Zone Consistency Checks
DENIC's extensive consistency checks of the complete zone file are described in
detail in part 2-5-b-vii: Zone File Generation.
(d) Monitoring
To ensure accuracy and quality of zone data DENIC monitors the zone both during
generation and distribution as well as during operations:
* Monitoring of zone file generation and distribution - described in part 2-5-b-
vii: Zone File Generation and part 2-5-b-viii: Zone File Distribution and
Publication
* Monitoring of zone accuracy and quality on operating zones - described above
(RIPE NCC dnsmon) |
|
|
(iii) Operational scalability sufficient to handle
existing registry database and projected growth; DNS queries including
peak periods and projected growth; DDoS attacks, viruses, worms and spam;
and restart capabilities.
|
(iii) Operational Scalability
Highlights
* DENIC already has more than ten years experience in successfully handling
large databases and processing huge volumes of transactions.
* DENIC will use a database system for .net which is similar to the .de system.
* The current system has enough excess capacity to handle 16 million domains
which equals more than three times the number of.net domains registered today.
Thus, the DENIC system will be dimensioned to handle the expected growth of
the .net domains with sufficient headroom (i.e. about eight million domains
until 2011).
* DENIC is able to quickly respond to any higher growth by e.g. adding further
system components to the expandable system infrastructure.
* DENIC regularly monitors and assesses the current capacities of the registry
database. Considering results, DENIC is able to anticipate the need for
critical resources well in advance and decide on increases in system capacity
e.g. system modifications, extensions or changes in the system architecture at
an early stage.
* DENIC will reserve a capacity of five TB on DENIC's primary HDS for its .net
database, providing scalability for more than 2500% of the current database
size.
* The registry database is not directly accessible from the outer network.
Viruses, worms, spam or (D)DoS attacks will not affect the database as DENIC's
well-established, extensive filtering mechanisms block these attempts.
* DENIC protects its namsystem against (D)DoS attacks and worms by providing
very high excess capacities for all relevant components and a highly scalable
system.
* DENIC implements extensive e-mail filtering procedures and conducts
comprehensive virus analyses.
* To remain informed about security problems and issues as well as to enhance
its proactive defensive procedures against e.g. (D)DOS attacks, viruses, worms
and spam, DENIC receives and monitors various security and full disclosure
mailing lists provided by CERT or other parties (e.g. vendors).
1. Handling of Existing Registry Database and Projected Growth
DENIC has already acquired more than ten years experience in successfully
handling large databases and processing huge volumes of transactions. By
constantly monitoring, modifying and upgrading the components of the database
system, DENIC was able to reach the current system performance.
As the current database system for the .de registry has proven to be highly
scalable and stable, DENIC will implement a similar database system for .net.
The .net system will be running on a comparable, but completely separate
infrastructure.
Please refer to part 2-5-b-i: Facilities and Systems for a detailed description
of the planned .net RSL architecture and part 2-5-b-xiv: Peak Capacities for
additional information on scalability and excess capacity of the system
components. In addition, part 2-5-b-v: Database Capabilities provides an
overview of the registry database specifications.
(a) Handling of the Existing Registry Database
As for .de, DENIC will operate a redundant architecture for the .net database
as it has proven to be reliable under all conditions.
The size of the current .de production database is 169.7 GB for more than eight
million registered domains with the largest table containing 170 million
records. The database server setup contains eight CPUs and 48 GB main memory.
Within the DENIC system, the database will be located in a high-performance
mass storage system HDS.
Even the introduction of IDN which caused a peak load of more than 625,000
registration requests in the first two days, was handled without any
performance deterioration.
Please refer to part 2-5-b-v: Database Capabilities for further information on
database specifications and part 2-5-b-xiv: Peak Capacities for details on IDN
registration and handling of peak loads.
Scalability
As for .de, the .net database infrastructure will be easily and quickly
scalable. The database server can be expanded without having to make changes to
the infrastructure. To be able to also cover a higher-than-projected demand,
servers with a higher capacity can be added to the infrastructure.
Also the bound caches of the database servers for tables and indexes can be
expanded up to the full extension of the UNIX server memory as the total size
of the cache is limited by its memory size. The architecture and program
interfaces are highly flexible to accommodate changing needs. Also the database
system's peripherals such as the mass storage system or the backup system are
highly scalable so that the .net data volume can be administrated. In the
backup system, the number of tape drives is scalable from eight to 32, the
number of tapes AIT-3 from 147 to 645 and the data capacity from 14.7 to 64 TB.
Currently, only 50% of the available 14.7 TB are in use.
For the .net primary RSL and for the .net backup location, DENIC will allocate
a disk capacity of 5 TB each. Compared to the current combined database size,
DENIC will thereby provide an excess capacity of more than 2500% of the current
database.
As the current average engine busy utilization of the active database is at or
below 40% today and less than 10% for the standby database, the .net system
will be equipped with large excess capacity to cover the expected number
of .net registration requests.
Please refer to part 2-5-b-v: Database Capabilities for details on the database
architecture and systems, part 2-5-b-x: Backup for backup system specifications
and scalability and part 2-5-b-xiv: Peak Capacities for further information on
the database system scalability.
Capacity Planning
DENIC conducts regular assessments of the current capacities of its registry
database (also network and other system components). During the budget planning
phase, DENIC creates a 2-year plan for its IT architecture which is revised
yearly. DENIC especially assesses whether assumptions and planned capacities
have to be redefined.
DENIC also monitors the whole database system in detail to early identify peak
loads or increases in workload. Automated monitoring programs interpret the
level of the critical values. According to the integrated escalation scheme,
the monitoring system automatically sends notifications whenever the defined
threshold values per component are exceeded. DENIC immediately reacts to these
notifications by conducting root cause analyses.
Considering the monitoring results, DENIC is able to anticipate the need for
critical resources well in advance and to decide on increases in system
capacity e.g. system modifications, extensions or changes in the system
architecture at an early stage. DENIC also holds regular meetings to develop or
enhance the system architecture.
Please refer to part 2-5-b-xvi: System Outage Prevention for details on
monitoring.
(b) Projected Growth
For the .net registry, DENIC will build up a system which is similar to the
existing .de system. The current registry database has enough excess capacity
to handle 16 million domains which equals more than three times the current
number of registered .net domains today (i.e. about five million domains).
DENIC currently expects the number of .net domains to grow about 60% until 2011
according to the medium demand scenario of the business case. This equals about
eight million domains by 2011.
Therefore, the planned .net registry system will be dimensioned to handle the
expected growth of the .net domains with sufficient headroom. As DENIC
constantly monitors the growth of the .net domain number, DENIC is able to
quickly respond to any higher growth by e.g. adding further system components
to the expandable system infrastructure.
Please refer to part 2-4: Revenue and Pricing Model for a detailed description
of the business case scenarios.
2. DNS Queries Including Peak Periods and Projected Growth
DNS Queries and Peak Periods
As for .de, DENIC will operate the .net name servers compliant to the standard
for root name servers (RFC2870, paragraph 2.3).
It is part of DENIC's security and stability policy to keep the load of the
database system components very low. DENIC committed itself to use 1.5% of the
server response capacity under normal conditions and 5% under peak conditions
at maximum. Therefore, DENIC currently exceeds the requirement set by RFC2870.
In addition, DENIC's comprehensive and highly effective monitoring system early
identifies peak loads on servers. Thus, DENIC is able to adapt the components
to the needs as required. DENIC also counteracts peak periods or increases in
demand by constantly upgrading of the hardware components.
Projected Growth of DNS Queries
Over the past ten years, DENIC continuously tracked the number of queries at
all .de name servers. Thus, DENIC expects a doubling of the number of queries
every 3-4 months in the long run.
DENIC is also aware of the fact that new DNS uses or features like DNSSEC or
Anti-Spam DNS-records are likely to further increase the query rate. Therefore,
DENIC actively participates in relevant IETF working groups and will consider
and point out operational consequences.
To ensure that the workload of the servers does not exceed 5% in peak periods,
DENIC will regularly adapt its capacities to the projected growth.
3. (D)DoS Attacks, Viruses, Worms and Spam
DENIC receives and monitors various security and full disclosure mailing lists
provided by CERT (Computer Emergency Response Team) or other parties (e.g.
vendors). To remain informed about security problems and issues as well as to
enhance its proactive defensive procedures, DENIC subscribed to dCERT several
years ago, a professional service offered by T-Systems which is a subsidiary of
Deutsche Telekom AG. dCERT regularly distributes up-to-date information on
viruses, worms, security gaps or software bugs as well as possible solutions to
the subscribers. (Please refer to http://www.dcert.de/index_e.html for further
information.)
According to the priority of any issues related to (D)DOS attacks, viruses,
worms and spam, DENIC's System Administration and Operations Team react to the
messages and discuss appropriate procedures or solutions to protect against
these threats.
To further protect its systems against attacks, viruses, worms or spam, DENIC
also made comprehensive maintenance agreements with all software suppliers to
receive relevant software upgrades when available.
In a current architecture upgrade initiative, DENIC will introduce multiple
GBit connectivity and the appropriate new routers in order to enhance its peak
capacities to effectively survive (D)DoS attacks. In addition to the enhanced
network capacity, new SLAs with the ISPs ensure a quick response to protect the
critical infrastructures.
Registry Database
As DENIC's registry database is located in layer five of the system
architecture (see also part 2-5-b-i: Facilities and Systems), it is not
directly accessible from the outer network. Viruses, worms, spam or (D)DoS
attacks will not affect the database as DENIC's well-established, extensive
filtering mechanisms block these attempts (see part 2-5-b-xiii: Security for
details on filtering). The reaction to malicious queries is always part of the
extensive testing all production software has to pass.
A comprehensive monitoring of the system components enables DENIC to quickly
identify potential attacks against the DENIC system and analyze the source of
the attacks.
DNS Queries
DENIC protects its name service against (D)DoS attacks and worms by providing
very high excess capacities for all relevant components and a highly scalable
system. As a consequence, the load per component is kept very low even under
peak conditions. For example, the servers only use 1.5% of their full response
capacity under normal and 5% under peak conditions. By providing these
capacities, DENIC has fundamental reserves to compensate for attacks and to
ensure a name service availability of 99.999%.
NSL Monitoring and Overload Detection
DENIC defined normal query rates for any NSL as well as for any server within
the NSL. All NSL query rates are permanently monitored. Whenever a query rate
exceeds the dynamically determined threshold value for more than a defined time
period, a notification of this occurrence is sent to the Operations Team.
DENIC automatically starts an internal analysis of the occurrence. The gathered
data is filtered, sorted and analyzed. All results are forwarded to the
Operations Team which then has to evaluate whether an attempt to overload one
site or a (D)DoS attack on parts of the NSL structure or the entire NSL
structure takes place.
Based on the results of the problem analysis, the DENIC Operations Team takes
various actions, e.g. block the address ranges where the attacks came from.
(D)DoS Attacks on Networks
DENIC counters (D)DoS attempts in three ways. All systems are designed to
handle excessive load. By providing these excess capacities, DENIC caters for
simply answering the incoming requests instead of only relying on network
mechanisms to block and filter unwanted connections.
The second way of dealing with attempts to overload the DENIC network concerns
the network management and traffic engineering. As soon as attack sources are
detected and grasped by the network, the incoming packets are already blocked
in the External Network Layer. In addition, routes are blackholed as needed and
traffic shaping is applied.
DENIC also counteracts the attempts by trying to stop them at the source.
Therefore, DENIC cooperates with the NOCs of ISPs, either source or transport
network owners.
The first way is the most important one in case of (D)DoS attempts, since there
are too many sources to effectively filter or contact.
Viruses and Worms
Viruses and worms mostly affect DENIC's office environment, since this part of
the network contains user workstations which are prone to these kinds of
attacks. These workstations have no transparent access to DENIC's server
systems. Viruses or worms appear in the office network only, if they were able
to pass the office e-mail server's control mechanisms and the workstations'
regularly updated virus detectors.
DENIC uses highly effective virus detection software to identify viruses and
worms, and, if not removed automatically, to announce them to the workstation
administration group. The group then immediately starts the manual process of
cleaning any infected workstation. DENIC has never encountered a virus or worm
spread through the office system to date. This was mainly due to the
administrators' short response time.
For further details, please refer to part 2-5-b-xiii: Security.
Spam e-mails
The DENIC system uses four entrance servers to handle incoming e-mail traffic.
DENIC implements extensive state-of-the-art filtering and blocking procedures
to avoid that the servers are attacked by spam e-mails. In addition, DENIC
conducts comprehensive virus analyses.
4. Restart Capabilities
DENIC made comprehensive arrangements to be able to quickly restart its systems
or components in the event of an outage. Non-critical systems can be restarted
automatically, whereas critical systems have to be started manually e.g. to
avoid inconsistencies.
For the event of an outage of the system or system components, DENIC ensures
the 24/7/365 availability of the required personnel who is able to perform the
appropriate restart procedures. A detailed description of the support concept
including the incident and resolution policies is available in part 2-5-b-xix:
Support.
All authorized technical employees regularly participate in practical training
sessions which focus on restarting the whole registry system or components of
the system. The training also covers the switchover process between the primary
and secondary RSL.
See also part 2-5-b-i: Facilities and Systems for a detailed description of the
system setup, architecture and redundancy, part 2-5-b-v: Database Capabilities
for details on the switchover process, part 2-5-b-xvi: System Outage Prevention
for details on system redundancy, part 2-5-b-xviii: System Recovery Procedures
for details on restarting of the system. | |
|
(iv) Describe the registry-registrar model and
protocol; availability of a shared registration system, including
processing times for standard queries (add, modify, delete); and duration
of any planned or unplanned outages.
|
(iv) Registry-Registrar Model and Protocol
Highlights
* DENIC will offer a thick registry model for .net.
* DENIC's .net registry will support EPP natively.
* DENIC will support a smooth transition for registrars using RRP by
implementing and supporting an RRP to EPP proxy for a period of time.
* DENIC is committed to implementing new additions to the standards as the
community accepts them.
Responsibilities of Registry and Registrars
Every domain registry is responsible for the registration of domains, serving
the community and delivering equitable, just, honest and competent services.
Beyond these common goals there are different ways to organize a registry's
work in general and the cooperation with the registrars in particular.
DENIC sees its main responsibility in maintaining a reliable, stable, and cost
effective registry system with equal access to all registrars, and providing
transparent and comprehensive information to the Internet community.
It is the task of the registrars to deal directly with the registrants, to
offer them various services, provide them with direct support, act on behalf
of their customers and forward their domain applications to the registry. As
the registry provides reliable, secure, high-capacity systems and takes care of
the technical infrastructure which is needed for running a TLD, the registrars
can fully concentrate on the services for and direct interaction with the
registrants.
1. Registry Model
Thick vs. Thin Model
Domain registries follow either the "thick" or the "thin" model for conducting
registrations of domains.
With the "thin" model, only the operational data about each domain is stored in
the central registry database while all contact data is maintained by the
registrar who currently sponsors the domain name. The registry only knows the
mapping from a domain name to a registrar, and knows about the name servers.
whois services operated by the registry publish that mapping; the registrant's
identity is then published by the registrar.
With a "thick model" the registry contains both the operational data for the
domain and the contact data. Domain data is not stored by the registrars any
longer but held up in the central registry database. Thus the registry's whois
service publishes domain data as well as contact data. .net is currently
designed as a thin registry, which means that information must be pulled from
the registrars' whois service for domain information.
DENIC provides its services to the .de community by using a thick registry
model and will implement the .net registry as a thick model as well. DENIC
firmly believes the thick model to be superior to the currently used thin model
of the incumbent, as it offers higher data integrity, security and increased
performance. A detailed explanation of the advantages of the thick registry
model can be found in part 2-5-b-xii: Whois Service.
2. Registry - Registrar Protocols and Interfaces
DENIC has a long and proud history as the .de registry. This history means
that DENIC has a great deal of experience with legacy applications that have
served the community well. One such application is the e-mail interface to
the .de registry system. This old technology is still satisfactory for a large
number of .de registrars.
Although DENIC has the capability to provide an e-mail interface to .net, it is
deliberately not supported for .net to are encourage universal adoption of EPP.
If it appears in the future that an e-mail interface is desirable, this
decision can be revisited and changed.
DENIC has a great deal of experience interacting with registrars, both on a
technical and functional level. DENIC is known for its excellent operations and
sensitivity to registrar issues. For the .de domain, all the technical support
systems work seamlessly and without issue. As a result, DENIC has a very high
degree of confidence that this history of excellence will continue and will be
carried over to the .net domain.
The following sections describe:
* EPP - the nature of the implementation for .net
* RRP - supported via a central proxy at DENIC's RSLs
* RRI - not to be implemented for .net, a description of DENIC's current .de
implementation to demonstrate our capabilities.
(a) Extensible Provisioning Protocol - EPP
DENIC will offer .net registrars its domain name registry functions compliant
to RFC3730, 3731, 3732, 3733, 3734 in an EPP 1.0 implementation as well as
Redemption Grace Periods as specified in RFC3915. Potential extensions to EPP
performed by DENIC will follow the guidelines of RFC3735.
In order to support the thick registry functionality, contact data has to be
supplied by means of the provisioning protocol. Therefore, all three object
mappings (domain, host, contact) will ultimately be available ([RFC3731], [RFC
3732], [RFC3733]).
Constraints applied to the data provided through the EPP interface will be
tightened during the migration phase from thin to thick registry. That is
straightforward due to the modularity and flexibility of the protocol. In a
first step, contacts are only optionally referenced by domains. In a second
step, contact references are mandatory for every <create>, <update> or <renew>
domain command. In a third step, every domain without contact references is
considered invalid.
In order to define potential new features and object management capabilities,
the guidelines described in [RFC3735] will be followed at any time. DENIC
actively follows all initiatives that present extensions to the EPP standard
within the IETF (e.g. DNSSEC-support like in "DNS Security Extensions Mapping
for EPP" Internet-Draft, work in progress) and will be able to implement them
with first-hand-knowledge if required.
The commands initially supported under DENIC's EPP installation are the
following:
(i) Session Management
EPP provides two commands for session management: <login> to establish a
session with a server and <logout> to end a session with a server. The <login>
command establishes an ongoing server session that preserves client identity
and authorization information during the duration of the session.
* EPP <login> Command: The EPP <login> command is used to establish a session
with an EPP server in response to a greeting issued by the server. A <login>
command must be sent to a server before any other EPP command to establish an
ongoing session. A server operator may limit the number of failed login
attempts N, 1 <= N <= infinity, after which a login failure results in the
connection to the server (if a connection exists) being closed. A client
identifier and initial password will be created on the server before a client
can successfully complete a <login> command. The client identifier and initial
password will be delivered to the client using an out-of-band method that
protects the identifier and password from inadvertent disclosure.
* EPP <logout> Command: The EPP <logout> command is used to end a session with
an EPP server. A server may end a session due to client inactivity or excessive
client session longevity.
(ii) Queries
EPP provides four commands to retrieve object information: <check> to determine
if an object can be provisioned within a repository, <info> to retrieve
detailed information associated with a known object, <poll> to receive service
notifications from the server, and <transfer> to retrieve object transfer
status information.
* EPP <check> Command: The EPP <check> command is used to determine if an
object can be provisioned within a repository. It provides a hint that allows
a client to anticipate the success or failure of provisioning an object using
the <create> command as object provisioning requirements are ultimately a
matter of server policy
* EPP <info> Command: The EPP <info> command is used to retrieve information
associated with an existing object.
* EPP <poll> Command: The EPP <poll> command is used to discover and retrieve
service messages queued by a server for individual clients. If the message
queue is not empty, a successful response to a <poll> command will return the
first message from the message queue.
* EPP <transfer> Query Command: The EPP <transfer> command provides a query
operation that allows a client to determine real-time status of pending and
completed transfer requests.
(iii) Object Transformations
EPP provides five commands to transform objects: <create> to create an instance
of an object with a server, <delete> to remove an instance of an object from a
server, <renew> to extend the validity period of an object, <update> to change
information associated with an object, and <transfer> to manage changes in
client sponsorship of an object.
* EPP <create> Command: The EPP <create> command is used to create an instance
of an object. An object can be created for an indefinite period of time, or an
object can be created for a specific validity period.
* EPP <delete> Command: The EPP <delete> command is used to remove an instance
of an existing object.
* EPP <renew> Command: The EPP <renew> command is used to extend the validity
period of an existing object.
* EPP <transfer> Command: The EPP <transfer> command is used to manage changes
in client sponsorship of an existing object. Clients can initiate a transfer
request, cancel a transfer request, approve a transfer request, and reject a
transfer request using the "op" command attribute.
A client who wishes to assume sponsorship of a known object from another
client uses the <transfer> command with the value of the "op" attribute set
to "request". Once a transfer has been requested, the same client can cancel
the request using a <transfer> command with the value of the "op" attribute set
to "cancel". A request to cancel the transfer MUST be sent to the server before
the current sponsoring client either approves or rejects the transfer request
and before the server automatically processes the request due to responding
client inactivity.
Once a transfer request has been received by the server, the server must notify
the current sponsoring client of the requested transfer by queuing a service
message for retrieval via the <poll> command. The current status of a pending
<transfer> command for any object can be found using the <transfer> query
command. Transfer service messages must include the object-specific elements
specified for <transfer> command responses.
The current sponsoring client may explicitly approve or reject the transfer
request. The client can approve the request using a <transfer> command with
the value of the "op" attribute set to "approve". The client can reject the
request using a <transfer> command with the value of the "op" attribute set
to "reject".
A server may automatically approve or reject all transfer requests that are not
explicitly approved or rejected by the current sponsoring client within a
fixed amount of time. The amount of time to wait for explicit action and the
default server behavior are local matters not specified by EPP, but they
should be documented in a server-specific profile document that describes
default server behavior for client information. Objects eligible for transfer
must have associated authorization information that must be provided to
complete a <transfer> command.
* EPP <update> Command: The EPP <update> command is used to change information
associated with an existing object. Its <restore> function is used to support
the Redemption Grace Period policy.
(b) Registry Registrar Protocol - RRP
In order to ease transition for the accredited .net registrars, DENIC will
offer a RRP-EPP proxy that complies with VeriSign's proprietary RRP 2.0.0 [RFC
3632] and any following extensions that VeriSign will be make public (It is
understood that VeriSign is currently using a version 2.1.2, but the
specification is not yet public.) The proxy will be programmed and supplied by
DENIC. Additionally it is DENIC's intention to have all registrars migrate to
the widely accepted EPP in the medium term.
To enable the soft transfer from the current .net protocol, DENIC aspires a
high transparency, a comprehensive documentation, how-tos, a test environment,
help and guidance for tests and adjustment of own systems and the offer of
several workshops. Details of the transition from RRP to EPP are described in
the Transition Plan.
(c) Real-time Registry Interface - RRI
As described in the previous section on EPP, DENIC will comply with ICANN
requirements and offer an EPP protocol according to the agreed standards. The
following details on DENIC's RRI system used for the .de registry are therefore
provided as evidence of DENIC's ability to run a real-time protocol with a
thick model.
Currently DENIC sees no need and has no intention on supplying a RRI protocol
interface for the .net registry. However, responsiveness to both the registrar
and registrant community is one of DENIC's core values. Should the community
of .net registrars request a RRI protocol for .net and should it be consistent
with ICANN policies, DENIC is able and willing to implement this protocol in a
short timeframe.
Development of RRI for .de
By statute, DENIC is required to provide a secure, solid registry interface to
its registrars. To cope with the continuously increasing rate of transactions
and to stay abreast of technical changes, DENIC decided to provide a real time
interface (Real-time Registry Interface - RRI) parallel to the established and
well proven e-mail interface.
Based on the registrars' requirements and the specific business and technical
processes of DENIC, the new interface was defined in a joint project with
registrars. One of the most important topics was the application protocol to
be used.
RRI has already been implemented and deployed in our testing environment.
Internal testing started at the end of November 2004 and registrar testing will
start by the middle of January 2005. RRI will be operational and go live by the
end of March 2005 at the latest.
RRI Compliance with Standards
RRI fulfills the general registry-registrar protocol requirements outlined in
RFC3375, declares a data structure with XML and takes into account the
recommendations for use of XML in IETF protocols stated in BCP70, RFC3470. RRI
design took into consideration internationali-zation and localization and
followed the relevant RFC2277, BCP18. RRI is transport independent. It can be
used over BEEP (RFC3080) or TCP, where the latter is secured with TLS.
RRI currently supports IDNA [RFC3490], IPv6 DNS [RFC3596] and will support
DNSSEC at the time of DNSSEC deployment in .de. RRI can be extended to support
other emerging features due to its flexible design.
3. Performance of Registry Systems
Availability of a Shared Registry System
DENIC has consistently been able to provide high availability of the registry
system for .de. Therefore DENIC will commit to a service level of 99.9%
availability for the registry system for .net.
Processing Times for Standard Requests
With DENIC's EPP implementation and high performance databases all standard
write transactions can be processed in very short time frames. Therefore DENIC
guarantees a processing time of less than one second (excluding round trip
time)
for more than 98% of all add, modify, and delete and commands.
Duration of any Planned or Unplanned Outages
Complete redundancy at all levels of DENIC's registry system ensures low outage
times. It has been DENIC's policy to always inform registrars far in advance of
planned outages of the registry system. Current DENIC registrars have
continuously voiced their satisfaction about DENIC's outage scheduling and
information policy.
DENIC commits to the following SLAs for the registry system of .net:
* Total outage per month: <6 hours
* Unplanned outage per month: <3 hours
* Unplanned outage per year: <9 hours (equals 99.9% availability)
* Planned outage per week: <2 hours
* Major upgrade outage: <6 hours (only twice per year)
With these commitments DENIC significantly improves the SLAs specified in
Appendix D of the current .net Registry Agreement, thus committing to improve
service for the .net community.
4. Innovation and Responsiveness to Community
Protocol Development
DENIC is actively involved in the development of new Internet standards within
the IETF working groups. Key technical staff actively participates in the IETF
process, and regularly attends IETF meetings.
DENIC has thus contributed significant input in the areas of protocol
development like IDN, or DNSSEC. In the development of the CRISP service DENIC
is assuming a leadership position within IETF. It is DENIC's outspoken goal to
continue this active and fruitful collaboration with IETF and other
international organizations in order to further promote the use of the Internet
as well as its stability, performance and security.
Registrar Diversity and Interaction
DENIC currently supports more than 220 registrars in 12 different countries.
The registrar structure is quite heterogeneous regarding the backgrounds,
manpower, technical know how, financial strength, core work area and
possibilities of the individual registrar. DENIC is encouraging this strong
registrar diversity, as it is a source of different ideas, innovations, and
abundant creativity - thus different offerings for different needs can be
provided to the Internet user.
Enhancements or new developments are always intensively discussed with DENIC
accredited registrars to not discriminate against (smaller) registrars by
changing technology that requires significant investments on the part of the
registrars. Thus DENIC can guarantee equivalent access for a wide spectrum of
registrars.
All registrars are informed at an early stage of a new development about
DENIC's plans and impacts for registrars in order to enable their participation
in the development process. Registrars' concerns are addressed at technical
meetings, by the Technical Advisory Council, in technical web forums, joint
work groups, etc. Details regarding the various forms of registrar interaction -
especially in the development process - are described in detail in part 2-5-b-
xix: Support. | |
|
(v) Database capabilities including database software,
size, throughput, scalability, procedures for object creation, editing,
and deletion, change notifications, registrar transfer procedures, grace
period implementation , availability of system with respect to unplanned
outage time, response time performance; ability to handle current volumes
and expected growth and reporting capabilities.
|
(v) Database Capabilities
Highlights
* DENIC currently administers more than eight million domains, and has capably
managed demand spikes, like the introduction of IDN when more than 625,000
transactions in the first two days were handled without any performance
deterioration.
* DENIC has reserved a capacity of five TB on DENIC's primary HDS for its .net
database, providing scalability for more than 2500% of the current database
size.
* Object creations, editing and deletions are safeguarded by database stored
procedures.
* DENIC has developed stored procedures to implement grace periods according to
ICANN policies.
* DENIC has designed its database with the following four principles in mind:
(1) High Availability and Security
* Complete redundancy of all components
* Regionally dispersed data centers in world class hosting sites
(2)High Data Integrity
* Real-time synchronization between active and standby database
* Consistent database monitoring and maintenance to prevent data loss or
corruption
(3) High Performance
* High excess capacities to handle peak requests
* Rapid response times through broad Internet connections and LAN backbone
between database servers
* Perform complex operations on managed objects
(4) High Scalability and Flexibility
* DENIC's database infrastructure is easily and quickly scalable
* Flexible architecture and program interfaces to accommodate changing needs
* Fully internationalized support based on UTF8
DENIC uses separate databases for domain and billing data. The following
chapter describes the currently productive .de database and the future
productive .net database, while the billing database is described in part 2-5-b-
ix: Billing and Collection.
1. Database Architecture, Systems and Maintenance
Database Design Factors
The production .de database (NIC DB) contains over ten million domain objects
and over 17 million contact objects. eight out of the ten million domain
objects are active, and while the others have been closed over the time, DENIC
keeps their history records for good business reasons. The database attributes
are shown in Figure 1.
Ability to Handle Transaction Volumes
DENIC's .de database is currently handling between 2,000 and 2,300 write
operations (insert, update, delete) per second.
The engine busy utilization percentage of the active database (db_active) is on
average at or below 40%, the engine busy utilization of the standby database
(db_standby) is on average below 10%, leaving enough capacity for transactional
growth for all three business cases.
For the .net registration system DENIC expects an average engine utilization on
a similar level, assuming a database size and transaction load that is
equivalent to the .de registration system.
Response Time Performance
Based on the current database engine utilization of the .de database, the
response time for whois queries stays below 100 ms for status queries and below
300 ms for domain queries. These short response times are the result of a high
performance hardware solution combined with continuous maintenance and
optimization of the database, all described in detail later in this chapter.
DENIC will commit to the same database response times for .net.
Ability to Handle Data Volumes
The production .de database currently uses 169.7 GB out of an allocated amount
of 250 GB. The development of .de data growth since September 2002 is depicted
in Figure 2.
Under the conservative assumption of an equal data volume of .de and .net
(currently .net is expected to be at 66% of the .de volume) there would be a
total data volume of around 350 GB.
Planning ahead for the potential win of the .net bid DENIC has reserved a
capacity of five TB on DENIC's primary HDS for its .net database, providing
scalability for more than 2500% of the current database size. The HDS at the
secondary RSL also has a disk capacity of 5 TB.
Database Structure and Data Model
Data fields will be mapped in an object oriented manner in a relational
structure.
Server Architecture
To ensure availability DENIC employs a redundant database setup. The two
database servers, db_active and db_standby, are based on the exact same
hardware (see Figure 3) and are located in different data centers. The
databases on both servers are synchronized in real-time, so that no data loss
can occur.
Data Storage
The NIC database is located on the HDS (StorEdge 9990) in DENIC's Storage Area
Network. This high-end storage system is fast and has an extremely high
availability 24/7/365. Details about the SAN technology are described in part 2-
5-b-i: Facilities and Systems.
Data Backup and Database Monitoring
DENIC's Backup and Data Escrow policies are described in part 2-5-b-x: Backup
and in part 2-5-b-xi: Escrow, and Database Monitoring is handled in part 2-b-b-
xvi: System Outage Prevention.
Database Maintenance
The database is designed in a manner to prevent additional maintenance as much
as possible. For instance, DENIC is using clustered indexes and locking schemas
which prevent fragmentation. However, in rare cases DENIC has to use a
different locking schema in order to avoid locking contention which need
regular maintenance in order to keep the performance.
Maintenance activities include such tasks as dropping and re-creating indexes,
performing dbcc checks, reorg on tables and indexes and updating index
statistics.
2. Database Procedures and Functions
This chapter contains the description of the future .net database and its
functionality.
(a) Database Integrity
Database integrity is guaranteed on several levels. On the lowest level, the
level of the database server, all safety mechanisms of the Sybase database are
used:
* Referential integrity by primary and foreign keys
* Transaction security
* Constraints
* Default clauses
* User and user rights management
By restrictive assignment of the user rights, manipulation of the database is
impossible by means of ad hoc SQL commands. This helps to ensure database
integrity during data changes made by applications as well as when changes are
made by DENIC staff.
On the application level database integrity is ensured by abstraction of the
objects and business processes with stored procedures which guarantee that
related data is manipulated at the same time and that relations are always
checked at deletion of objects.
All objects in the .net database are managed by stored procedures. The use of
stored procedures guarantees that all necessary references between the objects
are maintained and protects the system against SQL-Injection attacks. With the
stored procedures the database is protected against carelessly implemented
applications and/or the SQL commands used therein.
By appropriate right assignment it is only possible to create, to manipulate or
to delete objects on the database with the help of these stored procedures.
Most of the database activity will be initiated by the SRS system, which, based
on business processes, maps the EPP commands into stored procedures.
They also return if the transaction is chargeable for the registrar or not. The
billing service will be called depending of the result of these queries.
The remaining object management is triggered by DENIC staff through defined
interfaces, e.g. to create and update registrar objects and object attributes
like authentication records. Again these business processes will be mapped into
stored procedures.
(b) Database Objects
The object oriented database model comprises of four central objects, which
carry the actual state of the domain data (registrar, domain, host and
contact). For each object created, changed or deleted, a history record is
written with the same procedure call that is part of the transaction. It
contains the timestamp of that change as well as the type and content of it.
With the help of the history record, any past state can be determined at any
time. It is a good and proven business practice to keep a complete
documentation on any action undertaken.
(i) Registrar Object
The registrar object is the root object in the database. It is the only object
which may exist without linkage to other objects.
Registrar objects contain all necessary data of the registrar.
Registrar objects may be linked to domain, contact, and history objects.
It is ensured by means of a suitable authentication process that each registrar
can make changes only to their own domain, contact, and host data.
Authentication information is a part of registrar objects.
(ii) Domain Object
A domain object contains the domain name as primary key. The expire date (end
of the paid registration time), and the status are stored as well as necessary
data for the implementation of the grace periods.
A domain object must be linked to registrar, contact and host objects and has
references to its history records.
(iii) Host Object
A host object contains the name server information for a domain.
A host object may be linked to a domain object or to a registrar object.
(iv) Contact Object
Contact objects are used only with the thick registry model.
The contact object contains a complete data record (name, address, telephone,
fax, email,...) as well as disclosure policy information about this data record.
The contact object must be linked to registrar and may be linked to domain
objects.
(c) Database Procedures
(i) Object Creation
Database object creation is triggered by appropriate request through our SRS
system and defined interfaces as described in Figure 4.
Where it is expedient, incorrect entries are excluded and matching entries are
forced through the use of a primary or foreign key.
(ii) Object Editing
A registrar object can be changed by a DENIC staff member if there is an
appropriate request from the registrar. For security reasons there is no
automatic processing for these orders. They are examined by employees and
executed. A history record is written. This principle of manual checks also
applies to authentication attributes.
A domain, host and contact object is edited automatically in accordance with an
appropriate SRS request. For details refer to Figure 5.
(iii) Object Deletion
Only host and contact objects can be deleted from the database. Throughout, the
deletion process checks will be made so that the objects subject to the
deletion are no longer referenced. For details refer to Figure 6.
(iv) Registrar Transfer Procedures
Transfers are stored in the database and linked with domain and registrar
information. The transfer records contain inter alia transfer grace period
information. For details refer to Figure 7.
(v) Grace/Pending Period Implementation
All stored procedures for domain treatment examine during their execution
whether the domain in question is within one the following periods.
Grace Periods:
* Add Grace Period -- the Add Grace Period is a specified number of calendar
days following the initial registration of a domain.
* Renew Grace Period -- the Renew Grace Period is a specified number of
calendar days following the renewal of a domain registration period.
* Auto-Renew Grace Period -- the Auto-Renew Grace Period is a specified number
of calendar days following an auto-renewal.
* Transfer Grace Period -- the Transfer Grace Period is a specified number of
calendar days following the transfer of a domain
Pending Periods:
* Redemption Grace Period -- all domains deleted outside the Add Grace Period
will be placed in the RGP. During the RGP, the registrar who erroneously
deleted the domain previously, may restore it.
* Redemption Hold Period (begins after redemption grace period) -- at the
conclusion of the 30-day RGP, domains not requested for restore, are placed in
the Redemption Hold Period for the following five days waiting for deletion.
The database provides a stored procedure to delete these domains finally.
* Transfer Pending Period (begins after domain transfer command) -- during the
Transfer Pending Period, the current registrar may answer to the transfer
request, to approve or reject it.
* Restore Lock Period -- after the name has been restored, it will be placed
into a Restore Lock Period.
(d) Change Notifications
Change notifications are handled at the application level. The database
provides information about changes to the SRS-System, which is responsible for
notifying interested parties.
If the registrar uses the EPP protocol, the EPP <poll> command can be used to
get these notifications. For other registrars email notifications are sent.
(e) List Generation / Reporting Capabilities
All predefined reports and lists (e.g. zone files) are generated by using
stored procedures. The use of stored procedures even for standardized read
access ensures
* Data protection
(Stored procedures are a good security mechanism to control access to
information in tables. Selects on a table can be denied, but a stored procedure
allows to see certain rows or columns.)
* Best possible optimization of database queries
(Stored procedures run much faster than standalone statements for several
reasons, e.g. the execution plan is saved, through design and testing it is
assured that the best possible indexes are established and used)
* That queries generating a high load are serialized
(DENIC has implemented a mechanism that prevents concurrent use of certain
stored procedures, that create a high load)
If reports that differ form the predefined reports are needed for any reason,
they will be created by experienced DENIC staff having a special access right.
Details about available standard reports, access procedures, report generation
frequency and zone file generation are described in part 2-5-b-xix: Support,
part 2-5-b-ix: Billing and part 2-5-b-vii: Zone File Generation.
3. Architecture Redundancy and Switchover Procedures
As described in this chapter the .net database will be operated in a redundant
fashion on two identical database servers in geographically dispersed
locations. Should one server fail, the other will take over without any data
loss.
The servers are replicated and configured in warm standby mode through a
replication server via a 100 MB LAN connection (see Figures 8 and 9).
Switchover Concept
As both databases are synchronized (see sub chapter Server Architecture above)
they can switch the role db_active and db_standby anytime (switchover concept).
By using the described latency monitoring, it is ensured that all data is up to
date.
Both databases use virtual (non primary) IP addresses as endpoints for
application connections. The switchover concept is based on the use of these
virtual IP addresses. The applications connect to a virtual interface
(db_active or db_standby), which is started on either one of the servers and
will afterwards be made available to the ASE server after its restart.
In case of a switchover, the standby database is checked to be current via the
mechanism for measuring the latency. Zero latency means all transactions from
db_active are transferred to the standby system.
Synchronization Checks
Once every week an executable program "rs_subcmp" compares a replicated table
to the primary version of the table. rs_subcmp compares the primary and
replicate rows and creates lists:
* Missing rows - rows at the primary, but not at the replicate
* Orphaned rows - rows at the replicate, but not at the primary.
Availability of System with Respect to Unplanned Outage Time
During the switchover procedure described above there will be a minimal down
time for read and write applications - less than 10 minutes. These downtimes
during unplanned switchovers are accounted for in DENIC's commitments to no
more than three hours unplanned outage per month and no more than nine hours
unplanned outage per year.
4. Current Database Architecture Initiatives
DENIC is consistently enhancing its architecture in order to reduce answer
times, further strengthen reliability and increase overall stability of the
Internet. Currently three initiatives for increased database performance are
under evaluation:
* Improved whois service through dedicated database replicas
* Increased database availability by addition of failover methods
* Increased availability through additional complete replica
|
|
|
(vi) Geographic network coverage, including physically
diverse sites and support of growing and emerging
markets.
|
(vi) Geographic Network Coverage
Highlights
* DENIC's primary registry service location is located in Frankfurt for .de
and .net, with the .de secondary registry service location at COLT in
Frankfurt, and the .net registry location planned at one of the major
international access points in London, Amsterdam, or the US East Coast.
* 14 .net name server sites will be operational by June 30, each with multiple
name servers - .net infrastructure implemented in eleven existing .de name
server sites worldwide, three additional .net name server locations in North
America.
* Five additional .net name server locations to be opened until the end of
2005 - all of them in emerging markets.
* DENIC will provide helpdesk services to registrars from two service
locations, with DENIC's Frankfurt headquarters being the main .net service and
support location. Additionally, DENIC will establish an second support location
in Canada at a service provider which will be totally dedicated to the .net
domain and focus on 24/7/365 English language support.
* DENIC is committed to consistently expand its geographic coverage as needed
with a focus on emerging markets.
Types of Service Locations
DENIC divides its service locations into three types of locations:
* Registry service locations (RSL) - Providing Registration Services
* Name server locations (NSL) - Providing DNS Services
* Service and Support Locations - Providing Support for Registrars and
Registrants
1. Registry Service Locations
DENIC's primary .de Registry Service Location is located within its data center
at the headquarters location in downtown Frankfurt. The secondary .de RSL is
located at the COLT Internet Service Center (ISC) at the eastern end of
Frankfurt, approximately six miles away.
The .net RSL infrastructure will be equivalent and completely independent from
the current .de structure. The primary RSL for .net will be located within our
data center at our Frankfurt headquarters. DENIC is committed to locate the
secondary .net RSL at one of the major international access points. Currently
options in London, Amsterdam, and the US East Coast are under evaluation.
DENIC will carefully assess all potential locations regarding stability,
security and performance criteria for a RSL. DENIC's decision regarding a
location will be finalized and letters of intent will be signed by February
2005. If DENIC is awarded the .net registry contract, it will immediately sign
the hosting contract with the selected provider and build the RSL in order to
be operational by June 30, 2005.
Due to the high scalability of the current .de infrastructure, DENIC will be
able to offer test systems for .net at a very early stage on the existing .de
infrastructure.
2. Name Server Locations
Current .de Locations for .net
Currently, DENIC has an extensive infrastructure with eleven authoritative name
servers for .de distributed around the world (see Figure 1). The strong focus
on Germany and Europe has been deliberately chosen to optimize performance for
the .de community. One of the two Frankfurt servers is located in the primary
RSL, the other one is directly connected to DE-CIX, Germany's biggest and
Europe's third-biggest exchange point. All of these current .de locations will
also serve as .net locations with equivalent but completely independent
infrastructure.
Additional .net Locations in North America
As the .net community has a strong concentration in North America, DENIC will
expand its name server infrastructure if awarded the .net bid. Specifically
DENIC will deploy three additional .net name server locations at major access
points, with the exact locations to be decided upon after a detailed analysis
of network traffic. DENIC anticipates the following locations:
* One East Coast location
* One West Coast location
* One location still to be decided upon
All three new locations as well as the existing eleven .de locations will be
operational as .net NSLs by June 30, 2005.
Additional .de and .net Locations in Developing Markets
Independently of the .net bid DENIC will expand its geographic reach by at
least five more locations in 2005 to offer the best possible access for the .de
community. The focus of DENIC's geographic expansion are developing and
currently underrepresented markets. Therefore the locations to be established
in 2005 will be:
* South Africa (likely Cape Town)
* South America (likely Brazil)
* China / India / Taiwan (tbd)
* Singapore / Australia (tbd)
* Eastern Europe / Russia (likely Moscow)
By adding these locations DENIC will minimize response times in these
developing regions and offer equal quality of service to users around the
world. If DENIC is awarded the .net bid, DENIC will implement these locations
as .net NSLs as well, adding another five .net locations to its global network.
These locations will be implemented sequentially in Q3 and Q4 of 2005 and all
of them will be operational at the latest on December 31, 2005.
Complete .net Name Server Infrastructure
DENIC will have 14 .net name server locations operational by June 30, and
19 .net name server locations by December 31, 2005 (see Figure 2). By providing
this infrastructure DENIC ensures not only continued high-quality DNS
resolution in North America but also significantly improves .net DNS services
to Europe, Asia and other currently underrepresented markets. With its
extensive geographic network coverage and the commitment to further expand the
network as needed, DENIC is in an unparalleled position to provide high-class
DNS services to the .net and general Internet community.
Provider Diversity
While geographic coverage is one key aspect of delivering reliable and fast DNS
services, it alone will not suffice. Therefore DENIC has contracted its current
eleven name server sites to ten different hosting companies, ensuring an
unmatched provider diversity. Details about the name server location hosts,
setup and infrastructure are described above in this chapter, and details about
DENIC's multi-vendor strategy are described in part 2-7-ii: Multiple Suppliers.
3. Operations and Support Locations
Joint .de and .net Operations and Support Location in Frankfurt
DENIC's current .de operations and Service Team in the Frankfurt headquarters
location will be enlarged to handle both .net and .de requests. Support will be
offered both in English and German from 6 a.m. to 8 p.m. local time (5 to 19
UTC) for all kinds of service requests.
Dedicated .net Operations and Support Location in North America
DENIC will establish an Operations and Support location in North America
totally dedicated to the .net domain. This will be done at a second support
location in Canada at a service provider which will be totally dedicated to
the .net domain. Support will be offered in English between 16 and 7 UTC, so
that together with the Frankfurt location support in English will be guaranteed
24/7/365, with five hours of overlap at both switchover times.
Additionally, three call back languages (Korean, French, Spanish) will be
introduced in either of the locations within the year 2005 to be able to
resolve questions in the native language of the registrars.
Details on both facilities are given in part 2-3-b-iii: Description of
Facilities, and a extensive description of offered services holds part 2-5-b-
xix: Support.
4. Commitment to Develop Emerging Markets
DENIC has a ten year track record of delivering first class service, and
upgrading network infrastructure is one of the key aspects in fulfilling this
mission. As described, DENIC will therefore expand its name server
infrastructure by eight locations - five of them in developing and
underrepresented markets - within the year 2005 to effectively serve the .net
and the .de community.
Furthermore DENIC is committed to consistently expand its geographic coverage
as needed. Being a not-for-profit entity all revenue will flow into operations,
support and upgrade of .net infrastructure - enabling DENIC to invest more into
additional and improved infrastructure than a for-profit company. DENIC will
also continue its support of registries of developing countries through
sponsoring of root servers and DNS resolution services as well as through
infrastructure donations.
|
|
|
(vii) Zone file generation including procedures for
changes, editing by registrars and updates. Address frequency, security,
process, interface, user authentication, logging and data
back-up.
|
(vii) Zone File Generation
Highlights
* Highly secure zone file because of prohibition of manual access
* High data integrity of zone data through extensive consistency checks
* Extensive experience of DENIC in zone file generation for a larger TLD
* High zone quality as evidenced through positive independent reports
* Constant logging and monitoring of zone file generation
* Complete archiving of all created zones with unique serial numbers to enable
unequivocal identification of individual zone files
DENIC is committed to maintaining the integrity of the zone file. As a result,
it is DENIC's policy to not allow any direct manual write access to zone files
whatsoever. Registrars cannot update zone information directly in the zone
file. DENIC's zone update process happens in three defined sequential steps:
1. Updates of domain data in DENIC's registry database by the registrars via
the registry system (see below).
2. Zone generation with several consistency checks (see below).
3. Zone distribution and publication - described in Part 2-5-b-viii: Zone File
Distribution.
1. Data Changes and Updates of Zone File
Process
It is solely the registrars' responsibility to keep domain data up to date.
DENIC will not initiate changes of any kind. Procedures for changes and updates
by registrars are defined by the protocols in use (EPP and RRP) and are
described in Part 2-3-a: Proposed Registry Services.
Security and User Authentication for Data Updates
Registrars do not access the main database directly, but rather through several
security layers and via the Service Provisioning Layer as mediator. The layer
structure of DENIC's RSLs is described in part 2-3-b-iii: Description of
Facilities, with additional security aspects described in part 2-5-b-xiii:
Security.
Changes in the domain data can only be performed by the authorized registrar -
the one that is maintaining that specific domain. In order to initiate changes
in domain data, registrars have to authenticate themselves to be granted
authorization for domain data updates. The registrar authentication procedures
are described in detail in part 2-5-b-xiii: Security.
Access rights for DENIC staff are defined via clearly specified roles which are
described in detail in part 2-5-b-xiii: Security.
Interface
All transactions in DENIC's main database can only be made via the registry
system, which can be accessed for .net via RRP and EPP protocols. Support of
these protocols is described in detail in part 2-5-b-iv: Registry-Registrar
Model and Protocol, in part 2-2-b: Equivalent Access (Protocols) and in part 2-
8: Transition Plan.
2. Zone File Generation
(a) Process and Consistency Checks for .net Zone
The DENIC main database db_active has a real time synchronized copy db_standby,
so redundancy exists for all domain data. All zone files will be generated from
this main database copy.
Consistent with current .net practices, there will be no registrant
authoritative data present in the zone, just NS records for delegation and
potential future additions necessary to support DNSSEC as well as glue records.
The data to be extracted from the database includes the domain name, the names
of the name servers and the glue A and glue AAAA records where applicable. The
SOA record is generated automatically as is the list of authoritative name
servers for the .net zone.
For the generation of a new zone file the domain data on DENIC's registry
database will be read by the zone generation server from the db_standby. To
speed up the zone file generation it is executed in parallel processes.
To safeguard against failures or omissions during the zone generation process
the newly created zone file will be checked for several indicators including,
but not limited to:
* the file size in characters
* the number of lines in the file
* the number of owner names within the file
* the number of IDNs in ACE (starting xn--)
* changes of those numbers compared to previous version, i.e. first derivative.
Should any of those values differ from those of the previous zone by more than
a specific, continuously adapted threshold, the operations team will be
notified and the discrepancy will be analyzed before the new zone is
distributed to the name server locations. This procedure ensures utmost data
integrity and accuracy of distributed .de zones.
The consistency checks described above make use of heuristics trained through
years of experience while operating the .de zone. Actual numbers and trends
for .net will differ, but DENIC is prepared to phase in a similar process
for .net quickly during the transition period. Cooperation from the incumbent
operator would be helpful and appreciated.
(b) Frequency of Updates
Following .de practice there will be eight zone file updates per day in regular
three hour intervals. DENIC has consciously decided against real-time zone file
updates, details are described in Part 2 -5-b-viii: Zone File Distribution and
Publication.
(c) Emergency Zone Generation Procedure
Generally the Zone File Generation Process will be started automatically in
regular three hour intervals. However, should the need occur, the process can
be started manually by authorized personnel within DENIC's operations
department.
The manual start of the Zone Generation Process is limited to emergency
situations in which the immediate publication of a new zone is required. DENIC
does not have either a positive or negative list of qualifying incidents and
reserves the right to make the decision about an emergency update upon receipt
of the update request. Incorrect zone information seriously endangering the
stability and security of the .net zone or the Internet in general are examples
of such instances.
It is DENIC's policy - even given special circumstances - not to allow manual
changes to the zone file, neither from registrars nor internally from DENIC's
own operations staff. By taking this very strong stand against direct manual
manipulation of zone information DENIC ensures highest zone accuracy and
effectively prevents abuse. The updated zone will be loaded on all name servers
after less than 60 minutes from the receipt of the update request. Any changes
to the data must have been initiated and processed through the normal channels.
3. Zone Generation Logging, Monitoring and Backup
(a) Logging and Monitoring
All steps in generating new zone files and checksums are monitored and logged
consistently. Additionally to the consistency checks described above DENIC
monitors the adherence to clearly defined thresholds and assesses potential
long-term trends regarding zone file devel-opment. The operations team is
immediately informed of errors or potential long-term threats.
(b) Archiving and Backup
All DENIC zone files contain a unique serial number, which enables archiving
and correct association to specific dates. Consequently, every zone that has
been generated will be archived for future references. Based on the zone
archive DENIC can reconstruct the content of the .net zone at every single
point
in time.
Archived zone files are saved to DVDs in regular monthly intervals. These
backup DVDs are stored in safes either at the DENIC headquarters or at a third
party location.
Further details regarding general backup are described in Part 2-5-b-x: Backup. | |
|
(viii) Zone file distribution and publication.
Locations of name servers, procedures for and means of distributing zone
files to them.
|
(viii) Zone File Distribution and Publication
Highlights
* Distribution of compressed diff files instead of complete zones, therefore
the zone distribution is fast and resilient against malfunctions in the data
transmission
* Checks of correct zone distribution through use of several MD5 checksums
* Constant monitoring of zone distribution and server restart process
* Fast access to .net zones through 14 .net NSLs by June 30 and 19 .net NSLs by
December 31, 2005
1. Zone File Distribution
(a) Distribution Process
After the newly generated zone has been transferred from the Zone Generation
Server to the central NSL Management Server, a diff zone file will be generated
by comparing the new zone to the last zone file which is stored on the NSL
Management Server. Another MD5 checksum is generated, this time for the zone
diff file.
Using SecureCopy (scp) the compressed diff file is distributed to the loghosts
of the name server locations via the Out-of-band-Management connection (for
details see part 2-5-b-i: Facilities and Systems). By distributing compressed
diff files instead of complete zones the zone distribution is very fast and
reduces the probability of data corruption.
A new MD5 checksum of the transferred diff file is generated on the loghost and
compared to the existing MD5 checksum of the diff file on the NSL Management
Server. Only in case of an exact match the loghost will generate the new zone
by merging the existing zone with the newly received diff file. Another MD5
checksum is generated for the patched zone file and compared with the MD5
checksum of the original zone file on the Zone Generation Server. This process
of using two checksums ensures the integrity of the patched zone file. In case
of checksum inconsistencies the newly patched zone file is rejected and the
generation of a new zone file is requested from the central database.
Correct MD5 checksums will trigger the loghost to distribute zone files to the
three name servers within the NSLs via scp. The zone reloads are run
sequentially over the servers, always ensuring availability of at least two
servers per location. The complete zone file distribution process is shown in
Figure 1.
During the time of the zone reload the affected server will automatically be
removed from the setup. The remaining two servers will pick up the additional
load and the downtime of the individual server will not be noticed by anyone on
the outside.
In the unlikely event that an error with the zone file has not been detected
through the previous consistency checks and doubled MD5 checksum processes, the
first server to be updated with the new zone can not successfully be restarted.
The two remaining servers will then continue running with the previous zone
file and no interruption of the service and availability of any single NSL will
occur.
Any such unexpected event will be noticed by two separate monitoring
mechanisms: (1) the ongoing monitoring of the name server and the restart
process through the Operations Team, and (2) the immediate notification of the
Operations Team through the automated monitoring feature. The Operations Team
will then take the following actions:
* All restart attempts with the defective zone in other locations are aborted
* The Operations Team starts the missing server with the still existing
previous zone - which is available on every server for security reasons
* The error in the zone is analyzed and the reason for the error is eliminated
* A new and correct zone is generated and the normal zone distribution process
is initiated
(b) Monitoring of Zone File Distribution
All steps in distributing diff zone files to loghosts and servers as well as
comparing checksums are monitored and logged consistently. Examples for
specific monitoring activities of the zone file distribution are:
Success and Duration
Both success and duration of the zone distribution are monitored consistently.
If the duration of the distribution to any location exceeds a defined
threshold, information is sent to the Operations Team immediately. In case of a
consistent increase of distribution duration to any location the logs will
generate warnings and the Operations Team will counteract the development.
Distribution and Server Restarts
The process of zone distribution and server restarts is completely automated
with every step being monitored. The measured data is continuously visualized
and checked by the Operations Team. Displayed data includes per NSL:
* current status
* serial number of the currently published zone
* currently active DNS software
* current activities (e.g. secure copy of zone, server restart)
* result of these activities
* time of last status change
* query load (q/s)
The information is depicted in different colors depending on whether the
parameters are within the defined boundaries, within the security margin or
outside the acceptable threshold corridor in order to immediately alert the
Operations Team in case of potential or actual problems.
This graphic monitoring tool enables DENIC operations to permanently have an
overview of all deployed name servers worldwide. The system is scalable both in
terms of number of locations and name servers as well as in terms of monitored
parameters.
(c) DENIC's Position on High Frequency Zone Updates
DENIC believes that for the operation of a registry the stability and accuracy
of the DNS resolution process as well as the accuracy and timeliness of the
registration process are of utmost importance. The DNS was not designed to
distribute rapidly changing data and although features like dynamic update have
evolved over time, DENIC believes these features not only address needs more
dominant further down in the domain hierarchy but also imply or at least invite
choosing operational parameters (i.e. TTL values) in a way detrimental to the
efficiency and stability of the overall DNS if applied at the TLD level. While
committed to quick registration, DENIC sees its responsibility in not entering
into a competition focusing on only a small aspect of the overall registration
process ('time-to-DNS') at the cost of jeopardizing long term stability.
As has been documented in a working document of the IETF named 'Observed DNS
Resolution Misbehavior' based on experience made by the incumbent .net
operator, TTL issues can put an unnecessary burden on the infrastructure.
Effectiveness and influence of DNS caches and caching are subject to research
within the IETF and other groups and DENIC will actively participate in and
support such efforts. DENIC will review its position regularly based on the
latest research and developments within the DNS community.
DENIC is strongly confident that the .net TLD can and will evolve and be
competitive with the change frequency proposed in this document.
(d) DENIC's Position on the Use of AXFR
With the current and proposed setup, all name servers for .de and .net will be
under the sole operational control of DENIC itself. Consequently, there is no
need to provide an interoperable, standards compliant (i.e. AXFR) way of
accessing the zone data off a name server, the distribution mechanism is a
private matter subject only to stability, efficiency and accuracy
considerations. Potential future reassignment of the .net registry is not
encumbered since a zone file compliant to STD 13 is always involved in the
generation and distribution process.
DENIC has chosen not to use AXFR in favor of a proprietary scp based solution
for reasons of efficiency and integrity. While the latter could have been
achieved with TSIG (RFC2845), the amount of data to be transferred and thus the
time needed would be unnecessary large compared to the actual changes. IXFR
(RFC1995) is also not an option because it is still less efficient than
compressed data transfer and it is not yet available for all our
implementations or assumes use of other features (e.g. DNS Dynamic Update)
not applicable in this context.
2. Name Server Locations
Today, DENIC's eleven Name Server Locations (NSLs, see part 2-5-b-vi) are
distributed around the world with a focus on Europe to serve the .de community
in the best possible way. New .net infrastructure - while being completely
separate from .de - will be located in the same facilities as the .de
infrastructure currently is.
For .net DENIC will establish three additional NSLs at major access points in
North America in consideration of the concentration of the .net community in
the US and Canada. These NSLs will be fully operational by June 30, 2005.
Additionally to these three NSLs and independently of the .net decision DENIC
will expand its geographic network by five NSLs in 2005 with a focus on
developing and currently underrepresented markets. These locations will
sequentially be implemented in Q3 and Q4 of 2005, and all of them will be
operational as of December 31, 2005.
Consequently, DENIC will serve the .net community with 14 NSLs as of June 30,
2005, incrementally add additional name servers in Q3 and Q4 and have all 19
NSLs fully operational by December 2005. The details regarding DENIC's
geographically dispersed name server architecture are described in Part 2-5-b-
vi: Geographic Network Coverage, including graphs and network addresses. The
NSL setup is described in part 2-5-b-ii: Stability and Performance. |
|
|
(ix) Billing and collection systems. Technical
characteristics, system security, accessibility.
|
(ix) Billing and Collection Systems
Highlights
* The .net Billing and Collection (B & C) system will be able to fulfill all
functional .net B & C requirements such as creating individual reports, debit,
credit and monitor registrar accounts or initiate low-balance notifications.
* All billable transactions are processed and recorded in real-time.
* The system is able to handle the large amount of accounting information
needed to provide a detailed and regular charging of .net registrar
transactions.
* The billing cycles and service prices can be flexibly determined as required,
e.g. per hour, day, month, quarter, year.
* Invoices can be created at any time.
* New types of transactions can be added at any time.
* The B & C system will generate detailed online account reports for every
registrar on demand for a specified time period; reports are available online
for 24 months.
* DENIC will enforce strict security procedures on the network, the system and
the user level.
* All invoices and reports will strictly comply with German law and standards.
All information will be available for the current fiscal year and or a
succeeding period of ten years.
DENIC is highly committed to provide a fair and transparent billing process.
Therefore, DENIC will establish a clearly defined and efficient billing and
collection system for the .net registry services which will be fully compliant
with international norms as well as German law and standards.
1. Functional Overview
The main target of the DENIC .net Billing and Collection (B & C) system is to
maintain the registrars' account data which represent the basis for invoice
creation, audit tracking and financial reports.
The DENIC B & C process is based on deposit accounts which will be established
for each registrar client. DENIC will debit the accounts for all registrar-
related registry services payments and fee-initiating services (e.g. domain
registrations, domain renewals) as long as the deposit account has a positive
balance. In this context, the B & C system will be flexible in several aspects:
* The billing cycle (e.g. per hour, day, month, quarter, year) as well as the
configuration of service prices are flexible and can be modified just as
required.
* Invoices can be created at any time.
* New types of transactions can be added at any time.
The DENIC B & C system will handle all required B & C functionalities,
including:
* Collect registrar-related account information
* Create individual reports
* Debit and credit registrar accounts
* Monitor the registrar accounts
* Initiate low-balance notifications
* Enable registrars to view accounts
* Online credit accounts payment
* Track and report historical information
Figure 1 provides an overview of the DENIC B & C process.
The registrar sends all requests to the .net registry system. Within the
system, the .net registry database processes the requests. For any billable
action the B & C system is called. The B & C system checks the registrar
deposit at first to verify that sufficient funds are available to complete the
transaction. If this check is successful, the B & C system returns a positive
response to the registry system, which then processes the request. After the
request processing has been successfully completed, the B & C system is called
again to debit the account and record the transaction in the B & C database. If
the account balance is insufficient, the registrar will be notified and the
transaction will be canceled. The registrar receives a monthly invoice which
includes an overview of all completed billable transactions. To transfer money
to the account, the registrar can either use bank money transfer or a credit
card transfer. The registrar is able to conduct the latter by using the
registrar interface.
In addition to the registrars, the DENIC B & C Support Team, the B & C
administration as well as the B & C clerks have access to the B & C system to
e.g. provide user support, administrate the users or to create invoices and
collections.
2. Technical Capabilities & Characteristics
The existing B & C system was developed by DENIC to fulfill the specific
requirements of the .de billing and collection process. It will be extended to
a scaleable and flexible solution which will also be able to fulfill the
functional .net B & C requirements as described previously. The enhanced B & C
system will ensure data processing accuracy and handle increasing transaction
volumes as well as new billable transactions. The system will be ready to use
in time for the transition and fulfill all technical .net B & C requirements:
* Handling the large amount of accounting information needed to provide a
detailed and regular charging of .net registrar transactions
* Support of flexible queries of the .net B & C database through registrars or
DENIC personnel
* Reports of historical information
(a) B & C System Components
Figure 2 provides a general overview of the B & C system components.
Billing Service
This service processes billable transactions that are delivered from the .net
registry system and writes account data into the B & C database.
Deposit Monitor
Monitors the registrars' accounts for sufficient deposit.
Report Generator
Generates account statements for flexible time periods, annual reports and
customized reports. The customized reports requested by a registrar will be
initiated from the customer service personnel and generated real-time or in a
batch process by the report generator.
After generating the customized reports, the reports will either be displayed
or stored by the generator in the specific area of the secured web site for the
registrar to download.
B & C Database
For billing and collection, DENIC will set up a database which is handled
independently from the .net registry database. This database will contain
various data to document all performed billing processes in detail. The
following data will be included:
* Transaction Types: In this section, the different transaction types and
related information such as e.g. the amount to be charged will be stored.
* Registrar Information: Contains all relevant registrar information per
registrar, e.g. name and address.
* Transaction Data: Performed billable transactions will be documented in
combination with all related information, e.g. appropriate registrar
information.
* Account History: Contains relevant information to document all account
transactions (e.g. registrar information, amount received, relevant transaction
type).
* Account Information: Includes information about the current deposit and the
low account notification mark of a registrar.
* User Information: Stores all user information with corresponding user roles.
The B & C database will have the same general characteristics as the other
databases of the .net registry system. Further details on databases (e.g.
availability, data integrity, performance, scalability, architecture, hardware)
are described in part 2-5-b-v: Database Capabilities.
(b) B & C Processes
The content of the B & C database will be generated by several processes. These
can be performed by both users and systems. In this context, three different
areas can be distinguished:
* Registrar administration
* Billable functions and services
* Event-based processes
(i) Registrar Administration
This section will contain the following transactions:
Account Setup: After having verified the accreditation of each registrar,
DENIC establishes an account in the B & C system which includes all necessary
registrar information. In addition, DENIC asks the registrar to deposit the
required minimum amount in the debit account.
Debit Account Pre-payment: As soon as DENIC receives the minimum amount, it
will be credited to the account stored in the B & C database.
Update of B & C Profile: DENIC receives the update request for a registrant
profile, validates it and executes changes in the database.
(ii) Billable Functions and Support Services
All transactions will be handled by the .net registry system. For any billable
transaction, the registry system calls the "Billing Service" which processes
the transactions and writes the billing data into the B & C database. In this
context, the following billable transactions can be performed:
1. Standard Registry Functions
Create Domain: The registrar communicates a request to create a new domain for
a certain number of years. As this is a billable action, the .net registry
system calls the B & C system which thereby becomes an integrated part of the
transaction. The B & C system calculates the respective fee, checks the account
for a positive balance and instructs the registry system to process the
transaction. If the transaction was successfully completed, the B & C system
debits the account with the fee and updates the B & C database. If the account
balance is insufficient, the registry system receives a negative response from
the B & C system. In this case, the "create domain" fails and the registrar
will be notified.
Renew Domain (by Registrar) (including Auto-Renew): The registrar communicates
a renewal request for a certain number of years (See "Create Domain" for
details of the procedure).
Transfer: The registrar communicates a request on behalf of the registrant to
change sponsorship of an object.
Restore: The registrar communicates a request for a domain to recover the
status previous to deletion within the redemption grace period.
2. Additional Registry Functions
DomainSync - The DomainSync function enables the registrant to adjust the
renewal date for their domains to a calendar day of their own choice.
3. Additional Support Services
Customized Reports: The customer service generates a customized report after it
has been requested by a registrar. The B & C system calculates the fee, debits
the registrar accounts, and publishes the report in the registrars' web portal.
On the web site, the registrar can access the report.
(iii) Event-Based Processes
Event-based processes are initiated by several events:
* Low Account Balance: The B & C system notifies the registrar by e-mail, if
the deposit on the registrar account falls below the agreed minimum amount.
* Insufficient Funds: A transaction will not be processed, if the deposit on
the registrar account is less than the accrued fee. In this case, the system
cancels the transaction and notifies the registrar about the insufficient funds
(see also description of create domain earlier and for details on the RRI: part
2-5-b-iv: Registry-Registrar Model & Protocol).
* Reports: The B & C system will generate detailed online account reports for
every registrar on demand for a specified time period. These reports will be
available online for 24 months and can be generated for the following content:
* All performed billable transactions within a specified time period, including
a summary
* All performed non-billable transactions within a specified time period,
including a summary
* Current domain portfolio at the end of each month
The first two reports are created real-time, but the requestor also has the
option to generate them in batch. The third report, the current domain
portfolio will be created in batch only. This portfolio report will be
published for each registrar in the registrars' web portal.
At the beginning of every month, DENIC will create a monthly billing report
which shows the successful transactions for each registrar over the previous
month. In addition, the report indicates whether the transactions were subject
to charges according to the price list for registrars. The report will be made
available to the affected registrar only.
3. System Security
As security-related questions like technical and physical capabilities and
procedures to prevent system hacks or break-ins are described in detail in
part 2-5-b-xiii: Security, this chapter illustrates B & C-specific security
issues only.
To fully enforce security of the .net B & C system, DENIC will take
comprehensive precautions on the network, the system and the user level.
(a) Network Level Security
On the network level, the communication will be mainly based on the IP protocol
respectively the HTTP protocol. The security measures on this level include:
* Deployment of HTTP over SSL for encrypted communication
* Installation of a firewall between the internal network and public Internet
(b) System Level Security
Security on system level will be enforced through secure user login procedures.
These procedures ensure that the B & C system will only be accessible by fully
authorized and authenticated users. Whenever these users try to access the
secure web server via the web interface, they have to enter their specific
userID/ password combination. The information transmission is secured by using
SSL encryption (see network level security).
(c) User Level Security
DENIC already employs well-defined and tested .de security procedures on user
level. As these procedures have proven to be very reliable and effective, they
will be adopted to the new .net B & C system. Every B & C system user (internal
and external) has a unique user login account with a unique user identification
(UserID) and a password. This userID/ password combination is used to
authenticate the users and to control the access to system resources and
applications. User profiles and access privileges are established and
maintained in the database system to control the user access to the B & C
system. DENIC has defined and approved security procedures for adding and
deleting users and modifying login accounts, access control lists, and user
profile access privileges depending on the functional role of the user.
System Access Privileges
For the .net B & C system, all access privileges and roles will be individually
defined per user. The access privileges - realized with user profiles stored in
the database - determine the operations and transactions a user is allowed to
perform. In terms of access privileges, the following groups and roles can be
distinguished:
Registry Employee Group
For registry employees, a separate client application will be implemented to
perform the specific operations within the B & C system. This client will run
on employee workstations and is connected to B & C system via LAN.
Within the registry employee group different roles will be defined:
* B & C Administrators are responsible for user administration, configuring
user groups and their access rights, system upgrades, and maintenance issues.
* B & C System Operators monitor and correct billing errors and provide
registrar support.
* Customer Service Operators monitor the billing history of each registrar,
collect data for the B & C manager and initiate customized reports.
* B & C Manager create adjustments, customer changes and catalog changes.
* B & C Clerks perform transactions like creating invoices and collections, but
are not authorized to make adjustments.
* B & C Database Administrators are responsible for database updates,
modifications, and fixing operational failures.
Registrar Group
Generally, registrars will not be authorized to perform any write operations in
the B & C system. The only exception will be the change of their low account
notification mark. The notification mark can be defined as an amount of money
or in days. For defining the mark in days, the B & C System will calculate the
amount of money that the registrar has to pay on average for a specified number
of days. The registrars have the option to transfer money to their current
deposit amount either by bank transfer or by credit card using the registrar
interface. If the credit card transaction is approved, the amount will be added
to the deposit immediately.
In addition, the registrar is able to view his account status, statements/
invoices and reports as described earlier. For billing adjustments, customized
reports or other special services that modify existing data, the registrar has
to contact the DENIC B & C customer service personnel by e-mail, phone or fax.
The B & C manager will execute the requests as communicated by the registrars.
4. B & C System Backup & Recovery
DENIC will perform the same procedures used for the overall .net registry
system for the B & C system backup and recovery. For further details on data
backup, please refer to part 2-5-b-x: Backup.
5. B & C Audits
The DENIC billing & collection system will provide data for accounting purposes
and auditing reports. As all invoices as well as accounting and auditing
reports will be created in Germany, all invoices and reports will strictly
comply with German law and standards, e.g. comply with German Commercial Law
and section 14 of the German Act on Sales Tax and include German VAT. All
invoices will be created in English language.
All information will be available for the current fiscal year and for a
succeeding period of ten years.
To regularly verify the accuracy of the whole billing process, DENIC will
internally audit the B & C system including data and procedures once per
year. In addition, the cooperative association (of which DENIC is a member)
conducts an external audit of the billing and collection process annually while
auditing the whole cooperative. |
|
|
(x) Backup. Describe frequency and procedures for
backup of data. Describe hardware and systems used, data format, identity
of suggested escrow agent(s) and procedures for retrieval of data/rebuild
of database.
|
(x) Backup
Highlights
* For .net, the .net secondary RSL will be the backup location.
* The backup hardware and software for .net will be installed in the highly-
secured .net secondary RSL to increase security. The two separate .net RSLs
will be connected via high volume links.
* Main goals of the DENIC data backup are the restoration of business relevant
data within a few hours, restoration of server systems within a day and the
restoration of accidentally deleted data.
* The retention time of data backups varies between the different types of data
from 20 days to five weeks. The retention time of the tapes can be determined
individually as required.
* A full backup of the .net registry database will be done daily; backups of
the transaction logs are conducted every two hours.
* For .net, DENIC will use similar hardware as for .de because the hardware of
DENIC's backup system for the .de registry system has proven to be
reliable under all conditions.
* The .net backup server will be integrated into the SAN and directly connected
to the HDS as central storage in the .net secondary RSL as well as to a
SpectraLogic Tape Library with AIT-3 tapes as physical backup medium.
* As for .de, DENIC will use Time Navigator (TiNa) as central backup software.
This system is characterized by high availability and stability. The physical
data backup will be carried out by the Robotic Tape Library Hardware on 147 AIT-
3 tapes with a data capacity of 14.7 TB.
* Reports about the daily backups conducted by TiNa will be sent automatically
to all employees of the DENIC System Administration Team including information
about backup performance and occurring problems.
* In addition to the data backup described in this chapter, DENIC is now
implementing a new data escrow procedure to deposit all registry data.
1. Overview of the DENIC Backup System
DENIC operates two fully equipped registry systems in two separate RSLs
for .de. This approach will also be used for .net. The primary RSL for .net
will shared with the facilities of the current primary RSL for .de. In
addition, DENIC will set up a new secondary RSL for .net at one of the major
international access points, i.e. London, Amsterdam or a US East Coast
location. The .net secondary RSL will match the specifications of the
current .de secondary RSL at COLT and include a full replica of the .net
registry database system. The replica will be created with the multi-target
functionality of the replication server. (Please refer to part 2-3-b-iii:
Description of Facilities for a detailed description of the current
infrastructure and the approach for .net.). For. de, the secondary RSL serves
as .de backup location. The same principle will apply for .net so that
the .net secondary RSL will be the backup location for .net.
The backup server and the tape library for .net will be installed in the highly-
secured .net secondary RSL to increase security. The two separate .net RSLs
will be connected via high volume links (see Figure 1).
In DENIC's network infrastructure, data is stored in different segments of the
network according to their required level of security. Logically, the network
is divided several separate secure networks.
Main goals of the DENIC data backup are:
* Restoration of business relevant data within a few hours,
* Restoration of server systems within a day
* Restoration of accidentally deleted data
The retention time of data backups varies between the different types of data,
e.g. backups of the database are kept up to 20 days, other data is kept up to
five weeks. In addition, tapes can be archived on demand. Their retention time
can be determined individually as needed.
As for .de, DENIC will use Time Navigator (TiNa) as central backup software.
This system is characterized by high availability and stability. The physical
data backup will be carried out by the Robotic Tape Library Hardware
(SpectraLogic Gator 64) on 147 AIT-3 tapes with a data capacity of 14.7 TB.
This library will be available to the Time Navigator Backup server via Storage
Area Network (SAN) (See also part 2-5-b-i: Facilities & Systems for further
information about SAN).
2. Frequency and Procedures for Backup of Data
Backups will be conducted regularly for the following system elements as
follows:
Registry Database
* Frequency:
* Daily full backup of the registry database for .de & .net
* Periodic backup of the transaction logs, every two hours
* Retention time: 20 days
* Procedure:
* Due to warm standby configuration, backup of active registry databases only
* Backups conducted by automated processes
* Backup conducted directly to AIT-3 tape drives
* The tape drive can be selected out of six available drives; two of them will
be exclusively reserved for the database backups
Server Systems (file system data, internal mailing system)
* Frequency:
* Monthly full backup
* Daily incremental backup
* Retention Time: 5 weeks
* Procedure:
* Scheduling via TiNa server
* Online backups
* Backup conducted directly to AIT-3 tape drives
Accounting Databases
* Frequency:
* Daily full backup
* Backups of transactions every hour
* Retention Time:
* 1 week on local hard drive
* 5 weeks on tape
* Procedure:
* 2 step process
* Backups are stored on local hard drive automatically via programs
* Via backup of server system (see file system data)
TiNa Database Catalogue
* Frequency:
* Daily full backup
* Retention time: 6 days
* Procedure:
* Scheduling via TiNa server
* Daily export of report, including job & performance overview
* Report is posted daily to system administration
The e-mail archive, all zone files and log files of the applications will be
regularly archived on CD or DVD and stored in secured locations as long as
required. The log files will enable DENIC to reconstruct the registry system.
In addition, the registry database will be archived via TiNa using specially
configured "cartridge pools" (endless retention time) once a month. This
ensures long term availability of the registry data.
3. Backup Hardware and Software Systems
For .net, DENIC will install the TiNa software on a server dedicated to the
backup for the .net registry data. The backup server will be integrated into
the SAN and directly connected to the HDS as central storage in the .net
secondary RSL. In addition, it will have a direct connection to a SpectraLogic
Tape Library with AIT-3 tapes as physical backup medium.
The backup hardware and software will be installed in the DENIC .net secondary
RSL.
(a) Backup Hardware
For .net, DENIC will use similar hardware as for .de because the hardware of
DENIC's backup system for the .de registry system has proven to be
reliable under all conditions. The specifications of the current .de backup
hardware are as follows:
Hardware
* Processor: 2 CPU à 1.28 GHz
* Memory: 4 GB
* Disc for system software: local
* Disc for TiNa data (Catalogue & Catalogue Backup): HDS/SAN
* Disc for caches: Local
* Interfaces: 1 Gbps Ethernet Adapter, 2 Gbps Channel Adapter
* Software: TiNa Backup Software
Tape Library
* Robotic Tape Library: Spectra Logic 64k
* Virtual libraries: 2 (for production and testing environment)
* Power supply: redundant
* Tape drives:
* AIT-3 current number: 8
* For production environment: 6 (2 are reserved for backups of the registry
databases)
* For testing environment: 2
* Tapes
* AIT-3 / current number: 147
* Productive environment: 100
* Data capacity: 14.7 TB (current; scalable up to 64 TB)
* Degree of utilization: ca. 50% (current)
* Scalability:
* Number of tape drives: scalable to 32
* Number of tapes AIT-3 scalable to 645
* Data capacity: scalable up to 64 TB
(b) Backup Software
Product Time Navigator
Time Navigator (TiNa) is DENIC's current central .de backup software which will
also be used for .net. TiNa consists of a server and a client component. The
TiNa software also includes a GUI-application which can be started either from
the UNIX server or from any client. This application facilitates the monitoring
and administration of the whole backup system.
Furthermore, Time Navigator provides a number of toolkits for conducting
backups from the database server directly into the TiNa Library (see Figure 2).
The system is characterized by simple administration, high availability,
scalability and high performance. It is also compatible to a number of storage
products, e.g. ADIC, DELL, EXABYTE, HP, SpectraLogic.
The TiNa catalogue, which is the core database, contains all the information
required to run Time Navigator, such as the configuration of the platforms,
drives, libraries, users, cartridges etc. It also comprises the meta-data that
is recorded in the catalogue during writing operations. The meta-data contains
the descriptions and locations of all backed up files.
For .net, the TiNa catalogue will backed up on a daily schedule. After the
backup will be finished, a report about the backups conducted by TiNa will be
sent automatically to all employees of the DENIC System Administration Team.
The reports will include details on successfully completed backup jobs,
performance information about all backups as well as occurring problems during
the backup procedure.
4. Data Format
The backup server software TiNa is able to write the magnetic tapes in the
following formats:
* TiNa (the only format to allow data compression and encoding)
* tar
* cpio
* sidf (LAN free Backup only)
* none (raw format)
For the backup of the .net registry database, the dump files will be written
in "tar" format on the magnetic tapes. This format secures independence from
TiNa in case of restoration.
5. Identity of Suggested Escrow Agent(s)
In addition to the data backup described in this chapter, DENIC is now
implementing a data escrow procedure to deposit all registry data with the
following escrow provider:
HanseEscrow Management GmbH
Stresemannallee 118
D-22529 Hamburg
contact@hanse-escrow.de
www.hanse-escrow.de
The .net escrow procedure will be fully in operation until the transition of
the .net registry. In addition to this escrow provider, DENIC is currently
evaluating several US escrow providers to also deposit .net escrowed data in
the US. The .net registry data will be transferred to and stored at the escrow
provider site according to the agreement with ICANN.
Please refer to part 2-5-b-xi: Escrow for details on the escrow arrangements,
data formats, insurance arrangements and backup plans for data recovery and
Appendix R for details on the data escrow specifications.
6. Procedures for Retrieval of Data/ Rebuild of the Database
(a) Procedures for Retrieval of Data
All backup tapes will be stored in the tape library which will be installed in
the secondary RSL for .net. Thus, the tapes will be kept separate from the .net
primary RSL.
By employing an escrow agent, the .net registry data will be also stored in an
additional external secure location in XML-format (see part 2-5-b-xi: Escrow
and Appendix R for details).
The procedures for data retrieval are based on the following cases:
* Resynchronization of the standby systems after the switchover procedure in
case of the failure of the active RSL (Standby database takes over the
functions of the primary database)
* Recopying the full backup and the transaction log files
For .net, all these procedures will be documented in detailed checklists which
will be available to the relevant employees in a knowledge database at any
time. The switchover procedure as well as the re-import of backups will be
trained regularly while conducting maintenance tasks. Checklists will be
continuously reviewed and improved.
See part 2-5-b-v: Database Capabilities for a description of the switchover
process.
(b) Rebuild of the Database
The rebuild of the .net registry database will be described for two failure
scenarios (please see part 2-5-b-v: Database Capabilities for detailed
information on database and replication systems):
(i) Scenario 1: Failure of the Active Database
The standby system in the secondary RSL will be still available.
* Switchover from the active database in the primary RSL (db_active in the
following) to the standby database in the secondary RSL (db_standby in the
following). db_standby will then become db_active. The switchover process will
comprise a data integrity check of the standby database (see part 2-5-b-5:
Database Capabilities for details). The highly effective replication process
will ensure that the standby database remains the most accurate backup system.
The transactions performed on the active database will be transferred via the
replication server which runs on a high performance UNIX server. According to
the regularly conducted measurements, the latency time is zero. Exceptions
would only occur, if maintenance work or a long running query were performed on
the standby system.
* As the replication process will be transaction-based, a high level of
security will be achieved.
* After the switchover process has been completed, the registry processes will
be fully available.
* The standby database will be synchronized again after the failure of the
former active database has been corrected.
* A full backup of the new db_active will be conducted via TiNa.
* Simultaneous activation of the replication agent thread for the new
db_active. From that moment on, all transactions will be transferred to the
replication server and stored in the stable queue.
* The current full backup of the new db_active will be reloaded to the new
db_standby server via TiNa.
* The connection between the replication server and the new db_standby server
for the database will be activated.
* The replication can now be started as the warm standby system is available
again.
* If necessary, the roles of the new db_active and db_standby can be switched
back using the same procedure.
In this scenario, a downtime of approximately ten minutes will occur during the
switchover process. DENIC currently works on decreasing the switchover time.
(ii) Scenario 2: Logical Errors in the Registry Database
DENIC only deploys registry applications which have passed through multiple
quality assurance procedures. Therefore, logical errors have not occurred at
DENIC to date.
Despite the comprehensive quality assurance procedures and standards, it is
still possible that logical errors occur in the registry database - e.g. due to
defective software - which are transferred to the standby system through
replication.
In this case, the .net registry database will be rebuilt as follows:
* All applications as well as the replication process will be stopped.
* A backup of the transaction log in the active database will be conducted. In
addition, the time of the first logical error in the database will be
determined.
* The last full backup conducted prior to the failure will be restored to the
active database via TiNa.
* Then, all following transaction logs up to the time the error occurred will
be restored via TiNa (point-in-time recovery)
* All changes which occur until the setup of the database will have to be
reconstructed with the help of the application log on application level.
* All applications will be restarted, the registry system will now be available
again.
* Finally, the synchronization of the standby system will be conducted as
described in scenario 1.
(Please also refer to part 2-5-b-v: Database Capabilities) |
|
|
(xi) Escrow. Describe arrangements for data escrow, or
equivalent data backup security, data formats, insurance arrangements and
backup plans for data recovery.
|
(xi) Escrow
Highlights
* DENIC is implementing a new data escrow procedure.
* The complete verification process which is used at the escrow provider's site
to ensure completeness and integrity of the transferred data will be developed
and implemented by DENIC.
* The reports for a full deposit will be generated once a week as a snapshot of
the registry data.
* For the full deposit, the domain, host, contact, registrar object and pending
transfer reports will be concatenated.
* The incremental deposit consists of a report including the complete set of
transactions that were processed by the registry system since the generation of
the last full or incremental deposit file.
* All reports of the full and incremental deposit will be exported from the
database into XML format according to the XML 1.0 specification.
* DENIC will create PGP encrypted and signed data files which will be
transferred to the escrow provider.
* DENIC will verify and review escrowed data every three months and will make
the results of these reviews available to ICANN and the public.
* To ensure the serviceability of the transferred data files, DENIC will also
document the content and structure of the reports together with the related
schemas. Schemas will be stored separately from XML data files and updated
immediately at the escrow provider site, if the data file structure was updated
or changed.
* For the recovery of reports, DENIC provides the schemas for the description
of the report files, a full documentation of its own database structure as well
as the process of exporting data from the database to the XML escrow data files
to the escrow provider.
* DENIC additionally escrows the source code of self-developed software, all
relevant documentation, all business and technical procedures needed to restore
all technical facilities.
1. Data Escrow Arrangements
In addition to the backup procedure with daily full backups as well as
transaction log backups of the registry database, DENIC is now implementing a
new data escrow procedure to deposit the .de registry data with an established
European escrow provider. By the time DENIC takes over the .net registry, the
new procedure will be fully in operation. For .net registry data, the same
escrow provider will be used. In addition to this European escrow provider,
DENIC is currently evaluating several US escrow providers to deposit .net
escrowed data in the US. The .net registry data will be transferred and stored
at the escrow provider site according to the ICANN agreement. The whole escrow
process will be mutually examined and improved to meet the requirements of the
registry agreements between Registry Operator and ICANN.
Further details on the escrow agreement are described in appendix R.
Schedule
* Full Deposit on Sunday
* Incremental Deposit Monday through Saturday
Content Weekly Report
* Domain Object Report
* Host Object Report
* Contact Object Report
* Registrar Object Report
* Pending Transfer Report
Content Daily Report
* Transaction Report
Format
* All Reports are generated in XML format
The report files of a full deposit will be verified against the respective XML
schema (XML Schema 1.0 specification) to ensure correct data format and
integrity. Before the reports of a full deposit are transferred to the escrow
agent, they will be concatenated to a single file. For the .net data, files
will be named NET followed by a 4-digit sequence number for the related deposit
transfer. The deposit files are encrypted and signed using PGP.
The encrypted and signed file will be transferred to the escrow agent to a
nonpublic secure ftp server area.
The complete verification process which is used at the escrow provider's site
to ensure completeness and integrity of the transferred data will be developed
and implemented by DENIC. During the steps of the verification process, the
signature will be checked. The transferred data file must be decrypted and
split into the different reports. The report files will be verified using the
related report specific XML schema.
Schedule for Full Deposit
The five reports for a full deposit will be generated once a week on Sunday
00:00:00 UTC as a snapshot of the registry data. Database transactions which
have not been committed by this point in time, will not be exported to the
reports. The reports will be delivered by 06:00:00 UTC on Sunday.
Schedule for Incremental Deposit
The incremental deposit consists of a report including the complete set of
transactions that were processed by the registry system since the generation of
the last full or incremental deposit file. The first incremental deposit after
a full deposit covers the transactions not yet committed during the full
deposit snapshot taken at Sunday 00:00:00 UTC and all transactions until Monday
00:00:00 UTC. A sequence of six incremental deposits follows until Saturday
00:00:00 UTC. Incremental deposits will be generated, verified and transferred
until 04:00:00 UTC of the related day.
2. Data Formats
All reports of the full and incremental deposit will be exported from the
database into XML format according to the XML 1.0 specification. The XML format
is common for data exchange and storage on an application independent basis.
For the full deposit which is formed by the five different reports, a specific
schema exists for each of them. These schemas will be used for description of
the related report. The respective schema is the basis for the verification
process at DENIC and at the escrow provider. With the help of an XML-parser,
the reports will be checked for completeness, correctness, integrity, syntax
and coherence. The full deposit is described on database field level below.
Before describing the detailed reports, the following has to be considered:
* Only if the related database field contains data, the respective XML element
for a given object will be exported in combination with the opening and end
tag. Thus, there will not be any empty elements in the reports.
* All object reports contain an XML attribute id which is used to build the
relation between the objects in the different reports.
* XML files will be UTF-8 encoded to provide fully internationalized support.
(a) Content of Full Deposit
The reports which will be concatenated to a full deposit are:
* Domain Object Report - contains all domain objects in the registry database.
* Host Object Report - contains all host objects in the registry database.
* Contact Object Report - contains all contact objects in the registry database.
* Registrar Object Report - contains all registrar objects in the registry
database.
* Pending Transfer Report - contains all running transfers up to the moment of
the full deposit.
Domain Object Report
The following elements are included:
* Fqdn - Fully qualified domain name.
* Status - The domain status code.
* Period - The registration period in years.
* Owned-by - An identification (the "id" attribute of the registrar element) of
the sponsoring registrar of the domain.
* Created-by - An identification (the "id" attribute of the registrar element)
of the registrar that originally created the domain object.
* Created-on - The date/time the domain object was originally created.
* Renewed-on - The date/time the domain was last renewed.
* Updated-by - An identification (the "id" attribute of the registrar element)
of the registrar that last updated the domain object.
* Updated-on - The date/time the domain object was last updated.
* Transferred-by - An identification (the "id" attribute of the registrar
element) of the registrar that last transferred the domain object.
* Transferred-on - The date/time when the domain object was last transferred.
* Host-id - An identification (the "id" attribute of the host element) of a
name servers for the domain.
* Contact-id - Contact-ids that reference the contact records for this domain.
Contact-id has the attribute "type" to denote the type of contact. "Type" can
be one of: Registrant, Administrative, Technical or Billing.
* Expires-on - The date/time of the domain expiration.
* AuthInfo - The authorization information associated with the domain.
* Pending-transfer - An identification (the id" attribute of the transfer
element) for potentially existing transfers.
An example of the domain container appears below:
<domain id="1">
<fqdn>example.net</fqdn>
<status>ACTIVE</status>
<period>1</period>
<owned-by>42</owned-by>
<created-by>42</updated-by>
<created-on>2005-08-14T12:34:56+01:00</created-on>
<updated-by>42</updated-by>
<updated-on>2005-08-15T13:23:56+01:00</updated-on>
<host-id>99</host>
<host-id>100</host>
<expires-on>2006-08-15T13:34:56+01:00</expires-on>
<contact-id type="Registrant">1</contact-id>
<contact-id type="Administrative">2</contact-id>
<contact-id type="Technical">3</contact-id>
<contact-id type="Billing">4</contact-id>
<authInfo>fooBar</authInfo>
<pending-transfer>123</pending-transfer>
</domain>
Host Object Report
The following elements are included:
* Fqdn - Fully qualified host name.
* Owned-by - An identification (the "id" attribute of the registrar element)
of the sponsoring registrar of the host.
* Created-by - An identification (the "id" attribute of the registrar element)
of the registrar that originally created host object.
* Created-on - The date/time the host object was originally created.
* Updated-by - An identification (the "id" attribute of the registrar element)
of the registrar that last updated the host object.
* Updated-on - The date/time the host object was last updated.
* IP-address - Any IP addresses associated with this host, with an attribute
type indicating whether it is an IPv4 or an IPv6 address.
An example of the host container appears below:
<host id="99">
<fqdn>dns1.example.net</fqdn>
<owned-by>42</owned-by>
<created-by>42</created-by>
<created-on>2005-08-14T12:40:32+01:00</created-on>
<updated-by>42</updated-by>
<updated-on>2005-09-14T12:25:12+01:00</updated-on>
<ip-address type="v4">192.0.2.0</ip-address>
</host>
Contact Object Report
The contact element consists of the following elements:
* Name - The name of the contact.
* Organization - The organization for the contact.
* Within the "contact" container is a sub-container named "postal" with the
following elements:
* Address - The street address of the contact.
* City - The name of the city of the contact.
* State-province - The name of the state/province of the contact.
* Postal-code - The postal/zip code of the contact.
* Country - The two-letter ISO 3166-1 code for the contact's country.
* Voice - The voice phone number of the contact in E164a format.
* Fax - The fax number of the contact in E164a format.
* Email - The e-mail address of the contact.
* Owned-by - An identification (the "id" attribute of the registrar element) of
the sponsoring registrar of the contact.
* Created-by - An identification (the "id" attribute of the registrar element)
of the registrar that originally created the contact object.
* Created-on - The date/time the contact object was originally created.
* Updated-by - An identification (the "id" attribute of the registrar element)
of the registrar that last updated the contact object.
* Updated-on - The date/time the contact object was last updated.
* Transferred-by - An identification (the "id" attribute of the registrar
element) of the registrar that last transferred the contact object.
* Transferred-on - The date/time when the contact object was last transferred.
An example of the contact container appears below:
<contact id="1">
<name>Juergen Mustermann</name>
<organization>aol</organization>
<postal>
<address>Musterstrasse 1</address>
<city>Frankfurt</city>
<state-province>Hessen</state-province>
<postal-code>60000</postal-code>
<country>DE</country>
</postal>
<voice>+49.691234567</voice>
<fax>+49.691234568</fax>
<email>jmustermann@example.net</email>
<owned-by>42</owned-by>
<created-by>42</created-by>
<created-on>2005-08-14T12:42:22+01:00</created-on>
<updated-by>42</updated-by>
<updated-on>2005-09-14T19:21:22+01:00</updated-on>
</contact>
Registrar Object Report
The registrar element has the attribute "id", which is a unique identifier
assigned by the IANA., and consists of the following elements:
* Password - The password for the registrar.
* Name - The name of the registrar.
* Status - The registrar status code.
* Contact-id - Any number of contact-id associated with this registrar. Contact-
id has the attribute "type" to denote the type of contact. "Type" can be one
of: Administrative, Technical or Billing.
An example of the registrar container appears below:
<registrar id="42">
<password>denic12345</password>
<name>REGISTRAR-FOO</name>
<status>ACTIVE</status>
<contact-id type="Administrative">10</contact-id>
<contact-id type="Administrative">11</contact-id>
<contact-id type="Technical">12</contact-id>
<contact-id type="Technical">13</contact-id>
<contact-id type="Billing">14</contact-id>
</registrar>
Pending Transfer Report
The transfer element consists of the following elements:
* Period - The extension of lifetime (in years) of the domain.
* Requested-by - An identification (the "id" attribute of the registrar
element) of the gaining registrar.
An example of the pending transfer element appears below:
<transfer id="123">
<period >1</ period >
<requested-by>43</ requested-by >
</transfer>
(b) Content of Incremental Deposit
The report which forms an incremental deposit is:
* Transaction Report - consists of all transaction records since last full or
incremental Deposit.
Transaction Report
The transaction element contains the properties "operation"
and "type". "Operation" can be one of: add, modify, transfer or delete. "Type"
can be one of: domain, host, contact or registrar. The transaction element is a
container consisting of elements from the corresponding "type" element. For
example, a transaction element with a "type" of "registrar" will have the same
set of elements as a registrar element. For a "delete" operation, only the
object ID is included in the transaction element.
An example transaction container appears below:
<transaction operation="modify" type="registrar">
<password>new password</password>
<name>REGISTRAR-FOO</name>
<status>ACTIVE</status>
<contact-id type="Administrative">10</contact-id>
<contact-id type="Administrative">11</contact-id>
<contact-id type="Technical">12</contact-id>
<contact-id type="Technical">13</contact-id>
<contact-id type="Billing">14</contact-id>
</transaction>
3. Insurance Arrangements
DENIC will create PGP encrypted and signed data files which will be transferred
to the escrow provider. The encryption provides confidentiality and the
signature for integrity and authentication of deposit files. (Please refer to
Appendix R for a description of the usage of private and public keys.)
To ensure the successful completion of the data transfer from DENIC to the
escrow provider, the files, which will be sent, will not exceed a size of 1 GB.
The escrow provider checks the signature, decrypts the file, and splits it into
the different reports. Every report will then be verified for completeness,
correctness, integrity, syntax and coherence using the related report-specific
XML schema. Upon successful verification the reports will be stored encrypted
on two separate DVDs using ICANN's public key. The escrow provider uses single
layer DVDs with a storage capacity of 4.7 GB. These read-only media will be
checked for legibility. The created storage media will be transferred to
different bank safe deposits.
For the verification process the transferred data will be stored on a local
hard disk. After the verification process has been completed, the data will be
deleted from this hard disk.
In addition, DENIC will verify and review the escrowed data every three months.
The results of these reviews will be made available to ICANN and to the public.
To ensure the serviceability of the transferred data files, DENIC will also
document the content and structure of the reports together with the related
schemas. Schemas will be stored separately from XML data files and updated
immediately at the escrow provider site, if the data file structure was updated
or changed.
The content of the escrow contract also determines ICANN as the beneficiary who
is entitled to receive the escrowed data and the cases in which the delivery of
the escrowed data is permitted. The beneficiary is one of the contracting
parties.
The escrow provider also effected an insurance for its business operations
covering an amount of loss up to 1 million Euro. This insurance explicitly
covers the loss of escrowed data.
4. Backup Plans for Recovery
The data files are stored for a period of 42 days at the bank safe deposits of
the escrow agent. For the recovery of the reports, DENIC provides the schemas
for the description of the report files as well as a full documentation of its
own database structure. In addition, the process of exporting data from the
database to the XML escrow data files will be included, as the export process
is specific for the DENIC data model of the registry database. To prepare a
domain object report file from the registry database, the data must be read
from several tables. This documentation provides any third party, who is
entitled to receive escrow data, with helpful information to rebuild the
registry database based on the original data model or on a different model.
The data specification is a central part of the transition plan for the
transfer of the registry from the incumbent registry operator to DENIC. This
specification is based on the incumbent registry operator's data escrow
activities. A detailed data description will also be part of the documentation
deposited at the escrow provider.
Please refer also to part 2-5b-x: Backup for a detailed description of database
recovery from daily full backups and incremental transaction log dumps.
5. Escrowing of Software, Procedures & Documentation
As part of its .net disaster recovery plan, DENIC also escrows the following
additional information:
* Source code of self-developed software
* All relevant documentation
* All business and technical procedures needed to restore all technical
facilities
This information is weekly escrowed and deposited at the defined escrow
provider (see Appendix R for details). |
|
|
(xii) Publicly accessible WHOIS service. Address
software and hardware, connection speed, search capabilities and
coordination with other WHOIS systems. Frequency of WHOIS updates,
availability and processing times. Identify whether you propose to use a
“thick” registry model or “thin” registry model, and explain why you
believe your choice is preferable.
|
(xii) Publicly Accessible Whois Service
Highlights
* Scalable, fast, near real time whois service.
* Thick data model to enable one-stop-service for complete, standardized
information about each domain.
* Thick data model for increased availability - no dependency on third parties.
* Privacy flags to enable registrants to individually decide to which degree
contact data will be made available (still within the boundaries set by ICANN
for mandatory information fields).
* Separate registrar whois with direct read access to the active database.
* Privacy flags also honored when displaying data to others but the sponsoring
registrar.
* Clear migration path from thin to thick model.
* Strong commitment to work on whois successor CRISP/IRIS.
The complete documentation of DENIC's current whois service for the .de TLD can
be found at http://www.denic.de/en/domains/technik/denic_whois-
server/index.html.
1. Whois Architecture
Current Whois Architecture
Both public and registrar whois service are currently installed on servers in
the Service Provisioning Layer with direct access to DENIC's registry
databases. DENIC deploys clusters of whois servers at the primary and secondary
RSL which are operated in a load balancing fashion (see Figure 1).
These servers directly access the NIC database of the active database server
via a firewall and the whois backend. This direct whois access to the registry
database ensures real-time information accuracy for all whois requests.
Future .net and .de Whois Architecture
DENIC currently enhances the whois architecture by moving the public whois to
dedicated servers in the Service Provisioning Layer (see Figure 2). These
servers are integrated into the replication system of the database with the
replications customized to fit the exact needs of the public whois service. The
production databases will experience a significant load decrease through this
new setup leading to shorter response times for public whois. While generally
the advantage of dedicated whois servers is paid for by publishing only less
current data on the whois servers, this is not the case in DENIC's system. The
integration into the replication system ensures whois data is availability in
near real time with an average latency of few milliseconds and a maximum
latency of one minute. This transition is planned to be finished by the end of
2005 latest.
For details regarding DENIC's complete Registry Service Location System
Architecture with descriptions of the individual layers please see part 2-5-b-
i: Facilities and Systems.
2. Registry Model
Advantages of the Thick Registry Model
DENIC provides its services to the .de community following the thick registry
model and will implement the .net registry under the thick model as well. DENIC
firmly believes the thick model to be superior to the thin model currently
followed by the incumbent as it offers higher data integrity, security and
increased performance.
Specifically DENIC sees the following advantages:
* Complete, standardized information about each domain
* Overall scale effects, significantly reducing costs for registrars
* Opportunity to significantly streamline inter-registrar functions, such as
domain transfer
* Immediate registrant data availability in case registrar vanishes, enabling
faster transfer
* Less latency, shorter response times since only a single server needs to be
queried
* Easier escrow supervision since only a single party is responsible
* Ease of registry-level transfer enforcement.
Additionally, by implementing the thick model DENIC can implement the privacy
policy the registrant requests by centrally setting privacy flags. DENIC sees
this feature as one of the most important aspects for helping the registrant to
individually choose his or her privacy policy. From the experience with .de,
DENIC expects the vast majority of .net registrants to make use of this feature
and limit their domain information to the basic information fields. Currently
80% of .de registrants make use of that feature.
3. Whois Data Objects and Fields
While allowing for both RRP and EPP and both thin and thick data models in the
beginning, DENIC will migrate all registrars to EPP and to the thick model.
Details regarding protocols are described in part 2-2-b: Equivalent Access, in
part 2-5-b-iv: Registry-Registrar Model and Protocol and in part 2-8:
Transition Plan.
(a) Data Objects for .net Domains
Our whois for .net will fulfill all ICANN requirements regarding data objects
as specified for RRP as well as EPP. DENIC will build the .net database based
on EPP and a thick model. However, as outlined in detail in part 2-8:
Transition Plan and part 2-2: Equivalent Access, DENIC will provide a RRP to
EPP proxy for a transition time of four months after taking over responsibility
for the .net registry.
Registrars will have twelve months to migrate from the thin to the thick data
model. Therefore there will be different whois data outputs for thin and thick
data sets in these first twelve months depending on the migration stage of the
sponsoring registrar.
At the start of the migration phase registrars will have the option of
registering domains following either of both models. The whois output for thick
data sets is described in Appendix O. For domains with only a thin set of data,
the contact references in the domain object will not be shown. In order to
access contact data, clients will have to follow the referral included in the
domain output to reach the authoritative whois server supplied by the
sponsoring registrar.
All thin data sets will have to be updated to thick data sets and all data has
to be stored in DENIC's registry database twelve months after takeover of the
registry. All whois data output will then follow the thick model only.
(b) Current Data Objects for .de Domains
The current data object structure for .de will be made available upon request.
4. DENIC's Flexible Thick Data Output Model
As part of DENIC's thick registry model, DENIC will give registrants more
options to protect their privacy by limiting the amount of information given in
the public whois. Advantages of the flexible thick data output model for
the .net community are described below in detail.
Nevertheless there are certain mandatory information fields which will be
displayed in public whois in order to be able to unambiguously identify the
registrant, e.g. for legal reasons. The suggested mandatory fields are
identified in the proposed Appendix O.
The mandatory information fields will ensure that the domain holder can be
identified and contacted. Only providing information how to contact the domain
holder via regular mail will establish sufficiently high hurdles to protect the
registrant from unsolicited phone call or e-mails. Abuse of information by the
public or by registrar is effectively prevented.
The administering registrar will have access to the complete set of fields
regardless of the privacy settings.
The following fields are always displayed, if available, for all contacts:
* Name
* Address
* Zipcode
* City
* State
* Country
For the registrant contact, this field will also be shown, if available:
* Organization
For technical contacts these fields will be displayed, if available:
* Phone
* Fax
* E-mail
5. Whois Query Options
The whois service is used by two different user groups (registrars and public)
and can be accessed via two different means (command line and web servlet).
Since a registrar web whois does not exist, the whois requests originate from
three different query options: web whois, public whois via whois protocol and
registrar whois via whois protocol.
The query options described below represent current status for .de domains.
For .net DENIC will offer essentially the same options and make adjustments
where necessary (e.g. in regard to needed flags).
The public whois via whois protocol is by far the most widely used query
option, as shown in Figure 3.
Access Control Lists
DENIC uses Access Control Lists (ACLs) to prevent the whois service from being
overloaded by a high number of requests. If the request frequency of a source
exceeds a certain threshold value, the network will be blocked for a period of
time. The threshold values and time limits are defined by DENIC and adapted
regularly. The use of ACLs protects whois from grabbers or (D)DoS attacks,
ensures equal access of all users and prevents mass requests from reducing
whois performance.
(a) Public Whois via Web Servlet
In order to optimize its public whois services DENIC conducted a study among
Internet users about their interest in the whois service. This study suggested
that more than 90% of the public users are only interested in whether the
domain is already registered or still available. Therefore DENIC has designed
its web based whois as a two step process, first only giving the availability
information (see Figure 4).
For receiving additional information the user has to agree to terms and
conditions of use. Approximately 10% of public users actually use the second
step of the whois service. At a minimum, information about the domain holder,
administrative and technical contact, the zone administrator and technical data
is given (see Figure 5). The example below shows the current minimal whois data
output for .de according to the DENIC domain- and registration guidelines.
Additionally privacy flags can be set by the domain holder, the admin-c, tech-
c, and billing-c for their respective personal data.
A side benefit of introducing this two step procedure has been a significantly
reduced load on the database, as the majority only uses the first query
function to find out the status of the domain.
(b) Public Whois via Command Line
While individual users mainly use whois via the web servlet - as described
above - registrars checking for available domain mainly use the public whois
via whois protocol. As these registrars are requesting information about
domains they are not administering, they are treated like public users and the
same privacy regulations apply.
Query for Domain Status
The query for domain status resembles the first step of the web based whois
query. Only the status (available, registered, blocked,...) is returned.
Query for Domain Data
The query for domain data basically equals the second step of the web based
whois. The privacy policies are the same, only the mandatory set of data plus
data marked as public by the domain holder is returned. However, within these
limits the information output can be customized by the whois user via several
flags, which are describe later in detail.
(c) Registrar Whois via Command Line
The Registrar whois output only differs from the public whois output when a
registrar requests information about a domain administered by himself. While
this will not happen in the thin model (here the registrars hold their own
data), it is an important function in the thick data model.
After address based authorization the registrar has unlimited access to all
domain, contact and technical information of the domains it is maintaining.
While registrar whois is mainly used for domain queries, status queries are
also possible.
The same set of command line flags applies to both public and registrar whois.
(d) Additional Queries and Flags
Help Query and Flags
By setting flags for whois requests via the command line, data output can be
customized. The help query outputs all the flag options that can be used in
combination with whois queries and has the following syntax:
whois -h whois.member.denic.de HELP
Figure 6 shows the command line flags currently supported for .de whois as
output of the help query.
The syntax for these whois requests with flags is the following:
whois [-h hostname] [-Frk] [-T types] [-i attr] [-C charset] key
As described above these flags set by the whois user do not override privacy
settings by the domain holder. Data output is only being customized within the
limits defined by the registrant. Registrars are only granted access to
complete information for the domains they administer themselves.
Character Set Flags
The default output format of the registrar whois information is UTF-8; UTF-16,
ISO-8859-1, US-ASCII are also supported.
6. Availability, Response Times, and Monitoring
(a) Availability
The whois application is running in parallel on clustered servers. Via load
balancers the requests are distributed evenly to all servers which ensures a
whois availability of 99.99%.
DENIC is continuously upgrading hardware and software to enhance performance.
Extensive monitoring of the whole registry system and the whois service
ensures, that increasing demands are detected well in advance and will be
counteracted appropriately, so that demand can always be served. In the short
term the counteractions can be the introduction of an additional server, in the
long term the complete setup might be reengineered to meet the consistently
higher demands.
Figure 7 shows a load graph of the four whois servers in calendar week 49. New
whois servers can be added at any time (for details see RSL level 3 in part 2-5-
b-i: Facilities and Systems) to increase whois capacity to meet the needs of
the community.
In the long run use of DENIC's whois service has developed as shown in Figure
8. After the introduction of access control limits in June 2003 the number of
total whois requests dropped sharply, indicating that DENIC's measure about
limiting mass whois requests by few registrars had been effective.
However, as the number of whois requests has consistently been on the rise
again, DENIC had to act in order to provide enough capacity for all requests to
be served. The number of whois servers has therefore been doubled, and will be
increased as soon as the need arises.
(b) Response Times
Response times depend on the type of query. Status queries are answered in less
than 100 milliseconds (excluding round trip time outside DENIC's systems) for
more than 98% of all queries. These status queries represent about 85% of all
whois queries. Domain queries are answered in less than 300 milliseconds
(excluding round trip time outside DENIC's systems) for more than 98% of all
queries. User perceived total round trip times may vary due to factors outside
the sphere of influence of the registry operator.
(c) Performance Monitoring
DENIC is consistently monitoring its whois service for security and performance
reasons. Details regarding security of DENIC's whois service are described in
part 2-5-b-xiii: Security, and details regarding performance monitoring are
described in part 2-5-b-xvi: Outage Prevention. In all monitoring activities,
the applicable national and EU data protection legislation is honored.
7. Development of Additional Query Services
The nicname protocol (whois) is currently specified in RFC3912 which superseded
RFC954 without substantially modifying the protocol. The limitations of whois
discovered in recent years still apply, e.g. lack in security, structure or
internationalization support.
Feeling that the whois protocol at its current stage does not address the
requirements of a modern protocol, DENIC has actively supported the development
of the IRIS protocol in the Cross Registry Internet Service Protocol (CRISP)
IETF working group. Now that the specification has been published as RFC3981,
RFC3982, RFC3983, DENIC will soon start to evaluate, define, implement and
deploy IRIS as an information service parallel and superior to whois. |
|
|
(xiii) System security and physical security.
Technical and physical capabilities and procedures to prevent system
hacks, break-ins, data tampering and other disruptions to
operations.
The applicant's response to Part 2, Section 5, Subsection
b, Question xiii will remain confidential to ICANN and the independent
evaluators. ICANN will use reasonable efforts to avoid publication or
release of this information, but in no circumstance will ICANN's liability
for any release of this information exceed the amount of the application
fee.
|
[RESPONSE IS CONFIDENTIAL] | |
|
(xiv) Peak capacities. Technical capability for handling a
larger-than-projected demand for registration or load. Effects on load on
servers, databases, back-up systems, support systems, escrow systems,
maintenance and personnel.
|
(xiv) Peak Capacities
Highlights
* Due to the comprehensive monitoring of components and services, DENIC is able
to early identify and dissolve peaks.
* For the .net registry system, DENIC will assign large excess capacity to all
system components, including the backup and escrow system as well as the
support systems enabling the system to handle peaks without any performance
deterioration.
* The planned .net database will be equipped with very large excess capacity to
handle the transactional growth for all three business case scenarios.
* As DENIC closely cooperates with its registrars, no planned mass requests or
any other planned peaks should occur during maintenance periods.
* DENIC will respond to peak load situations by dynamically reassigning teams
and actively communicating internally and externally (i.e. to the registrars).
* DENIC personnel has profound experience in handling peak loads, e.g.
introduction of IDN.
While operating the .de registry, DENIC was able to acquire profound experience
in planning and managing a registry that is fully reliable also in peak load
situations.
DENIC relies on continuous capacity planning which bases on assessing the
current capacities of the registry system. A 2-year plan for the IT
architecture is created during the yearly budget planning phase. The plan is
revised yearly to find out whether assumptions and planned capacities have to
be redefined.
DENIC also permanently monitors all relevant system parameters for .net. DENIC
uses the system monitoring results to identify resources that tend to critical
utilization ratio in peak situations well in advance and to decide upon
capacity increases e.g. system modifications, extensions or changes in the
system architecture.
For each parameter, DENIC defined a threshold value. The levels of the values
are interpreted by automated monitoring programs. Whenever the defined
threshold values per component are reached or exceeded, system-generated
notifications are sent automatically according to the integrated escalation
scheme.
For .net, DENIC will also establish continuous capacity planning and system
monitoring.
See also part 2-5-b-iii: Operational Scalability for details on capacity
planning and system scalability. Part 2-5-b-xvi: System Outage Prevention
outlines details on the monitoring System.
1. Network & Servers
(a) Network
(i) RSLs
For .net, DENIC will strictly monitor its network components so that peak loads
can be identified early. To ensure that the system is also able to handle peak
loads, DENIC will provide high excess capacities for the .net RSL components
similar to those for the current .de system. The excess capacities for the
relevant .de components are as follows:
Layer 1: External Routing Layer
* 400 Mbps transit capacity (vendor); typical usage: 15-20 Mbps
* Routers at 1-3% of tested bandwidth
* Core routers at 5-12% of packet forwarding capacity
Layer 2: Perimeter Network Layer
* Packet filters at 8-15% system load
* Packet filters at 0-2% of forwarding capacity
* Packet filters at 3-10% of session setup capacity
Layer 3: Service Provisioning Layer
* Switches: System load at 1-5%
* Server: Scalable by load balancers and clusters (additional servers)
Layer 4: Internal Network Layer
* Packet filters at 0-1% system load
* Packet filters at 3-5% of forwarding capacity
* Packet filters at 2-8% of session setup capacity
* Switches at <1% of forwarding capacity
* Inter-RSL links at 1-10% of available bandwidth
* Processing reserve on all components
Layer 5: Data Provisioning Layer
* Switches: System load between 1% and 2% for all switches
* Application Servers: Scalable by installation of additional components (add
CPU, I/O, server)
See also part 2-5-b-i: Facilities & Systems for details.
In addition, DENIC will ensure a stable and highly-available connection to the
Internet for .net. Several providers will be selected so that connectivity will
be still guaranteed, also if one provider fails. As for. de, each of the core
routers at the .net RSLs will have two transit providers connected by at least
100 Mbps lines whose capacity will be only used by 2.5%.
See part 2-3-b-iii: Description of Facilities for details.
(ii) NSLs
As for .de, the .net NSLs will be implemented considering robustness,
performance and extensibility. The .net NSL components will operate at less
than 5% workload at normal query rates. Thus, high excess capacity of query or
packet rates in peak times or during (D)DoS attacks will be provided. The
excess capacities for the relevant components currently used for .de are as
follows:
1. NSL Architecture
* Switches at <1% of forwarding capacity and system load
* Processing reserve on all components
2. NSL Production Architecture
Layer 1: External Network Layer
* External lines are burstable to 100 Mbps
* Typical bandwidth use is 1% of burst
* Router/Load balancer at max. 3% typical load
* BGP router (in anycast setups) equipped with memory for at least 500,000
routes; typically carries 1,000 routes
Layer 2: Service Provisioning Layer
* Switch is at about 1% system load
* Servers are at max. 5% system load under normal conditions
3. NSL Management Architecture
Central NSL OoB Management
* 4 additional Disc Bays available
* 2 additional CPU Slots available
* max. 5% system load under normal conditions
* External line is burstable to 100 Mbps
* Maximum tunnel throughput is about 22 Mbps
* Typical VPN tunnel traffic 200 Kbps
* All components are at minimal system load
NSL OoB Management Layer
* 4 additional Disc Bays available
* 2 additional CPU Slots available
* max. 5% system load under normal conditions
* External line is burstable to 100 Mbps
* Maximum tunnel throughput is about 22 Mbps
* Typical VPN tunnel traffic 200 Kbps
* All components are at minimal system load
See part 2-5-b-i: Facilities & Systems and part 2-5-b-ii: Stability &
Performance for details.
(b) Server
Name Server
DENIC permanently monitors the data throughput for each server. Currently, the
name servers have an average workload of 1.5% (see Figure 1). As this average
workload leaves high excess capacity to handle peak loads, DENIC plans to
deploy the same capacities for the .net registry.
whois
In the current .de setup, clusters of UNIX servers handle the whois requests.
Load balancers ensure the equal distribution of the requests to all servers.
Due to the comprehensive and regular monitoring of the whois service, DENIC is
able to identify any increases or peaks in request volume early and quickly
respond to the higher volume. Short term reactions include the deployment of
additional UNIX servers which can be added to the current highly-scalable
architecture.
For .net, the whois service will be implemented with the same setup (including
the monitoring system) to ensure that sufficient capacities will be available
to handle peaks or increases in request volume.
Figure 2 illustrates the number of queries per minute and whois server.
To be able to provide a whois data availability in near real-time (average
latency of few milliseconds and a maximum latency of one minute), DENIC
currently enhances the whois architecture by moving the public whois to
dedicated whois servers in the Service Provisioning Layer. These dedicated
whois servers will be integrated into the replication system of the database
and the replications on the servers will be adapted to the demand of the public
whois service.
This new set up will take a significant part of the public whois queries from
the production databases and, thus, shorten the response times for the public
whois.
Please refer to part 2-5-b-xii: Whois for details.
Application Server
Just as in the .de current setup, DENIC plans to deploy two application servers
for .net which will be configured similar to the server of .de. Currently, the
average workload of the CPU on the application servers (with 4 CPUs and 8 GB
memory) is about 30% with an average e-mail request processing time of three
minutes (see Figure 3). The servers will be scalable to 8 CPU and 64 GB memory.
2. Database System
DENIC will establish the .net database system based on the experience with .de.
The .de production database currently uses 169.7 GB out of an allocated amount
of 250 GB. DENIC expects the .net data volume to be around 66% of the
current .de data volume (based on five million .net domains vs. eight
million .de domains). Assuming an equal data volume for .de and .net, this
refers to an anticipated total data volume of around 350 GB for .de and .net.
For the .net registry system, DENIC expects an average engine busy utilization
on a similar level to .de (i.e. currently at or below 40% of the active
database and less than 10% of the standby database), assuming a database size
and transaction load that is equivalent to the .de registration system.
DENIC will assign a capacity of five TB on the primary HDS and five TB on the
secondary HDS providing an excess capacity of more than 2500% compared to the
current database size.
Considering these aspects, the planned .net database will be equipped with very
large excess capacity to handle the transactional growth for all three business
case scenarios.
Due to its comprehensive monitoring system, which automatically sends e-mail
notifications according to the integrated escalation scheme, DENIC is always
aware of the database system status. Thus, DENIC is able to detect critical
workloads well in advance and increase the capacity of the database system
appropriately. The database system is well protected against outages caused by
peak loads.
See part 2-5-b-v: Database Capabilities for details on the database system and
part 2-5-b-xiv: System Outage Prevention for details on monitoring. Part 2-4:
Revenue and Pricing Model contains information on the business case scenarios.
3. Backup Systems
For the .net registry, DENIC will establish comprehensive backup procedures
which are based on the highly effective and reliable backup processes DENIC
currently uses for the .de registry. The .net secondary RSL will serve as
the .net backup location.
The currently operating backup system is expandable from eight to 32 devices
regarding the tape drives. The number of administrable AIT-3 magnetic tapes can
be increased from 147 to 645 and the data capacity from 14.7 to 64 TB.
Currently, only 50% of the available 14.7 TB are in use. Thus, there will be
sufficient reserves for the backup system at hand to save handle peaks.
See part 2-5-b-x: Backup for details.
4. Support Systems
For .net, DENIC will provide helpdesk services to registrars from two
locations. An operations and support location will be built up at a service
provider in Canada. Support services for .net and .de will be provided from the
current helpdesk location in Frankfurt/ Germany. DENIC is highly committed to
offer the same well established and highly accepted support service through its
central helpdesk for .net registrars as currently for .de.
The helpdesk can be contacted by telephone, VoIP telephony, e-mail, web, the
ticketing system, post and fax. Currently, the central helpdesk handles about
200 telephone requests per day with an average handling time of three minutes.
As for .de, DENIC will ensure the availability of support systems for .net that
will be equipped with high excess capacity to also handle significant increases
in traffic. These capacities will be planned considering the past experience
with the .de registry as the support service and systems served the registrars
and registrants of eight million domains (compared to five million .net
domains).
See part 2-5-b-vi: Geographic Network Coverage and part 2-5-b-xviv: Support for
details.
Telephone & Fax System
DENIC's office PBX currently is equipped with two PRIs providing for up to 60
simultaneous external calls which represents 10% of the capacity that DENIC's
telephone system can handle. Just 53% of the 320 possible individual phone hook-
ups are utilized. If necessary, the system can be expanded to handle 800 such
equipment connections.
During the IDN-Launch, the support service demonstrated its high class
potential as it handled 1,000 calls per day with an average handling time of
just over three minutes and a longest queue time of 1.5 minutes.
The system for processing incoming faxes is also expandable up to eightfold of
its current capacity with the installation of additional modems.
Call Distribution
At present, the call-center software distributes an average of just over 200
calls per day to five processing groups in a three level priority system. Up to
100 agents can be registered in the call-center simultaneously. Currently,
however, only 15 agents are logged-in on average at any one time. With only
this 15% of potential utilized, the maximum waiting time is under two minutes.
Should it become necessary to use them further, the waiting queues can handle
an unlimited number of calls.
E-mail
At present, DENIC has four servers handling incoming e-mail traffic. They
currently process an average of 150 incoming e-mails per minute including
registration requests and support e-mails. This represents approximately 1% of
the available capacity. During the implementation of IDN, over 6,000 e-mail
requests were handled per minute with just one server processing these requests.
5. Escrow Systems
DENIC is currently implementing a data escrow procedure with a European Escrow
Provider. DENIC expects that the deposit file size will be affected by registry
volume peaks. To cover any expansion of the transferred data volume, DENIC
included contractual clauses which determine the handling of data volume peaks.
Please refer to part 2-5-b-xi: Escrow and Appendix R for details.
6. Maintenance
DENIC generally cares for reducing possible service or system outages due to
maintenance operations to an absolute minimum.
Maintenance operations for .net will always be pre-announced and conducted in
separate maintenance windows. As DENIC closely cooperates with its registrars,
no planned mass requests or any other planned peaks should occur during
maintenance periods. Thus, effects of peak loads on maintenance are minimized.
If peaks overlap with any maintenance operations, DENIC is very flexible in
delaying the maintenance.
To increase system availability and to avoid any performance deterioration of
the system, DENIC normally waives system redundancy while conducting
maintenance operations.
7. Personnel
At DENIC, particularly the technical and support teams will be affected by peak
load situations. DENIC will respond to these situations by dynamically
reassigning teams and actively communicating internally and externally (i.e. to
the registrars) to enhance the exchange of information. The reassignment of the
employees is facilitated by the broad education of the DENIC employees.
DENIC will also actively communicate with the registrars via mailing lists,
messages posted on the web site or recorded announcements to keep registrars
updated on the development during a peak load situation and, thus, to decrease
the number of calls at the helpdesk.
To make the personnel available that is required to ensure a quick solution of
the peak load situation, DENIC will also instruct to work overtime, if needed.
DENIC employees also regularly attend specific training sessions in which the
procedures of handling of peak load situations are practiced. Therefore, the
staff is able to built up a profound experience in handling peak load situation
as the trainings keep the employees updated with state of the art problem-
solving processes. Additionally, every employee participates in the trainings
offered to the registrars.
Additionally, DENIC will use a knowledge database that will be available to all
employees over the intranet. It will contain a detailed documentation of proven
processes and solutions to handle peak loads, i.e. reducing reaction time to
future occurrences.
For the .net registry, DENIC will increase the number of its support and
technical personnel to provide a 24/7/365 support. Support teams for .net will
be available in Frankfurt/ Germany and Canada.
Please refer to part 2-5-b-xix: Support for details.
8. Prevention of Peak Loads
Registrar Trainings
DENIC will offer training and workshop sessions as well as technical meetings
to all .net registrars. These will aim at improving the registrars' knowledge
about topics such as the DENIC registry processes, handling of peak load
situations, system upgrades or contract issues. The trainings will improve the
contact to and cooperation with the registrars and help DENIC to receive
feedback or suggestions e.g. on current processes. In turn, the registrars
better understand DENIC's processes and will be able to prevent or to early
announce peak load situations.
See part 2-5-b-xix: Support for details.
Customer Relations Team
If peak load situations such as seasonal promotions occur at registrars, they
should directly contact the DENIC Customer Relations Team. In cooperation
between the team and the registrar, solutions for handling the peaks will be
determined to avoid any performance loss for the other registrars, i.e. to
guarantee equivalent system access for all registrars.
Even if there was no prior consultation with the registrar service, the
comprehensive monitoring system would quickly identify peaks. DENIC will
immediately analyze the reasons for the peak and contact the originator to
resolve any failures. DENIC will also provide additional system resources at
short notice.
See part 2-5-b-xvi: System Outage Prevention for details.
9. Handling Peak Loads: Introduction of IDN
On March 1, 2004, DENIC started to register IDNs. DENIC was the only registry
which was able to handle the introduction of IDN on a large scale. Within two
days, the e-mail interface of the DENIC registry system processed more than
625,000 IDN requests. Figure 4 shows a sample distribution for incoming
registration requests. The highest registration rate was more than 300 requests
per domain. As of today, IDN has already become a common standard within
the .de domain.
Due to a detailed planning of the processes and comprehensive testing well
before the registry start, the IDN registration was handled without any
performance deterioration. Tests included peak load tests on all programs,
processes and interfaces to test the functionality and behavior of the system
in peak load situations.
During the IDN registration, the incoming requests were processed using the
first-come-first-serve principle. Every request was marked by a precise (i.e.
exact to the microsecond) entry date stamp and handled according to this order.
DENIC was fully compliant to the first-come-first-serve principle over the full
handling period.
In addition, DENIC conducted pre-delegation checks for all registration
requests to ensure that a newly delegated or updated domain had no impact on
the .de DNS system.
The equivalent access of all registrars (i.e. the availability of a guaranteed
minimum bandwidth per registrar to successfully post registration requests) to
the system was fully guaranteed at all times during the IDN registration Bulk
requests sent by a few registrars did not cause any performance loss of the
registry system for other registrars. |
|
|
(xv) System reliability. Define, analyze and quantify
quality of service.
|
(xv) System Reliability
Highlights
* DENIC guarantees a 99.9% availability of its registry service, a 99.99%
availability of its whois service and a 99.999% availability of the name
service.
* To further improve its already high service levels, DENIC will introduce a
comprehensive service level management system (SLM) for the .net and registry.
* DENIC already gathered extensive experience in developing services for
registrars and thus will ensure professional and reliable processes as well
as an exceptional high quality of service for the .net registry operations.
* For determining the relationship between the helpdesk and the internal
support teams, DENIC will develop Operational Level Agreements (OLAs).
* Software development at DENIC for .net will strictly follow a formal
standardized process to assure quality and enable quantitative quality
measurements.
* All services will be tested by the departments and the registrars in an
internal test environment before they are released.
* All deployed hardware will tested for adequacy, stability, performance and
scalability.
* For testing, DENIC uses a customized testing suite which consists of self-
developed and standardized testing software.
* For the Object-Oriented (OO) analysis and design, DENIC uses UML (ArgoUML-
Open Source UML Tool). The predominant programming language is JAVA.
* For .net, DENIC will operate a comprehensive monitoring system with 24/7/365
availability which will constantly measure the system and network components as
well as database operations. Registrars will always have access to current
monitoring information on the DENIC registrars' web portal.
* For constantly improving the processes in line with the Quality Improvement
Program and for generating quantitative statistics, DENIC uses the Goal
Question Metric (GQM) method.
DENIC is fully committed to ensure a high availability and reliability of its
services. Therefore, DENIC guarantees a 99.9% availability of its registry and
a 99.99% availability of its whois service.
During the operation of the .de registry, DENIC gathered extensive experience
in developing services for registrars and, thus, will ensure professional and
reliable processes as well as an exceptional high quality of service for
the .net registry operations.
To be able to meet these service levels, DENIC offers redundant RSLs which are
kept on the same data status through replication. Each RSL will have redundant
network and telecommunications components.
International name server locations as well as geographically separated RSLs
will contribute to minimizing the possibility of outages through natural or man-
made disasters. The two .net RSLs will be connected via high volume links. All
other name server sites can be reached from each of the RSLs via a secure
Virtual Private Network.
Please refer to part 2-3-b-iii: Description of Facilities for details on RSL
connectivity, part 2-5-b-i: Facilities & System on RSL architecture, part 2-5-b-
ii: Stability & Performance for NSL connectivity and architecture.
1. Defining & Quantifying Quality of Service
DENIC defines quality of service as high availability, reliability and
performance of all its services perceived by the registrars, registrants and
Internet users.
To further improve its already high service levels, DENIC will introduce a
comprehensive service level management system (SLM) for the .net registry. For
this purpose, service level agreements (SLAs) will be defined which reflect
DENIC's service goals. SLAs have been developed and include the following
information:
* Description of the respective service and its characteristics
* Agreed service times
* Response and removal times for failures and service disruptions
* Availability, security and continuity goals for the service
* Registrar duties
* Critical business hours and exceptions (e.g. public holidays, escalation
procedures etc.)
DENIC is committed to comply with the following performance indicators:
* 99.9% availability of the registry service
* 99.99% availability of the whois service
* 99.999% availability of the name service
* add domain average: < 300 ms (excluding round trip time)
* Update frequency zone file: eight times per day
Please refer to Appendix D for a full overview of the SLAs offered by DENIC to
ICANN.
The SLM system will also monitor and control the actual service levels to
detect whether DENIC is compliant to its SLAs.
For determining the relationship between the helpdesk and the internal support
teams, DENIC will further develop Operational Level Agreements (OLAs).
Software Development Process
Software development for .de strictly follows a formal standardized process at
DENIC to assure quality and enable quality measurements. For .net, DENIC will
implement the same proven standardized procedure.
At DENIC, the Development and the Operations Teams participate in this
development process. In this clearly defined process, several points are
established for quantitatively measuring quality. Measurements include error
frequency in each phase of the software development process. The results are
used for continuously improving and refining the process steps. Before a new
software package is released, it is internally tested at first and then tested
by registrars.
DENIC conducts all steps of the required testing processes in its dedicated
test environments. In the location of its headquarters, DENIC installed a
complete setup for the RSL as well as for the NSL. DENIC will replicate this
setup for .net and provide both a dedicated .net NSL and .net RSL test setup.
(Please refer to part 2-5-b-i: Facilities & Systems for a detailed description
of the RSL and NSL test architecture.)
Whenever DENIC develops new software or upgrades, the correct functionality is
checked by comprehensive test scenarios before the software is deployed into
the production environment. Applications which might be affected by the new
software are also considered in the scenarios.
Figure 1 illustrates one of the DENIC testing procedures. DENIC's Operations
Team is responsible for determining the software specifications as well as for
developing appropriate testing scenarios. To accelerate the software
development process, the testing scenarios are defined parallel to the software
development so that the software testing can be started immediately after the
software has been developed.
In the development environment, the software is checked for functional
correctness. Then, the software is installed in a test environment which is
nearly identical to the production system (i.e. different hardware is used).
The Quality Assurance Team carries out comprehensive functional tests which
check the system's response to the submission of valid, invalid or inconsistent
data. The software has to prove its stability and react correctly to all (i.e.
100%) test cases. For example, the software must not crash and has to write its
data correctly to the database or react to invalid input with an error message.
All functional tests are carried out with the help of a customized testing
suite which consists of self-developed and standardized testing software.
Performance tests are conducted to find out whether the software acts correctly
in normal and peak load situations. Collected data include the number of
requests handled within a determined time frame and the impacts to the database
or other applications.
If problems occur, trouble tickets are opened. These are sent to the Software
Development Team for analysis and bugfixing. After that, all tests are
repeated.
When no further bugs occur, the registrars are informed about the upcoming
software changes and the software is installed in the registrar test
environment, so that they also have the possibility to update and test their
programs. The test phase takes about four weeks depending on the complexity of
the software. Finally, the software is deployed to the production environment.
Registrars are generally informed early about changes.
DENIC comprehensively documents all its testing processes and results. The
documentation is updated regularly and analyzed to improve the testing
scenarios and procedures. The information is available to all employees.
DENIC conducts all steps of the test process in its dedicated test
environments. In its headquarters, DENIC installed a complete setup for the RSL
as well as for the NSL. DENIC will replicate this setup for .net and provide
both a dedicated .net NSL and .net RSL Test setup. (Please refer to part 2-5-b-
i: Facilities & Systems for a detailed description of the RSL and NSL test
architecture.)
Test Scenarios for Hardware
Before new hardware is deployed, it is tested for adequacy. Therefore, several
manufactures are asked to provide test hardware of different architectures,
like x86 (Intel, AMD), Sparc and PowerPC. DENIC then installs the software that
will be running on the hardware in the DENIC production environment. The
hardware is tested for stability, performance and scalability. In the test
laboratory an infrastructure is arranged which complies with the planned setup
or comes close, e.g. includes other servers, routers, load balancers and peak
generators.
Development Tools
For the Object-Oriented (OO) analysis and design, DENIC uses UML (ArgoUML-Open
Source UML Tool). The predominant programming language is JAVA.
DENIC uses the two following tools for software development:
* Source Repository: CVS - Concurrent Version System
* Build Process & Version: ApplicationGenerator (developed by DENIC)
The build process automatically models projects from the start i.e. it checks
the sources of the CVS, compiles them and creates applicable versions.
In the build phase, extensive unit and integration tests are conducted for all
modules. Furthermore, DENIC uses the "Continuous Integration" process. This
process ensures an early identification of bugs. Whenever project modules have
to be changed, the whole project is rebuilt. All unit tests are rebuilt and re-
executed.
In addition to the unit and integration tests, DENIC also conducts validation
and verification, error recovery, performance and usability tests.
DENIC also uses an internal bug tracking system.
2. Analyzing Quality of Service
For .net, DENIC will operate a comprehensive monitoring system with 24/7/365
availability which will enable the company to conduct multifaceted measurements
of the system, network or database operations. DENIC will constantly monitor
e.g. response times, availability of systems or components, database
utilization ratios, up-times, processed requests etc. The data will be stored
in the monitoring tools which then generate numerous pre-programmed reports.
The monitoring approach will allow DENIC to immediately solve errors and
malfunctions. In addition, DENIC will use the generated reports to prove its
compliance to the SLAs as well as for planning future technical and
organizational capacity enhancements. To be able to plan capacities according
to future needs, the monitoring system will automatically send notification
messages whenever the defined threshold values per component, e.g. for
component workloads, are exceeded. For example, additional servers will be
deployed to the infrastructure when the workload per component meets or exceeds
5%.
For .net, DENIC will also create monthly reports on the basis of the collected
data. (Please refer to part 2-5-b-xvi: System Outage Prevention for a detailed
description of the DENIC monitoring system).
For constantly improving the processes in line with the Quality Improvement
Program and for generating quantitative statistics, DENIC uses the Goal
Question Metric (GQM) method.
DENIC also saves diagnosis and solution approaches in a designated knowledge
database. This database is available to all employees on the intranet. The
collected information is used to improve reactions to future bugs as well as to
conduct quality and long-term analyses. (Please refer to part 2-5-b-xix:
Support for details on the knowledge database.)
Registrars will always have access to current monitoring information on the
DENIC registrars' web portal. So, every registrar can find out about the
availability of the services. In addition, the monthly registrar newsletter
will publish statistics about quality aspects such as the availability of the
name server, response times of the robots, downtimes etc.
Furthermore, registrars will be able to directly influence new developments by
discussing them in the registrars' discussion forum, in technical meetings or
via mailing lists.
The technical employees continuously participate in trainings to be regularly
updated on the latest technological developments. Furthermore, the personnel is
closely involved in the improvement processes to assure quality. Therefore,
DENIC regularly conducts workshops and practical training sessions. DENIC
encourages its employees to make suggestions for improvements and honors them.
Please refer to part 2-5-b-xix: Support for details on the DENIC support
concept.
|
|
|
(xvi) System outage prevention. Procedures for problem
detection, redundancy of all systems, backup power supply, facility
security and technical security. Outline the availability of backup
software, operating system and hardware. Outline system monitoring,
technical maintenance staff and server locations.
|
(xvi) System Outage Prevention
Highlights
* To detect problems early, DENIC will operate a comprehensive service and
performance monitoring system for monitoring the network, systems, services,
components and applications.
* As of a DENIC-specific principle, all caches, queues etc. of the .net
registry system will be largely scaled.
* To prevent system outages, DENIC will only deploy high-quality and
comprehensively tested software.
* DENIC will establish a .net secondary RSL which will provide full redundancy
of the network and system components.
* DENIC will employ the concepts of intra-location setup equivalence and inter-
location setup diversity of hardware and software components to ensure full
stability and availability of the .net name service.
* At the .net primary and secondary RSL, DENIC ensures uninterruptible power
supply.
* For the .net backup system, DENIC will deploy highly available backup
software, hardware and operating system components.
* DENIC will establish a dedicated Monitoring Team within the Operations Team
being responsible for system monitoring and outage prevention at the RSLs and
NSLs.
DENIC currently operates a highly redundant infrastructure for the .de
registry. Due to the record of excellent system performance, this concept will
also be implemented for the .net registry operations. Thus, DENIC will be able
to provide a highly-available .net registry service reducing the risk of
outages to a minimum.
Major features for the .net registry system include a standby database which is
kept on the same status as the primary database by replication, redundant
system components, a comprehensive data backup and escrow system.
1. Procedures for Problem Detection
Comprehensive Monitoring
For .net, DENIC will automatically monitor all network and system components as
well as services and applications. For each measured indicator, DENIC will
define a threshold value. Whenever a threshold value is reached or exceeded,
the technical personnel will immediately be informed by system-generated
notification messages (24/7/365). Thus, the personnel will have sufficient time
to solve the problem before a system outage occurs.
Scalable Systems
As of a DENIC-specific principle, all caches, queues etc. of the .net registry
system will be largely scaled. Thus, three - four days can be bridged without
causing a system outage, if a subordinated component such as the backup system
fails. The transaction log of the registry database will be designed so that a
multi-day failure of e.g. the backup system, which will be used for saving and
deleting log information, does not cause a database server outage. Therefore,
the log will be backed up and emptied regularly. The stable queues of the
replication server will be sized large to save the transactions of about seven
days.
See part 2-5-b-xiv: Peak Capacities for details.
Software Development
To prevent the .net registry system from outages, DENIC will only deploy high-
quality and comprehensively tested software. Therefore, DENIC relies on the
broad experience in developing stable .de registry software. DENIC strictly
complies to standardized software development procedures.
See part 2-5-b-xv: System Reliability for details.
2. Redundancy of all Systems
RSLs
For .net, DENIC will establish a secondary RSL which will provide full
redundancy of the network and system components such as the registry database,
servers or power supply to the primary RSL. Both database servers will be
configured identically. All changes of the configuration or user administration
in the active database will be transferred to the standby system. The databases
will be logically interconnected for replication.
See part 2-5-b-i: Facilities & Services and part 2-5-b-v: Database Capabilities
for details.
With the help of a switchover procedure between the two databases that is
currently used for .de and will also be used for .net, DENIC will be able to
quickly change between the two RSLs. The procedure is based on virtual
interfaces. For training and maintenance purposes, the procedure will be
practiced regularly. (See part 2-5-b-v: Database Capabilities.)
In 2005, DENIC will deploy an additional database server with a second full
replica as well as an additional special replica of the public whois. For this
purpose, the replication server technique will be used to minimize latency
times. The replication server tool also checks whether the active and standby
database are identical by comparing the results of SQL-select statements.
NSLs
As for .de, DENIC will employ the concepts of intra-location setup equivalence
and inter-location setup diversity of hardware and software components to
ensure full stability and availability of the .net name service. Therefore,
DENIC will not only operate server redundancy within one location but also
between the NSLs.
Each NSL consists of at least three active name servers and one log host. As
the name servers have exactly the same hardware and software setup within a
NSL, administration and maintenance is facilitated.
In each NSL, DENIC installed three different types of server hardware,
operating systems and DNS software. Only one software implementation is active
at a time. In case of a failure of one software type, DENIC is able to quickly
switch to the other software types.
This setup highly contributes to minimizing the sensibility of the whole NSL
system to operating system, application or hardware-induced problems.
Additionally, the risk of attacks as well as the dependency on vendors are
reduced. There would also be no impact on the name service, if a component
within a location failed.
See part 2-5-b-ii: Stability & Performance for details.
3. Backup Power Supply
Primary RSL
At the .net primary RSL, DENIC uses two separate power inputs which lead into
an uninterruptible power supply and are connected to two independent power
stations (see Figure 1). The switchover process from the main input to the
reserve input is automated. A battery buffer is able to bridge a power supply
disruption for up to 120 minutes. This time period depends on the number of
devices in operation. Currently, DENIC uses less than 50% of the available
capacity. If the capacity was fully used, the available battery buffer would be
reduced to 45 minutes. Due to the highly stable and reliable power supply in
Frankfurt/ Germany, the buffer never had to be used, i.e. no DENIC location
ever had to operate on emergency power supply. The power supplier of Frankfurt
(i.e. "Mainova") also guarantees to switch between the two power stations
within one second.
Secondary RSL
DENIC will operate its .net secondary RSL in a professionally operated state-of-
the-art hosting center which will meet or exceed the specifications of the
current .de secondary RSL hosted by COLT Telecom GmbH.
This hosting center is equipped with a fully fault-tolerant power supply
architecture to keep the center alive in the absence of electrical grid power.
The average working voltage supply consists of two 10 KV rings and three oil
transformers (one backup) of 1,000 kVA provided by the energy supplier. The low
voltage supply comprises two redundant main supplies with an utilization of 50%
each. They are separated due to fire protection purposes. As reactive current
compensation, COLT is equipped with a protective conductor which is separated
from the neutral conductor starting at the master switch.
To guarantee an uninterrupted power supply, a power-thyristor switch switches
to feed-ins (N+1 redundant power feeds with failover capacity) without any
performance deterioration. Additionally, N +1 diesel generators with twelve
cylinders each, 1,600 HP, a current power output of 1,400 kVA and 72h of fuel
supply are available. Handover batteries bridge the warm-up phase of the
generator. Within the energy control system (PLC), voltage, electricity and
performance are monitored by a digital bus system.
See part 2-3-b-iii: Description of Facilities for details.
4. Facility Security
Primary RSL
The primary RSL for .net will be located in DENIC'S current primary RSL
for .de. In this RSL, DENIC enforced comprehensive security policies and
standards.
These include:
* Multi-level physical access restrictions, enforced by electromagnetic badges
and readers
* Strict access limitations of DENIC personnel and visitors to rooms with
technical infrastructure
* Uninterruptible power supply
* An alarm system protecting the office areas; an additional alarm system for
the server rooms
* Two alarm codes required for entering the server rooms out of office hours
* Surveillance of server rooms and corridors by cameras and motion detectors;
monitoring by the contracted professional surveillance company which supplies
the alarm system
* Effective air conditioning, temperature and fire control systems
See part 2-3-b-iii: Description of Facilities and part 2-5-b-xiii: Security for
details.
Secondary RSL
The .net secondary RSL will be equipped with the same state-of-the-art security
specifications regarding physical access restrictions, surveillance, security
personnel, power supply, environmental and physical security as the current .de
secondary RSL which is located in a highly secure and modern hosting center.
See part 2-5-b-i: Description of Facilities and part 2-5-b-xiii: Security for
details.
5. Technical Security
DENIC enforced strict security policies that comply with ISO1799 and include
the rigid definition of protocols, extensive filtering, access limitations and
password policies.
Part 2-5-b-xiii: Security provides a detailed description of network, system
and application security at the RSLs and NSLs as well as an outline of database
security.
6. Availability of Backup Software, Operating System & Hardware
For the .net registry, DENIC will set up similar highly effective and reliable
backup procedures as currently used for .de. DENIC will deploy the same highly
available backup software, hardware and operating system components as for .de
because the components proved to be reliable under all conditions. All
components will be highly scalable and, thus, provide high excess capacities.
The .net backup server and tape library system will be installed in the highly
secure secondary RSL located at the premises of a state-of-the-art housing
provider. As the two RSLs are geographically separated from each other, the
availability of at least one RSL in the event of an emergency in ensured. The
two separate .net RSLs will be connected via high volume links.
The TiNa software will be installed on a dedicated .net backup server which
will be integrated into the SAN and directly connected to the HDS as central
storage. It will also have a direct connection to a SpectraLogic Tape Library
with AIT-3 tapes as physical backup medium.
Part 2-5-b-x: Backup for further details.
7. Monitoring
DENIC operates a comprehensive service and performance monitoring system that
regularly monitors the network, systems, services, components and applications.
Due to these monitoring procedures, DENIC is able to early identify, track and
document system problems and outages. DENIC also uses the monitoring data to
prevent future outages. A similar system will also be established for the .net
registry.
(a) Network Monitoring
(i) RSL Network & Service Monitoring
All RSL network components are monitored for abnormal behavior by centrally
storing and processing syslog messages, catching SNMP traps and notifying the
operators quickly in case of any event that could cause a service degradation
or interruption.
Network monitoring currently takes place from a central location, while a copy
of syslog messages is stored in the local buffer of every machine. In the
future, monitoring and logging will be performed decentrally to avoid missed
messages or traps, if a part of the management network is temporarily
unreachable. This logging mechanism will first be implemented in the NSLs.
Service monitoring is already performed from various points of the network
topology. Services are monitored and, if necessary, modified from the inside.
Log files are written and processed locally and the engineers are notified upon
any incident occurring in the service or machine log files. This will also move
to a decentralized logging structure implemented on redundant log storage and
processing servers.
Log file monitoring is not only used for the detection of emergency situations,
but also for performance and functionality monitoring. Thus, DENIC can change
or add resources to specific services before a service degrades noticeably.
(ii) NSL Network & Service Monitoring
NSL monitoring is two-staged process. The NSL log host collects all data per
NSL locally and real-time. It filters and classifies all collected data and
sends them to central collectors. Decentral systems consolidate all incoming
information.
Reachability of the NSLs is monitored from the RSLs both for the NSL management
network and for the provided service. The service is also monitored from
external locations. For anycast NSLs, this external monitoring is located close
to the NSLs because of the nature of anycast.
DENIC is working on an agreement with the RIPE NCC to use their worldwide
monitoring infrastructure to check and ensure .de and .net DNS service quality.
RIPE NCC monitors the name servers of the root zone and of selected TLDs such
as .de. Therefore, RIPE NCC sends requests to DENIC's name servers from many
worldwide locations and analyzes the responses. The results are put into
graphics and made available to the public by RIPE NCC.
Visualized results are available under http://dnsmon.ripe.net.
(b) System Monitoring
DENIC uses Sightline as the main monitoring software tool for monitoring server
system parameters, services, log files as well as for data analysis. Additional
programs developed by DENIC monitor run times or perform functional tests.
The Network Team conducts additional post-mortem analyses of log files for
tracking failures. The log files include:
* Log messages of the components
* SNMP-Traps in case of events (e.g. Interface up/down, BGP-Session start/stop)
* Packet filter rules
* Used bandwidth on switch and router ports (graphical)
Potential additional tools such as Nagios (i.e. controls services and
availabilities of services and components) are continuously evaluated.
The collected data is stored (e.g. live data for six days, engine data for six
weeks, long history files for years) and used for root cause analysis of system
problems and outages. In addition, it allows a comprehensive capacity planning
as data is documented and reported over time.
Monitoring statistics are available to DENIC registrars on the respective
registrars' web portal.
In defined intervals ranging from 30 - 60 seconds, DENIC frequently collects
extensive data on system parameters such as CPU, network, memory, process,
kernel, I/O metrics as well as disk controller or file system information on
relevant servers.. These servers include:
* Name servers
* Application servers
* Database servers
* Replication server
* whois servers
* E-mail servers
* Web & FTP servers
DENIC also monitors selected services such as http and https, smtp, ftp, dns,
whois. Collected data include round trip times, response times or error
indicators.
Additionally, the following information is automatically gathered, visualized
and archived to continuously monitor the compliance to the SLAs:
* whois and name server query load
* Web whois utilization
* whois response time
* Service reply time (registry service availability)
* Sychronization check of the two registry databases
* Functional tests of all service
The data is transferred to Sightline for visualization, to send notification
messages and to archive them.
All indicators are permanently monitored. If error messages or critical entries
occur, notification messages are sent to the Operations Team. The e-mail
servers generate a daily activity report documenting the activities of the
previous day. DENIC uses this data as basis for detecting potential future
bottle necks.
The availability of the DENIC services is also monitored from several external
locations to e.g. check the way the registry requests are coming to the system.
(c) Database Monitoring
DENIC permanently monitors the complete database system by automated programs.
The following parameters are continuously read from the database, verified and
written into the appropriate logfiles.
* memory space and degrees of utilization
* free space of the database
* database processors
* error logs of the database and replication server
* success control of database backups, full and transaction log backup
* runtime and data volume of backups
* database replication
* replication agent threads
* utilization of the replication queues
* latency times
Performance reports of the monitored indicators (e.g. engine busy utilization)
on the registrars' web portal ensure a high transparency regarding the database
status.
For critical parameters like the number of required locks, an escalation scheme
was integrated. Depending on the value, the appropriate message is sent to the
responsible employees. In the unlikely event of an error, the 24/7/365
available Emergency Team initiates the appropriate actions at once.
Errors in one of the databases are always treated with the utmost urgency. An
incident in the database will be classified as priority 1 or 2. The incident
prioritization scheme and escalation policies are described in detail in Part 2-
5-b-xix: Support.
8. Technical Maintenance Staff
For .net, DENIC will establish a dedicated Monitoring Team within the
Operations Team being responsible for system monitoring and outage prevention
at the RSLs and NSLs. This team will conduct comprehensive analyses of the
monitoring data and of past system failures to help prevent future outages and
to continuously improve the current infrastructure.
In case of a system failure, the 24/7/365 available team will receive
notification messages and be able to instantly react according to the DENIC
emergency procedure. DENIC will also set up an Emergency Team offering a
24/7/365 standby service for the registrars.
9. Server Locations
For the .net operations, the primary RSL will share the facilities of the .de
registry in Frankfurt/ Germany; the .net secondary RSL will be either located
in Amsterdam, London or a US East Coast location at the premises of a
professional hosting provider. The distance between the two .net RSLs increases
security as the dependence from single points of failure is minimized.
For the name service, DENIC will provide 14 .net NSLs operational by June 30
and 19 .net NSLs by December 31, 2005:
* Each site will be equipped with multiple name servers.
* The .net infrastructure will be implemented in eleven existing .de NSLs
worldwide
* Three additional .net NSLs in North America.
* Five additional .net NSLs to be opened until the end of 2005 - all of them in
emerging markets.
DENIC operates all its name servers compliant to the standards of root name
servers [RFC2870].
All NSL setups will be installed at professional high-quality hosting sites
with extensive backup systems for cooling, electricity and security.
See also part 2-5-b-vi: Geographic Network Coverage and part 2-3-b-iii:
Description of Facilities for details. |
|
|
(xvii) Ability to support current feature
functionality of .NET (to the extent publicly or otherwise available to
the applicant, including IDNs, support of IPv6,
DNSSEC.
|
(xvii) Ability to support current feature functionality of .NET
Highlights
* DENIC will support current feature functionality for .net, including IDN,
IPv6 and DNSSEC.
* DENIC has been registering IDN since March 2004 for .de domains and will
expand this service to .net domains.
* DENIC is currently running two name servers on IPv6 and is ready to adapt the
infrastructure to a potential increase in demand. DENIC will offer whois and
other services on IPv6 in the near future.
* DENIC has been researching DNSSEC for more than five years and has evaluated
Secure DNS for the .de operations. DENIC is prepared to respond to the needs of
the Internet community in this area.
1. IDN Registration
DENIC will offer IDN (Internationalized Domain Names) registration for .net
domains based on the ICANN guidelines as published on June 20, 2003 at
http://www.icann.org/general/idn-guidelines-20jun03.htm. DENIC will comply to
these guidelines and will implement its IDN offering in the following way:
(1) DENIC will implement a solution according to the Proposed Standards RFC
3490, 3491, and 3492 (collectively the "IDN standards") and will not follow any
IDN approach which is not sanctioned by the IETF (e.g. responses to 8-bit DNS
queries, either in different local encodings or UTF-8).
(2) In terms of allowed domain name characters it is, according to the IDN
Standards, generally possible to generate any domain name that consists of
Unicode codepoints (see http://www.unicode.org/charts/). However, some
characters will be mapped after applying a normalization (nameprep) to them
(e.g. in German dass.net: daß.net becomes dass.net after normalization). Taking
this into account, all Unicode codepoints which can be mapped after applying
nameprep should be allowed and be admitted on the respective positive lists.
(3) The Unicode tables contain language related definitions, too. This area
defines tables that are valid and allowed for a certain language. So, when a
registrant states a language tag for its domain it can only use the codepoints
from the accordant language specific code tables. A Unicode/codepoint-language
matrix will support and simplify the validation process of using characters in
the context of a specific language.
(4) DENIC will collaborate with other registries, regional bodies and cultural
communities to develop language-specific registration policies.
(5) DENIC's Unicode/Codepoint-Language matrix will ensure that, for every
initial implementation, only character-sets can be used that are permitted for
the specific language.
(6) DENIC will offer registrar support as described in part 2-5-b-xix:
Support. Registrars will offer support to registrants for .net in the
respective languages.
DENIC has been offering its .de IDN services since March 2004. DENIC's web site
gives more information on the start and some details on the status of IDN
(http://www.denic.de/en/domains/idns/).
2. IPv6 Support
DENIC is committed to supporting the IPv6 protocol. The focus of DENIC's
efforts is on supporting community use of IPv6 for their business by providing
the necessary services.
For .de domains, DENIC has been offering IPv6 DNS resolution service since
December 2003. DENIC currently operates two name servers on IPv6. DENIC was one
of the first TLDs applying for the inclusion of an AAAA record in the root zone
on July 27, 2004 after IANA enabled records in the root zone on July 12, 2004.
The first DENIC server with an AAAA record has been in the root zone since
October 2004 and the second name server since December 2004. DENIC constantly
monitors DNS queries received over IPv6 and will add capacity in sync with
increasing IPv6 demand. For instance, DENIC will offer AAAA glue in the records
in the .de zone in the first quarter of 2005, now that first registrant demand
has appeared. For this offering, the database and zone generation is ready for
operations. This functionality obviously will also be offered for .net.
Furthermore, DENIC will offer a whois server, web presence and registry
services on IPv6 protocol in the near future.
3. DNSSEC Support
DENIC will take over the complete data stock of the test bed from VeriSign and
will continue and further develop DNSSEC for .net. For a smooth data transfer
it will be important that detailed information on the status of the pilot be
handed to DENIC immediately after the decision about the new registry operator
on March 30, 2005.
DENIC is committed to broaden the DNSSEC development from a purely server
focused approach as currently followed by VeriSign to a holistic DNSSEC
approach. Real security can only be gained if servers as well as resolver
software and all applications are integrated into the DNSSEC concept. DENIC
will foster the DNSSEC development with such a holistic approach and will
cooperate with software and application providers to enable a fully secure
environment.
DENIC has been working on DNSSEC topic for several years to understand and
evaluate this protocol for its benefits and deployment options for .de
operations. In 2000, DENIC did a first study on the deployment of DNSSEC
for .de. The following link directs to a presentation on an update of this
study in 2001 (http://www.dfn-cert.de/dfn/berichte/db092/DFN-Praesentation-
160501_03.pdf). In 2003, DENIC in cooperation with the Research Center for
Information Technology (FZI) and the German Federal Department for Security in
the Information Technology (BSI) has done a study on "Security for the top
level domain .de through Secure DNS"
(http://www.bsi.de/literat/studien/securedns/).
DENIC is committed to further develop and to provide DNSSEC functionality to
the scope, breadth and in the form as it is requested and demanded by the
Internet community.
| |
|
(xviii) System recovery procedures. Procedures for
restoring the system to operation in the event of a system outage, both
expected and unexpected. Identify redundant/diverse systems for providing
service in the event of an outage and describe the process for recovery
from various types of failures. Describe the training of technical staff
that will perform these tasks, the availability and backup of software and
operating systems needed to restore the system to operation and the
availability of the hardware needed to restore and run the system.
Describe backup electrical power systems and the projected time for system
restoration. Describe procedures for testing the process of restoring the
system to operation in the event of an outage, the documentation kept on
system outages and on potential system problems that could result in
outages.
|
(xviii) System Recovery Procedures
Highlights
* DENIC has a disaster recovery plan in place that aims at ensuring the quick
full recovery and resumption of the normal operations within predefined time
frames following an unpredictable event.
* For .net, DENIC is committed to set up a highly reliable system architecture
and to apply and - if appropriate - enhance the recovery procedures.
* DENIC will define a standardized problem resolution procedure to be able to
quickly resolve failures.
* DENIC will operate redundant components on all architecture layers.
Therefore, expected and unexpected outages will be handled by switching the
failed component from the primary RSL to the secondary RSL without having to
perform comprehensive recovery procedures.
* DENIC applies the concepts of intra-location setup equivalence and inter-
location setup diversity of hardware and software components to ensure full
stability and availability of its name service.
* For the RSLs and NSLs, DENIC uses a mixture of spare components and
preconfigured systems as well as vendor service contracts to ensure a quick
reestablishment of redundancy in case of hardware failures.
* The concept for a prompt resumption, including cold recovery of the .net
registry operations in the case of a disaster, is based on escrowed information
(i.e. data, production versions of DENIC's developed software, the latest DRP
including procedures and documentation etc.) and the placement of a contract
with an RSL operator.
* The responsible DENIC technical staff has already built up a profound
knowledge in recovering the systems, as the staff has several years of
experience in executing routine recovery procedures.
* For training purposes, scenarios causing a disaster are tested once a year.
* DENIC will introduce a database to fully document and analyze system outages
as well as to document the related solutions.
* For .net, DENIC will compile an instruction manual of the .net processes and
procedures that enables DENIC or any entitled third party to restore the
services in case of a disaster.
1. Procedures for Restoring the System to Operation in the Event of a System
Outage
For .net, DENIC will operate a highly redundant architecture for all system
components. In addition, only intensively tested high-quality hardware and
software products will be deployed to the production environment. Thus, DENIC
is able to reduce potential outages to a minimum.
For the unlikely event of an outage, DENIC defined appropriate system recovery
procedures for the .de operations, which are exercised during regular training
sessions.
For .net, DENIC is committed to apply and - if appropriate - enhance the
recovery procedures. Details on recovery procedures are presented in this
chapter.
As for .de, DENIC will also set up all .net systems to be compliant to well-
accepted standards such as ITIL or the IT security guidelines issued by the BSI
(i.e. German Federal Office for Information Security) to further increase
system stability or security.
(See http://www.bsi.bund.de/gshb/english/etc/index.htm for details on the IT
Baseline Protection Manual.)
(a) Disaster Recovery Plan
DENIC is committed to protecting all business information, processes and
registry data from unpredictable events. Therefore, the primary and backup
registry system for .net will be prepared and tested to ensure the ability to
continue the operation in the event of a business interruption.
As for .de, the .net RSLs will also be designed to:
* Recover DENIC's technology infrastructure and information
* Prevent the loss of information and transactions
* Allow DENIC to continue conducting its primary business functions
DENIC`s Disaster Recovery Plan (DRP) aims at ensuring the quick full recovery
and resumption of the normal operations within predefined time frames following
an unpredictable event.
To accomplish this, DENIC has
* developed formal processes that allow the continuation or prompt resumption
of critical business functions and
* established procedures for data backup, software, documentation and
procedures.
The plan is reevaluated once a year. DENIC always reviews all parts of the plan
in detail. In addition, the plan is tested on a regular basis and enhancements
are continuously added. The Disaster Recovery Coordinator is responsible for
monitoring the accomplishment of the recovery plan. The coordinator also
ensures that the plan meets standards (ISO 17799) and is consistent with the
rest of the plan.
(b) Problem Resolution Procedure
For .de, DENIC defined a standardized problem resolution procedure to be able
to quickly resolve failures. This procedure will also be applied for .net and
enhanced and/or modified, if required.
Whenever a problem occurs, DENIC scans its Outage and Solution Database for
similar entries. If the problem occurred in the past, an entry will be found
including a solution procedure. Otherwise, a new entry is created, categorized
and prioritized. This entry keeps track of all activities until problem
resolution.
For documenting the outage in detail, a respective failure report is added to
the database including date and time of the occurrence, the removal process as
well as the employee who removed the failure.
To continuously improve the problem resolution process, DENIC also performs
periodical analyses of incidents including the resolution status, time of
resolution and frequency sorted by category and priority.
(c) Whois Service
For .net, DENIC will use clusters of whois servers in the primary RSL and in
the secondary RSL. Requests will be distributed to the servers by load
balancers. This setup can be scaled by adding whois servers as required.
For recovering the server system, the following steps will have to be completed:
* Automatic installation of the operating system via installation server
* installation of specific software from repository
* adding the server to the cluster after verification
Load balancers will also be redundant in the whois cluster. As the load
balancers monitor each other constantly, one automatically replaces the other
in case of a failure.
Please refer to part 2-5-b-xii: Whois for further details.
2. Redundant/ Diverse Systems for Providing Service in the Event of an Outage
Registry Service Locations (RSL)
For .net, DENIC will establish two separate and independently operating RSLs
with a complete database and registry system available in Frankfurt/ Germany
(primary RSL) and at a major international access point, e.g. Amsterdam, London
or a US East Coast location (secondary RSL). The databases will be kept on the
same data status through replication. Upgrades and changes of the registry
system will be conducted on both RSLs in parallel.
For .net, DENIC will operate redundant components on all architecture layers
(see Part 2-5-b-i: Facilities and Systems for additional details). Therefore,
expected and unexpected outages will be handled by switching the failed
component from the primary RSL to the secondary RSL without having to perform
comprehensive recovery procedures. DENIC regularly switches between the two
RSLs in order to test the recovery plan.
In case some parts, applications, components etc. or even a whole RSL fail, the
redundant component(s)/ RSL take over the functionality immediately. The switch
from one component to the other is a semi-automated process, as there are
consistency checks to perform. The switchover process of the RSL has already
become a DENIC standard procedure which is regularly practiced.
Due to this technical architecture, failures of e.g. a web server processor,
the authentication server or VPN link will not impact the production
environment as the redundant component replaces the functionalities of the
failed one.
For the RSLs, DENIC relies on spare components and preconfigured systems as
well as vendor service contracts to quickly reestablish the redundancy in case
of hardware failures.
Please see part 2-5-b-i: Facilities and Systems for detailed information on RSL
architecture and redundancy, part 2-5-b-xvi: System Outage Prevention for
details on redundancy, part 2-5-b-v: Database Capabilities for the setup of the
database system and switchover process and part 2-5-b-x: Backup for details on
recovery procedures of the database.
Name Server Locations (NSL)
As for .de, DENIC will apply the concepts of intra-location setup equivalence
and inter-location setup diversity of hardware and software components to
ensure full stability and availability of the .net name service.
Therefore, DENIC will not only operate redundant servers within one location,
but also between the currently eleven name server locations (14 .net locations
by June 30, 2005 and 19 .net locations by December 31, 2005). The redundant
components within one location will be absolutely equivalent, while setups
between locations will differ.
There will be a cluster of at least three identical active name servers and one
log host in each location. The failure of one server will not cause any
outages, as the cluster management software disables the failed server. The
data processing will continue on the remaining servers.
To ensure a quick reestablishment of redundancy in the event of hardware
failures, DENIC uses a mixture of spare components and preconfigured systems as
well as vendor service contracts. A failed device will be replaced within one
day inside Europe and within four days outside Europe on average.
In each location, DENIC will install three different types of software. Across
these locations, different types of software will be active at a time. It will
be possible to immediately switch an NSL cluster from one software to another,
e.g. in case of known software exploitation. Additionally, DENIC will use three
different server types across its locations and employ both unicast and anycast
technology in the network layer. To keep the name service responsive to client
requests, DENIC will deploy every known technology.
Due to the setup of all NSLs (e.g. three types of DNS software, three server
hardware types, IPv4 and IPv6 per location) as well as the high excess
processor capacity (NSL servers have a maximum workload of 5%), a failure of
the name service due to Distributed Denial of Service [(D)DoS] attacks or
hardware/ network problems is very unlikely.
Please refer to part 2-5-b-i: Facilities and Systems and part 2-5-b-ii:
Stability and Performance for detailed information on NSL architecture,
connectivity and functionality. Part 2-5-b-xvi: System Outage Prevention for
further details on NSL redundancy, part 2-5-b-vi: Geographic Network Coverage
for details on name server locations. Part 2-5-b-iii: Operational Scalability
provides additional information on (D)DoS attacks.
3. Process for Recovery from Various Types of Failures
According to DENIC's DRP, it is possible to quickly resume the full operations
after the rather unlikely case of total breakdown of both RSLs. This concept
will also be applied to the .net registry operations.
Even in case of a disaster, the name service operations for .net can be
sustained with the database status at the time the disaster happened. Only the
registry service would be affected by this outage.
The concept for a prompt resumption, including cold recovery of the .net
registry operations in the case of a disaster, is based on the following
prerequisites. Most of them are already in place; the remaining will be put in
place during 2005:
* The production versions of DENIC's developed software is always deposited at
DENIC's escrow provider, as well as the latest DRP including procedures and
documentation.
* In case of a disaster, a contract will be placed with an RSL operator, who
can provide the required capacities of server systems and data memory
(including network connectivity) as well as the necessary capacity of
workstations (including network connectivity). Thus, all registry
functionalities (e.g. registration, support, etc.) could be restored.
* All data required for the resumption of the registry operations will be
transferred to these systems. This data covers:
* Software packages for standard software (system software and software close
to the system, e.g. database server, replication server, application servers)
including configuration data
* Software for special registry services including configuration data
* Backup or escrowed data of the registry database
* Metadata of the registry database, e.g. DDL scripts for the generation of the
database and all database objects (e.g. tables, indices, constraints, trigger)
* Network configuration data
* Installation instructions, which provide a detailed description of the system
implementation procedure so that these procedures can be carried out by DENIC's
qualified personnel
* Diagnostic and startup programs
4. Technical Staff who Perform Recovery Procedures
Immediately following an incident, a planned sequence of events begins. Key
personnel are notified and necessary recovery teams are grouped to carry out
the plan. Personnel currently employed are listed in the relevant checklists
and DRP.
At DENIC, the responsible technical staff (Operations, System Administration
and Emergency Team) has already built up a profound knowledge in recovering the
systems, as the staff has several years of experience in executing routine
recovery procedures.
For training purposes, scenarios causing a disaster are tested once a year.
Certain recovery procedures such as the switchover from one RSL to the other
are practiced regularly. In addition, all team members regularly attend .de-
specific training sessions, which will be extended by .net-specific trainings,
to regularly practice the recovery procedures.
5. Software and Operating Systems for Restoring System Operations
DENIC keeps replacement components for the name servers at the headquarters in
Frankfurt/ Germany to facilitate the exchange of components in case of a
failure. Usually, one or two devices with the appropriate configurations are
available per server. These servers will be shipped and implemented within one
day inside Europe and within four days outside Europe on average.
As all systems are redundant on all levels, the failure of a system component
or the whole system will not cause any service outages. The redundant device
will take over the functionalities of the failed one until its replacement.
Switchovers between the RSLs or its components are regularly performed. In
addition, DENIC operates a comprehensive testing environment.
See part 2-5-b-i: Facilities and Systems and part 2-5-b-ii: Stability and
Performance for details on system redundancy and the testing environment and
part 2-5-b-v: Database Capabilities for details on the switchover process.
6. Documentation of System Outages and Potential Problems
Outage and Solution Database
As for .de, DENIC will also introduce a database to fully document and analyze
system outages as well as to document the related solutions.
All historic outages are documented in this database including a detailed
description of the outage and its resolution. The database is constantly
available to all employees.
The documented problems and outages are regularly reviewed and mainly used for
comprehensive root cause analyses, future capacity planning, performance
management or trend analyses. On the basis of all the collected information,
DENIC is fully enabled to develop strategies for the future prevention of the
outages.
Instruction Manual
As part of the DRP, DENIC developed a detailed instruction manual for its .de
processes. The technical departments documented their procedures and processes
for the day-to-day operations as well as for the restoration of services, e.g.
configurations of all system components in case of disasters.
For .net, DENIC will also compile a similar instruction manual that enables
DENIC or any entitled third party to restore the services in case of a disaster.
Trouble Ticketing and Knowledge Database
To guarantee the permanent monitoring and possible escalation of all .net-
related requests that enter the second level support, DENIC will log and manage
them all in a central ticketing system (see Figure 1). Tickets will be closed
as soon as the second level support was able to solve the requests. If a new
request or a new solution appears, it will be entered into the knowledge
database.
As for .de, this database will contain know-how on process handling as well as
a Frequently Asked Question Section, e.g. how to restart a server. All
employees will have access to this database. Thereby, DENIC is able to reduce
response times as the resolution of technical problems or outages or the
recovery of applications can be accomplished faster. To offer a demand-oriented
selection of information, DENIC continuously analyzes all requests.
Please see also part 2-5-b-xix: Support for details on the ticketing system and
knowledge database.
Risk Management System
Two years ago, DENIC built up an extensive risk management system to document
potential risks, the protection against these risks as well as procedures and
processes for resolving the risks. For .net, DENIC will also develop a risk
management system which will be based on the existing one.
DENIC regularly lists and evaluates potential risks for all of its business
operations and also assesses the probability of occurrence per risk. In this
case, risks include e.g. fires, burglaries, environmental or man-made
disasters. Furthermore, the resolution procedures and escalation processes are
described in detail for each risk and employees who will be responsible for
conducting the procedures correctly in case of emergency are assigned.
All of the information mentioned above is summarized in DENIC's risk manual,
which is audited by the Cooperatives Association once per year.
DENIC also uses the regular risk reviews to continuously enhance and improve
its resolution and recovery procedures as well as to minimize the risk
occurrence.
Performance Monitoring System
For .net, DENIC will operate a comprehensive service and performance management
system which will be based on the current monitoring system.
The system extensively monitors all systems, services, components, and
applications. Due to these monitoring procedures, DENIC is able to early
identify, track and document system problems and outages.
Please refer to part 2-5-b-xvi: System Outage Prevention for a detailed
description of the DENIC monitoring system. |
|
|
(xix) Technical and other support. Support for
registrars and for Internet users and registrants. Describe technical help
systems, personnel accessibility, web-based, telephone and other support
services to be offered, time availability of support and
language-availability of support. Ability to support new and emerging
technologies.
|
(xix) Technical and Other Support
Highlights
* Complete web site support in Arabic, Chinese, English, French, German,
Korean and Spanish for .net.
* 24/7/365 customer service in English, support in German from 5 to 19 UTC
seven days, together covering 90% of all registered .net domains and 70% of
all .net registrars in their native language.
* Support in three further languages (Korean, Spanish, French) through call
back, additional languages will be added later upon need.
* Leading edge three level support structure with a 98% first contact
resolution rate at 1st and 2nd levels.
* Long track record of customer service for registrars and registrants with
excellent service levels (e.g. 1,000 calls a day at peak with average
resolution times of three minutes).
* Very close contact to registrars to ensure service quality and further
development of services.
* Full compliance with all ICANN policies, e.g. the agreed UDRP.
Support for Public Internet Users and Registrants
DENIC is committed to delivering high quality and reliable service to all
registrants and the Internet community as a whole. Therefore DENIC provides
support via several interfaces and communication channels, namely web, e-mail,
letter and fax.
Public Web Site
The future .net web site will contain equivalent information to the current
public .de web site (http://www.denic.de/en/index.html) with all information
available in Arabic, Chinese, English, French, German, Korean and
Spanish.
In addition to this general information, several tools are publicly available
on the web site, such as an "IDN-Converter" to find the ACE form of an IDN
domain, a "Zone Check" tool developed by AFNIC to check zones and name server
configurations. DENIC will also offer "Reporting Lame Delegations" to allow
users to report domains with incorrect delegations.
A public whois service is also provided. (see part 2-5-b-xii: Whois Service for
details).
The web site offers an extensive FAQ section as well as a contact form which
sends a help request to DENIC's central helpdesk.
DENIC's websites enable output on Braille converters to accommodate the needs
of the visually impaired and blind. All websites are designed to meet the
relevant standards.
Central Helpdesk
DENIC is currently offering a well established, experienced and highly accepted
support service for .de via its central helpdesk for registrants, registrars
and the interested public.
The central helpdesk currently handles about 200 requests per day with an
average handling time of three minutes and about 4,000 e-mails per month. The
support service demonstrated its high potential on the IDN-launch by handling
approx. 1,000 calls in one day with an average handling time of three minutes
and a longest queue time of 1.5 minutes. DENIC's central helpdesk has
consistently been able to answer 98% of all questions directly.
As DENIC will not have contractual agreements with registrants, the main focus
of our .net Support Team is dedicated to the registrars. Nevertheless, DENIC
places high importance on the information and support of the general public.
Mailing Lists
Registrants and other Internet users can subscribe to DENIC's public mailing
lists which provide information about DENIC, new developments in the registry
environment, as well as planned maintenance and other relevant topics. If
subscribed, users can also send messages to the complete list and thus interact
with other users and/or DENIC. DENIC will offer similar mailing lists
customized to the needs of the .net registrant community.
Dispute Resolution
The Uniform Domain-Name Dispute Resolution Policy (UDRP) has been adopted by
ICANN-accredited registrars for all gTLDs. DENIC will fully implement the UDRP
for all .net domains as specified in ICANN policies
(http://www.icann.org/dndr/udrp/policy.htm). Therefore, DENIC will employ a
fulltime employee in its Frankfurt headquarters to overlook the ICANN policy
compliance including UDRP of DENIC for all .net services.
AuthInfo Code Support
For every domain a unique AuthInfo Code will be generated and saved. Domain
transfers can only be executed when this AuthInfo Code is stated by the
registrant to prevent unauthorized transfers. The registrar is committed to
give the AuthInfo Codes to its registrants. Additionally DENIC will offer a
service for registrants who forgot or lost their AuthInfo Code to recover the
code or to generate a new code.
2. Support for Registrars
DENIC is experienced in supporting registrars of all backgrounds and sizes.
In its special position as German ccTLD registry DENIC is offering direct
registrar services for .de to the public, as described in part 2-b-i:
Description of Current Business Operations. While these services are not at the
core of its philosophy, DENIC gains valuable insights into the activities and
concerns of registrars through this.
The Support Team maintains a database with registrar contact information. The
data is treated with the utmost confidentiality and is only used internally for
conflict resolution between registrars.
(a) Registrar Administration
Registrar administration refers to two separate processes:
* Adding, activating, updating, deactivating or deleting registrars
* Updating accredited registrar's data, e.g. contact addresses, status and
technical details
While the activities listed first are solely performed by DENIC's central
helpdesk, the update of specific registrar information can be done by each
registrar via DENIC's secure web access. The registrar web portal is described
in detail later in this chapter.
(b) Report Generation
DENIC generates regular reports and statistics that contain relevant
information for registrars. They can be accessed in the registrar area of the
DENIC intranet or received via mail. Currently, the following reports are
available:
* Domain portfolio
* Domain activity list
* Object list
* Billing reports
* Customized reports
The standard reports for .net are going to be defined by DENIC in close
cooperation with the registrars.
(c) Web Portal
In addition to the public web sites, registrars have access to a separate
secure web portal via SSL. (For reference, a password can be requested by the
evaluators to review the existing portal for .de registrars at
https://member.secure.denic.de/en/index.html).
General Information Area of Registrar Web Portal
The web portal consists of a general registrars area with information relevant
for the whole registrar community. Specifically, the following information is
available:
* News
* Technical background information
* Documentation of the registry system and How Tos
* Help for administrative questions
* Tools (name server check, IDN converter, cryptpw)
* Statistics about registry performance
* Lists with registrars and their contact information
* System overviews and maintenance information
* Information about upcoming events
* Minutes and presentations of meetings, workgroups, etc.
* Archive of mailing lists
* Project plan, roadmap and implementation rollout
* FAQs
Registrar Forum
DENIC provides a registrar forum where registrars have the ability to exchange
opinions and information with other registrars and with DENIC. Registrars can
comment about new developments and address open questions to DENIC.
Individual Information and Administration Area of Registrar Web Portal
The second area in the web portal is a private area for each registrar. Here
DENIC will make available individual registrar data and customized information,
e.g.:
* Standardized and customized domain reports
* Accounting and billing data
* Individual messages
* Registrars will also be able to perform registrar administration functions
like updating contact billing and other relevant information via the web portal.
(d) Mailing Lists and Newsletters
As is the current practice for .de, DENIC will maintain several mailing lists
for .net for providing information to and encouraging interaction between the
registrars. DENIC maintains two types of mailing lists, announcement lists and
discussions lists for various topics. Furthermore, once per month DENIC
provides a newsletter with the highlights of that month's discussions and
events.
(e) Central Registrar Helpdesk
DENIC's central .net helpdesk will be strongly dedicated to the needs of
registrars, which can access our dedicated 24/7/365 support service via phone,
mail, fax or the web. Our three tiered support (see Figure 1) ensures call
resolution in the shortest possible time.
The Support Teams of 1st and 2nd level are affiliated to the appropriate
technical and administrative departments to have direct insight to the
workflows and processes. Thus, they have been able to resolve 98% of all
requests, with only 2% of issues having to be forwarded to 3rd level support in
the respective functional departments. This high performance has been upheld
over many years and was also maintained during major land rushes like the
introduction of IDN.
Additionally, DENIC's 1st and 2nd level support will also provide customized
reports and other information via e-mail to registrars upon requests.
As problems with registration and other requests by registrars are considered
time-critical by DENIC, all registrars have a direct access number to DENIC's
2nd level technical helpdesk.
DENIC's 3rd level support takes care of complex problems mainly of technical
nature. This support is provided by the experts in the functional departments.
If not immediately reachable, call backs are guaranteed according to our
escalation policies.
Ticketing System and Knowledge Base
All requests that enter our 2nd level support are logged and managed in the
central ticketing system.. Tickets which cannot be closed will be forwarded to
the 3rd level support and resolved according to the assigned priority. Details
about DENIC's prioritization and escalation policies are described later in
this chapter.
Every employee has access to the knowledge base with all previous calls and
their solutions. It enables the Support Team to react to changes in the
structure and content of questions through focused trainings and updates via
web sites or mailing lists. Information about new upcoming support themes will
be made available immediately as website topics or a HowTo/FAQ, thus improving
self help opportunities.
Service Locations
DENIC will provide helpdesk services to registrars from two service locations,
with the main location being at DENIC's Frankfurt headquarters. There, the
complete range of service and support requests will be handled, comprising of:
* Registrar support including helpdesk
* Monitoring and alert management
* Account management
* Billing and Accounting
* Marketing
* Training
As described in part 2-3-b-iii: Description of Facilities, DENIC will establish
an additional support location in Canada at a service provider which will be
totally dedicated to .net. Functional responsibilities of this location will
include:
* Registrar support including helpdesk
* Monitoring and alert management
* Marketing assistance
* Training assistance
DENIC has opted to subcontract these functionalities to better serve the large
North American .net community and to offer support in English 24/7/365. With
this solution DENIC also wins a cooperation partner for marketing and training
in North America. The contract negotiations between DENIC and this Canadian
provider are in an advanced status and will be finalized shortly after the
decision of the ICANN.
Languages and Accessibility
The Frankfurt service location will be available from 5 to 19 UTC and the
Canadian location from 16 to 7 UTC seven days year round. This results in
English support 24/7/365 with five hours overlap between the locations, and
German support from 5 until 19 UTC. With these two languages DENIC offers 70%
of current .net registrars and 90% of .net registrants support in their native
language.
DENIC will also introduce three call back languages (Korean, Spanish, French).
Currently, DENIC can already offer Spanish and French call back service at its
Frankfurt location. Including the call back languages 83% of current .net
registrars and 95% of .net registrants can be supported in their native
language. DENIC will expand the call back languages into full support languages
and introduce further call back languages as the need arrives.
DENIC will have access phone numbers in Germany and North America that route
the caller to the active support location. To minimize costs for registrars,
DENIC's ticketing system will be opened for registrars so that registrars can
open own tickets to request a call back. Furthermore, DENIC's support is also
reachable through Voice over IP telephony.
(f) Training
DENIC provides trainings and workshops with different content to convey all
aspects of the cooperation with DENIC to the accredited registrars. Training
topics include, but are not limited to:
* Basic technical information
* Technical enhancements
* Introduction of new systems and services
* Troubleshooting
* Registrar administration
* Privacy regulations
* Legal and contractual topics
* General DENIC information
Trainings are offered both in English and German with the complete training
material available in both languages. Excerpts from our comprehensive training
material can be made available to the evaluators on request.
198 participants from 116 different registrars had attended DENIC's training
program in 2004 by the end of October. In total 84% of DENIC's members have
participated in the trainings, and the vast majority of them certified more
than one employee.
(g) Test Environment
A test environment which resembles the production system is provided free of
charge for every registrar. There, the registrars' technical processes can be
tested and optimized. As potential changes are introduced in the test
environment, the registrars have the possibility to adapt their system at an
early stage to new standards and minimize go live problems. The Support Team
offers help in case of problems and questions and detailed roadmaps which
define and recommend the adequate tests for the given situation and system.
(h) Registrar Toolkit
DENIC will provide a Registrar Toolkit for the registrars immediately after the
bid decision. It will consist of a working Java and C API and samples for the
registrars to communicate with the registry system. There will be an RRP API
with samples as well as for EPP. The software will provide the basis for a
reference implementation that conforms to the Registry-Registrar Protocol.
The Registrar Tool Kit will be licensed under the GNU Lesser General Public
License.
DENIC may issue new releases of the Registrar Toolkit and the provided APIs
which will follow the same release rules as any other software developed by
DENIC. The rules and notification timelines regarding patches, updates and
upgrades are described in DENIC's suggestion for Appendix C, section 5: Patch,
update, and upgrade policies.
3. Emergency Support and Escalation Policies
Emergency Team and Access
In the extremely unlikely event of an outage of the registry system, DENIC's
monitoring system will immediately alert the 24/7/365 Emergency Team, which
will take the necessary steps to resolve the problem. Registrars will be
informed immediately via e-mail and information will be posted prominently on
the registrars web portal.
For problems undetectable by DENIC (e.g. problems of individual registrars with
DENIC's services) registrars can contact DENIC's Emergency Team 24/7/365 via an
emergency number distributed only to accredited registrars.
Incident Prioritization, Resolution and Escalation Procedures
DENIC categorizes support incidents in five priority levels. Depending on the
priority DENIC guarantees different Response and Resolution Times. DENIC
employs the standard resolution procedures, escalation and registrar
notification policies. A detailed description is given in Figures 2 to 5.
4. Proactive DENIC-Registrar Interaction and Support for new Technologies
To continuously improve our services DENIC encourages registrars to participate
in technical, legal and other relevant discussions. Therefore, DENIC regularly
organizes events with a focus on information exchange, enhancement of registrar
interaction as well as integration of registrar's feedback and recommendations.
Technical Registrar Meetings
Once or twice per year DENIC invites all registrars to a technical meeting,
where current technical topics are presented and discussed. DENIC provides a
preview on its activities for the next six to twelve months. These meetings
will be organized parallel to ICANN conferences in the future to facilitate
participation for all .net registrars.
Registrar Advisory Councils
DENIC has instituted a technical advisory board in which a representative
sample of registrars meet on a bimonthly schedule to discuss technical issues,
potential future developments and, if applicable, issue recommendations for
DENIC's future work. Key DENIC personnel (CEO, CTO, Operations Manager)
participates in these meetings. As for technical questions a legal registrar
advisory board is also implemented.
Joint DENIC-Registrar Work Groups
Work groups of DENIC employees and registrars are formed for topics of special
concern to the registrars. Such a work group was recently held for the
development of the Real time Registry Protocol. These work groups jointly
analyze issues, prepare specifications and recommendations and document
decisions. They are also intimately involved in facilitating the implementation
of the selected solutions.
DENIC's Commitment for .net
Despite the geographically dispersed structure of .net registrars, DENIC is
committed to provide an equal opportunity for information and interaction
for .net registrars. Jointly with the accredited .net registrars DENIC will
develop a plan on how to best serve the needs of the registrar community
through the various means of interaction.
DENIC's Commitment to Provide Support for New Technologies
Several of DENIC's employees participate in relevant international
organizations and panels (IETF, CENTR) and actively contribute to the
development of new technologies and standards. Examples of DENIC's contribution
to the development of new technologies and standards are described in part 2-5-
b-iv: Registry-Registrar Model and Protocol and part 2-5-b-xii: Whois Service.
DENIC is therefore highly committed to implement developed technologies,
standards and services and to offer the appropriate support for these services.
As described, DENIC has a long track record of early involvement of all .de
registrars in the implementation of new technologies. This ensures that
registrars with different technical and financial abilities can voice their
opinions about and define support requirements for the new technology early in
the implementation process, enabling DENIC to customize its services and
support offers to fit the needs of the diverse registrar community and to
preserve the existing variety of registrars.
The means for discussions and providing feedback are mailing lists, web portal
discussion forums, the technical advisory board, the semiannual technical
meeting and the joint DENIC-Registrar workgroups.
|
|
| |
|
|
