JP4992016B2 - Domain name management system - Google Patents

Description

  The present invention relates to a domain name management system, and in particular, can respond quickly and in large quantities to data corresponding to a query by domain name on the Internet.

  All computers connected to the Internet currently in use have a unique IP (Internet Protocol: IP) address, and any computer on the Internet will eventually be accessed. I need to know my IP address.

This IP address is assigned a “Fully Qualified Domain Name” (referred to as a “Domain Name”) as a name that is actually easy for humans to remember, and is assigned the domain of FIG. As shown in the name management system 1, when a computer of one client 3A connected to the network 2 accesses a computer of another client 3B... 3N, a network interface card (Network Interface Card: NIC) Access the network interface card 6X of the DNS (Dmain Name System) server 6 through the transmission path 5 through the network 2 from the communication hardware consisting of 4A. The inquiry request D1 for the domain name of the other client 3B... 3N is transmitted, and the IP address corresponding to the domain name is returned through the network interface card 6X → the transmission path 5 → the network 2 → the network interface card 4A. A technique (referred to as “name resolution processing”) is used (see Patent Document 1).
JP 2007-166659 A

  However, according to the conventional configuration of FIG. 1, as the number of clients 3A, 3B... 3N connected to the network 2 increases, the number of inquiry requests D1 from each client to the DNS server 6 increases. The DNS server 6 needs to create the same number of name resolution responses D2 in response to a large number of query requests D1 and reply to each client. Due to the performance limitations of the DNS server 6, the queries received by the DNS server 6 are not necessarily received. Since the name resolution response D2 cannot be returned for all the requests D1, from the viewpoint of efficient use of the network 2, it is possible to reduce the load on the DNS server 6 and to put a lot of load on the DNS server 6. Even if the name resolution response D2 to the inquiry request D1 from each client is accurately sent to each client. It is desirable to be able to answer.

  The present invention has been made in consideration of the above points. The name resolution response D2 in the name resolution process is transmitted instead of the DNS server 6 to reduce the load on the corresponding DNS server as much as possible. It is intended to propose a domain name management system that can create and send a name resolution response D2 regardless of the state.

