NAMED.CONF(5)

명칭
named.conf - named(8) 용무의 설정 파일

개요
BIND 8 은, 이전의 릴리스와 비교해 훨씬 더 설정 가능한 것이 되어 있습니다. 완전하게 새로운 설정 항목이 있습니다. 예를 들면 액세스 제어 리스트나 카테고리별의 로그 등입니다. 이전에는 존 모두에 대해서 적용되고 있던 옵션의 대부분이, 선택적으로 사용할 수 있게 되어 있습니다. 이러한 기능에 가세해 장래 필요하게 되는 설정이 어떠한 것이 될까를 잘 생각한 결과, 새롭게 설정 파일의 포맷을 만들기로 했습니다.

  일반적인 문법
BIND 8 의 설정에는, 일반적인 특징이 2 개 있습니다. 그것은, 스테이트먼트와 코멘트입니다. 스테이트먼트는 모두 세미콜론으로 끝납니다. 스테이트먼트의 상당수는 서브 스테이트먼트를 가지고 있어 서브 스테이트먼트도 세미콜론으로 끝납니다.

다음과 같은 스테이트먼트를 서포트하고 있습니다 :

logging
    서버가 무엇을 로그에 남기는지, 그리고 어디에 로그 메세지를 보내는지를 지정합니다.

options
    글로벌인 서버 설정 옵션을 제어해, 그 외의 스테이트먼트에 대한 디폴트를 설정합니다.

zone
    존을 정의합니다.

acl 이름포함의 IP 주소 매칭 리스트를 정의합니다. 이것은, 액세스 제어나 그 외의 용도에 사용됩니다.

key 인증과 허가에 사용되는 열쇠 정보를 지정합니다.

trusted-keys
    DNSSEC 열쇠를 정의합니다. 이것은, 사전에 서버로 설정되어 있어 암묵중에 신뢰합니다.

server
    개개의 리모트 서버용의 설정 옵션을 설정합니다.

controls
    ndc 유틸리티가 사용하는 제어 채널을 선언합니다.

include
    다른 파일을 인클루드 합니다.

logging 및 options 스테이트먼트는, 각 설정에 대해 1 회만 기술 가능합니다. 그에 대해, 그 외의 스테이트먼트는 몇회에서도 기술 가능합니다. 각 스테이트먼트의 상세한 것에 대하여는, 다음에 개개의 섹션으로 말합니다.

코멘트는, BIND 설정 파일중에서 화이트 스페이스가 나타나 좋다 곳이라면 어디에서라도 기술 가능합니다. 여러가지 프로그래머의 주의를 끌도록(듯이), C 나 C++, 혹은 쉘나 perl 의 형식의 코멘트를 쓸 수가 있습니다.

C 의 스타일의 코멘트는, 다음의 2 개의 캐릭터로부터 시작됩니다. /* (slash와 별표) 그리고, */ (별표와 slash)(으)로 끝납니다. 이 형식의 코멘트는, 이러한 캐릭터로 완전하게 단락지어지는 것이므로, 행의 일부분만에서도 복수행에 걸쳐도 사용할 수가 있습니다.

C 의 스타일의 코멘트는 상자에는 할 수 없습니다. 예를 들면, 다음의 예는 부적절한 것입니다. 왜냐하면, 코멘트 전체가 최초의 */ 그리고 끝나 버리기 때문입니다.

    /* 이 행은 코멘트의 최초로.
       이 행도 코멘트의 일부입니다.
    /* 이 행은, 잘못해 코멘트를 상자로 하려고 하고 있습니다.  */
       이 행은, 이제 코멘트 내부가 아닙니다.  */

C++ 스타일의 코멘트는, 다음의 2 캐릭터로부터 시작됩니다. // (slash와 slash) 그리고, 그 행의 마지막까지가 코멘트로서 계속됩니다. 이 종류의 코멘트는, 복수행에 걸쳐서 계속되지 않습니다. 의미로서는 1 개(살)이지만 복수행에 걸치는 것 같은 코멘트를 쓰고 싶은 경우는, 각 행에 // (을)를 쓰지 않으면 안됩니다. 예를 들면, 다음과 같게입니다 :

    // 이 행은, 코멘트의 시작입니다. 다음의 행은,
    // 새로운 코멘트가 됩니다. 비록, 의미로서는
    // 전의 행의 코멘트의 일부분이어도입니다.

쉘 스타일 (혹은, 기호라면 perl 스타일)의 코멘트는, 다음의 캐릭터로 시작됩니다. # (해시라든지 파운드라든지 번호라든지 넘 기호라든지 어떻게 불러도 좋다) 그리고, C++ 스타일의 코멘트와 같게, 그 행의 끝까지 코멘트가 계속됩니다. 예를 들면, 다음과 같게입니다 :

    # 이 행은, 코멘트의 시작입니다. 다음의 행은,
    # 새로운 코멘트가 됩니다. 비록, 의미로서는
    # 전의 행의 코멘트의 일부분이어도입니다.

주: 존 파일로 쓰도록(듯이),; (세미콜론)(을)를 코멘트의 시작되어에 사용할 수 없습니다. 세미콜론은, 설정 스테이트먼트의 말미를 나타내는 것이므로, 그 뒤로 계속되는 캐릭터는, 무엇으로 저것다음의 스테이트먼트의 선두라면 해석되어 버립니다.

  BIND 4.9.x 로부터 변경한다
BIND 4.9.x 의 설정 파일은, src/bin/named/named-bootconf (이)라는 이름의, BIND 8.2.x 의 소스 킷에 동고 되고 있다 셸 스크립트를 사용하는 것으로 새로운 포맷으로 변환한다 일이 생깁니다.

기술 방법의 정의
다음으로부터 말하고 있는 것은, BIND 설정 파일을 기술하는 동안 사용되는 요소 에 붙어입니다. 1 개의 스테이트먼트로 밖에 결합되지 않는 요소는, 그 스테이트먼트에 대해 말하고 있는 섹션에만 기술이 있습니다.

acl_name
    acl 스테이트먼트로 정의된다 address_match_list 의 명칭입니다.

address_match_list
    ip_addr, ip_prefix, key_id, acl_name 요소가 1 개 또는 그 이상 모인 리스트입니다. 이것에 대해서는, 주소 매치 리스트 의 항으로 말합니다.

dotted-decimal
    닷 (``. '')만으로 단락지어진, 1 개(살) 또는 그 이상의 수의 0 에서 255 까지의 정수입니다. 예를 들면, 123, 45.67, 89.123. 45.67 등입니다.

domain_name
    DNS 명으로서 사용되는 캐릭터 라인을 쿼테이션으로 둘러싼 것입니다. 예를 들면, "my.test.domain" 의 같게입니다.

path_name
    패스명으로서 사용되는 캐릭터 라인을 쿼테이션으로 둘러싼 것입니다. 예를 들면, "zones/master/my.test.domain" 의 같게입니다.

ip_addr
    dotted-decimal 표기로 정확히 4 개의 요소로부터 되는 IP 주소입니다.

ip_port
    IP 포트를 나타낸다 number 입니다. number (은)는, 0 (으)로부터 65535 까지의 값으로 한정되고 있어 그 중 1024 이하의 값은, 전형적으로는, 소유자가 root 의 프로세스에만 제한되고 있습니다. 경우에 따라서는, 적당하게 큰 번호를 선택하도록(듯이), 보충으로서 asterisk 캐릭터 (``*'')(을)를 사용할 수가 있습니다.

ip_prefix
    dotted-decimal 표기로 지정된 IP 네트워크입니다. 그 후에,``/''가 계속되어, 그리고 넷 마스크의 비트수가 계속됩니다. 예를 들면, 127/8 (은)는, 네트워크 127.0. 0.0 그리고, 넷 마스크는 255.0. 0.0 입니다. 1.2. 3.0/28 (은)는 네트워크 1.2. 3.0 그리고, 넷 마스크는 255.255. 255.240 입니다.

key_name
    공유열쇠의 이름을 나타낸 캐릭터 라인입니다. 이것은 트랜잭션(transaction) 보안에 사용합니다.

number
    C 언어에서의 부호 다하고 정수 (32 비트 정수의 머신에서는 2,147,483,647) 의 범위 전체를 취하는, 비부정수입니다. 취할 수 있는 값의 범위는, 사용되는 문맥에 의해 한층 더 제한될지도 모릅니다.

size_spec
    number 또는 단어 unlimited 인가 단어 default 입니다.

    size_spec 의 최대치는, 머신의 부호 없음 long 형 정수의 최대치가 됩니다. unlimited (은)는, 값을 무제한하게 사용할 수 있도록(듯이) 요구하거나 취할 수 있는 최대의 값을 요구하거나 하기 위해서 사용합니다. default (은)는, 서버가 시동했을 때에 유효했던 제한이 사용됩니다.

    number 에는, 다음과 같은 스케일 팩터를 계속할 수도 있습니다 : K 또는 k (은)는 킬로바이트를, M 또는 m (은)는 메가바이트를, 그리고 G 또는 g (은)는 기가바이트를 나타냅니다. 이것들은 각각, 1024, 1024*1024, 1024*1024*1024 배인 것을 나타냅니다.

    스케일 팩터의 변환시에, 정수치의 격납 장소에서 오버플로우가 발생해도, 현재 상태로서는 입다물어 무시합니다. 그 결과, 기대한 결과보다 작은 값, 어쩌면 부의 값에조차 되어 버립니다. 정말로 큰 값을 안전하게 설정하고 싶으면 unlimited (을)를 사용하는 것이 최선의 방법입니다.

yes_or_no
    yes 또는 no 입니다. 혹은 true (와)과 false 그렇다고 하는 단어에서도 받아들입니다. 1 (와)과 0 그렇다고 하는 번호에서도 같습니다.

주소 매치 리스트

  문법

    address_match_list    = 1*address_match_element

    address_match_element = [ "! " ] ( address_match_list /
                                      ip_address / ip_prefix /
                                      acl_name / "key " key_id ) ";"

  정의와 사용법
주소 매치 리스트는, 주로 몇개의 서버의 조작에서의 액세스 제어를 결정하기 위해서(때문에) 사용됩니다. 또, 주소 매치 리스트는, 다른 네임서버에 문의할 때의 우선 순위나, named 하지만 문의를 기다리는 주소를 결정하기 위해서(때문에)도 사용됩니다. 주소 매치 리스트를 구성하는 요소는, 다음 중 어떤 것이기도 할 수 있습니다 :

