5.3.3. Algorithm
5.3.3. 알고리즘
The top level algorithm has four steps:
최상위 수준 알고리즘에는 네 가지 단계가 있습니다:
1. See if the answer is in local information, and if so return it to the client.
1. 답변이 지역 정보에 있는지 확인하고, 그렇다면 고객에게 반환합니다.
2. Find the best servers to ask.
2. 물어볼 최고의 서버를 찾으세요.
3. Send them queries until one returns a response.
3. 응답이 돌아올 때까지 쿼리를 보냅니다.
4. Analyze the response, either:
4. 다음 중 하나를 수행하여 응답을 분석합니다:
a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client.
a. 응답이 질문에 대답하거나 이름 오류가 포함된 경우 데이터를 캐시하고 클라이언트에 다시 반환합니다.
b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.
b. 응답에 다른 서버에 대한 더 나은 위임이 포함되어 있으면 위임 정보를 캐시하고 2단계로 이동합니다.
c. if the response shows a CNAME and that is not the answer itself, cache the CNAME, change the SNAME to the canonical name in the CNAME RR and go to step 1.
c. 응답에 CNAME이 표시되고 그것이 응답 자체가 아닌 경우 CNAME을 캐시하고 SNAME을 CNAME RR의 정식 이름으로 변경한 후 1단계로 이동하세요.
d. if the response shows a servers failure or other bizarre contents, delete the server from the SLIST and go back to step 3.
d. 응답에 서버 오류나 기타 이상한 내용이 표시되면 SLIST에서 서버를 삭제하고 3단계로 돌아가세요.
Step 1 searches the cache for the desired data.
1단계에서는 캐시에서 원하는 데이터를 검색합니다.
If the data is in the cache, it is assumed to be good enough for normal use.
데이터가 캐시에 있으면 일반적인 사용에 충분한 것으로 간주됩니다.
Some resolvers have an option at the user interface which will force the resolver to ignore the cached data and consult with an authoritative server.
일부 리졸버에는 리졸버가 캐시된 데이터를 무시하고 권한 있는 서버에 문의하도록 강제하는 옵션이 사용자 인터페이스에 있습니다.
This is not recommended as the default.
이는 기본값으로 권장되지 않습니다.
If the resolver has direct access to a name server's zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data.
리졸버가 네임 서버의 영역에 직접 액세스할 수 있는 경우 원하는 데이터가 신뢰할 수 있는 형식으로 존재하는지 확인해야 하며, 그렇다면 캐시된 데이터보다 신뢰할 수 있는 데이터를 우선적으로 사용해야 합니다.
Step 2 looks for a name server to ask for the required data.
2 단계에서는 필요한 데이터를 요청할 네임서버를 찾습니다.
The general strategy is to look for locally-available name server RRs, starting at SNAME, then the parent domain name of SNAME, the grandparent, and so on toward the root.
일반적인 전략은 SNAME에서 시작하여 로컬에서 사용 가능한 이름 서버 RR을 찾은 다음 SNAME의 상위 도메인 이름, 조부모 등을 루트 방향으로 찾는 것입니다.
Thus if SNAME were Mockapetris.ISI.EDU, this step would look for NS RRs for Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
따라서 SNAME이 Mockapetris.ISI.EDU인 경우, 이 단계에서는 Mockapetris.ISI.EDU, ISI.EDU, EDU, 에 대한 NS RR을 찾습니다. (루트).
These NS RRs list the names of hosts for a zone at or above SNAME.
이러한 NS RR은 SNAME 이상의 영역에 대한 호스트 이름을 나열합니다.
Copy the names into SLIST.
이름을 SLIST에 복사합니다.
Set up their addresses using local data.
로컬 데이터를 사용하여 주소를 설정합니다.
It may be the case that the addresses are not available.
주소를 사용할 수 없는 경우도 있습니다.
The resolver has many choices here; the best is to start parallel resolver processes looking for the addresses while continuing onward with the addresses which are available.
리졸버는 여기에서 많은 선택을 할 수 있습니다. 가장 좋은 방법은 사용 가능한 주소를 계속 사용하면서 주소를 찾는 병렬 확인 프로세스를 시작하는 것입니다.
Obviously, the design choices and options are complicated and a function of the local host's capabilities.
분명히, 디자인 선택과 옵션은 복잡하며 로컬 호스트의 기능에 따라 다릅니다.
The recommended priorities for the resolver designer are:
리졸버 디자이너에게 권장되는 우선순위는 다음과 같습니다:
1. Bound the amount of work (packets sent, parallel processes started) so that a request can't get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA.
1. 누군가가 일부 데이터를 잘못 구성한 경우에도 요청이 무한 루프에 빠지거나 다른 구현과의 요청 또는 쿼리의 연쇄 반응이 시작되지 않도록 작업량 (패킷 전송, 병렬 프로세스 시작)을 제한합니다.
2. Get back an answer if at all possible.
2. 가능하다면 답변을 받으십시오.
3. Avoid unnecessary transmissions.
3. 불필요한 전송을 피하세요.
4. Get the answer as quickly as possible.
4. 가능한 한 빨리 답변을 얻으십시오.
If the search for NS RRs fails, then the resolver initializes SLIST from the safety belt SBELT.
NS RR 검색이 실패하면 리졸버는 안전 벨트 SBELT에서 SLIST를 초기화합니다.
The basic idea is that when the resolver has no idea what servers to ask, it should use information from a configuration file that lists several servers which are expected to be helpful.
기본 아이디어는 리졸버가 어떤 서버에 물어볼지 모르는 경우 도움이 될 것으로 예상되는 여러 서버를 나열하는 구성 파일의 정보를 사용해야 한다는 것입니다.
Although there are special situations, the usual choice is two of the root servers and two of the servers for the host's domain.
특별한 상황이 있더라도 일반적으로 루트 서버 두 대와 호스트 도메인용 서버 두 대를 선택합니다.
The reason for two of each is for redundancy.
각각 2개씩 있는 이유는 중복 때문입니다.
The root servers will provide eventual access to all of the domain space.
루트 서버는 모든 도메인 공간에 대한 최종 액세스를 제공합니다.
The two local servers will allow the resolver to continue to resolve local names if the local network becomes isolated from the internet due to gateway or link failure.
두 개의 로컬 서버를 사용하면 게이트웨이 또는 링크 오류로 인해 로컬 네트워크가 인터넷에서 격리되는 경우 리졸버가 계속해서 로컬 이름을 확인할 수 있습니다.
In addition to the names and addresses of the servers, the SLIST data structure can be sorted to use the best servers first, and to insure that all addresses of all servers are used in a round-robin manner.
서버의 이름과 주소 외에도 최상의 서버를 먼저 사용하고 모든 서버의 모든 주소가 라운드 로빈 방식으로 사용되도록 SLIST 데이터 구조를 정렬할 수 있습니다.
The sorting can be a simple function of preferring addresses on the local network over others, or may involve statistics from past events, such as previous response times and batting averages.
정렬은 로컬 네트워크의 주소를 다른 주소보다 선호하는 간단한 기능일 수도 있고, 이전 응답 시간 및 타율과 같은 과거 이벤트의 통계를 포함할 수도 있습니다.
Step 3 sends out queries until a response is received.
3 단계에서는 응답을 받을 때까지 쿼리를 보냅니다.
The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission.
전략은 각 전송 사이에 시간 초과를 두고 모든 서버의 모든 주소를 순환하는 것입니다.
In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver.
실제로는 멀티홈 호스트의 모든 주소를 사용하는 것이 중요하며, 너무 공격적인 재전송 정책은 동일한 이름 서버에 대해 경합하는 여러 리졸버에서 사용될 때, 때로는 단일 확인자를 위해 경합하는 경우 실제로 응답 속도를 느리게 합니다.
SLIST typically contains data values to control the timeouts and keep track of previous transmissions.
SLIST에는 일반적으로 시간 초과를 제어하고 이전 전송을 추적하는 데이터 값이 포함되어 있습니다.
Step 4 involves analyzing responses.
4단계에는 응답 분석이 포함됩니다.
The resolver should be highly paranoid in its parsing of responses.
리졸버는 응답을 구문 분석할 때 편집증적이어야 합니다.
It should also check that the response matches the query it sent using the ID field in the response.
또한 응답의 ID 필드를 사용하여 보낸 쿼리와 응답이 일치하는지 확인해야 합니다.
The ideal answer is one from a server authoritative for the query which either gives the required data or a name error.
이상적인 대답은 필요한 데이터를 제공하거나 이름 오류를 제공하는 쿼리에 대해 권한이 있는 서버의 대답입니다.
The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero.
데이터는 TTL이 0보다 큰 경우 나중에 사용할 수 있도록 사용자에게 다시 전달되고 캐시에 입력됩니다.
If the response shows a delegation, the resolver should check to see that the delegation is "closer" to the answer than the servers in SLIST are.
응답에 위임이 표시되면 확인자는 위임이 SLIST의 서버보다 답변에 "가까운"지 확인해야 합니다.
This can be done by comparing the match count in SLIST with that computed from SNAME and the NS RRs in the delegation.
이는 SLIST의 일치 개수를 SNAME 및 위임의 NS RR에서 계산된 일치 개수와 비교하여 수행할 수 있습니다.
If not, the reply is bogus and should be ignored.
그렇지 않은 경우 답변은 가짜이므로 무시해야 합니다.
If the delegation is valid the NS delegation RRs and any address RRs for the servers should be cached.
위임이 유효한 경우 NS 위임 RR과 서버의 모든 주소 RR이 캐시되어야 합니다.
The name servers are entered in the SLIST, and the search is restarted.
SLIST에 네임서버가 입력되고 검색이 다시 시작됩니다.
If the response contains a CNAME, the search is restarted at the CNAME unless the response has the data for the canonical name or if the CNAME is the answer itself.
응답에 CNAME이 포함된 경우 응답에 정식 이름에 대한 데이터가 없거나 CNAME이 답변 자체인 경우가 아니면 CNAME에서 검색이 다시 시작됩니다.
Details and implementation hints can be found in [RFC-1035].
자세한 내용과 구현 힌트는 [RFC-1035]에서 확인할 수 있습니다.