In order to solve such a problem, in the present invention, domain name-IP address conversion data for mutually converting the domain names of a plurality of clients into IP addresses is added to the network 2 to which the plurality of clients 3A, 3B... 3N are connected. The domain name conversion server 6 is connected, and one of the plurality of clients 3A, 3B... 3N 3A uses the domain name of the other client 3B... 3N as an inquiry request D11 to the domain name conversion server 6 via the network 2. In the domain name management system 10 in which the domain name conversion server 6 supplies the IP addresses of the other clients 3B... 3N to the one client 3A via the network 2 when transmitted, the network 2 and the domain name conversion A domain name management device 25 is provided between the server 6 and the server 6. When the domain name conversion server 6 supplies the IP address of the other client 3B... 3N to the one client 3A via the network 2, the in-name management device 25 sends the other client 3B. When a query request D11 is transmitted from one client 3A via the network 2, the domain name-IP address conversion memory 36 for storing the domain name-IP address conversion data representing the IP address corresponding to the name is stored. When the domain name-IP address conversion data corresponding to the inquiry request D11 exists in the domain name-IP address conversion memory 36, the corresponding domain name-IP address conversion data is sent through the network 2 to the inquiry request D11. Name resolution response D23 to two clients 3A So as to feed. Then, the domain name management device 25 stores data having the same data format as the data format of the name resolution response D23 to the inquiry request D11 as the domain name-IP address conversion data in the domain name-IP address conversion memory 36, and A part of the stored domain name-IP address conversion data is modified so as to conform to the inquiry request D11 and is supplied as a name resolution response D23 to the one client 3A via the network 2.

  According to the present invention, when the domain name management device is provided between the network and the DNS server, and the domain name-IP address conversion data corresponding to the inquiry request is stored in the domain name-IP address conversion memory, Even if the number of clients connected to the network becomes enormous by returning the corresponding domain name-IP address data as a name resolution response to the client that issued the inquiry request, the name resolution response regardless of the state of the DNS server Can be sent.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

  In FIG. 2, reference numeral 10 denotes a domain name management system, and a domain name management device 25 is provided on the transmission path 5 between the network 2 and the DNS server 6 as shown in FIG. It has an arranged configuration.

  As shown in FIG. 3, the domain name management device 25 has a network interface card (NIC) 25Y on the network side and a network interface card 25Z on the DNS server side, and the network interface card 25Y on the network side is connected to the transmission line 5 as shown in FIG. The network interface card 25Z on the DNS server side is connected to the network interface card 6X of the DNS server 6 via the transmission path portion 5B of the transmission path 5.

  Thus, the data taken into the domain name management device 25 from the network interface cards 25Y and 25Z is taken into the central processing unit (CPU) 32 through the bus 31, and the CPU 32 sends the fetched data through the input means 33. Based on the designation information inputted by the user, the domain name-IP address conversion process is executed while being displayed to the operator by the display 35 using the program stored in the program / operation memory 34, and the domain name-IP The result of the address conversion process is stored in the domain name-IP address conversion memory 36.

  When the CPU 32 of the domain name management device 25 receives the inquiry request D11 from the network interface card 25Y on the network side or the name resolution response D22 from the DNS server 6 to the network interface card 25Z on the DNS server side, FIG. The DNS name resolution processing procedure RT1 shown in FIG.

  When entering the DNS name resolution processing procedure RT1, the CPU 32 first determines in step SP1 whether the received data is an inquiry request packet.

  If a positive result is obtained here, this means that the inquiry request D11 is received from any of the clients 3A, 3B,... 3N from the transmission path unit 5A connected to the network 2, and the CPU 32 at this time Then, the process proceeds to step SP2 to obtain an inquiry packet that has arrived from the network interface card (NIC) 25Y.

  Subsequently, the CPU 32 proceeds to step SP3 to calculate the hash value of the data for the hash table 36A provided in the domain name-IP address conversion memory 36, thereby representing the obtained inquiry packet in the hash table 36A. Search for the response packet corresponding to the domain name.

  In this embodiment, as shown in FIG. 5, the hash table 36A includes response packets A, B, C, and so on in the memory areas with hash values “1010”, “1030”, “1050”, “1110”. Thus, the CPU 32 sequentially calculates the hash values “1010”, “1030”, “1050”, “1110”... So that the response packets A, B, C, D .. Are sequentially checked to search for a response packet corresponding to the packet acquired in step SP2.

  Each of the response packets A, B... Consists of an IP (Internet Protocol) packet PT1, a UDP (User Datagram Protocol) packet PT2, and a DNS (Domain Name System) packet PT3.

  The IP packet PT1 is configured in a format as shown in FIG. 6A, includes data for ensuring communication between the source client and the destination client, and serves as an OS (Operating System: Operating System) driver. Have the following data to realize the function

Version The version field indicates the format of the Internet header. In the current Internet, IP protocol version 4 is used. Therefore, a numerical value of 4 is written in this area.

Header length The Internet header length (IHL) is the length of the Internet header in units of 32 bits, and indicates the start point of data. The minimum value for a correct header is 5.

Service type Data indicating the reliability and priority of this packet. It describes how important this packet is and how preferentially it must be carried. It is similar to “express delivery” and “registered mail” at post offices.

Total data length The total data length is the length of the datagram, calculated in octets, and includes the Internet header and data. This field can be up to 65535 octets in length of the datagram. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to receive datagrams of up to 576 octets (whether they receive whole or fract cement). If there is a guarantee that the destination is ready to receive a larger datagram, it is recommended that the host send a datagram larger than 576 octets.

Identifier A value that identifies the packet. Since a huge amount of packets fly on the network, a number (such as a car license plate) for identifying each packet is given.

Flag This field indicates where in the datagram this fragment belongs. The fragment offset is calculated in units of 8 octets (64 bits). The offset of the first fragment is zero.

Survival Time This field indicates the maximum time that a datagram is allowed to remain in the Internet system. If this field contains the value 0, the datagram must be discarded. This field is updated by Internet header processing. Although time is measured in seconds, every module that processes a datagram must reduce the TTL by at least one, even if it processes the datagram in less than one second, so TTL has a datagram present. Only the upper limit of time that may be taken into account must be considered. The intent of this field is to discard datagrams that cannot be delivered and to allocate a maximum datagram lifetime.

Protocol Describe what the higher-level protocol is. Since the upper level of IP is usually “TCP” or “UDP”, either one of them is entered.

