Subject : DNS에 관한 일반적인 내용 정리
Description :
1. DNS 란?
- Domain Name Service (DNS)는 표준 TCP/IP Protocol suite 의 부분인
Applications layer protocol임.
- DNS의 기본적 기능은 query들을 질문하고 대답함으로써 한 네트워크상에
있는 host들에 관한 정보를 얻거나 제공함.
2. DNS Domain Hierarchy
- DNS는 자기의 local administrative domain 안에 있는 host들간에
naming 을 수행함.
- 각 server들은 in.named이라 불리는 daemon을 수행함으로써 DNS를
실행시킴. 이러한 server들은 흔히 name servers로서 언급됨.
- client 측에서, service는 resolver를 통해서 실행됨.
resolver는 하나의 daemon이나 program이 아니며 일종의 C-library
function 이고 그것의 기능은 user query들을 resolve함.
그때 name server는 바랬던 대답을 돌려줌.
- name server는 두종류의 data를 유지함.
첫번째 종류는 'authoritative' 라 하는데 이것은 server에 의해
유지되는 zone들을 언급하며 , server에 의해 유지되는
두번째 종류는 local resolver를 통해 얻는 cached data임.
- DNS name들은 계층적 구조를 가지고 있는데, 이것은 sunOS directory와
같은 형태로 domain들을 구성하고 있다.
아래 그림은 DNS계층의 예를 보여주고 있다.
< THE ROOT LEVEL DOMAIN >
- 가장 상위의 root level은 NIC(Network Information Center)에 의해 현재
운영되고 있음. 그래서 Internet와 연결하기 위해서는 반드시 NIC와
접촉해야함. BITNET,CSNET와 같은 다른 대중 network들을 담당하는
조직들은 그들 자신의 network들을 위한 영역을 관리하고 있다.
root level에서 NIC는 next lower level의 name server들에 관한 정보를
유지하고 있는 root domain name server들을 관리함.
< TOP LEVEL DOMAINS >
- 윗그림에서 보는 바와 같이 Internet top level domain들은 EDU,ARPA,
COM,GOV등이 있다.여러분이 NIC에 등록할경우 여러분의 network을
조직특성에 따라 이러한 domain들로 할당함.
예를 들면 현재 NIC에서는 educational institutions은 EDU domain으로
business institutions은 COM domain으로 할당하고 있음.
- NIC는 또한 top level domain들을 위한 DNS를 관리함.
< SECOND LEVEL DOMAINS >
- 윗그림에서 dogstar,sun,rigel과 같이 각각 top level domain 으로 부터
second level domain으로 분기함.
이 단계에서 name server들은 domain administrator들이 관리함.
< LOCAL ADMINISTRATIVE DOMAINS >
- 각각의 second level밑은 local administrarive domain들이고, 이러한
domain들은 여러분의 조직을 위하여 여러분이 관리해아 함.
하나의 second level domain은 하나의 host처럼 규모가 작을수도 있고
많은 host들을 포함하기에 충분할만큼 규모가 클수도 있다.
윗그림에서 second level domain SUN.COM은 세개의 internal
administrative domain(venus,earth,mars)들을 가지고 있다.
domain earth는 moon과 같은 individual host들과 subdomain인 eurostar를
포함하고 있음.
3. Name Space 와 Administrative Zones
- 하나의 zone이란 single authority와 name server들에 의해 관리되는
host들의 hierarchical community임.
이런 community 는 individual host들과 모든 name server,그것의
client(subzone)들을 포함하고 있다.
zone은 여러분의 local administrative domain처럼 administrative
boundary를 나타냄.
- 다음 그림은 어떻게 가상의 zone들이 구성되었는가를 보여주고 있다.
이 그림에서는 4개의 zone들로 구성되있음.
. root zone => 이것은 Internet root domain name server에 의해 관리됨.
. three zone => 이것은 domain SUN.COM에서의 name server들에 의해
관리됨.
점선으로 나타낸 부분은 각 zone을 구성하는 영역을 구분하고 있음.
< How Name Space Relates to Host and Domain Names >
- host name 표기시 fully-qualified domain name으로 해야함.
이 이름은 name space 안에서 host 혹은 domain의 위치를 반영함
fully-qualified domain name들은 SunOS full pathname들과 비슷하지만
두가지 차이점이 있다.
domain name들은 오른쪽에서 왼쪽으로 나타내고 / 보다는 . 로 구분한다.
다음은 sample domain name임.
COM. rigel.COM. venus.sun eurostar.earth.sun.COM.
period가 domain name가장 오른쪽에 나타날경우 그것은 root의 null
label을 나타내는것임.
만약 domain name venus.sun처럼 trailing period가 열거되지 않았다면
DNS는 domain name 을 상대적개념 으로 여긴다.
여러분의 local network 상에 있는 host 의 fully qualified domain
name 열거방법은 아래와 같다.
subdomain eurostar 안의 machine named uk fully qualified domain 을 보면
uk.eurostar.earth.sun.COM. 로 표기할수 있다.
< How Name Space Relates to Zones >
- zone들의 이름은 zone hierarchy 의 top domain label 로 부터 취한다.
윗그림에서 4개의 domain들이 형성되있다.
sun.COM venus.sun.COM mars.sun.COM . (the root zone)
zone sun.COM은 그 이름을 second level domain sun.COM의 label로 부터
취한다.
zone sun.COM은 다음 3가지로 구성되있다.
. domain sun
. local administrative domain earth
. subdomain eurostar
zone sun.COM은 domain venus와 mars를 포함하지 않는다. 그들은 그들
자신의 zone들을 가지고 있다. 그러나 venus와 mars는 sun.COM domain
계층의 일부분이다.
< Name Space and the IN-ADDR.ARPA Domain >
- domain hierarchy 와 name space는 host name을 가지고 정보를 유지한다.
이것은 in.named daemon이 name을 address로 mapping이 가능하기 때문이다.
부가적으로 , DNS가 인식하는 특별한 domain이 있는데 이것을
IN-ADDR.ARPA라 부르는데 이것의 기능은 address를 name으로 mapping
을 용이하게 하는 기능이 있다. 이것은 IP address로 표현된다.
host address 표현방식은 오른쪽에서 왼쪽으로 나열이 됨.
예를 들면 host IP address가 128.32.0.4면서 IN-ADDR.ARPA domain name을
가지고 있을 경우 아래와 같이 표현함.
4.0.32.128. IN-ADDR.ARPA.
< DNS Servers and Clients >
- DNS에서 두가지 측면을 살펴볼수가 있는데
in.named daemon을 수행시키는 name server와
resolver를 수행시키는 client가 있다.
in.named 를 수행시키는 name server는 또한 resolver를 수행시킬수 있다.
또한 두종류의 client가 있는데 다음과 같이 구분한다.
. Client-only
. Server/client
- 여러분은 일련의 server들의 zone을 위해 name service를 실행할수 있다.
일련의 server들은 다음과 같은 것을 포함할수 있다.
. Master servers (primary and secondary)
. Caching-only server
. Forwarding server
< Clients >
- clinet-only machine은 in.named daemon을 수행하지 않는다.
대신에 /etc/resolv.conf file을 참조한다. 이 file은 query들을
관리하는 name serving machine list를 제공한다.
- name server/clinet는 user의 query를 분석하기 위하여 in.named에서
제공하는 domain name service 를 사용하는 machine이다.
그러나 만약 daemon이 죽거나 hangup 이 될경우 자신의 resolver를
통해서 query들을 해결할수 있다.
< Master Servers >
- 각각의 zone은 그 zone의 모든 data를 유지하는 두개의
master name server 들을 적어도 가지고 있어야 한다.
즉, 주어진 zone에 일치하는 data는 적어도 two server에 유용해야 한다.
여러분은 primary master server로서 하나의 name server를 지정해야
하고 만약 primary를 쓸수가 없을 경우 하나의 backup으로서
secondary master를 지정해야 한다.
- primary master server는 zone을 변화시킬수 있는 name server이며
이 server는 in.named을 시작할때 disk로 부터 data를 copy해서
master에다 적재한다. primary server는 또한 자기 zone안에 있는
혹은 밖에 있는 다른 server들에게 authority를 부여할수 있다.
- secondary master server는 copy된 data를 유지하는 name server이다.
primary server는 secondary server에게 자신의 data를 보내고
자신의 authority를 부여한다.
secondary server가 in.named을 booting할때 primary로 부터 주어진
zone의 모든 data를 요구하고 그 data를 update할 필요가 있을경우
primary와 의논을 한다.
< Caching and Caching-Only Servers >
- 모든 name server들은 caching server들이다.
이것이 의미하는 것은 name server는 data가 소멸할때까지 받은 정보를
저장한다.
부가적으로 , 여러분은 어떤 zone을 위해 authoritative하지 않는
caching only server를 setup할수 있다.
이 server는 query들을 처리하고 실제로 정보의 authoritative를 갖고
있는 다른 name server들에게 질문할수 있다.
그러나 caching only server는 어떤 authoritative한 data자체를
유지할수 없다.
< Forwarding Servers >
- 여러분은 request를 다른 server들에게 전달함으로써 처리하는
server들을 setup할수 있다.
Forwarding list에는 하나이상의 server들이 있을수 있고
list가 없어질때까지 교대로 시도할것이다.
예를 들어 만약 여러분이 Internet 혹은 다른 network에 연결된
large machine과 외부와 연결되지 않은 small machine 혹은 workstation
을 가지고 있다고 할때 workstation을 Internet 혹은 다른 network 에
연결할경우 여러분은 small machine들을 large machine의 forwarding
slave들로 setup 할수 있고 그들의 request들은 large machine으로
전달될것이다. 그래서 교대로 query를 해결하기 위해서 다른 server들과
상호작용해서 대답을 돌려줄것이다.
4. Name Server Files
- domain name server는 자신의 database를 load하기 위해
몇개의 file을 사용한다.
resolver단계에서는 실제 정보를 얻을수 있는 server들의 주소를 나타낸
file을 (소위 /etc/resolv.conf)필요로 한다.
resolver가 host의 address를 발견할때마다 (혹은 address에 상응하는 name)
query packet을 만들어 resolver가 알고있는(/etc/resolv.conf참조)
name server로 보낸다.
그 server는 자체적으로 query에 답을 하고 혹은 다른 server들의 service를
이용하여 resolver에게 결과를 보낸다.
- name단계에서는 우선 server들(primary,secondary,cache-only,
forwarding name server)을 설정하는 boot file(소위 /etc/named.boot)을
필요로 한다.
이 file은 여러분이 named daemon을 call하기전에 설정이 되야한다.
- resolver와 named daemon에 사용되는 format형태를 보면 다음과 같다.
. semicolon(;)은 comment line으로 사용
. 괄호는 line확장시 사용됨
- resolver configuration file과 named boot file 은 자신의 syntex를 가지고
있고 다른 모든 file들은 Resource Record standard syntax를 따른다.
< Resolver Configuration File >
- 이 file은 local domain과 name server들의 위치를 알기위해서
resolver에 의해 읽혀진다.
다음은 resolv.conf file의 예이다.
; Sample resolv.conf file
domain Podunk.Edu
nameserver 128.32.0.4
nameserver 128.32.0.10
이 예는 local domain 을 Podunk.Edu로 설정했고, resolver routine이
어떤정보를 위해서 상기에 기록된 name server 참조하며
이 file은 resolver에 의해서만 사용된다.
< Boot File >
- 이 file은 named이 server의 /etc/rc.local로 부터 시작될때 처음으로
읽혀진다. boot file은 server의 type 과 zone과 initial data를 얻을수
있는 곳을 알려준다.
boot file의 default location 은 /etc/named.boot이다.
그러나 command line상에서 다른 이름으로 변경함으로써 default location 을 변경할수 있다.
- boot file과 data file들의 관계는 아래 그림에서 보여준다.
- 모든 data file들은 Standard Resource Record Format을 사용한다.
< Boot File For a Primary Server >
- 다음은 primary server를 위한 sample boot file이다.
- line별로 분석을 해보면
1. directory /var/named
. 이 line은 name server가 수행하는 directory를 가리킨다.
filed의 가변을 위해서 /var밑에 directory를 정했지만
어떤 directory를 선택해도 상관이 없다.
. boot file안에 directory가 없으면 모든 file name은
절대pathname이 되야한다.
2. cache . named.ca
. 모든 server들은 root name server들을 발견하기 위해 boot file
안에다 상기 line을 가져야 한다.
첫번째 field(cache)는 server가 named.ca과 같은 명시된 file로
부터 root server hints를 얻을수 있다는 것을 나타냄.
세번째 field(named.ca)는 root server들을 나타낸 file name이다.
일반적으로 named.ca라는 이름을 많이 사용하며 다른 이름을
사용해도 무방하다.
다음은 sample named.ca file이다.
3. primary Podunk.Edu puhosts
. 첫번째 field(primary)는 두번째 field(Poduk.Edu)에서 언급된
zone의 primary로서의 server를 가리킨다.
세번째 field(puhosts)는 data가 읽혀지는 hosts file name이다.
이 file은 그 zone안에 있는 machine들에 관한 모든 data를
가지고 있다.
이 file도 standard Resource Record format을 따른다.
4. primary 32.128.in-addr.arpa puhosts.rev
. 이 server는 domain 32.128.in-addr.arpa를 위한 primary
server이고 server를 위한 data는 reverse hosts file (즉
puhosts.rev)에서 발견된다.
이 file은 IN-ADDR.ARPA domain안에 있는 zone을 열거한다
이 domain은 address-to-name mapping할수 있는 특별한 domain이다.
IP address 128.32.0.4는 domain 4.0.32.128.IN-ADDR.ARPA와 같다.
5. primary 0.0.127.in-addr.arpa named.local
. 이 server는 domain 0.0.127.in-addr.arpa(즉 local host loopback)
를 위한 primary server 이고, data는 named.local에서 볼수있다.
또한 이 file은 local loopback interface 혹은 localhost를 위한
address (127.0.0.1)를 나타낸다.
< Boot File For a Secondary Server >
- 다음은 위의 primary server처럼 같은 domain안에 있는 secondary server
를 위한 sample boot file이다.
- line 별 분석
. secondary라는 말은 두번째 field의 zone을 위한 secondary server
를 말한고 나열된 server들로부터 data 를 얻는다. 통상 primary
server다음에는 하나이상의 secondary server가 온다.
multiple secondary addresses를 나타낼수 있다는 것은 zone을
backup한다는 점에서 상당한 유연성을 보여준다.
< Boot File for Primary and Secondary Server >
- server는 하나이상의 zone들을 위해 primary server와 secondary server
역할을 할수있다.
< Boot File for Caching-Only Server >
- 다음은 caching-only server을 위한 sample boot file이다.
- 여기서는 caching-only server를 하나의 server로서 특별히 나타낼
필요가 없다.
caching-only server는 authoritative data를 관리하지 않고 단순히
query들을 다룬다.
< Boot file for Forwarding Server >
- 다음은 forwarding server을 위한 sample boot file이다.
- forwarders line은 local적으로 해결될수 없는 query들은 명시된
server들로 돌리게 된다는 것을 보여주고 있고
slave line은 local적으로 query를 해결할려는 시도를 하지 않고 바로
모든 query들을 forwarders로 돌린다는 것을 나타낸다.
주의: forwarders line 없이 slave line이 존재할수 없다.
5. Standard Resource Record Format
- 모든 data file들 (예 named.ca , named.local , hosts , host.rev) 은
standard format으로 기록된다.
- data의 각 line은 다음과 같은 field들을 포함하는 Resource Record(RR)
이라 불리는 record이다.
{name} {ttl} class Record Type Record Specific data
- field의 순서는 항상 같다. 그러나 첫번째,두번째 field는 option이다.
- 각 항목을 살펴보면 다음과 같다.
. name : 첫번째field는 그 record를 적용할 domain name이다.
. ttl : 두번째 field는 time-to-live field이다.
이것은 data가 무시되거나 새로운 정보가 server로부터 요청되기
전에 얼마나 오랫동안 data가 database안에
저장될것인가를 나타낸다.
만약 ttl value가 매우 높게 설정되있으면 server는 data 회복을
위해 무수한 반복 request들을 초래할 것이다.
그 반면에 ttl value가 너무 낮게 설정되있으면 정보의 변화들을
적절히 배분하지 못할것이다.
대부분의 ttl value는 처음에 day(86400)와 week(604800)사이로
설정되있다.
. class : 세번째 field는 record class이다.
. type : 네번째 field는 resource record 의 type을 나타내다.
. RR data : data field의 내용들은 Resource Record type에 의존한다.
< Control entries >
- data file에서 standard RR format을 따르지 않는 유일한 line이
control entry line들이다.
두 종류의 control entry가 있다.
. $INCLUDE
--> include line은 column 1에서부터 시작하고 뒤따라서 file name이
나온다.
예) $INCLUDE /etc/named/data/mailboxes
이라인은 file(/etc/named/data/mailboxes)를 load하기 위한
request로 해석된다.
. $ORIGN
--> origin 명령은 data file안에서 origin을 변화시키는 명령이다.
이 line은 column1에서부터 시작하고 뒤따라서 domain name이
나온다.
이것은 하나의 data file안에다 하나이상의 domain을 넣는데
유용하다.
< Resource Record Types >
- 다음은 자주 사용되는 RR type들이다.
- 다음은 hosts file의 예이다.
< SOA -Start Of Authority >
- 다음은 Start Of Authority resource record format이다.
- SOA record는 zone의 시작을 가리킨다. 그 zone은 다음 SOA record에서
끝난다.
. name --> zone name를 가리킴 , @은 현재의 zone 혹은 origin을
가리킴.
. IN --> address class
. SOA --> Resource Record 의 type
. Origin --> data file이 상주하는 host name
. person_in_charge --> name server를 책임지는 사람을 위한
mailing address
. Serial --> data file의 version number.
data file을 변화시킬때마다
이 number를 증가시켜야 한다.
secondary server들은 master server로 부터 data file을
copy 했던때부터 그 data file이 변화했었는지를 확인
하기위해 Serial field를 사용한다.
. Refresh --> 얼마나 자주 secondary name server가 data update시
primary name server하고 상의를 하는지를 나타냄.
. Retry --> refresh check 실패후 얼마나 오래 secondary server가
retry하는지를 나타냄.
. Expire -->secondary name server가 refresh를 얻지못해 완료되기
전에 data를 사용할수 있는 상한시간
. Minimum --> ttl을 열거하지 않은 resource record에서 ttl field
를 위해 사용되는 기본시간
- zone당 하나의 SOA가 존재해야 한다.
- 다음은 sample SOA resource record이다.
< NS - Name Server >
- 다음은 NS resource record format이다.
- Name Server record(NS)는 주어진 domain에 대해 권한이 있는
name server를 나열한다.
- 다음은 sample NS resource record이다.
< A - Address >
- 다음은 A resource record format이다.
- Address record(A)는 주어진 machine에 대한 address를 나열한다.
name field는 machine name이고 address는 IP address이다.
< HINFO - Host Information >
- 다음은 HINFO resource record format이다.
- HINFO는 host specific data를 포함한다.
< WKS - Well Known Services >
- 다음은 WKS resource record format 이다.
- Well Known Services record (WKS)는 명기된 address에서
특별한 protocol에 의해 지원되는 WKS를 설명하고 있다.
list of services 항목은 services database안에 명기된
list of services로 부터 온다.
- 다음은 WKS resource record example이다.
< CNAME -Canonical Name >
- 다음은 CNAME resource record format 이다.
- CNAME은 canonical name( 즉 formal혹은 real name) 을 위한 nickname을 열거한다.
nickname은 유일한 것이어야 한다.
모든 다른 resource record들은 nickname이 아니고 canonical name하고
관련이 되야 한다.
nickname들은 특히 machine name이 변했지만 여러분이 old machine name을
사람들이 사용할수 있도록 해줄때, 그런 과도기 동안에 유용하다.
- 다음은 sample CNAME resource record이다.
< PTR -Domain Name Pointer >
- 다음은 PTR resource record format이다.
- Pointer record(PTR)는 special name들이 그 domain안에 다른 location을
가리키는 것을 허락해준다.
PTR은 address(special name)를 real name으로 변환키 위해 IN-ADDR.ARPA
에서 주로 사용된다.
PTR name들은 그 zone에서 유일해야 한다.
- 아래 PTR record들은 special IN-ADDR.ARPA domain을 위해 reverse
pointer들을 설정한다.
< MX -Mail Exchanger >
- 다음은 MX resource record format이다.
- MX resource record들은 mail를 한 domain안에 있는 machine들이나 domain
으로 전달하는 법을 아는 machine을 열거하는데 사용된다.
아래보기에서 , Seismo.CSS.GOV은 mail를 Munnari.OZ.AU로 전달하는
법을 아는 mail gateway이다. 네트워크상에 있는 다른 machine들은
직접 Munnari.Seismo로 mail를 전달할수 없다.
preference value field는 mail를 single machine으로 전달하는
방법이 하나이상일때 mailer가 따라야할 순서를 나타낸다.
value가 높으면 높을수록 preference가 낮다.
- MX record들에서 mail routing을 위해 wildcard * 를 가진 name
을 사용할수 있다.
아래 예에서 , domain foo.COM안에 있는 host들 대한 모든 mail은
RELAY.CS.NET을 통해 route 된다.
아래예에서 wildcard resource record을 만든 것을 볼수 있는데
그것은 *.foo.COM을 위한 mail exchanger가 RELAY.CS.NET이라고
나타낸다.
*은 어떤 host나 혹은 foo.COM의 subdomain과 일치한다.
< MB - Mailbox >
- 다음은 MB resource record format이다.
- Mailbox record (MB)는 mail을 받기를 원하는 machine을 열거한다.
name field는 user login name을 포함한고, machine field는
mail이 전달되어야할 machine을 나타낸다.
Mailbox name들은 그 zone에서 유일해야 한다.
- 다음은 MB resource record 예제이다.
< MR - Mail Rename Record >
- 다음은 MR resource record format이다.
- 여러분은 user를 위한 alias을 나타내기 위해 Mail Rename (MR)을
사용한다.
name field는 하나의 corresponding MB record을 갖는 네번째 field에서
나열된 name을 위한 alias 을 나타낸다.
아래예에서, "postmistress"을 위해 받은 mail은 "miriam"으로
route된다.
< MINFO - Mailbox Information >
- 다음은 MINFO resource record format이다.
- Mail Information record (MINFO)는 mailing list를 위한 하나의
mail group을 만든다.
이 resource record는 적어도 항상 하나의 Mail Group resource record와
연관되있다. 그러나 Mail Box record와 함께 사용될수 있다.
name field는 mailbox이름을 나타낸다.
request field는 mail을 보내는곳을 나타낸다.
maintainer field는 error message들을 받는 mailbox을 나타낸다.
- 다음은 MINFO resource record 예제이다.
< MG - Mail Group Member>
- 다음은 MG resource record format이다.
- Mail Group record (MG)는 하나의 mail group의 member들을 나타낸다.
- 다음은 MG resource record 예제이다.
- mailing list을 set up하는 예는 아래와 같다.
6. Practical Example
- imaginary network이 필요로하는 file들을 구성해보자.
- 여러분의 network이 C-Class를 이용하는 세개의 network으로
구성되있다고 생각하자.
name number
junk 223.100.100
widget 223.100.101
zap 223.100.102
- imaginary network은 아래 그림과 같다.
- 다음은 zone junk안에 있는 host들을 reverse address들의 sample file이다.
- server widget과 zap을 위한 reverse address file들은 위와 같은
방법으로 쓰여진다.
< Adding a Cache Only Server >
- 여러분은 하나의 cache only server를 imaginary set up으로 첨가할수
있다. zone bond.junk.COM은 223.100.103.1인 host bond에 의해서
serve되고, 223.100.103.2- 223.100.103.80범위 안에 있는 host들을
가진다. 그것의 named.boot file은 아래와 같다.
< Self-contained DNS >
- 만약 여러분의 network이 Internet에 연결되지 않았어도 ,(즉 outside
world에 연결되지 않은 self-contained domain,)
DNS를 수행할수 있다.
- primary server을 위해 named.boot을 modify해야함.
- 새로운 named.root file을 create해야함.
- root server을 위한 file을 create해야함.
- 모든 다른 file들은 변하지 않아야 한다.
7. Setting Up DNS
- 이 부분은 named와 resolver를 시작시키는 정보를 포함한다.
< Starting named >
- /etc/named.boot file은 in.named daemona을 불러냄으로써 자동적으로
나타난다. 이것은 아래 line에 의해 /etc/rc.local에서 조절된다.
- 윗 line들은 여러분이 server안에서 사용중인 boot file이 /etc/named.boot
이다. 만약 다른 name을 사용한다면 , 아래와 같이 변경해야 한다.
< Starting the resolver >
- resolver를 수행하는 각 machine은 적당한 /etc/resolv.conf file
을 만든다.
- resolver는 query packet들을 만들어서 name server와 교환하는
몇개의 routin들로 구성되있다.
정상적으로 ,단지 NIS server만이 resolver library와 직접 연결될
필요가 있고, 다른 program들은 name들을 access하기 위해
정상적인 NIS function들을 사용한다.
위 내용들은 NIS master server상의 /var/yp안에 위치한
Makefile에서 -b flag를 사용함으로써 수행된다.
sendmail.mx의 사용은 mail host상의 /etc/sendmail.cf을 modifying 한다.
8. Modifying the database
- 여러분이 master DNS server안의 data file들중에서 하나의 host를
add,delete 할경우 또는 data file들을 modify할 경우 SOA resource
record안에 있는 Serial number를 변화시켜야 한다. 따라서
secondary server들은 그들의 data를 modify해야 한다.
그리고 master server에다 named을 알리고, data file들을 re-read와
internal database을 update해야 한다.
< named's PID >
- 성공적으로 named가 시작할때, 그것의 process ID을 /etc/named.pid file
로 write한다. 그래서 여러분은 named's process ID 을 얻기위해서
ps 을 수행시킬필요가 없고 단지 cat명령을 이용하는 것이 빠르다.
< Reload(SIGHUP) >
- named.boot을 re-read하는 named와 database을 reload하기 위해
다음과 같이 해야 한다.
# kill -HUP `cat /etc/named.pid`
(주의) 이전의 모든 cached data는 소멸되고, caching process가
다시 시작됨.
9. Debugging named
- kill utility를 통해 signal들을 보냄으로써 named을 debug 할수가 있다.
< Database Browsing (SIGINT) >
- named가 database를 생각하게끔 해주는 방법은 다음과 같다.
# kill -INT `cat /etc/named.pid`
- 이 signal를 받자마자 named은 현재의 database를 dump하고,
/var/tmp/named_dump.db로 저장한다.
이것은 여러분들에게 database가 정확하게 load되었는지 여부를
표시해준다.
만약 named이 부정확하게 수행되면 /usr/adm/messages에서 확인
할수 있고, syslog에 의해 log된 messages들을 check할수 있다.
예를 들어 , hostname을 nickname으로 나타낸 data file 있다면,
여러분은 다음과 같은 messages를 볼수 있다.
May 4 02:35:26 hostname named[4804] : hazy.widget.junk.COM
has CNAME and other data (illegal)
혹은, 만약 database가 문제일 경우,
May 1 11:02:33 hostname named[17808] : /etc/named/junk.zone:
line 759: database format error ()
< Turning on debugging (SIGUSR1) >
- debugging을 가동시키기위해 ,여러분은 -d option을 가진
named을 시작할수 있거나 혹은, 만약 named가 이미 수행중일때
다음과 같이 할수 있다.
# kill -USR1 `cat /etc/named.pid`
USR1은 debug level를 증가시킨다. 출력은 /var/tmp/named.run으로
간다.
< Turning off debugging (SIGUSR2) >
- debugging을 완전히 중지시키기 위해선 다음과 같이 한다.
# kill -USR2 `cat /etc/named.pid`
< Using nslookup >
- nslookup utility는 Internet domain name server들을 query할수
있도록 해주는 하나의 interactive program이다.
여러분은 특정한 host에 관한 정보를 요청하거나 혹은 domain안에
있는 일련의 host들을 print하기 위해 server들을 접촉할 수 있다.
- 여러분이 처음에 nslookup 명령을 칠때 아래와 같은 유사한
messages를 볼수 있을 것이다.
- '>'은 nslookup prompt이다.
여러분의 dafault server가 localhost나 혹은 다른 server인지는
DNS와 여러분이 사용하고 있는 server의 /etc/resolv.conf내용을
어떻게 설정했는가에 달려있다.
- 예를 들여, 만약 여러분이 junk.COM domain안의 lazy 라는 host의
주소를 알고자 할때 다음과 같이 한다.
> lazy
그러한 host가 있다면 주소가 나타날 것이다.
만약, 찾고자 하는 host가 그 domain안에 없으면 여러분은
fully qualified name을 써야 한다.
- 여러분이 정보를 요청했을때 server에 의해 보내진 query종류와
이러한 query들에게 도착한 대답들을 볼수 있는 방법은 다음과 같다.
> set debug
10. Administerring DNS for your domain
- DNS를 setup 하는 것은 server와 client들상에서 적당한 program들을
수행할 뿐만 아니라, domain name을 결정하고, complaint들을 대답하고
다른 여러 form들을 기록함으로써 public network에 참여할 수 있다.
< Types of Administrators and Their Responsibilities >
- DNS를 위한 여러분의 administrative responsiblity는 전체적 network
계층에서 여러분의 domain 위치에 달려있다.
예를 들어 , 작은 administrative domain안에 있는 name server들을
관리하는 것은 큰 zone의 authoritative set을 관리하는 것보다
책임이 들 따른다.
책임은 여러분이 하나의 domain 혹은 zone을 위한 chief authority
인지 여부와 혹은 chief authority에다 보고하는 administrator
인지에 달려있다.
- NIC는 Internet의 administrator들을 domain administrator과
chief authority와 technical contact와 chief으로 보고하는
administor들로 나눈다.
< Domain Administrator >
- domain administrator(DA)는 second level혹은 lower domain을 위한
coordinator,manager,technician이다.
- DA의 역할은 다음과 같다.
. domain을 등록해야 한다.
domain은 network 계층의 그 level에서 유일한 name을 가져야 한다.
network을 담당하는 조직과 접촉해서 적당한 domain regiistration
form을 요청해아 한다.
. domain안에서 host들을 naming하고 그 이름들을 verifying하는 것은
유일해야 한다.
많은 site들에서 , user들은 그들의 host들을 명명할수 있고,
반면에 administrator들은 server들을 명명할수 있다.
administrator는 하나의 zone안에서 중복 name들이 있으면 않된다.
이것을 확인하는 방법은 그 zone의 모든 resource record들을
조사하거나 혹은 nslookup program을 사용한다.
. user들로 부터 불평과 질문들을 다룬다.
. 보안문제들 , protocol 위반 , 다른 network의 오용을 대비해서
domain상에서 hosts들의 행동을 알아야 한다.
< Technical Contact >
- domain technical/zone contact는 DNS program과 file들을 수행하고
관리하는 name server들을 유지할 책임이 있다.
- Technical contact는 또한 network problem들을 해결하기 위해
그들의 Domain Administrator들과 다른 domain들의 DA와
상호작용해야 한다.
- technical contact의 가장 큰책임은 corresponding zone과 관련된
file들을 관리하는 것이다.
Revision History
작성일자 : 96.06.17
작성자 : 이진수
수정일자 :
수정자