•   ip-address ( dotted-decimal 표기

•   ip-prefix ('/'에서의 표기)

•   key 스테이트먼트로 정의되었다 key_id

•   먼저 acl 스테이트먼트로 정의된 주소 매치 리스트명

•   다른 address_match_list

요소는, 느낌표 (``! '')로 시작하면(자) 무효로 할 수 있습니다. 또, 주소 매치 리스트명에 any, none, localhost, localnets 하지만 미리 정의되고 있습니다. 리스트명에 관한 새로운 정보는, acl 스테이트먼트의 설명의 곳에 있습니다.

key 마디가 추가된 것에 의해, 이 문법의 원가요소명은 어떤 종류의 오용 (이)가 되어 버리고 있습니다. 왜냐하면, 호스트나 네트워크 주소 에 관계없이, 액세스의 인증에는 인증열쇠를 사용할 수가 있기 때문입니다. 그런데도 아직, 이 문서를 통해 「주소 매치 리스트」라고 한다 용어가 사용되고 있습니다.

주어진 IP 주소 또는 프레픽스가 주소 매치 리스트와 비교될 때는, 요소가 합치할 때까지 리스트를 스캔 해 갈 것입니다. 합치한 것을 어떻게 해석할까는, 액세스 제어, listen-on 포트 정의, 또는 위상기하학의 어느 용도에 리스트를 사용했는지, 또 그 요소가 무효로 되고 있었는지로 결정합니다.

액세스 제어 리스트로서 주소 매치 리스트가 사용되는 경우, 합치한 요소가 무효로 되어 있지 않을 때는 액세스를 허가해, 무효가 되어 있을 때는 액세스를 금지합니다. 주소 매치 리스트중에 합치하는 것이 1 개(살)도 없는 경우에는, 액세스는 금지됩니다. allow-query, allow-transfer, allow-update, allow-recursion, blackhole 마디는 모두 이와 같이 주소 매치 리스트를 사용합니다. 같이 listen-on 옵션을 사용하면(자), 리스트에 합치하지 않는 머신의 주소에서의 문의는, 모두 서버가 받지 않게 됩니다.

topology 옵션과 함께 주소 매치 리스트가 사용되는 경우, 합치한 요소가 무효로 되어 있지 않은 경우, 리스트중에서 합치한 위치에 근거한 거리가 돌려주어집니다 (합치한 개소가 리스트의 선두에 가까우면 그 만큼, 서버와의 사이의 거리는 짧게 됩니다). 합치한 요소가 무효가 되어 있는 경우, 서버로부터 무엇보다 먼 거리를 할당할 수 있게 되겠지요. 합치하는 것이 없었던 경우는, 그 주소에는, 무효로 되어 있지 않은 리스트 요소보다는 멀고, 무효가 되어 있는 요소보다는 가까운 거리가 돌려주어지겠지요.

퍼스트 매치 알고리즘을 사용하고 있기 때문에, 리스트중에서 다른 요소의 부분집합을 정의하고 있는 요소 쪽이, 보다 넓은 범위의 정의를 하고 있는 요소보다, 먼저 정의해야 합니다. 이것은, 어느 쪽인지 한편의 요소가 무효 (이)가 되어 있든지 있지 않든지가 관계 없습니다. 예를 들면,
    1.2. 3/24;! 1.2. 3.13
그럼, 1.2. 3.13 이라고 하는 요소는 무의미합니다. 왜냐하면, 이 알고리즘에서는, 1.2. 3.13 의 검색을 1.2. 3/24 그렇다고 하는 요소에 합치 해 버리기 때문입니다.
    ! 1.2. 3.13; 1.2. 3/24
(을)를 사용하면(자), 1.2. 3.13 은 요소가 무효가 되어 있는 것으로 거부됩니다만, 그 외의 1.2. 3. * 의 호스트는 그냥 지나침이 되기 때문에, 이 문제를 회피할 수 있습니다.

logging 스테이트먼트

  문법

    logging {
      [ channel channel_name {
        ( file path_name
           [ versions ( number | unlimited ) ]
           [ size size_spec ]
         | syslog ( kern | user | mail | daemon | auth | syslog | lpr |
                    news | uucp | cron | authpriv | ftp |
                    local0 | local1 | local2 | local3 |
                    local4 | local5 | local6 | local7 )
         | null );

        [ severity ( critical | error | warning | notice |
                     info  | debug [ level ] | dynamic ); ]
        [ print-category yes_or_no; ]
        [ print-severity yes_or_no; ]
        [ print-time yes_or_no; ]
      }; ]

      [ category category_name {
        channel_name; [ channel_name; ... ]
      }; ]
      ...
    };

  정의와 사용법
logging 스테이트먼트는, 네임서버에 대한 여러가지 종류의 로그용 옵션을 설정합니다. 그 중의 channel 프레이즈에서는, 출력 방법과 포맷 옵션과 중대도를 이름과 묶습니다. 이 이름은 다음에 category 프레이즈로 사용해, 여러가지 메세지 클래스를 어떻게 로그에 떨어뜨리는지를 선택합니다.

다만 1 개(살)의 logging 스테이트먼트를 사용해, 바랄 뿐(만큼) 많은 채널과 카테고리를 정의할 수 있습니다. 설정중에, 복수의 logging 스테이트먼트가 있었을 경우, 최초 이외의 logging 스테이트먼트에 대해서는 경고가 나옵니다. logging 스테이트먼트가 1 개나 존재하지 않았던 경우, 로그용의 설정은 다음과 같이 되겠지요 :

        logging {
            category default { default_syslog; default_debug; };
            category panic { default_syslog; default_stderr; };
            category packet { default_debug; };
            category eventlib { default_debug; };
        };

로그용의 설정은, logging 스테이트먼트가 퍼스 되자 마자 확립됩니다. 만약, 설정 파일 전체의 처리 상황에 대한 메세지를 리디렉트 하고 싶은 것이면, logging 스테이트먼트가 최초로 나오도록(듯이) 하지 않으면 안됩니다. 비록, 설정 파일의 퍼스 상황을 나타내는 메세지를 리디렉트 하고 싶지 않아도, logging 스테이트먼트는 파일의 선두에 두는 것을 권합니다. 그렇게 하는 것에 의해, 파서가 내는 메세지를 재차 설정할 필요가 생겼을 때에, 의식해 이 룰을 생각해 낼 필요가 없어집니다.

  채널 프레이즈
로그의 출력은 모두, 1 개(살) 또는 그 이상의 「채널」로 건넙니다. 채널은 좋아할 뿐(만큼) 만들 수가 있습니다.

각각의 채널의 정의에는, 그 채널용으로 선택한 메세지가 파일에 떨어뜨려지는지, 특별한 syslog 퍼실리티에게 건네지는지, 또는, 버려지는지를 지정하는 마디가 포함되지 않으면 안됩니다. 채널의 정의에서는, 채널이 받는 메세지의 중대도를 제한한다 일도 옵션으로 완성됩니다 (디폴트는 info 입니다). 또, named 하지만 생성하는 타임 스탬프와 카테고리명과 중대도를 포함하는지 어떤지를 제한할 수도 있습니다. 디폴트에서는, 이 3 개(살)의 모두 포함하지 않게 되어 있습니다.

채널에 대한 로그의 발송지의 옵션에 null 그렇다고 하는 단어를 사용하면(자), 그 채널에 보내지는 메세지는 모두 버려지게 됩니다. 채널에 대한 그 외의 옵션은 의미가 없습니다.

file 마디를 사용하면(자), 로그 파일이 얼마나 커져도 좋을것인가 라고 하는 일과 로그 파일이 오픈될 때 마다 몇개의 버젼을 남기는가 하는 것에 관한 제한을, 수중에 넣을 수가 있습니다.

로그 파일에 대한다 size 옵션은, 단순하게 로그가 커지는 것을 제한하는 단단한 천정이 되는 것입니다. 로그 파일이 size 를 넘으면(자), 로그 파일이 재차 오픈될 때까지 named (은)는 파일에 아무것도 기입하지 않습니다. size 를 넘고 있어도, 자동적으로는 파일은 오픈되지 않습니다. 디폴트에서는, 로그 파일의 사이즈 제한은 없습니다.

로그 파일 옵션에 versions (을)를 사용하면(자), named (은)는, 로그 파일이 오픈될 때 파일의 백업 버젼의 이름을 변경해, 지정한 수만큼 보관 유지합니다. 예를 들면, lamers.log 라고 하는 파일의 낡은 버젼을 3 개 보관 유지하도록(듯이) 선택했을 경우, lamer.log 가 오픈된다 직전에 lamers.log. 1 이라고 하는 파일은 lamers.log. 2 라는 이름으로 변경되어 lamers.log. 0 이라고 하는 파일은 lamers.log. 1 이라는 이름으로 변경되고 그리고 lamers.log 라고 하는 파일이 lamers.log. 0 이라는 이름으로 변경됩니다. 순회 버젼은 디폴트에서는 보관 유지되지 않습니다. 벌써 존재하고 있는 로그 파일은, 다만 단지 추가해 쓰여집니다. unlimited 키워드는, 현재의 BIND 의 릴리스에서는 99 (와)과 동의입니다. size 및 versions 옵션의 사용예는 다음과 같습니다 :

        channel an_example_level {
            file "lamers.log" versions 3 size 20m;
            print-time yes;
            print-category yes;
        };

syslog 마디의 인수는, syslog(3) 메뉴얼 페이지에 기술되고 있는 syslog 퍼실리티를 나타냅니다. syslogd 하지만 이 퍼실리티에 보내지는 메세지를 어떻게 취급할까에 대해서는, syslog.conf(5) 메뉴얼 페이지에 기술이 있습니다. openlog() 함수에 2 개의 인수 밖에 사용하지 않는, 매우 낡은 버젼의 syslog 를 사용하고 있는 시스템을 사용의 경우는, 이 마디는 입다물어 무시됩니다.

severity 마디는, syslog 의 「우선도」와 같이 일합니다. 다만, syslog 를 사용하는 대신에 파일을 직접 써도 사용할 수 있는 곳(중)이 다릅니다. 주어진 중대도보다 낮은 레벨의 메세지는, 이 채널에 대해서는 선택되지 않습니다. 주어진 중대도 보다 높은 레벨의 메세지가 받아 들여집니다.

syslog 를 사용하고 있는 경우, syslog.conf 에서의 우선도에 의해도 최종적으로 무엇이 빠져 나갈지가 결정됩니다. 예를 들면, 채널의 퍼실리티 및 중대도를 daemon 및 debug 에 정의하고 있지만, syslog.conf 그럼 daemon.warning 밖에 로그에 떨어뜨리지 않게 하고 있는 경우, info 및 notice 의 중대도를 가진 메세지는 버려져 버립니다. 상황이 거꾸로 되어, named 하지만 warning 인가 그 이상의 중대도를 가진 메세지 밖에 써서내지 않게 되어 있는 경우, syslogd (은)는, 그 채널로부터 받은 메세지를 모두 써내겠지요.

디버그 모드가 되어 있는 경우, 서버는 좀 더 많은 디버그 정보를 제공할 수 있습니다. 서버의 디버그 레벨이 0 보다 커지고 있으면, 디버그 모드는 유효하게 되어 있습니다. 전체에서의 디버그 레벨은, -d 플래그에 정의 정수치를 계속해 지정해 named 서버를 개시하는지, 또는, 움직이고 있는 서버에 SIGUSR1 시그널을 보낸다 (예를 들면, ndc trace (을)를 사용해) 것에 의해 설정합니다. 전체에서의 디버그 레벨은 0 에도 설정할 수 있어 이 때는, 디버그 모드는 무효가 됩니다. 이 상태에는, 서버에 SIGUSR2 시그널을 보낸다 ( ndc notrace (을)를 사용해) 것에 의해도 할 수 있습니다. 서버에서의 디버그 메세지에는 모두 디버그 레벨이 있습니다. 그리고, 디버그 레벨이 높을 정도(수록)보다 상세한 출력이 되어 있습니다. 예를 들면, 특정의 디버그 중대도를 다음과 같이 지정한 채널 그럼, 서버가 디버그 모드이면 언제라도, 레벨 3 또는 그것 이하의 레벨의 디버그 출력을 얻을 수 있습니다.

        channel specific_debug_level {
            file "foo";
            severity debug 3;
        };

그것은, 전체에서의 디버그 레벨에는 의선. dynamic 중대도를 지정한 채널에서는, 어느 메세지를 출력할까를 결정하기 위해서(때문에) 서버 전체의 디버그 레벨을 사용합니다.

print-time 하지만 온이 되어 있으면, 일자 및 시각이 로그에 떨어뜨려집니다. print-time (은)는, syslog 채널에 대해서도 지정할 수 있습니다만, 통상은 의미가 없는 것입니다. 왜냐하면, syslog 도 일자 및 시각은 출력하기 때문입니다. print-category 하지만 요구되고 있는 경우, 메세지의 카테고리도 이와 같이 로그에 떨어뜨려집니다. 마지막으로, print-severity 하지만 온이 되어 있으면, 메세지의 중대도가 로그에 떨어뜨려집니다. print- 옵션은 어떤 편성에서도 사용할 수가 있어 항상 다음과 같은 차례로 출력됩니다 : 그것은 time, category, severity 의 순서입니다. 다음에 나타내는 예는, 3 개(살) 모든 print- 옵션을 온으로 한 예입니다 :

        28-Apr-1997 15:05:32. 863 default: notice: Ready to answer queries.

디폴트의 로그 취득용으로 사용되는 채널에는, 다음과 같은, 사전에 정의된 4 개가 있습니다. 어떻게 이 채널을 사용하는지에 붙어 차절 category 프레이즈 에 기술이 있습니다.

        channel default_syslog {
            syslog daemon;       # syslog 의 daemon 퍼실리티에 보낸다
            severity info;       # 우선도가 info 및 그 이상의 것만 보낸다
        };

        channel default_debug {
            file "named.run";    # 작업 디렉토리내의 named.run 파일에
                                 # 기입한다
                                 # 주 : 서버가 -f 옵션 돌출하고 개시되고 있다
    			     # 경우는,"named.run" 대신에 표준 에러
                                 # 출력이 사용됩니다.
            severity dynamic;    # 서버의 현재의 디버그 레벨로 로그에 떨어뜨린다
        };

        channel default_stderr { # 표준 에러 출력에 써낸다
            file "<stderr>";     # 여기에서는, 보이도록(듯이) 썼을 뿐입니다. 현재,
                                 # 내부의 파일 기술자를 설정 파일의
                                 # 문중에 기술하는 방법은 없습니다.
            severity info;       # 우선도가 info 및 그 이상의 것만 보낸다
        };

        channel null {
            null;                # 이 채널에 보내진 메세지는 보고튕긴다
        };

일단 채널이 정의되면(자), 재설정은 할 수 없습니다. 그 때문에, 편입의 채널은 직접 변경할 수 없는 것입니다. 그러나, 정의한 채널에서의 카테고리를 지시하는 것에 의해, 디폴트의 로그용 기능을 변경할 수가 있습니다.

  category 프레이즈
카테고리는 많이 있습니다. 그 때문에, 보고 싶다고 생각하는 로그를 어디든지 보낸다 일이 생겨 보고 싶지 않은 로그는 보고있고로 끝낼 수가 있습니다. 카테고리에 대해서 채널의 리스트를 지정하지 않았던 경우는, 대신에 default 카테고리에 로그가 보내집니다. default 카테고리를 지정하지 않았던 경우, 다음과 같은 「디폴트의 default 카테고리」가 사용됩니다 :

        category default { default_syslog; default_debug; };

예로서 보안의 이벤트를 파일에 로그로서 떨어뜨리고 싶지만, 디폴트의 로깅의 거동은 유지하고 싶다고 합시다. 그렇다면, 다음과 같이 지정하게 되겠지요 :

        channel my_security_channel {
            file "my_security_file";
            severity info;
        };
        category security { my_security_channel;
                            default_syslog; default_debug; };

카테고리내의 모든 메세지를 버리려면 , null 채널을 지정해 주세요 :

        category lame-servers { null; };
        category cname { null; };

다음과 같은 카테고리가 사용 가능합니다 :

default
    모두 잡습니다. 많은 메세지가 아직 카테고리 나누고 되지 않고, 모두 여기서 잡힙니다. 게다가 카테고리에 대해서 어떤 채널도 지정하지 않았던 경우, 대신에 default 카테고리가 사용됩니다. default 카테고리를 지정하지 않았던 경우, 다음과 같은 정의가 사용됩니다 :
        category default { default_syslog; default_debug; };

config
    하이레벨의 설정 파일 처리입니다.

parser
    로 레벨의 설정 파일 처리입니다.

queries
    서버가 받은 문의 각각 대해, 짧은 로그 메세지를 생성합니다.

lame-servers
    ``Lame server on ...''라고 하는 것 같은 메세지입니다.

statistics
    통계입니다.

panic
    서버 내부의 문제로 서버 자체가 셧다운 하지 않으면 안 되게 되면(자), 문제가 일어난 원의 카테고리와 이 카테고리의 양쪽 모두에, 문제를 로그로서 써 넣습니다. panic 카테고리를 정의하고 있지 않는 경우에는, 다음과 같은 정의가 사용됩니다 :
        category panic { default_syslog; default_stderr; };

update
    동적인 갱신입니다.

ncache
    네가티브 캐싱입니다.

xfer-in
    서버가 받고 있는 존 전송입니다.

xfer-out
    서버가 보내고 있는 존 전송입니다.

db  모든 데이타베이스의 조작입니다.

eventlib
    이벤트 시스템으로부터의 디버그 정보입니다. 이 카테고리에는, 다만 1 개(살)의 채널을 지정할 수 있어 그 채널은 파일 채널이 아니면 안됩니다. eventlib 카테고리를 지정하지 않는 경우는, 다음과 같은 정의가 사용됩니다 :
        category eventlib { default_debug; };

packet
    받은 패킷 및 보낸 패킷의 덤프입니다. 이 카테고리에는, 다만 1 개의 채널을 지정할 수 있어 그 채널은 파일 채널이 아니면 되지 않습니다. packet 카테고리를 지정하지 않는 경우는, 다음과 같은 정의가 사용됩니다 :
        category packet { default_debug; };

notify
    NOTIFY 프로토콜입니다.

cname
    ``... points to a CNAME''와 같은 메세지입니다.

security
    허가된 / 허가되지 않았던 리퀘스트입니다.

os  operating system의 문제입니다.

insist
    내부의 정합성 체크의 실패입니다.

maintenance
    정기적에 행해지는 메인트넌스의 이벤트입니다.

load
    존에의 로드 메세지입니다.

response-checks
    응답의 체크로부터 발생하는 메세지입니다. 예를 들면, ``Malformed response ...'', ``wrong ans. name ...'', ``unrelated additional info ...'', ``invalid RR type ...'', ``bad referral ...''라고 한 것입니다.

options 스테이트먼트

  문법

    options {
      [ hostname hostname_string; ]
      [ version version_string; ]
      [ directory path_name; ]
      [ named-xfer path_name; ]
      [ dump-file path_name; ]
      [ memstatistics-file path_name; ]
      [ pid-file path_name; ]
      [ statistics-file path_name; ]
      [ auth-nxdomain yes_or_no; ]
      [ deallocate-on-exit yes_or_no; ]
      [ dialup yes_or_no; ]
      [ fake-iquery yes_or_no; ]
      [ fetch-glue yes_or_no; ]
      [ has-old-clients yes_or_no; ]
      [ host-statistics yes_or_no; ]
      [ host-statistics-max number; ]
      [ multiple-cnames yes_or_no; ]
      [ notify ( yes_or_no | explicit ); ]
      [ suppress-initial-notify yes_or_no; ]
      [ recursion yes_or_no; ]
      [ rfc2308-type1 yes_or_no; ]
      [ use-id-pool yes_or_no; ]
      [ treat-cr-as-space yes_or_no; ]
      [ also-notify yes_or_no; ]
      [ forward ( only | first ); ]
      [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]
      [ check-names ( master | slave | response ) ( warn | fail | ignore ); ]
      [ allow-query { address_match_list }; ]
      [ allow-recursion { address_match_list }; ]
      [ allow-transfer { address_match_list }; ]
      [ blackhole { address_match_list }; ]
      [ listen-on [ port ip_port ] { address_match_list }; ]
      [ query-source [ address ( ip_addr | * ) ]
                     [ port ( ip_port | * ) ] ; ]
      [ lame-ttl number; ]
      [ max-transfer-time-in number; ]
      [ max-ncache-ttl number; ]
      [ min-roots number; ]
      [ serial-queries number; ]
      [ transfer-format ( one-answer | many-answers ); ]
      [ transfers-in  number; ]
      [ transfers-out number; ]
      [ transfers-per-ns number; ]
      [ transfer-source ip_addr; ]
      [ maintain-ixfr-base yes_or_no; ]
      [ max-ixfr-log-size number; ]
      [ coresize size_spec ; ]
      [ datasize size_spec ; ]
      [ files size_spec ; ]
      [ stacksize size_spec ; ]
      [ cleaning-interval number; ]
      [ heartbeat-interval number; ]
      [ interface-interval number; ]
      [ statistics-interval number; ]
      [ topology { address_match_list }; ]
      [ sortlist { address_match_list }; ]
      [ rrset-order { order_spec ; [ order_spec ; ... ] }; ]
      [ preferred-glue ( A | AAAA ); ]
    };

  정의 및 사용법
options 스테이트먼트는 BIND 로 사용되는 글로벌 옵션을 설정합니다. 이 스테이트먼트는, 설정 파일중에서 1 번만 출현할 수 있습니다. 만약 복수의 스테이트먼트가 출현했을 경우는, 최초로 출현한 스테이트먼트가 실제로 사용되는 옵션을 결정해, 경고를 합니다. options 스테이트먼트가 존재하지 않는 경우는, 각 옵션이 디폴트로 설정된 options 블록이 사용됩니다.

  서버 정보

hostname
    이 디폴트는, 네임서버를 제공하고 있는 머신의 호스트명을, gethostname()의 실행 결과의 형식에서 줍니다. 제 1 의 목적은, 다수의 이탈리아 국연탄화수소공사-캐스트 서버의 어떤 것이 실제로 문의해에 대답하고 있는지를 식별할 수 있도록(듯이) 하는 것입니다. chaos 클래스의 hostname.bind 의 텍스트 문의를 이탈리아 국연탄화수소공사-캐스트 서버에 송신해, 일의인 이름을 얻는 것에 의해, 이것을 실현합니다. in class chaos to the anycast server and geting back a unique name. hostname 를 공문자열 ("")로 설정하면(자), 문의의 처리를 무효화합니다.

version
    ndc 명령의 문의나 chaos 클래스의 version.bind 이름의 문의를 통해 서버가 리포트해야 할 버젼입니다. 디폴트에서는 서버의 진짜 버젼 번호가 되어 있습니다만, 서버의 오퍼레이터중에는 이 캐릭터 라인이 기호라고 하는 사람도 있습니다 ( 물론 농담으로 정해져 있습니다만 ).

  패스명

directory
    서버의 작업 디렉토리입니다. 설정 파일중의 절대 패스가 아니다 패스명은, 어떤 것이라도 이 디렉토리로부터의 상대 패스라고 수취됩니다. 대부분의 서버의 출력 파일 (예를 들면, named.run) 의 디폴트의 두는 곳소는, 이 디렉토리입니다. 만약, 디렉토리의 지정이 없으면, 작업 디렉토리는 디폴트로 ~. (이)가 됩니다. 이 디렉토리는, 서버가 기동한 디렉토리입니다. 지정된 디렉토리는 절대 파스가 아니면 쓸 만하지 않습니다.

named-xfer
    내부에의 존 전송용으로 서버가 사용하는 named-xfer 프로그램에의 패스명입니다. 지정되어 있지 않은 경우의 디폴트는, 시스템 의존입니다 (예를 들면, /usr/sbin/named-xfer 입니다).

dump-file
    SIGINT 시그널을 서버가 받았을 때 ( ndc dumpdb 하지만 보냈을 경우와 같이)에, 데이타베이스의 덤프를 떨어뜨리는 파일에의 패스명입니다. 지정되어 있지 않은 경우의 디폴트는, named_dump.db 입니다.

memstatistics-file
    deallocate-on-exit 하지만 yes (이)가 되어 있는 경우에, 서버가 종료시에 메모리 사용 통계를 써내는 파일에의 패스명입니다. 지정되어 있지 않은 경우의 디폴트는, named.memstats 입니다.

pid-file
    서버가 자신의 프로세스 ID 를 써내는 파일에의 패스명입니다. 지정되어 있지 않은 경우의 디폴트는, operating system에 의존합니다만, 통상은, /var/run/named.pid 혹은 /etc/named.pid 입니다. pid-file 는, ndc (와)과 같은, 동작하고 있는 네임서버에 시그널을 보내고 싶다 프로그램이 사용합니다.

statistics-file
    서버가 SIGILL 시그널을 ( ndc stats (으)로부터) 받았을 경우에, 통계를 추가 기입하는 파일에의 패스명입니다. 지정되어 있지 않은 경우의 디폴트는, named.stats 입니다.

  불리언 값의 옵션

auth-nxdomain
    이것이 yes 의 경우, AA 비트는, 항상 NXDOMAIN 의 응답에 세트 됩니다. 비록 서버를 실제로는 신뢰할 수 있는 것에서는 없어도입니다. 디폴트에서는, yes (이)가 되어 있습니다. 옛부터 있는 소프트웨어가 싫어 하므로, 자신이 하고 있는 것에 확신을 가질 수 없고 있다면, auth-nxdomain (을)를 오프으로서는 안됩니다.

deallocate-on-exit
    이것이 yes 의 경우에는, 서버는, 종료시에 자신이 확보한 오브젝트를 철저히 해 해방해, memstatistics-file 에 메모리 사용 리포트를 써냅니다. 디폴트에서는, no (이)가 되어 있습니다. 왜냐하면, operating system에 클린 업을 시키는 편이 고속이기 때문에입니다. deallocate-on-exit (은)는, 메모리 리크를 검출하기 위해서 편리합니다.

dialup
    이것이 yes 의 경우에는, 서버는, 모든 존을, 요구시 다이얼에 의한 다이얼 업 링크를 통해 존 전송을 실시해 있는 것과 같게 취급합니다. 이 다이얼 업 링크는, 이 서버로부터 통신이 시작되었을 경우에 시작할 수 있는 것입니다. 이것은, 존의 종류에 따라서 다른 효과를 가져와, 존의 메인트넌스에 전념할 수 있게 됩니다. 이것에 의해, heartbeat-interval 마다 1 번, 아무쪼록, 1 회의 호출동안이라고 하는 짧은 간격으로 존의 메인트넌스를 실시할 수 있게 됩니다. 이 옵션은 또, 통상의 존 메인트넌스에 걸리는 트래픽을 얼마인가 억제할 수도 있습니다. 디폴트는, no 입니다. dialup 옵션은, zone 스테이트먼트중에서도 지정할 수가 있습니다. 이 경우는, options dialup 스테이트먼트는 덧쓰기됩니다.

    존이 master 인 경우, 서버는, 모든 슬레이브에 대해서 NOTIFY 리퀘스트를 송신하게 됩니다. 이것에 의해, 슬레이브를 체크해, 호출이 살아 있는 동안에 슬레이브가 존을 검증할 수 있도록(듯이) 하는 것으로, 존을 최신의 것으로 하는 계기가 생깁니다 (서버가 NOTIFY (을)를 서포트하는 경우입니다).

    존이 slave 혹은 stub 인 경우, 서버는, 통상의 존의 업데이트 문의를 억제해, heartbeat-interval 하지만 마감 시간이 되었을 때만 문의하도록(듯이) 합니다.

fake-iquery
    이것이 yes 의 경우, 서버는, IQUERY 그렇다고 한다, 이제 낡아져 사용되지 않은 DNS 문의를 시뮬레이션 합니다. 디폴트는 no 입니다.

fetch-glue
    이것이 yes 의 경우 (디폴트에서는 그렇습니다), 서버는, 추가의 응답용 데이터 섹션을 만들려면 가지고 있지 않은 「풀」이 되는 리소스 레코드를 취득합니다. 서버의 캐쉬가 커지거나 파괴 되거나 하지 않게 하기 위한(해) (이렇게 되면, 클라이언트로부터도 와 많은 일이 요구된다고 한다 대상을 지불하게 됩니다), fetch-glue no (은)는, recursion no (와)과 함께 사용할 수 있습니다.

has-old-clients
    이 옵션을 yes (으)로 설정하는 것으로, 다음의 3 개의 옵션을 설정하는 것으로는 등가입니다 : auth-nxdomain yes;, maintain-ixfr-base yes;, rfc2308-type1 no; has-old-clients (을)를 auth-nxdomain, maintain-ixfr-base, rfc2308-type1 (와)과 함께 사용하는 것으로 일어나는 것은, 지정의 차례로 따릅니다.

host-statistics
    이것이 yes 인 경우, 네임서버와 서로 작용하는 각 호스트에 대해서 통계가 보관 유지됩니다. 디폴트에서는 no 입니다. 주: host-statistics (을)를 온으로 하면(자), 방대한 양의 메모리를 소비할 가능성이 있습니다.

maintain-ixfr-base
    이것이 yes 의 경우, 모든 동적으로 갱신되는 존에 대해서, 단일의 IXFR 데이타베이스 파일이 보관 유지됩니다. 이것을 유효하게 하면(자), 존 전송을 매우 고속화 가능한 IXFR 문의에, 서버는 대답합니다. 디폴트는 no 입니다.

multiple-cnames
    이것이 yes 인 경우, 1 개의 도메인명에 대해 복수의 CNAME 리소스 레코드나 허가됩니다. 디폴트는 no 입니다. 복수의 CNAME 레코드를 허가한다고 하는 것은, 표준으로부터는 빗나가고 있어 추천 되는 것이 아닙니다. 이전의 버젼의 BIND 가 복수의 CNAME 레코드를 가지는 것을 허락하고 있어 이 레코드가 몇개의 사이트에서는 부하의 밸런스를 취하기 위해서(때문에) 사용되고 있던 것으로부터, 복수의 CNAME 의 서포트를 이용할 수 있다고 하는 것입니다.

notify
    이것이 yes 인 경우 (그것이 디폴트입니다), 변경을 실시하기 위해서(때문에) 존 서버를 신뢰할 수 있는 경우에 DNS NOTIFY 메세지를 보내게 됩니다. NOTIFY 를 사용하면(자), 마스터 서버와 그 슬레이브와의 사이의 수습이 앞당겨집니다. NOTIFY 메세지를 받아들여, 이해하는 슬레이브 서버는 그 존용으로 마스터 서버에 접속해, 존 전송을 실시할 필요가 있을까를 점검합니다. 그리고, 필요가 있는 경우는 즉시 존 전송을 개시합니다. explicit 의 경우, DNS NOTIFY 메세지는 also-notify 리스트중의 주소 에 대해서만 송신됩니다. notify 옵션은 zone 스테이트먼트내에서도 지정할 수 있습니다. 이 경우는, options notify 스테이트먼트는 덧쓰기됩니다.

suppress-initial-notify
    이것이 yes 의 경우, 서버가 최초로 로드할 때의 최초의 통지 메세지를 억제합니다. 디폴트에서는, no 입니다.

recursion
    이것이 yes (이어)여, DNS 의 문의가 재귀 처리를 요구하고 있는 경우, 서버는 그 문의에 답하기 위해서(때문에) 필요한 일을 모두 실시하려고 합니다. recursion 가 온으로 되어 있지 않은 경우, 서버가 대답을 모르는 경우는, 서버는 클라이언트에 조회를 돌려줍니다. 디폴트에서는, yes 입니다. 전술의 fetch-glue 도 참조해 주세요.

rfc2308-type1
    이것이 yes 이면, 서버는, 부정 응답용으로 SOA 레코드와 함께 NS 레코드를 보냅니다. 만약, 낡은 BIND 서버를 가지고 있어, SOA 와 NS 의 양쪽 모두를 포함한 부정 응답을 이해하지 않는 포워드용 서버로서 사용해 있는 경우나, 낡은 버젼의 sendmail 를 가지고 있는 경우는, 이 옵션을 no 로 설정할 필요가 있습니다. 올바른 해결책은, 그러한 망가진 서버나 sendmail 를 사용하지 않는 것입니다. 디폴트에서는, 이 옵션은 no 입니다.

use-id-pool
    이것이 yes 이면, 서버는 자기 자신의 미해결의 문의 ID 를 추적해, 중복을 피해 랜덤성을 높이도록(듯이) 합니다. 이것에 의해, 서버가 128 KB 나 많이 메모리를 소비하게 됩니다. 디폴트는 no 입니다.

treat-cr-as-space
    이것이 yes 의 경우, 서버는, 스페이스나 탭을 취급하는 것과 같은 방법으로 CR 캐릭터를 취급하도록(듯이) 됩니다. NT 혹은 DOS 머신으로 생성한 존 파일을 UNIX 시스템상에 로드할 때, 이 옵션은 필요하겠지요. 디폴트에서는, 이 옵션은 no 입니다.

  Also-Notify
also-notify

존의 새로운 카피가 로드 될 때는 언제라도 송신되었다 NOTIFY 메세지도 받아들이는 IP 주소의 글로벌 리스트를 정의합니다. 이 옵션은, 존의 카피가 재빠르게 「비밀의」서버상에서 확실히 수습 하는 도움이 됩니다. also-notify 리스트가 zone 스테이트먼트로 주어졌을 경우, options also-notify 스테이트먼트는 덧쓰기됩니다. zone notify 스테이트먼트가 no (으)로 설정되어 있는 경우, 글로벌의 also-notify 리스트의 IP 주소는, 이 존에 대한 NOTIFY 메세지를 송신되지 않습니다. 디폴트에서는, 이 리스트는 하늘입니다 (글로벌인 notification 리스트는 없다고 하는 것입니다).

  포워드
포워드 기능은, 소수의 서버상에서 큰 사이트 단위의 캐쉬를 작성한다 위해(때문에) 사용할 수가 있습니다. 이것에 의해, 외부의 네임서버에의 링크를 넘은 트래픽을 경감할 수 있습니다. 포워드 기능은, 직접 인터넷에 접속할 수 없지만, 어쨌든 외부의 호스트명을 찾아내고 싶다 그렇다고 하는 서버의 문의를 허가하기 위해서도 사용할 수 있습니다. 포워드가 발생하는 것은, 그러한 문의에 대해서 서버가 권한을 가지지 않고, 캐쉬에 그 응답이 들어가 있지 않은 경우 뿐입니다.

forward
    이 옵션은, forwarders 리스트가 하늘이 아닌 경우에만 의미가 있습니다. first 그렇다고 하는 값이 디폴트입니다만, 이 때 서버는, 우선 포워드를 실시하는 서버에 문의를 실시해, 포워드를 실시하는 서버가 요구에 대해서 응답하지 않는 경우, 스스로 응답을 찾습니다. only 하지만 지정되었을 경우, 서버는, 다만 포워드를 실시하는 서버에 문의를 실시할 뿐입니다.

forwarders
    포워드를 실시하기 위해서(때문에) 사용되는 IP 주소를 지정합니다. 디폴트에서는, 이것은 하늘의 리스트입니다 (포워드를 실시하지 않습니다).

포워드 기능은, 존 단위를 기초로 해 설정할 수도 있습니다. 이 때는, 글로벌의 포워드용 옵션이, 다양한 방법으로 덧쓰기할 수 있게 됩니다. 특정의 존에 대해, 다른 포워드용 서버를 사용하거나 다른 forward only/first (이)가 거절하지 않든지를 갖게 하거나 혹은 전혀 포워드 하지 않기도 하고 할 수 있습니다. 새로운 정보에 대해서는, 존 스테이트먼트 의 섹션을 참조해 주세요.

BIND 8 의 장래의 버젼에서는, 좀 더 강력한 포워드용 시스템을 제공할 예정입니다. 먼저 말한 문법은 계속해 서포트될 예정입니다.

  네임 체크
서버는, 기대하는 클라이언트의 관계에 근거해 도메인명을 체크할 수 있습니다. 예를 들면, 호스트명으로서 사용되는 도메인명은, 정당한 호스트명을 정의하고 있는 RFC 에 준거하는가 하는 점으로 체크됩니다.

체크 방법에는 3 방법의 방식이 이용 가능합니다 :

ignore
    어떤 체크도 행해지지 않습니다.

warn
    기대하는 클라이언트의 관계로부터 이름을 체크합니다. 부정한 이름은 로그에 쓰여집니다만, 처리는 보통으로 계속합니다.

fail
    기대하는 클라이언트의 관계로부터 이름을 체크합니다. 부정한 이름은 로그에 쓰여져 룰에 맞지 않는 데이터는 거부됩니다.

서버는, 이름을 3 개의 에리어에서 체크할 수 있는 : 마스터 존 파일, 슬레이브 존 파일, 그리고, 서버가 발행한 문의에의 응답 입니다. check-names response fail 하지만 지정되어 있어 클라이언트의 문의에 대한 응답이 클라이언트에 부정한 이름을 보낼 필요가 있는 것이었을 경우, 서버는, REFUSED 응답 코드를 클라이언트에 보냅니다.

디폴트는, 다음과 같습니다 :

        check-names master fail;
        check-names slave warn;
        check-names response ignore;

check-names (은)는, zone 스테이트먼트에서도 지정할 수 있습니다. 이 경우, options check-names (은)는 덧쓰기됩니다. zone 스테이트먼트로 사용했을 경우, 에리어는 지정되지 않습니다 (왜냐하면, 존의 종류로부터 에리어는 추측할 수 있다 (으)로부터입니다).

  액세스 제어
서버에의 액세스는, 액세스를 요구한 시스템의 IP 주소 또는 공유 비밀열쇠에 근거해 제한할 수가 있습니다. 액세스 기준을 어떻게 지정할까에 대한 자세한 것은, 주소 매치 리스트 (을)를 참조해 주세요.

allow-query
    어느 호스트가 통상의 문의를 할 수가 있는지를 지정합니다. allow-query (은)는, zone 스테이트먼트에서도 지정할 수 있습니다. 이 경우, options allow-query 스테이트먼트를 덧쓰기합니다. 만약, allow-query 옵션이 지정되어 있지 않은 경우는, 디폴트는, 모든 호스트로부터의 문의를 허가합니다.

    allow-recursion
        어느 호스트가 재귀적인 문의가 가능한가를 지정합니다. 지정되어 있지 않은 경우는, 디폴트에서는 모든 호스트로부터 재귀적인 문의를 할 수 있습니다.

    allow-transfer
        어느 호스트가 존 전송을 서버로부터 받는 것을 허가될까를 지정합니다. allow-transfer (은)는, zone 스테이트먼트에서도 지정할 수 있습니다. 그 경우, options allow-transfer 스테이트먼트는 덧쓰기됩니다. 만약, allow-transfer 옵션이 지정되어 있지 않은 경우는, 디폴트에서는, 모든 호스트로부터의 전송을 허가합니다.

    blackhole
        서버가 문의를 받아들이지 않게 되거나 문의를 해결하기 위해서 사용하지 않게 되는 주소의 리스트를 지정합니다. 이러한 주소로부터의 문의는, 응답될 것은 없습니다.

  인터페이스
서버가 문의에 답하는 인터페이스 및 포트는, listen-on 옵션을 사용해 지정할 수가 있습니다. listen-on (은)는, 옵션의 포트 및 주소 매치 리스트를 취합니다. 서버는, 주소 매치 리스트로 허가된 인터페이스 모두로 대기합니다. 포트를 지정하지 않는 경우는, 53 번 포토가 사용됩니다.

listen-on 스테이트먼트가 다수 있어도 좋습니다. 예를 들면,

        listen-on { 5.6. 7.8; };
        listen-on port 1234 { ! 1.2. 3.4; 1.2/16; };

그럼, IP 주소가 5.6. 7.8 의 머신용으로 네임서버에 53 번 포트의 사용을 허가해, 1234 번 포트를 1.2 의 네트워크에 있어, IP주소가 1.2. 3.4 는 아니다 머신에 사용을 허가합니다.

listen-on 하지만 지정되어 있지 않은 경우는, 서버는, 모든 인터페이스상에서 53 번 포트에서의 대기를 합니다.

  문의 주소
서버가 문의에 대한 답을 모르는 경우, 그 서버는, 다른 네임서버에 문의를 실시합니다. query-source (은)는, 이러한 문의에 사용되는 주소 및 포트를 지정합니다. address 하지만 * (이었)였거나, 생략 되고 있는 경우, 와일드 카드 IP 주소 ( INADDR_ANY ) 하지만 사용됩니다. port 하지만 * (이었)였거나, 생략 되고 있는 경우, 특권의 필요없는 포트가 랜덤에 사용됩니다. 디폴트에서는
    query-source address * port *;
입니다.

주 : query-source (은)는, 현재 UDP 문의하고 마셔 적용됩니다. TCP 문의에는, 항상 와일드 카드 IP 주소와 랜덤으로 선택되었다 특권의 필요없는 포트가 사용됩니다.

  존 전송

max-transfer-time-in
    여기서 지정된 시간보다 길게 동작하고 있는 내부에의 존 전송 ( named-xfer 프로세스) (을)를 종료합니다. 디폴트에서는, 120 분 (2 시간)입니다.

transfer-format
    서버는 2 종류의 존 전송 방법을 서포트하고 있습니다. one-answer 전송 되는 리소스 레코드 각각 붙어 1 개의 DNS 메세지를 사용합니다. many-answers 가능한 한 많은 리소스 레코드를 1 개의 메세지에 밀어넣습니다. many-answers (분)편이 효율적입니다만, BIND 8.1 및, 패치가 맞은 BIND 4.9. 5 에서만 이해되는 것입니다. 디폴트에서는, one-answer (이)가 됩니다. transfer-format (은)는, server 스테이트먼트를 사용해 서버 단위로 덧쓰기할 수가 있습니다.

transfers-in
    동시에 동작시킬 수 있는 내부에의 존 전송의 최대치입니다. 디폴트는 10 입니다. transfers-in 의 수를 늘리면(자), 슬레이브의 존의 수습이 앞당겨집니다만, 로컬 시스템의 부하도 올라 버릴 우려가 있습니다.

transfers-out
    이 옵션은, 장래, 동시에 동작하는 외부에의 존 전송수를 제한하기 위해서 사용한다 예정입니다. 현재, 문법은 체크하고 있습니다만, 그 이상는 무시하고 있습니다.

transfers-per-ns
    어느 리모트의 네임서버로부터 동시에 실행할 수 있는 내부에의 존 전송 ( named-xfer 프로세스)의 최대치입니다. 디폴트는 2 입니다. transfers-per-ns 의 수를 늘리면(자), 슬레이브 존의 수습은 앞당겨집니다만, 리모트의 네임서버의 부하가 올라 버릴 우려가 있습니다. transfers-per-ns (은)는, server 스테이트먼트의 transfers 프레이즈를 사용해 서버 단위로 덧쓰기할 수가 있습니다.

transfer-source
    transfer-source (은)는, 서버가 내부에 전송 하는 존을 모두 취득하기 위해서 사용된다 TCP connection와 어느 로컬 주소가 묶을 수 있을까를 결정합니다. 이것이 설정되어 있지 않은 경우, 시스템이 제어하고 있는 기본값로 설정됩니다. 이 값은, 통상, 리모트측의 종단에 「가장 가깝다」인터페이스의 주소가 됩니다. 이 주소는, 만약 지정되어 있다면, 리모트측의 종단의 전송 존용의 allow-transfer 옵션으로 등장하고 있지 않으면 안됩니다. 이 스테이트먼트는, 모든 존의 transfer-source (을)를 설정합니다만, 설정 파일중의 존 블록내에 transfer-source 스테이트먼트를 포함하는 것으로 존 단위로 덧쓰기할 수가 있습니다.

  리소스의 제한
다종의 system resource를 서버가 어디까지 사용해도 좋은가 제한 가능합니다. operating system에 따라서는, 이 제한을 몇개인가 서포트하고 있지 않는 것도 있습니다. 그러한 시스템에서는, 서포트되어 있지 않은 제한을 사용한다고 경고가 발생합니다. 또, operating system에 따라서는, 리소스 제한 자체를 서포트하고 있지 않는 것도 있습니다. 그러한 시스템에서는,
    cannot set resource limits on this system
그렇다고 하는 메세지가 로그에 기록됩니다.

리소스 제한을 지정하려면 , 스케일을 바꾼 값을 사용할 수가 있습니다. 예를 들면, 1 기가바이트의 제한을 지정하고 싶은 경우에, 1G (을)를 1073741824 대신에 사용할 수가 있습니다. unlimited (은)는, 무제한하게 리소스를 사용하는, 즉, 이용 가능한 최대의 양의 리소스를 요구합니다. default (은)는, 서버가 개시했을 때에 유효했던 제한치를 사용합니다. 상세한 것에 대하여는, 기술 방법의 정의 의 섹션의 size_spec 의 항을 참조해 주세요.

coresize
    코어덤프의 최대 사이즈입니다. 기본값은 default 입니다.

datasize
    서버를 사용할 수 있는 데이타메모리의 최대 area입니다. 기본값은 default 입니다.

files
    서버를 동시에 오픈할 수 있는 파일의 최대수입니다. 기본값은 unlimited 입니다. operating system에 따라서는, unlimited 라고 하는 값을 설정하지 못하고, 커널을 서포트할 수 있는 오픈하는 파일의 최대치를 결정할 수 없는 것이 있는 것에 주의해 주세요. 이러한 시스템에서는, unlimited (을)를 선택하면(자), 서버가 getrlimit(RLIMIT_NOFILE) (으)로부터 얻을 수 있다 rlim_max 의 값보다 큰 파일수를 취급해 버려, sysconf(_SC_OPEN_MAX) (을)를 돌려주어 버리게 됩니다. 실제의 커널의 제한치가 이 값보다 큰 경우는, limit files (을)를 사용해, 명시적으로 제한치를 지정해 주세요.

max-ixfr-log-size
    max-ixfr-log-size (은)는, 장래의 서버의 릴리스에서는, 인크리멘타르존 전송용으로 보관 유지해 둔다 트랜잭션(transaction) 로그의 크기에 제한을 마련하기 위해서(때문에) 사용할 예정입니다.

stacksize
    서버를 사용할 수 있는 스탁크메모리의 최대량입니다. 기본값은 default 입니다.

  정기적인 태스크의 간격

cleaning-interval
    서버는, cleaning-interval 분 마다 기한이 끊어진 리소스 레코드를 캐쉬로부터 삭제합니다. 디폴트는 60 분입니다. 이것이 0 으로 설정되어 있을 때는, 정기적으로 캐쉬가 클리닝 될 것은 없습니다.

heartbeat-interval
    서버는, 이전 격이 지나면 언제라도 dialup yes 의 표가 붙은 존 모두에 대해서 존 관리 태스크를 실행합니다. 디폴트에서는 60 분입니다. 적절한 값은 1 일 (1440 분 )까지입니다. 이 값이 0 으로 설정되어 있는 경우, 이러한 존에 대한 존 관리는 실행되지 않습니다.

interface-interval
    서버는, interface-interval 분 마다 네트워크 인터페이스 리스트를 스캔 합니다. 디폴트에서는 60 분입니다. 이 값이 0 으로 설정되어 있는 경우, 인터페이스의 스캔을 실시하는 것은, 설정 파일이 로드 되었을 때 뿐입니다. 스캔 한 후, 대기 태스크 (listener)는, 어느 새로운 인터페이스상에서도 시동합니다 (그 태스크가 listen-on 의 설정이 되고 있어 허가되고 있는 경우입니다). 제거된 인터페이스상에서 동작하고 있는 대기 태스크는, 소거됩니다.

statistics-interval
    네임서버의 통계가 statistics-interval 분 마다 로그에 기록됩니다. 디폴트는 60 입니다. 이 값이 0 으로 설정되어 있는 경우, 어떤 통계도 기록되지 않습니다.

  위상기하학

네임서버의 리스트로부터 문의처의 네임서버를 서버가 1 개 선택할 때, 다른 점에서는 모두 대등한 경우, 이 서버는, 자기 자신으로부터 위상기하학적으로 가장 가까운 것을 선택합니다. topology 스테이트먼트는, 주소 매치 리스트를 취해, 특별한 방법으로 그 리스트를 해석합니다. 각각의 맨 위의 리스트 요소는 거리를 할당할 수 있고 있습니다. 무효에되어 있지 않은 요소는, 리스트중의 위치에 근거해 거리를 취득합니다. 여기서, 리스트의 선두에 매치 한 지점이 가까우면 가까울수록, 서버와 요소와의 거리가 가깝게 됩니다. 무효로 되고 있는 매치에는, 서버로부터의 거리의 최대를 할당할 수 있습니다. 매치 하는 것이 없는 경우는, 그 주소는, 무효에되어 있지 않은 리스트의 요소의 어떤 것보다 먼 거리를 취득합니다. 예를 들면,

        topology {
            10/8;
            ! 1.2. 3/24;
            { 1.2/16; 3/8; };
        };

의 경우에서는, 네트워크 10 상의 서버가 가장 바람직한 것이 됩니다. 다음이, 네트워크 1.2. 0.0 (넷 마스크가 255.255. 255.0) 위의 호스트 및 네트워크 3 상의 호스트입니다만, 네트워크 1.2. 3 (넷 마스크가 255.255. 255.0) 위의 호스트는 제외됩니다. 이 네트워크상의 것은, 어떤 것보다 선택되기 어려운 것입니다.

디폴트의 위상기하학은
    topology { localhost; localnets; };
입니다.

  리소스 레코드의 정렬
복수의 RR (역주: 리소스 레코드)가 되돌아 오면(자), 통상 네임서버는, 라운드로빈 그리고 그것들을 돌려줍니다. 즉, 각 요구의 뒤에, 최초의 RR 가 리스트의 마지막에 놓여집니다. RR 의 차례가 정해져 있지 않기 때문에, 이것으로 문제 없습니다.

클라이언트의 resolver의 코드가, 이러한 RR 를 적절히 구성 다시 하지 않으면 안됩니다. 즉, 다른 주소보다, 로컬 넷상의 임의의 주소를 우선해 사용한다고 하는 것입니다. 그렇지만, 모든 resolver가 이렇게 할 수가 있거나 적절히 설정되어 있는 것은 아닙니다.

클라이언트가 로컬 서버를 사용하고 있을 때, 서버내에서, 클라이언트의 주소에 근거한 정렬를 실행할 수 있습니다. 이 소트를 위해서(때문에)는, 다만 네임서버를 설정하는 것만으로 자주(잘), 모든 클라이언트를 설정한다 필요는 없습니다.

sortlist 스테이트먼트는, 주소 매치 리스트를 취해, topology 스테이트먼트보다 더욱 늘어난 특별한 방법으로 리스트를 해석합니다.

정렬 리스트중의 각 선두의 스테이트먼트는, 그것 자신, 1 개(살) 또는 2 개의 요소를 가졌다 명시적인 주소 매치 리스트가 아니면 안됩니다. 각 선두의 리스트의 최초의 요소 (IP 주소, IP 의 프레픽스, ACL 명, 혹은 네스트 된 주소 매치 리스트) 에 대해, 매치이 발견될 때까지, 문의원의 주소를 체크합니다.

한번 문의원의 주소가 매치 했다면, 선두의 스테이트먼트가 다만 1 개의 요소만의 경우, 문의원의 주소와 매치 한 요소 그 자체가 응답의 주소를 선택하기 위해서 사용되어 그것이 응답의 선두로 이동합니다. 스테이트먼트가 2 개의 요소를 가진 리스트였을 경우, 2 번째의 요소는, topology 스테이트먼트의 주소 매치 리스트와 같이 다루어집니다. 각 선두 요소에는, 거리를 할당할 수 있고 있어 가장 짧은 거리를 가진 응답중의 주소가, 그 응답의 선두에 이동됩니다.

다음의 예에서는, 호스트 그것 자신의 주소로부터 받은 문의는, 로컬에 접속되었다 네트워크상의 주소를 우선하는 것 같은 응답을 받아들입니다. 다음에 우선되는 것이, 192.168. 1/24 네트워크상의 주소로, 그 후에, 192.168. 2/24 혹은 192.168. 3/24 네트워크가 옵니다. 마지막 2 개의 네트워크간에는 어느 쪽이 우선인가는 나타나고 있지 않습니다. 192.168. 1/24 네트워크상의 호스트로부터 받은 문의는, 그 네트워크상의 다른 주소를 192.168. 2/24 및 192.168. 3/24 네트워크보다 우선합니다. 192.168. 4/24 혹은 192.168. 5/24 네트워크상의 호스트로부터 받은 문의는, 직접 접속된 네트워크상의 주소를 우선한다 뿐입니다.

    sortlist {
               { localhost;         // 만약 로컬 호스트라면
                 { localnets;       //    다음의 넷상에서
                   192.168. 1/24;    //    최초로 피트한 것으로 한다
                   { 192,168.2/24; 192.168. 3/24; }; }; };
               { 192.168. 1/24;      // 만약 클래스 C 192.168. 1 상이라면
                 { 192.168. 1/24;    //     . 1 혹은,. 2 인가 . 3 을 사용한다
                   { 192.168. 2/24; 192.168. 3/24; }; }; };
               { 192.168. 2/24;      // 만약 클래스 C 192.168. 2 상이라면
                 { 192.168. 2/24;    //     . 2 혹은,. 1 인가 . 3 을 사용한다
                   { 192.168. 1/24; 192.168. 3/24; }; }; };
               { 192.168. 3/24;      // 만약 클래스 C 192.168. 3 상이라면
                 { 192.168. 3/24;    //     . 3 혹은,. 1 인가 . 2 를 사용한다
                   { 192.168. 1/24; 192.168. 2/24; }; }; };
               { { 192.168. 4/24; 192.168. 5/24; }; // . 4 인가 . 5 라면
               };                                 // 그 넷을 우선한다
    };

다음의 예는, 로컬 호스트 및 직접 접속된 네트워크상의 호스트에 대한, 이치에 필적한 거절하지 않든지를 제공하는 것입니다. 이것은, BIND 4.9.x 에서의 주소의 정렬가 거절하지 않든지 닮았습니다. 로컬 호스트로부터의 문의에 대해서 보내진 응답은, 직접 접속되었다 네트워크상의 호스트를 우선합니다. 다른 직접 접속된 네트워크상의 호스트로부터의 문의에 대해서 보내진 응답은, 같은 네트워크상의 주소를 우선하겠지요. 그 외의 문의에 대한 응답에 대해서는 정렬 되지 않습니다.

    sortlist {
                { localhost; localnets; };
                { localnets; };
    };

  RRset 의 차례 붙어라
응답중에 복수의 레코드가 돌려주어지고 있는 경우, 그 응답중에 레코드가 어느 차례로 놓여질까를 설정하는 것이 유익한 일이 있습니다. 예를 들면, 어느 존에 대한 레코드는, 존 파일로 정의된 차례로 항상 돌려주어지도록(듯이) 설정될지도 모릅니다. 혹은, 레코드가 돌려주어질 때 랜덤에 상훌 되도록(듯이) 하고 싶다고 하는 일도 있겠지요. rrset-order 스테이트먼트를 사용하면(자), 복수 레코드가 포함되는 응답중의 레코드의 차례를 설정할 수가 있습니다. 차례가 정의되어 있지 않은 경우, 디폴트에서는, 순회순서 (라운드로빈)(이)가 됩니다

order_spec (은)는 다음과 같이 정의되고 있습니다 :

      [ class class_name ][ type type_name ][ name "FQDN" ] order ordering

클래스가 지정되어 있지 않은 경우, 디폴트는 ANY 입니다. Ictype 하지만 지정되어 있지 않은 경우, 디폴트는 ANY 입니다. 이름이 지정되어 있지 않은 경우, 디폴트는 "*" 입니다.

ordering 의 정당한 값에는, 다음과 같은 것이 있습니다 :

fixed
    레코드는, 존 파일로 정의된 차례로 돌려주어집니다.

random
    레코드는, 어떤 종류의 랜덤인 차례로 돌려주어집니다.

cyclic
    레코드는, 라운드로빈에 돌려주어집니다.

예를 들면,

        rrset-order {
            class IN type A name "rc.vix.com" order random;
            order cyclic;
        };

그럼, 사픽스에 "rc.vix.com" 를 가져, 클래스 IN 로 타입 A 의 레코드에 대한다 응답은, 항상 랜덤인 차례로 돌려주어집니다. 그 외의 레코드는 모두 순회순서에 돌려주어집니다.

rrset-order 스테이트먼트가 복수 나타났을 경우, 스테이트먼트는 연결되지 않습니다. 마지막 것이 적용됩니다.

rrset-order 스테이트먼트가 지정되어 있지 않은 경우, 디폴트는

        rrset-order { class ANY type ANY name "*" order cyclic ; };

하지만 사용됩니다.

  아교의 순서
루트 네임서버 실행시에는, 준비중의 다른 네임서버가 성공하는 것을 프로텍션할 필요가 있는 경우가 있습니다. 준비의 문의에 대한 대답안에, 네임서버의 쳐 적어도 1 개(살)에 대한 아교 (김)의 A 레코드가 돌려주어지는 것이 필요합니다. 이것은, preferred-glue A; (을)를 설정하는 것으로 실현 가능하고, 추가 섹션중의 다른 타입의 전에 A 레코드를 추가합니다.

  튜닝

lame-ttl
    불완전한 서버의 지시를 캐쉬해 두는 초수를 설정합니다. 0 의 경우, 캐쉬하지 않습니다. 디폴트는 600 (10 분 )입니다. 최대치는 1800 (30 분 )입니다.

max-ncache-ttl
    네트워크의 부하를 경감해 퍼포먼스를 올리기 위해서(때문에), 서버가 부정 응답을 저축합니다. max-ncache-ttl (은)는, 서버로, 이러한 응답의 최대 보존 시간을 설정하기 위해서 사용합니다. 초단위입니다. 디폴트의 max-ncache-ttl (은)는 10800 초 (3 시간)입니다. max-ncache-ttl 통상의 (긍정) 응답에 대해서는, 최대 보존 시간을 넘어서는 안됩니다 (7 일). 만약, 이 값이 7 일 이상으로 설정되어 있었을 경우, 입다물어 7 일에 절약해 버리겠지요.

min-roots
    루트 서버에 대한 요구를 받아들이기 위해서(때문에) 필요한 루트 서버의 최소치입니다. 디폴트는 2 입니다.

zone 스테이트먼트

  문법

    zone domain_name [ ( in | hs | hesiod | chaos ) ] {
      type master;
      file path_name;
      [ check-names ( warn | fail | ignore ); ]
      [ allow-update { address_match_list }; ]
      [ allow-query { address_match_list }; ]
      [ allow-transfer { address_match_list }; ]
      [ forward ( only | first ); ]
      [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
      [ dialup yes_or_no; ]
      [ notify ( yes_or_no | explicit ); ]
      [ also-notify { ip_addr; [ ip_addr; ... ] };
      [ pubkey number number number string; ]
    };

    zone domain_name [ ( in | hs | hesiod | chaos ) ] {
      type ( slave | stub );
      [ file path_name; ]
      masters [ port ip_port ] { ip_addr [ key key_id ]; [ ... ] };
      [ check-names ( warn | fail | ignore ); ]
      [ allow-update { address_match_list }; ]
      [ allow-query { address_match_list }; ]
      [ allow-transfer { address_match_list }; ]
      [ forward ( only | first ); ]
      [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
      [ transfer-source ip_addr; ]
      [ max-transfer-time-in number; ]
      [ notify yes_or_no; ]
      [ also-notify { ip_addr; [ ip_addr; ... ] };
      [ pubkey number number number string; ]
    };

    zone domain_name [ ( in | hs | hesiod | chaos ) ] {
      type forward;
      [ forward ( only | first ); ]
      [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
      [ check-names ( warn | fail | ignore ); ]
    };

    zone ". " [ ( in | hs | hesiod | chaos ) ] {
      type hint;
      file path_name;
      [ check-names ( warn | fail | ignore ); ]
    };

  정의와 사용법
zone 스테이트먼트는, 특정의 DNS 존이 서버에 어떻게 관리되는지를 지정하기 위해서 사용됩니다. 존에는 5 개의 종류가 있습니다.

master
    서버는, 그 존용 데이터의 마스터 카피를 가지고 있어, 존에 대해서 신뢰할 수 있다 응답을 제공할 수 있습니다.

slave
    slave 존은 마스터 존의 복제입니다. masters 리스트는, 존의 복제를 갱신하기 위해서 슬레이브 서버가 통신을 실시하는 1 개(살) 이상의 IP 주소를 지정합니다. port 하지만 지정되어 있는 경우, 이 포트에 대해, 존이 현재 사용되고 있는 것인 것의 확인과 존 전송을 합니다. file 하지만 지정되어 있는 경우, 지정된 파일에 존의 복제가 써내집니다. file 마디를 사용하는 것을 강하게 권합니다. 왜냐하면, 대체로 서버의 기동을 앞당기고, 통신회선을 쓸데없게 사용하는 것을 막아 주기 때문입니다.

stub
    stub 존은 slave 존과 같은 것입니다만, 존 전체를 복제하는 것이 아니라, 마스터 존의 NS 레코드만을 복제한다고 하는 점이 다릅니다.

forward
    forward 존은, 자신으로 향해진 문의를 다른 서버에 배분하기 위해서(때문에) 사용합니다. 이것은, option 스테이트먼트 의 섹션으로 설명하고 있습니다. 이러한 존에서의 옵션 사양은, options 스테이트먼트로 선언된 글로벌 옵션을 덧쓰기합니다.

    forwarders 마디가 zone 스테이트먼트중에 존재하지 않는지, 혹은, forwarders 에 대해서 하늘 리스트가 주어지고 있는 경우는, 그 존에 대해서 포워드는 행해지지 않고, options 스테이트먼트중의 forwarders (은)는, 모두 효력을 잃습니다. 그 때문에, 사용되는 서버가 아니고, 글로벌의 forward 옵션의 거동을 변경하기 위해(때문에)인 만큼 이 종류의 존을 사용하고 싶은 것이면, 글로벌의 forwarders 절도 지정 다시 할 필요가 있습니다.

hint
    루트 네임서버의 초기 집합은, hint 존을 사용해 지정됩니다. 서버가 기동할 때에, 루트 힌트를 사용해 루트 네임서버를 찾아내 루트 네임서버의 최신 리스트를 취득합니다.

주 : 이전의 BIND 릴리스에서는, 마스터 존에 대해서는 primary 그렇다고 하는 용어를 사용해, 슬레이브 존에 대해서는, secondary (을)를, hint 존에 대해서는 cache 그렇다고 하는 용어를 사용하고 있었습니다.

  클래스
존명에는, 옵션으로 클래스를 계속할 수가 있습니다. 만약, 클래스가 지정되어 있지 않은 경우는, in 클래스 ( 「인터넷」용)이라고 가정됩니다. 이것은, 대부분의 경우 올바릅니다.

hesiod 클래스는, MIT 의 Project Athena 유래의 정보 서비스용의 클래스입니다. 이 클래스는, 유저, 그룹, 프린터등이라고 한, 다양한 시스템 데이타베이스에 관한 정보를 공유하기 위해서 사용됩니다. 새로운 정보는, ftp://athena-dist.mit.edu/pub/ATHENA/usenix/athena_changes.PS (으)로부터 입수할 수 있습니다. 키워드 hs 하 hesiod (와)과 동의어입니다.

MIT 가 개발한 이제(벌써) 1 개의 것이, 1970 년대 중반에 만들어진 LAN 프로토콜이다 CHAOSnet 입니다. 이것은, LISP 스테이션이나 AI 커뮤니티에서 사용되고 있다 다른 하드웨어로, 아직 때때로 보여집니다. CHAOSnet 용의 존 데이터는, chaos 클래스를 사용해 지정할 수 있습니다.

  옵션

check-names
    options 스테이트먼트 의 네임 체크 에 관한 서브 섹션을 참조해 주세요.

allow-query
    options 스테이트먼트 의 액세스 제어 서브 섹션안의 allow-query 에 관한 설명을 참조해 주세요.

allow-update
    어느 호스트가 동적인 DNS 의 갱신을 서버에 제출하는지를 지정합니다. 디폴트는, 어느 호스트로부터도 갱신을 허가하지 않는다고 하는 것입니다.

allow-transfer
    options 스테이트먼트 의 액세스 제어 서브 섹션안의 allow-transfer 에 관한 설명을 참조해 주세요.

transfer-source
    transfer-source 어느 로컬 주소가, 이 존을 취득하기 위해서 사용되는 TCP 접속과 묶을 수 있을까를 지정합니다. 이것이 설정되어 있지 않은 경우는, 시스템이 제어하는 값이 디폴트가 됩니다. 이 값은, 통상은, 리모트측의 종단에 「가장 가깝다」인터페이스의 주소입니다. 이 주소는, 만약 지정되어 있다면, 이 존에 대한 리모트측의 종단의 allow-transfer 옵션중에 나오지 않으면 안됩니다.

max-transfer-time-in
    options 스테이트먼트 의 존 전송 서브 섹션중의 max-transfer-time-in 의 설명을 참조해 주세요.

dialup
    options 스테이트먼트 의 불리언 값 옵션 서브 섹션중의 dialup 의 설명을 참조해 주세요.

notify
    options 스테이트먼트 의 불리언 값 옵션 서브 섹션중의 notify 의 설명을 참조해 주세요.

also-notify
    notify 하지만 이 존에 대해서 액티브한 경우만 also-notify (은)는 의미를 가집니다. 이 존에 대한 DNS NOTIFY 메세지를 받아들이는 머신군은, 그 존용으로 리스트 되었다 모든 네임서버 (프라이머리 마스터를 제외하다)와 also-notify 그리고 지정된 IP 주소로부터 되어 있습니다. also-notify 하 stub 존에 대해서는 의미를 가지지 않습니다. 디폴트에서는, 이것은 하늘의 리스트입니다.

forward
    forward (은)는, 그 존이 forwarders 리스트를 가지고 있는 경우만 의미를 가집니다. only 값은, 먼저 forwarders (을)를 시험해, 응답이 없었던 경우에 검색을 실패시킵니다. 그에 대해, first (은)는, 통상의 검색을 허가합니다.

forwarders
    존안으로 forwarders 옵션을 사용하면(자), 글로벌의 forwarders 리스트가 덧쓰기됩니다. forward 타입의 존안으로 이것이 지정되어 있지 않았던 경우는, 이 존에 대해서는 무슨 포워드도 실시하지 않습니다. 글로벌의 옵션은 사용되지 않는다고 하는 것입니다.

pubkey
    DNSSEC 의 플래그, 프로토콜, 알고리즘과 base-64 로 encode 된 열쇠를 나타내는 캐릭터 라인을 지정합니다.

acl 스테이트먼트

  문법

    acl name {
      address_match_list
    };

  정의와 사용법
acl 스테이트먼트는, 이름이 붙은 주소 매치 리스트를 생성합니다. 이 스테이트먼트는, 프라이머리로 사용하고 있는 주소 매치 리스트, 즉, 액세스 제어 리스트 (ACL)로부터 그 이름을 취득합니다.

주소 매치 리스트명은, 다른 곳에서 사용하기 전에 acl (을)를 사용해 정의하지 않으면 안됩니다. 파일의 전방에의 참조는 용서되고 있지 않습니다.

다음과 같은 편입의 ACL 가 있습니다 :

any 모든 호스트를 허가합니다.

none
    모든 호스트를 거부합니다.

localhost
    시스템상의 모든 인터페이스의 IP 주소를 허가합니다.

localnets
    시스템이 인터페이스를 가진 네트워크상의 모든 호스트를 허가합니다.

key 스테이트먼트

  문법

    key key_id {
      algorithm algorithm_id;
      secret secret_string;
    };

  정의와 사용법
key 스테이트먼트는, 열쇠의 ID 를 지정합니다. 이 ID 는, server 스테이트먼트로 사용되어 단순한 IP 주소에서의 매칭보다 엄격한 특정의 네임서버와 인증 방법을 관련 짓습니다. 열쇠의 ID 는, server 의 정의나 주소 매치 리스트중에서 사용되기 전에 key 스테이트먼트를 사용해 작성되어 있지 않으면 안됩니다.

algorithm_id (은)는, 보안 / 인증 알고리즘을 지정하는 캐릭터 라인입니다. secret_string (은)는, 지정된 알고리즘이 사용하는 비밀의 열쇠로, base-64 로 encode 된 캐릭터 라인으로서 다루어집니다. 말하지 않고와도 당연한 일입니다만, 때문생각 지적해 두면(자), named.conf 안에 secret_string (을)를 넣고 있는 경우, named.conf 를 슈퍼 유저 이외의 누구에게도 읽어들여 가능하게 해서는 안됩니다.

trusted-keys 스테이트먼트

  문법

    trusted-keys {
      [ domain_name flags protocol algorithm key; ]
    };

  정의와 사용법
trusted-keys 스테이트먼트는, 원래, RFC 2065 로 사양이 결정되어 있는 DNSSEC 스타일의 보안와 함께 사용됩니다. DNSSEC 는, 3 개(살)이 다른 서비스를 제공하는 것입니다 : 그것은, 열쇠의 배포, 데이터의 발생원의 인증, 그리고, 트랜잭션(transaction) 및 요구의 인증입니다. DNSSEC 에 대한 완전한 설명과 이 문서의 범위를 넘은 사용법을 알고 싶은 경우, 그리고, 독자가 새로운 정보에 흥미가 있는 경우는, 우선, RFC2065 를 읽는 것으로부터 시작해 주세요. 그리고, http://www.ietf.org/ids.by.wg/dnssec.html 로부터 입수할 수 있는 인터넷 드래프트로 계속되어 주세요.

신뢰된 열쇠는 각각, 도메인명과 관련 지을 수 있고 있습니다. 그 속성은, 비부의 정수치인, flags, protocol, algorithm 라고 key (을)를 나타내는 base-64 로 encode 된 캐릭터 라인입니다.

신뢰된 열쇠의 번호는 모두 지정 가능합니다.

server 스테이트먼트

  문법

    server ip_addr {
      [ edns yes_or_no; ]
      [ bogus yes_or_no; ]
      [ support-ixfr yes_or_no; ]
      [ transfers number; ]
      [ transfer-format ( one-answer | many-answers ); ]
      [ keys { key_id [ key_id ... ] }; ]
    };

  정의와 사용법
server 스테이트먼트는, 리모트의 네임서버에 관련지을 수 있다 특징을 정의합니다.

서버가 EDNS 를 서포트하고 있지 않는 경우, edns no; (을)를 지정하는 것으로 named 가 EDNS 문의하고 하지 않게 할 수 있습니다. edns 의 기본값은 yes 입니다.

서버가 잘못한 데이터를 보내고 있는 것에 깨달았을 경우, 그 서버를 bogus (으)로 하는 것으로, 그 서버에의 문의를 억제할 수가 있습니다. bogus 의 기본값은 no 입니다.

서버가 IXFR 를 서포트하는 경우, support-ixfr (을)를 yes (으)로 설정하는 것으로, IXFR 스타일의 존 전송을 시도하도록(듯이) named 에 지시 가능합니다. support-ixfr 의 기본값은 no 입니다.

서버는, 2 개의 존 전송 방식을 서포트하고 있습니다. 1 번째는, one-answer (이어)여, 이것은, 전송 되는 각 리소스 레코드에 1 개의 DNS 메세지를 사용합니다. many-answers (은)는, 가능한 한 많은 리소스 레코드를 1 개의 메세지에 밀어넣습니다. many-answers (분)편이 효율적입니다만, BIND 8.1 및, 패치가 맞은 BIND 4.9. 5 에서만 이해되는 것입니다. 서버에 대해서 어느 쪽의 방법을 사용할까는, transfer-format 옵션을 사용해 지정할 수가 있습니다. transfer-format 하지만 지정되어 있지 않은 경우는, options 스테이트먼트로 지정되었다 transfer-format 하지만 사용됩니다.

transfers (은)는, 장래의 릴리스에서의 서버로, 지정된 서버로부터 동시에 행해지는 내부에의 존 전송수를 제한하기 위해서 사용될 예정입니다. 현재는, 문법은 체크합니다만, 그 외는 무시됩니다.

keys 마디는, key 스테이트먼트로 정의되었다 key_id (을)를 식별하기 위해서 사용됩니다. 이것은, 리모트 서버와 통신할 때의 트랜잭션(transaction)의 보안용으로 사용됩니다. key 스테이트먼트는, 그것을 참조한다 server 스테이트먼트보다 먼저 나타나지 않으면 안됩니다.

keys 스테이트먼트는, 장래, 서버에 의해 사용되는 것을 기대되고 있습니다. 현재는, 문법은 체크됩니다만, 그 외는 무시됩니다.

controls 스테이트먼트

  문법

    controls {
      [ inet ip_addr
        port ip_port
        allow { address_match_list; }; ]
      [ unix path_name
        perm number
        owner number
        group number; ]
    };

  정의와 사용법
controls 스테이트먼트는, 시스템 관리 책임자가 로컬의 네임서버의 조작에 영향을 주기 위해서(때문에) 사용하는 제어 채널을 선언합니다. 제어 채널은, ndc 유틸리티가, 네임서버에 명령을 보내, DNS 이외의 결과를 받기 위해서(때문에) 사용합니다.

unix 제어 채널은, 파일 시스템에서의 FIFO 입니다. 이 채널에의 액세스는, 통상의 파일 시스템의 퍼미션에 의해 제어됩니다. 이 제어 채널은, 지정된 파일 모드의 비트 ( chmod(1) (을)를 참조)와 유저 및 그룹의 소유자 정보를 사용해, named 하지만 작성합니다. 주의하는 것은, chmod (와)과는 달라, perm 에 대해서 지정되는 모드의 비트에는, 통상 선두에 0 하지만 붙어 있는 것입니다. 그 때문에, 숫자는 8 진수로서 해석됩니다. 한층 더 주의하는 것은, owner 및 group (으)로서 지정되는 유저 및 그룹의 소유자 정보는, 숫자로 주지 않으면 안 된다고 하는 것입니다. 이름이 아닙니다. 이 퍼미션은, 관리자에만 제한하는 것을 권합니다. 그렇게 하지 않으면 이 시스템상의 유저라면 누구라도 로컬 네임서버를 조작 가능하게 됩니다.

inet 제어 채널은, 인터넷 접속을 할 수 있는 TCP/IP 소켓입니다. 이것은, 지정되었다 ip_addr 위의 지정되었다 ip_port 에 있습니다. 최근의 telnet 클라이언트는, 이러한 소켓과 직접 대화를 할 수 있습니다. 이 때의 제어 프로토콜은, ARPAnet 형식의 텍스트입니다. 127.0. 0.1 만을 ip_addr 에 사용하는 것을 권합니다. 이것은, 네임서버를 관리하기 위해서, 로컬 호스트상의 특권을 가지지 않는 유저를 모두 신용하고 있는 경우만으로 한정합니다.

include 스테이트먼트

  문법

    include path_name;

  정의와 사용법
include 스테이트먼트는, 그 스테이트먼트가 나타난 지점에, 지정되었다 파일을 삽입합니다. 다만, 다른 스테이트먼트내에서 사용하는 것은 할 수 없습니다. 그러므로,
    acl internal_hosts { include internal_hosts.acl; };
(와)과 같이는 사용할 수 없습니다.

include (을)를 사용해, 설정 파일을 간단하게 관리할 수 있을까 모임으로 나누도록(듯이) 해 주세요. 예를 들면, 다음과 같게입니다 :

    include "/etc/security/keys.bind";
    include "/etc/acls.bind";

이 예는, 임의의 ACL 또는 인증열쇠 정보를 수중에 넣기 위해서(때문에), BIND 설정 파일의 선두에서 사용할 수가 있겠지요.

C 언어에서의 프로그램으로 하도록(듯이) ``#include''와 타이프 치지 말아 주세요. ``#''는 코멘트의 개시로서 사용하는 것이기 때문입니다.

사용예
실제로 사용하는 장면에서도 실용적이어, 가장 단순한 설정 파일은, 다만 단지 루트 서버 파일에의 풀 패스를 가진 힌트 존을 정의한 것입니다.

    zone ". " in {
            type hint;
            file "/var/named/root.cache";
    };

다음의 예는, 좀 더 열매 세계에 맞은 것입니다.

    /*
     * 단순한 BIND 8 의 설정
     */

    logging {
    	category lame-servers { null; };
    	category cname { null; };
    };

    options {
    	directory "/var/named";
    };

    controls {
    	inet * port 52 allow { any; };			// 이것은 좋지 않다
    	unix "/var/run/ndc" perm 0600 owner 0 group 0;	// 디폴트
    };

    zone "isc.org" in {
    	type master;
    	file "master/isc.org";
    };

    zone "vix.com" in {
    	type slave;
    	file "slave/vix.com";
    	masters { 10.0. 0.53; };
    };

    zone "0.0. 127.in-addr.arpa" in {
    	type master;
    	file "master/127. 0.0";
    };

    zone ". " in {
    	type hint;
    	file "root.cache";
    };

관련 파일
/etc/namedb/named.conf
    BIND 8 named 설정 파일

관련 항목
named(8), ndc(8)