Checksum Data for confirming whether the IP header is broken.

  Since network communication is an electrical signal transmission, data may be changed (broken) during transmission. So you need to check if the packet is broken. Therefore, a special calculation is performed on the entire IP header, and the value calculated by the calculation is stored in this checksum area. By checking the value of this checksum area and the entire IP header, it is possible to confirm whether the data is accurately transmitted.

Source IP address IP address of the source.

Destination IP address Destination IP address.

Various information about the option network is described but not used in the present invention.

  The UDP packet PT2 has a format as shown in FIG. 6B, and has a function of transferring data of a lower application layer, and is composed of the following data.

Source port number Source port number.

Destination port number Destination port number.

UDP data length Size of UDP data (including UDP header).

UDP checksum Basically, it is the same as the checksum of the IP header, but here, the UDP data (including the UDP header) is calculated (checked) for damage.

  The DNS packet PT3 has the format shown in FIG. 6C, and has the following data for realizing a function as an upper application layer.

Identifier Number for identifying this DNS data.
This is basically the same as the one in the IP header, but this is the identification number for the DNS protocol.

QR (Query / Response)
Client 3A, 3B... A number for determining whether it is a packet sent by 3N or a packet sent by a DNS server is entered. Clients 3A, 3B... "0" if the packet is sent by 3N, and "1" if the packet is sent by the DNS server 6.

OPCODE
Contains status information regarding the DNS request. Client 3A, 3B... 3N sets. This request sets “what purpose is being sent”, “what kind of response is desired”, and the like.

AA (abbreviation of Authoritative Answer)
Set by the DNS server 6. When it is answered from the reliable DNS server 6, it is “1”, and when it is answered from the cache server, it is set to “0”.

TC (abbreviation for truncation)
When the response from the DNS server 6 becomes longer, the DNS server 6 sets “1”.
A DNS packet usually fits in one packet (less than 512 bytes), but it may become so long that it is rarely divided into a plurality of packets. In this case, this value is set to “1” to notify the client that there are a plurality of reply packets.
Incidentally, the DNS accelerator domain name management device 25 does not support response packets having a TC of “1”.

RD (Recursion Desired)
The RD is set by the client. Tells the server whether to allow recursive queries. A recursive query is when a DNS server that has been asked a question fails to answer the question by itself and asks another DNS server. Set whether the DNS server can do it.

RA (Recovery Available)
RA is set by the server. Tells the client whether recursive queries are possible.

Z
A reserved area in case the protocol is expanded in the future. Currently, it is decided to set all of them to “0”.

RCODE (abbreviation for Response Code)
The server sets status information about the response.

Status information example:
・ No problem ・ Packet format error ・ Cannot answer due to DNS server failure ・ Unsupported question ・ Reject answer to this request

Number of questions Sets the number of questions present in the question record. Normally “1” is set.

Number of answers RR Sets the number of answers existing in the answer record.
The client sets “0” and the server sets “1”.

Authority number of RRs Set the number of DNS servers present in the authority record. (Normally “0”)

Number of additional RRs Set the number of additional information existing in the additional information record. (Normally “0”)

Question record Client sets “Name to Inquire”, “Type” and “Class”. In other words, the question that the client wants to hear is described here.

Answer record server sets "answer to question". In other words, the answer to the question that the client wants to hear is described here.

Authority record For this answer, the name of the authoritative DNS server is set. It is not used much in normal DNS packets.

