5.2.1. Typical functions
5.2.1. 일반적인 기능
The client interface to the resolver is influenced by the local host's conventions, but the typical resolver-client interface has three functions:
리졸버에 대한 클라이언트 인터페이스는 로컬 호스트의 규칙에 영향을 받지만 일반적인 리졸버-클라이언트 인터페이스에는 세 가지 기능이 있습니다:
1. Host name to host address translation.
1. 호스트 이름을 호스트 주소로 변환합니다.
This function is often defined to mimic a previous HOSTS.TXT based function.
이 함수는 종종 이전 HOSTS.TX 기반 함수를 모방하도록 정의됩니다.
Given a character string, the caller wants one or more 32 bit IP addresses.
문자열이 주어지면, 호출자는 하나 이상의 32 비트 IP 주소를 원합니다.
Under the DNS, it translates into a request for type A RRs.
DNS에서는 유형 A RR에 대한 요청으로 변환됩니다.
Since the DNS does not preserve the order of RRs, this function may choose to sort the returned addresses or select the "best" address if the service returns only one choice to the client.
DNS는 RR의 순서를 유지하지 않으므로 이 함수는 반환된 주소를 정렬하도록 선택할 수도 있고, 서비스가 클라이언트에 하나의 선택 항목만 반환하는 경우 "최적의" 주소를 선택할 수도 있습니다.
Note that a multiple address return is recommended, but a single address may be the only way to emulate prior HOSTS.TXT services.
다중 주소 반환이 권장되지만 단일 주소가 이전 HOSTS.TXT 서비스를 에뮬레이션하는 유일한 방법일 수 있습니다.
2. Host address to host name translation
2. 호스트 주소를 호스트 이름으로 변환
This function will often follow the form of previous functions.
이 함수는 이전 함수의 형식을 따르는 경우가 많습니다.
Given a 32 bit IP address, the caller wants a character string.
32 비트 IP 주소가 주어지면 호출자는 문자열을 원합니다.
The octets of the IP address are reversed, used as name components, and suffixed with "IN-ADDR.ARPA".
IP 주소의 옥텟은 반전되어 이름 구성 요소로 사용되며 "IN-ADDR.ARPA"라는 접미사가 붙습니다.
A type PTR query is used to get the RR with the primary name of the host.
유형 PTR 쿼리는 호스트의 기본 이름으로 RR을 가져오는 데 사용됩니다.
For example, a request for the host name corresponding to IP address 1.2.3.4 looks for PTR RRs for domain name "4.3.2.1.IN-ADDR.ARPA".
예를 들어, IP 주소 1.2.3.4에 해당하는 호스트 이름에 대한 요청은 도메인 이름 "4.3.2.1.IN-ADDR.ARPA"에 대한 PTR RR을 찾습니다.
3. General lookup function
3. 일반 조회 기능
This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems.
이 기능은 DNS에서 임의의 정보를 검색하며 이전 시스템에는 해당 정보가 없습니다.
The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs.
호출자는 QNAME, QTYPE, 및 QCLASS를 제공하며 일치하고 일치하는 모든 RR을 원합니다.
This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions.
이 기능은 로컬 호스트 대신 모든 RR 데이터에 대해 DNS 형식을 사용하는 경우가 많으며 로컬 인용 규칙에 따라 처리된 형식 대신 모든 RR 콘텐츠 (예: TTL)를 반환합니다.
When the resolver performs the indicated function, it usually has one of the following results to pass back to the client:
리졸버가 표시된 기능을 수행할 때 일반적으로 다음 중 하나를 갖습니다. 다음 결과를 클라이언트에 다시 전달합니다.
- One or more RRs giving the requested data.
- 요청된 데이터를 제공하는 하나 이상의 RR
In this case the resolver returns the answer in the appropriate format.
이 경우 리졸버는 적절한 형식으로 답변을 반환합니다.
- A name error (NE).
- 이름 오류 (NE)
This happens when the referenced name does not exist.
참조된 이름이 존재하지 않는 경우에 발생합니다.
For example, a user may have mistyped a host name.
예를 들어, 사용자가 호스트 이름을 잘못 입력했을 수 있습니다.
- A data not found error.
- 데이터를 찾을 수 없다는 오류입니다.
This happens when the referenced name exists, but data of the appropriate type does not.
참조된 이름은 존재하지만 해당 유형의 데이터는 존재하지 않는 경우에 발생합니다.
For example, a host address function applied to a mailbox name would return this error since the name exists, but no address RR is present.
예를 들어, 사서함 이름에 적용된 호스트 주소 기능은 이름이 존재하지만 주소 RR이 없기 때문에 이 오류를 반환합니다.
It is important to note that the functions for translating between host names and addresses may combine the "name error" and "data not found" error conditions into a single type of error return, but the general function should not.
호스트 이름과 주소 사이를 변환하는 함수는 "이름 오류" 및 "데이터를 찾을 수 없음" 오류 조건을 단일 유형의 오류 반환으로 결합할 수 있지만 일반 함수는 그렇지 않아야 한다는 점에 유의하는 것이 중요합니다.
One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application.
그 이유 중 하나는 애플리케이션이 이름에 대한 한 가지 유형의 정보를 먼저 요청한 후 다른 유형의 정보에 대해 동일한 이름에 대한 두 번째 요청을 할 수 있다는 것입니다. 두 가지 오류가 결합되면 쓸모없는 쿼리로 인해 애플리케이션 속도가 느려질 수 있습니다.