U.S. Army DEVCOM Army Research Laboratory Statement of Compliance with RSSAC001v2

 

The US Army DEVCOM Army Research Laboratory (ARL) is committed to serve the DNS root zone securely and reliably as one of the Internet’s root server operators (RSOs).  This document serves to demonstrate our compliance with the expectations of an RSO as described in RSSAC001v2.

 

[E.3.1-A] Individual Root Server Operators are to publish or continue to publish operationally relevant details of their infrastructure, including service-delivery locations, addressing information and routing (e.g., origin autonomous system) information.

 

This information is published and updated accordingly at https://www.root-servers.org

 

[E.3.1-B] The RSOs are collectively expected to deliver the service in conformance to IETF standards and requirements as described in BCP 40.

 

The operation of the ARL root name servers conforms to IETF BCP 40 and other relevant IETF standard protocols.

 

[E.3.1-C] Each RSO is expected to notify the Internet community of service-impacting operational changes.

 

ARL will notify the Internet community of changes that impact DNS root service delivery such as a change of address.

 

[E.3.2-A] Each RSO is expected to implement the current DNS protocol through appropriate software and infrastructure choices.

 

The operation of the ARL root name servers complies with current DNS protocol and associated best practices by using appropriate software and hardware.

 

[E.3.2-B] Each RSO is expected to accurately serve the IANA root zone.

 

The ARL root name servers publish the root zone as provided by IANA via the Root Zone Maintainer (RZM).  New versions of the zone are loaded and served as soon as notification and zone transfer complete.

 

[E.3.2-C] Each RSO is expected to serve up-to-date zone data.

The ARL root name server instances receive notifications directly from the RZM and attempt to transfer/load the zone immediately upon receipt of said notification.  Notification, zone transfer, and load times vary slightly among instances.

 

[E.3.2-D] Each RSO is expected to validate root zone data distributed by the RZM.

 

The ARL root name server instances ensure the integrity of zone data received from the RZM using the TSIG protocol (RFC 6895) with best practices for key management.  ARL will only serve unmodified contents of zone data received from the RZM.

 

[E.3.3-A] Each RSO is expected to deploy their systems such that planned maintenance on individual infrastructure elements is possible without making the entire service unavailable.

 

Planned maintenance is scheduled such that the maximum number of instances are always available.  BGP announcements are withdrawn for instances that are temporarily unavailable for maintenance.

 

[E.3.4-A] Each RSO is expected to make all reasonable efforts to ensure that sufficient capacity exists in their deployed infrastructure to allow for substantial flash crowds or denial of service (DoS) attacks.

 

Significant over-provisioning of network and compute capabilities have been deployed in the ARL root server infrastructure.  Rate limiting and denial-of-service mitigations are in place.

 

[E.3.5-A] Each RSO is expected to follow best practices with regard to operational security in the operation of their infrastructure.

 

ARL follows current best practices for operational security of critical systems on its root server infrastructure.

 

[E.3.5-B]  Each RSO is expected to maintain business continuity plans with respect to its infrastructure.

 

The root server infrastructure at ARL is deemed “critical infrastructure” and its operation will not be affected by organizational stoppages.  Operational personnel are considered critical as well and are available to perform their required duties at all times.

 

[E.3.6-A] Each RSO is expected to share, possibly under non-disclosure agreement, details that describe key implementation choices with the other RSOs. The RSOs are expected to collectively publish aggregated implementation diversity reports from time-to-time.

 

ARL uses NSD software on Linux systems across its root server infrastructure.  As new versions of software and OS components are released, software is tested and deployed following best practices for secure systems.  Diversity of resolver software among the infrastructure will be considered for future expansion.

 

ARL participates in diversity assessment activities among root server operators.

 

[E.3.7-A] Each RSO is expected to monitor elements within its own infrastructure.

 

The ARL root server infrastructure uses redundant monitoring systems to enable low-latency alerting of potential service issues.  Logs are analyzed for trends that might affect the stability of the service.

 

[E.3.7-B]  Each RSO is expected to perform measurements and publish statistics as specified in RSSAC002.

 

ARL publishes statistics on query traffic in compliance with RSSAC002 at

 

https://h.root-servers.org/rssac.html

 

[E.3.8.1-A] Each RSO is expected to maintain functional communication channels with the other RSOs in order to facilitate coordination and maintain functional working relationships between technical staff.

 

ARL participates in the root server community and is connected to common emergency communication channels.

 

[E.3.8.1-B] Each RSO is expected to regularly exercise all communications channels.

 

ARL participates in emergency channel testing and verification on a recurring basis.

 

[E.3.8.2-A] Each RSO is expected to publish administrative and operational contact information.

 

Contact information for the ARL root server team is available at https://h.root-servers.org/ and hroot@arl.army.mil.