Additional information record Additional information for this DNS packet is set. It is not used much in normal DNS packets.

  Subsequently, in step SP4 following step SP3 described above, the CPU 32 determines whether or not a response packet exists in the hash table 36A as a search result for the hash table 36A. If a negative result is obtained, the CPU 32 proceeds to step SP5. Then, the inquiry packet acquired in step SP2 is sent as an inquiry request D12 to the transmission path portion 5B connected to the DNS server 6 via the network interface card 25Z.

  Thus, the CPU 32 confirms that the corresponding response packet does not exist in the hash table 36A of the domain name IP address conversion memory 36 in response to the inquiry request D11 fetched from the network interface card 25Y. Procedure RT1 is ended in step SP6.

  In this way, the query request D12 sent to the DNS server 6 by the loop SP2-SP3-SP4-SP5-SP6 of the DNS name resolution processing procedure RT1 of the domain name management device 25 is the network interface of the DNS server 6. The response processing corresponding to the inquiry request D12 is executed by fetching the data from the card 6X into the DNS server 6 and executing the DNS name resolution processing procedure RT2 shown in FIG.

  When the DNS name resolution processing procedure RT2 is entered, the DNS server 6 acquires a packet from the network interface card 6X in step SP21, and then analyzes data in step SP22.

  Subsequently, the DNS server 6 determines whether or not the analyzed inquiry request in step SP23 is a request for DNS data managed by itself.

  When a positive result is obtained here, this means that the DNS server 6 can respond by converting to an IP address corresponding to the domain name requested for inquiry. At this time, the DNS server 6 moves to step SP24. In step SP25, the converted packet data is transmitted from the network interface card 6X to the transmission path unit 5B connected to the domain name management device 25 as a name resolution response D22.

  On the other hand, if a negative result is obtained in step SP23 described above, this means that the domain name requested for inquiry is not managed by itself, so that the IP address cannot be responded. At this time, the DNS server 6 After generating packet data notifying that the corresponding IP address is not held in step SP27, the generated packet data is transmitted as a name resolution response D22 from the network interface card 6X to the transmission path unit 5B in step SP25. .

  Thus, the DNS server 6 ends the DNS name resolution processing procedure RT2 for the inquiry request D12 transferred from the domain name management device 25 in step SP26.

  Thus, the packet data transmitted as the name resolution response 22 from the DNS server 6 to the transmission path unit 5B of the transmission path 5 arrives at the network interface card 25Z of the domain name management device 25. At this time, the domain name management The CPU 32 of the device 25 determines whether or not it is a request packet in step SP1 of the DNS name resolution processing procedure RT1 in FIG.

  Since the packet data arrived at this time is not an inquiry request from the network 2 but a name resolution response packet from the DNS server 6, the CPU 32 proceeds to step SP10 when a negative result is obtained in step SP1, and moves to the network interface card 25Z. In step SP11, the packet data is stored in the hash table 36A of the domain name-IP address conversion memory 36.

  Thereafter, in step SP12, the CPU 32 transmits the packet acquired in step SP10 described above as it is as the name resolution response D23 from the network interface card 25Y on the network 2 side to the transmission path unit 5A.

  Thus, the CPU 32 completes the DNS name resolution processing procedure RT1 in step SP6 by performing the processing in the loop of steps SP10-SP11-SP12.

  As a result, the CPU 32 stores the name resolution processing result in the DNS server 6 in response to the inquiry request D11 coming from the network 2 in the hash table 36A of the domain name-IP address conversion memory 36 of the domain name management device 25, and stores the data in the network 2 to the client that issued the request.

  In this way, in the hash table 36A of the domain name-IP address conversion memory 36, when there is no corresponding name resolution response in the hash table 36A for the query request coming from the clients 2A, 2B,. The server 6 waits for name resolution processing, and sequentially accumulates the processing results.

  When the inquiry request D11 for the stored name resolution data arrives at the network interface card 25Y, the CPU 32 enters the DNS name resolution processing procedure RT1 in FIG. 4 each time and performs steps SP1-SP2-SP3-SP4. By executing the processing of the loop, a positive result is obtained in step SP4.

  At this time, the CPU 32 moves to step SP15 and transmits a corresponding response packet from the hash table 36A of the domain name-IP address conversion memory 36 to the transmission path unit 5A via the network interface card 25Y, and then in step SP6 the DNS name. The solution processing procedure RT1 is terminated.

  As a result, the CPU 32 of the domain name management device 25, for the query request D11 received from the clients 3A, 3B,. When the address is stored, the name resolution response D23 can be supplied to the clients 3A, 3B,... 3N that have requested the stored data immediately from the network interface card 25Y via the network 2.

  The response packet is generated in step SP15 of the DNS name resolution processing procedure RT1 when a DNS request packet (for example, packet “A”) is acquired from the network interface card 25Y as shown in the function block BL1 as shown in FIG. As shown in the functional block BL2, the response packet “A” from the hash table 36A corresponding to the DNS request packet “A” is acquired.

  The obtained DNS response packet (functional block BL3) includes the IP packet PT1, the UDP packet PT2, and the DNS packet PT3 as described above with reference to FIGS. 6 (A), (B), and (C). First, as shown by the function block BL4, the source IP address and the destination IP address included in the IP packet format are changed (modified).

  At the same time, as shown in the function block BL5, after recalculating the checksum included in the format of the IP packet PT1, the source PORT number and the destination PORT number in the UDP packet PT are changed as shown in the function block BL6 ( Modify).

  Further, the generation of the response packet is finished by changing the identifier included in the DNS packet PT3 indicated by the functional block BL7, and is passed to the network interface card 25Y.

  Thus, as a response packet generation process, the CPU 32 of the domain name management device 25 sees the first layer IP packet PT1 (FIG. 6A) and the higher protocol layer relative to the first layer as seen from the protocol layer. UDP packet PT2 (FIG. 6 (B)) formed as the second layer and DNS packet PT3 (FIG. 6 (C)) forming the third layer that is an upper application layer with respect to the second layer. A hash value is added to the hash table 36A as data having a format prepared in advance, and the response packet can be generated simply by modifying a part of the data in the format.

  As shown in FIG. 9, such a method of generating a response packet can be achieved by leaving the operating system (OS) without generating the IP packet PT1 and the UDP packet PT2 that are part of the response packet. A function M1 that searches for a corresponding packet prepared separately from the operating system (OS) in the lower software layer (second layer) of the name management device 25, a function M2 that responds when there is a response packet as a result of the search, and a corresponding This is because when there is no packet, the passage function M3 is executed by the CPU 32 and passed as response data to the network interface constituting the hardware layer (first layer) LY1.

  A function M1 in which the system searches all packet data as a function of a kernel including an operating system (OS) from the hash table 36A of the domain name-IP address conversion memory 36, and a response packet as a result of the search. By managing the function M2 that responds at a time, management is performed such that response data is created and passed to the network interface card 25Y of the hardware layer (first layer) LY1. In addition, when there is no corresponding packet in the hash table 36A, the inquiry request acquired by the passing function M3 is passed to the network interface card 25Z constituting the hardware layer (first layer) LY1.

  Thus, the CPU 32 realizes such a control function that the lower layer software layer (second layer) LY2 has a kernel function for controlling its operation while being closely related to the hardware of the hardware layer (first layer) LY1. .

  The function of the second layer LY2 constructs a layer configuration in which the setting data is applied and the operation is controlled as the operation condition of the domain name management device 25 in the third layer LY3 forming the upper software layer.

  In the above configuration, when the CPU 32 of the domain name management device 25 receives an inquiry request D11 including a domain name from one of the clients 3A, 3B,... 3N via the network 2, the DNS name resolution process of FIG. The response packet having the corresponding domain name is searched by searching the hash table 36A of the domain name-IP address conversion memory 36 through the loop of steps SP1-SP2-SP3-SP4 of the procedure RT1, and the corresponding response packet exists. Then, based on the format of the packet stored in the hash memory 36 in step SP15, a part of the packet, that is, the source IP PORT, the destination IP PORT, and the packet data to be responded are created, Network interface card 2 It is supplied as a name resolution response D23 to the client that has issued a response request via 5Y.

  According to the above configuration, the domain name management device 25 is provided between the network 2 and the DNS server 6, and the domain name-IP address conversion data corresponding to the inquiry request D11 is stored in the domain name-IP address conversion memory 36. If not, a name resolution response is obtained by transferring the query request to the DNS server 6 and performing domain name-IP address conversion processing, and returned as a name resolution response D23 to the client 3A that issued the query request. This is stored in the domain name-IP address conversion memory 36.

  On the other hand, when the domain name-IP address conversion data corresponding to the inquiry request D11 is stored in the domain name-IP address conversion memory 36, the corresponding domain name-IP address data is used as the name resolution response D23. By returning the inquiry request to the client 3A, the name resolution response can be transmitted regardless of the state of the DNS server even if the number of clients 3A, 3B... 3N connected to the network 2 becomes enormous. .

  At this time, an IP packet PT1 that forms a first layer protocol having a predetermined format for generating a response packet, a UDP packet PT2 that constitutes a second layer packet, and a DNS packet PT3 that constitutes a third layer are used. As a result, the time from receiving the inquiry request D11 to supplying the name resolution response D23 can be further shortened.

  According to the experiment, in a general network where the domain name management device 25 is not installed, the response amount is confirmed to be about 20 times per unit time as compared with the case where the inquiry request is directly sent from the network 2 to the DNS server 6. It was possible.

  Accordingly, the response amount can be further increased by forming the hash table 36A on the domain name-IP address conversion memory 36 and calculating each hash value by calculating the hash value.

  Further, by constructing a kernel-type software that can control the hardware substantially directly in the system configuration, a faster response process to the inquiry request D11 is realized.

  Further, since the packet format of the name resolution response to the inquiry request can be made common, the source IP address (including PORT) and the destination IP address (PORT) included in a part of the name resolution data based on the inquiry request data. And the name resolution response packet data for the inquiry request can be generated only by changing the identifier, and the response time can be further shortened.

  The present invention can be applied to a management system that mutually converts domain names and IP addresses on the Internet.

