F.1.1 Resolve Hostname

F.1.1.1 Scope

The DNS Client can obtain the IP number for a host by giving the DNS hostname to a DNS Server and receive the IP number in response.

F.1.1.2 Use Case Roles

[pic]

Figure F.1-1 Resolve Hostname

Actor: DNS Client

Role: Needs IP address, has the DNS Hostname

Actor: DNS Server

Role: Provides current IP address when given the DNS Hostname

F.1.1.3 Referenced Standards

The standards and their relationships for the family of DNS protocols are shown in Figure F.1-2. The details of transactions, transaction diagrams, etc. are contained within the referenced RFC’s.

[pic]

Figure F.1-2 DNS Referenced Standards

F.1.1.4 DNS Security Considerations (Informative)

The issue of security is under active development by the Internet Engineering Task Force and its various working groups. The security related RFCs and drafts are identified in Figure F.1-2. Some of these are completed. Others are still in the draft stage. The Basic Network Address Management Profile does not include specific requirements for support of DNS security extensions by the DNS Client.

The Basic Network Address Management profile should not be used outside a secured environment. At a minimum there should be:

  1. Firewall or router protections to ensure that only approved external hosts are used for DNS services.

  2. Agreements for VPN and other access should require that DNS clients use only approved DNS servers over the VPN.

Other network security procedures such as automated intrusion detection may be appropriate in some environments. Security features beyond this minimum should be established by the local security policy and are beyond the scope of DICOM.

The purpose of the selected security is to limit the scope of the threat to insider attacks. The DNS system discloses only hostnames and IP addresses, so there is little concern about eavesdropping. The protections are to limit the exposure to denial of service attacks by counterfeit servers or clients.

F.1.1.5 DNS Implementation Considerations (Informative)

Client caches may cause confusion during updates. Many DNS clients check for DNS updates very infrequently and might not reflect DNS changes for hours or days. Manual steps may be needed to trigger immediate updates. Details for controls of cache and update vary for different DNS clients and DNS servers, but DNS caching and update propagation delays are significant factors and implementations have mechanisms to manage these issues.

DNS Server failure management should be considered. Redundant servers and fallback host files are examples of possible error management tools.

F.1.1.6 Support for Service Discovery

The DNS server may provide additional optional information in support of configuration management. See section H.2 for the specification of this information and additional RFC’s to be supported.