It is a block diagram which shows the conventional structure. It is a block diagram which shows one Embodiment of the domain name management system by this invention. It is a block diagram which shows the detailed structure of the domain name management apparatus of FIG. It is a flowchart which shows the DNS name resolution process sequence in a domain name management apparatus. It is a basic diagram which shows the detailed structure of the hash table of FIG. FIG. 6 is a schematic diagram illustrating a configuration of a response packet in FIG. 5. It is a flowchart which shows the DNS name resolution process sequence in the DNS server 6. It is a functional block diagram which shows the production | generation procedure of a response packet. It is a basic diagram which shows the layer structure of a system.

Explanation of symbols

  1, 10 ... Domain name management system, 2 ... Network, 3A, 3B ... 3N ... Client, 4A, 4B ... 4N, 6X, 25Y, 25Z ... Network interface card, 31 ... Bus, 32 ... ... CPU, 33 ... input means, 34 ... program / operation memory, 35 ... display, 36 ... domain name-IP address conversion memory, 36A ... hash table.

Claims (3)

A domain name conversion server having domain name-IP address conversion data for converting the domain names of the plurality of clients into IP addresses is connected to a network to which a plurality of clients are connected, and one of the plurality of clients is connected to the other When the domain name of a client is sent as an inquiry request to the domain name translation server via the network, the domain name translation server supplies the IP address of the other client to the one client via the network. In the domain name management system that
A domain name management device is provided between the network and the domain name conversion server,
When the domain name conversion server supplies the IP address of the other client to the one client via the network, the domain name management device is configured to provide the IP corresponding to the domain name of the other client. A domain name-IP address conversion memory for storing domain name-IP address conversion data representing an address;
When the inquiry request is transmitted from the one client via the network, when the domain name-IP address conversion data corresponding to the inquiry request exists in the domain name-IP address conversion memory, the corresponding domain Supplying name-IP address conversion data as a name resolution response to the one client that has made the inquiry request via the network ;
Data having a data format similar to the data format of the name resolution response to the inquiry request is stored in the domain name-IP address conversion memory as the domain name-IP address conversion data, and the stored domain name-IP address conversion is stored. A domain name management system, wherein a part of data is modified so as to conform to the inquiry request and is supplied to the one client via the network as the name resolution response . The domain name management system according to claim 1, wherein the domain name-IP address conversion memory has a hash table when searching for domain name-IP address conversion data. A domain name-IP address conversion data for converting a domain name of a plurality of clients connected to a network into an IP address, and one of the plurality of clients via the network as a query request for the domain name of another client A domain name management apparatus provided between the network and a domain name translation server that supplies the other client's IP address to the one client via the network
When the domain name translation server supplies the IP address of the other client to the one client via the network, the domain name-IP representing the IP address corresponding to the domain name of the other client Having a domain name-IP address translation memory for storing address translation data;
When the inquiry request is transmitted from the one client via the network, when the domain name-IP address conversion data corresponding to the inquiry request exists in the domain name-IP address conversion memory, the corresponding domain Supplying name-IP address conversion data as a name resolution response to the one client that has issued the inquiry request via the network;
The domain name-IP address conversion data is stored in the domain name-IP address conversion memory in the same data format as the data format of the name resolution response to the inquiry request,
A part of the stored domain name-IP address conversion data is modified to conform to the inquiry request and supplied to the one client as the name resolution response via the network.
A domain name management device.