DNS 및식별체계 고도화표준연구 A Research on the Standardization of DNS and Identification Infrastructure 수탁기관 : 안양대학교 2009. 10.
1-1 -
- 2 -
2-3 -
1 단계 D N S 확장표준화활동 X R I 국내표준화활동 과제연구팀 2 단계 D N S A nycast 라우팅프로세스국제표준추진 X R I 응용분야연구 K IS A, 과제연구팀 3 단계 D N S 존파일의다국어사용의국제표준도출 X R I 국제표준화활동추적 K IS A, 과제연구팀 - 4 -
- 5 -
1-6 -
2 XRDS - 7 -
- 8 -
<XRDS xmlns="xri://$xrds" ref="xri://(tel:+1-201-555-0123)*foo"> <XRD xmlns="xri://$xrd*($v*2.0)" version= 2.0 > <Query>*foo</Query> <Status code="100"/> <ServerStatus code="100"/> <Expires>2005-05-30T09:30:10Z</Expires> <ProviderID>xri://(tel:+1-201-555-0123)</ProviderID> <LocalID>*baz</LocalID> <EquivID>https://example.com/example/resource/</EquivID> <CanonicalID>xri://(tel:+1-201-555-0123)!1234</CanonicalID> <CanonicalEquivID> xri://=!4a76!c2f7!9033.78bd </CanonicalEquivID> <Service> <ProviderID> xri://(tel:+1-201-555-0123)!1234 </ProviderID> <Type>xri://$res*auth*($v*2.0)</Type> <MediaType>application/xrds+xml</MediaType> <URI priority= 10 >http://resolve.example.com</uri> <URI priority= 15 >http://resolve2.example.com</uri> <URI>https://resolve.example.com</URI> </Service> <Service> <ProviderID> xri://(tel:+1-201-555-0123)!1234 </ProviderID> <Type>xri://$res*auth*($v*2.0)</Type> <MediaType>application/xrds+xml;https=true</MediaType> <URI>https://resolve.example.com</URI> </Service> <Service> <Type match="null" /> <Path select="true">/media/pictures</path> <MediaType select="trueimage/jpeg"></mediatype> <URI append="path">http://pictures.example.com</uri> </Service> <Service> <Type match="null" /> <Path select="true">/media/videos</path> <MediaType select="truevideo/mpeg"></mediatype> <URI append="path" >http://videos.example.com</uri> </Service> <Service> <ProviderID> xri://!!1000!1234.5678</providerid> <Type match="null" /> <Path match="default" /> <URI>http://example.com/local</URI> </Service> <Service> <Type>http://example.com/some/service/v3.1</Type> <URI>http://example.com/some/service/endpoint</URI> <LocalID>https://example.com/example/resource/</LocalID> </Service> </XRD> </XRDS> - 9 -
- 10 -
- 11 -
- 12 -
- 13 -
- 14 -
- 15 -
- 16 -
- 17 -
- 18 -
- 19 -
- 20 -
3-21 -
- 22 -
- 23 -
- 24 -
- 25 -
- 26 -
- 27 -
- 28 -
QXRI (Path in bold) XRD @example <Path match="null"/> POSITIVE @example <Path></Path> POSITIVE @example <Path>/</Path> POSITIVE @example/ <Path>/</Path> POSITIVE @example// <Path>/</Path> NEGATIVE @example// <Path>//</Path> POSITIVE @example// <Path>/foo</Path> NEGATIVE @example/foo <Path>/foo</Path> POSITIVE @example//foo <Path>/foo</Path> NEGATIVE @example//foo <Path>//foo</Path> POSITIVE @example/foo*bar <Path>/foo</Path> NEGATIVE @example/foo*bar <Path>/foo*bar</Path> POSITIVE @example/foo*bar <Path>/foo*bar/</Path> POSITIVE @example/foo*bar <Path>/foo*bar/baz</Path> POSITIVE @example/foo*bar <Path>/foo*bar*baz</Path> POSITIVE @example/foo*bar <Path>/foo*bar!baz</Path> POSITIVE @example/foo*bar/ <Path>/foo*bar</Path> NEGATIVE @example/foo*bar/ <Path>/foo*bar/</Path> POSITIVE @example/foo*bar/ <Path>/foo*bar/baz</Path> POSITIVE @example/foo*bar/ <Path>/foo*bar*baz</Path> NEGATIVE @example/foo!bar <Path>/foo*bar</Path> NEGATIVE @example/foo!bar <Path>/foo!bar*baz</Path> POSITIVE @example/(+foo) <Path>/(+foo)</Path> POSITIVE @example/(+foo)*bar <Path>/(+foo)</Path> NEGATIVE @example/(+foo)*bar <Path>/(+foo)*bar</Path> POSITIVE @example/(+foo)*bar <Path>/(+foo)*bar*baz</Path> POSITIVE - 29 -
- 30 -
- 31 -
- 32 -
- 33 -
FOR EACH SEP CREATE set of nine SEL match flags (see text above) SET all flags to FALSE FOR EACH SEL of category x (where x=type, Path, or Mediatype) SET Present.x=TRUE IF match type on this SEL is POSITIVE IF select="true" ;see 13.4.2 ADD SEP TO SELECTED SET NEXT SEP ELSE SET Positive.x=TRUE ENDIF ELSEIF match="default" ;see 13.3.2 IF Positive.x!= TRUE AND ;see 13.3.5 Nodefault.x!= TRUE ;see 13.3.2 SET Default.x=TRUE ENDIF ENDIF ENDFOR FOR EACH category x (where x=type, Path, or Mediatype) IF Present.x=FALSE ;see 13.3.3 IF Nodefault.x!= TRUE ;see 13.3.2 SET Default.x=TRUE ENDIF ENDIF ENDFOR IF Positive.Type=TRUE AND Positive.Path=TRUE AND Positive.Mediatype=TRUE ;see 13.4.3 ADD SEP TO SELECTED SET NEXT SEP ELSEIF SELECTED SET!= EMPTY ;see 13.5.1 NEXT SEP ELSEIF (Positive.Type=TRUE OR Default.Type=TRUE) AND (Positive.Path=TRUE OR Default.Path=TRUE) AND (Positive.MediaType=TRUE OR Default.MediaType=TRUE) ADD SEP TO DEFAULT SET ;see 13.4.4 ENDIF ENDFOR IF SELECTED SET = EMPTY FOR EACH SEP IN DEFAULT SET ;see 13.5.2 IF (Positive.Type=TRUE AND Positive.Path=TRUE) OR (Positive.Type=TRUE AND Positive.MediaType=TRUE) OR (Positive.Path=TRUE AND Positive.MediaType=TRUE) ADD SEP TO SELECTED SET ENDIF ENDFOR IF SELECTED SET = EMPTY FOR EACH SEP IN DEFAULT SET ;see 13.5.2 IF Positive.Type=TRUE OR Positive.Path=TRUE OR Positive.MediaType=TRUE ADD SEP TO SELECTED SET ENDIF ENDFOR ENDIF ENDIF IF SELECTED SET!= EMPTY RETURN SELECTED SET ELSE RETURN DEFAULT SET ENDIF - 34 -
- 35 -
- 36 -
4-37 -
- 38 -
- 39 -
- 40 -
- 41 -
- 42 -
- 43 -
- 44 -
- 45 -
- 46 -
- 47 -
- 48 -
1 DNSEXT WG (2009.10 ) - 49 -
- 50 -
제목 발표시기 2009. 9 특기사항 RFC 4033, RFC 4034, RFC 4035, RFC 5155의개정판 내용요약 - 이문서는 DNSSECbis 문서집합에대한기술적설명을담고있음. 따라서이문서는 DNSSECbis 구현을위한자원으로서의역할과 DNSSECbis 의교정들에대한저장소역할을할것임 제목 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC 발표시기 2009. 6 특기사항 내용요약 - 이문서는 DNSSEC 에서 RSA/SHA-256, RSA/SHA-512 DNSKEY 와 RRSIG RR 을생성하는방법을설명함. 제목 Update to DNAME Redirection in the DNS 발표시기 2009. 9 특기사항 RFC 3363, RFC 3363, RFC 4294의개정판 - DNAME 레코드는 DNS의도메인이름트리의서브트리의재설정 내용요약 (redirection) 을지원함. 즉특정접미사로끝나는모든이름들을 DNS 의다른부분으로재설정할수있음. - 51 -
제목 Revised extension mechanisms for DNS (EDNS0) 발표시기 2009. 7 특기사항 내용요약 - DNS에는한계에곧도달하거나이미클라이언트의능력을서버에게다표시할수없는고정필드들이존재함. 이문서는하위호환성을제공하면서그러한프로토콜이성장할수있도록하는메커니즘을설명함 제목 Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records 발표시기 2009. 5 특기사항 내용요약 RFC 2845, RFC 2930, RFC 4635의개정판 - 이문서의목적은 DNS의 TSIG(secret key transaction authentication) 을위한알고리즘의하나로이용중인 HMAC-MD5을제거하는것임. 또한 TKEY(secret key establishment for DNS) 를위해이용중인 MD5 를제거하는것임. 제목 발표시기 2009. 9 특기사항 내용요약 RFC 2535, RFC 3755, RFC 4034의개정판 - 이문서는 IANA 레지스트리에 DNSSEC 암호화알고리즘식별자를할당하는방법에대해명시하고있음. 이문서에의해규칙이 "standard required" 에서 "RFC required" 으로변경되었음. 그러나, DNSSEC 구현에요구되거나권장되는알고리즘의목록은변경되지않음. - 52 -
제목 발표시기 2009. 9 특기사항 내용요약 - 이문서는새로운 RR 타입을 DNS 소프트웨어에서처리하는방법에 대해명시하고있음. 제목 발표시기 2009. 10 특기사항 내용요약 - 이문서는 DNSSEC 에서 DSNKEY 와 RRSIG RR 에사용하는 GOST 서명 과 hash 알고리즘의생성방법에대해설명하고있음. 제목 발표시기 2009. 10 특기사항 내용요약 RFC 1123, RFC 1035 의개정판 - 이문서는 DNS 트래픽의전송을위한 TCP 프로토콜의요구사항을갱 신하였음. - 53 -
제목 발표시기 2009. 10 특기사항 내용요약 - 이문서는 IANA 레지스트리테이블에 DNSSEC 알고리즘의사용여부 를나타내는 DNSSEC 알고리즘숫자열을추가하였음. 제목 A DNS RR for specifying the location of services (DNS SRV) 발표시기 2000. 2 특기사항 obsoletes RFC 2052 - 사용자가특정서비스를이용하기위해서먼저서버의정확한주소를알거나브로드캐스트로질의를해야하는데, SRV RR은관리자가하나의도메인에여러개의서버를이용하도록하고, 별무리없이호스트에서호스트로서비스를이동하는것이가능하게하며, 어떤호스트들은주서버로지정하고다른서버들은백업으로설정하는것을가능하게함. 내용요약 - 클라이언트는특정도메인의특정서비스 / 프로토콜을문의할수있고, 가능한서버들의이름들을돌려받게됨. - 예를들면 SRV를인식한 LDAP 클라이언트가 example.com 도메인에서 TCP 프로토콜을지원하는 LDAP 서버를알고자하는경우 _ldap._tcp.example.com에대해검색. - 여기서 SRV에대한 DNS 코드는 33이며, 밑줄은보통발생할수있는 DNS 레이블과의충돌을방지하기위해사용됨. - 54 -
제목 Secret Key Transaction Authentication for DNS (TSIG) 발표시기 2000. 5 특기사항 updates RFC 1035 - 이프로토콜은공유된비밀과일방해슁을통해트랜잭션레벨의인증 (authentication) 을제공하는데, 이것은인정된클라이언트로부터오는동적갱신이나인정된리커시브서버로부터오는응답을인증하는데이용될수있음. - 여기서공유된비밀을배포하는방법에대한내용은다루어지지않음. - DNSSEC에서는 DNS가출발지인증과공개키배포가가능하도록확장내용요약되었지만, 과도한로컬키캐슁과복수개의키들과서명들에대한인증추적이요구되는문제가있으며, 이를개선하기위한하나의방안으로제시된것임. - 클라이언트와지역서버간단순하고효율적인인증이필요할때여기서제안한안이이용될수있으며, 많은서버와통신해야하는일반적인서버와서버간인증의경우, 키의수가많아져서키관리가불가능해지므로부적합함. 제목 Domain Name System (DNS) IANA Considerations 발표시기 2000. 9 특기사항 - DNS는도메인이름아래 RR을계층적으로저장하는, 복사된분산안전계층적데이터베이스이며, 이러한데이터는각각독립적으로관리내용요약될수있는클래스들과존으로구조화됨. - 이문서에서는 DNS 질의와응답헤더들과 RR에서이용되는일반적인 IANA 매개변수들을다루고있음. - 55 -
제목 Secret Key Establishment for DNS (TKEY RR) 발표시기 2000. 9 특기사항 - TSIG는 TSIG RR을통해공유된비밀키로 DNS 메시지를효율적으로인증하는수단을제공하지만, 그러한키를직접교환하는방법외에다른메커니즘을제공하고있지않음. 내용요약 - 이문서에서는 TKEY RR을정의하고, 이를 DNS 리졸버와서버들사이에서공유비밀키를설정하고삭제하는여러모드에서이용할수있도록함. 제목 DNS Request and Transaction Signatures ( SIG(0)s ) 발표시기 2000. 9 특기사항 updates RFC 2535 내용요약 - DNSSEC을구현하는과정에서미약하지만서로호환이되지않는변화가요구되어이를명시한것이 SIG(0) 임. 제목 Domain Name System Security (DNSSEC) Signing Authority 발표시기 2000. 11 특기사항 updates RFC 2535 내용요약 - 검토대상에서제외 - 56 -
제목 Secure Domain Name System (DNS) Dynamic Update 발표시기 2000. 11 특기사항 obsoletes RFC 2137/ updates RFC 2535, RFC 2136 내용요약 - 이문서는보안 DSN 동적업데이트를수행하는방법에대해제안하고있음. 이방법은최소한의변경으로프로콜을유연하고유용하게적용할수있도록함. - 동적업데이트메시지의인증은데이터의 DNSSEC 유효성과분리되어있음. - 인증요청에따른보안통신과처리는인증을제공하는데에사용됨. 제목 DNS Security Extension Clarification on Zone Status 발표시기 2001. 3 특기사항 내용요약 - 검토대상에서제외 - 57 -
제목 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 발표시기 2001. 5 특기사항 obsoletes RFC 2537 내용요약 - 이문서에서는 RSA/SHA1 SIG RR을생성하는방법을기술함 - DNS에서의 RSA 서명을위한표준이적용된이후해슁에대한발전이있었는데, 이를도입하기위한새로운 DNS 서명알고리즘이필요했고, 이문서에는그것을정의함 제목 A DNS RR Type for Lists of Address Prefixes (APL RR) 발표시기 2001. 6 특기사항 실험적인프로토콜 내용요약 - DNS에서는 A RR을이용하여도메인이름을 IPv4 주소로번역하는데, 망이나주소범위에대한여러제안들이존재함 - 이문서에서는주소프리픽스 (prefix) 리스트를위한새로운 APL RR을제안함 제목 Applicability Statement for DNS MIB Extensions 발표시기 2001. 11 특기사항 내용요약 - 정보 - 이문서는 DNS 서버와리졸버 MIB 확장이 6년이상 proposed 표준으로있었음에도불구하고, 결국적용되지못하고 historical 상태로바뀔수밖에없었던이유를설명함 - 58 -
제목 DNSSEC and IPv6 A6 aware server/resolver message size requirements 발표시기 2001. 12 특기사항 updates RFC 2874, RFC 2535 - 이문서는 DNSSEC 나 A6 레코드중하나를지원하기위해선언된 DNS 객체의 EDNS0의지원을의무화하였음. - 이요구사항은새로운구조가 DNS 메시지의사이즈를증가시켰기때내용요약문에필요함. - 이문서는새로운요구사항을추가하여 RFC 2535, RFC 2874를업데이트하였음. 제목 Indicating Resolver Support of DNSSEC 발표시기 2001. 12 특기사항 내용요약 제목 Representing IPv6 addresses in DNS 발표시기 2002. 8 특기사항 updates RFC 2673,RFC 2874 - IETF에서는 IPv6 주소를위해 2가지주소형식 (AAAA[RFC1886], A6[RFC2874]) 으로표준화를시작했으나혼돈과충돌이있어하나의안으로정리될필요성이대두되었음. - 이문서는이러한상황을정리하기위한것으로서, IPv6 주소의역방내용요약향매핑을지원하기위한이진라벨 (Binary Label) 에관한문제를다루고있음 - 이문서는 2001년 DNSEXT와 NGTRANS 합동회의에서다루어진기술적논의에기반한내용이주를이룸 - 59 -
제목 Tradeoffs in DNS support for IPv6 발표시기 2002. 8 특기사항 updates RFC 2673, RFC 2874 내용요약 - IETF에서는 IPv6를지원하기위한 DNS의방안으로 2가지다른제안을가지고있는데, 어떤방안이더나은지에대한합의에도달하지못함상태임 - 이문서에서는각방안의장단점을검토하여더나은방안에대한결론을도출하기위한노력의일환으로작성됨문서임 제목 Obsoleting IQUERY 발표시기 2002. 11 특기사항 updates RFC 1035 내용요약 - DNS 역탐색에이용되는 IQUERY 방법은구현이되지않거나, 구현이되어도사용하지않는것이일반적임. 이것은그방법이현명한방법이못되며, 또다른방법인 PTR 질의를이용하는것이훨씬더현명한방법이기때문임 - 이문서에서는 IQUERY 방법전체를제거하여삭제하는내용을담고있음 - 60 -
제목 Limiting the Scope of the KEY Resource Record out 발표시기 2002. 12 특기사항 updates RFC 2535 내용요약 - 검토대상에서제외 제목 Handling of Unknown DNS Resource Record (RR) Types 발표시기 2003. 9 특기사항 내용요약 제목 DNS Extensions to support IP version 6 발표시기 2003. 10 특기사항 obsoletes RFC 3152, RFC 1886 내용요약 - 이문서는 DNS에서 IPv6를지원하기위해변화되어야하는부분을다루고있음. - 여기에는 IPv6 주소를저장하기위한 RR, IPv6 주소에기반한탐색, 기존의인터넷주소를반환하는질의에대한변화된정의를포함하며, 이러한확장은기존응용과 DNS 구현자체와호환될수있도록설계됨. - 61 -
제목 GSS Algorithm for TSIG (GSS-TSIG) 발표시기 2003. 10 특기사항 updates RFC 2845 내용요약 - TSIG(Secret Key Transaction Authentication for DNS) 는트랜잭션레벨의인증을제공함. - TSIG는새로운알고리즘에따라확장이가능한데, 이문서에서는 GSS-API(Generic Security Service Application Program Interface) 에기반한알고리즘을정의함 제목 Redefinition of DNS AD bit 발표시기 2003. 11 특기사항 updates RFC 2535 - 이문서는 RFC 2535에서정의된내용을변경한다. - 이문서는서버의보안정책에따라레코드나응답의암호화검증내용요약여부를설정하는데에 DNS 헤더의 AD 비트를사용하도록재정의한다. - 검토대상에서제외 제목 Delegation Signer Resource Record 발표시기 2003. 11 특기사항 updates RFC 3090, RFC 3008, RFC 2535, RFC 1035 내용요약 검토대상에서제외 - 62 -
제목 KEY RR Secure Entry Point Flag 발표시기 2004. 4 특기사항 updates RFC 3755, RFC 2535 내용요약 검토대상에서제외 제목 Legacy Resolver Compatibility for Delegation Signer 발표시기 2004. 5 특기사항 updates RFC 3658, RFC 2535 내용요약 검토대상에서제외 제목 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 발표시기 2004. 8 특기사항 updates RFC 3755, RFC 2535 내용요약 검토대상에서제외 - 63 -
제목 Threat Analysis Of The Domain Name System 발표시기 2004. 8 특기사항 내용요약 - DNSSEC에대한연구는진행중이지만, DNSSEC이방어하고자하는보안위협에대한정리가안되어있었음 - 특히 cart-before-the-horse 상황은위협에대한명확한정리가안되어있는상황이어서 DNSSEC이원래의도한바를만족시키고있는지를판단하기가어려운상황임 - 이문서는 DNS에대해알려진보안위협을문서화하고, 그를통해 DNSSEC이이러한위협을방지하는유용한도구인지를밝히는시도로작성됨 제목 DNS Security Introduction and Requirements 발표시기 2005. 3 특기사항 내용요약 obsoletes RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845/ updates RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3007, RFC 3597, RFC 3226 - DNSSEC은 DNS에게데이터근원지인증과데이터무결성기능을추가함. 본문서에서는이러한보안기능확장과기능, 한계등을소개함 - 또한이문서에서는 DNSSEC이제공하지못하는서비스들을논의하고. DNSSEC 관련문서들간의관계를정리함 - 64 -
제목 Resource Records for the DNS Security Extensions 발표시기 2005. 3 특기사항 내용요약 obsoletes RFC 3845, RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757/ updates RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3007, RFC 3597, RFC 3226 - 이문서는 DNSSEC을설명하는문서들중하나임 - DNSSEC은 RR들과프로토콜개정들의집합체로서 DNS에게근원지인증을제공하는데, 이문서에서는 DNSKEY(public key), DS(delegation signer), RRSIG(resource record digital signature) 와 NSEC( authenticated denial of existence) RR 타입을정의하며, 각 RR의형식과목적, 사용예를자세히설명함 제목 Protocol Modifications for the DNS Security Extensions 발표시기 2005. 3 특기사항 내용요약 obsoletes RFC 3845, RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757/ updates RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3007, RFC 3597, RFC 3226 - 본문서는 DNSSEC을설명하는문서들중하나임 - DNSSEC은 RR들과프로토콜개정들의집합체로서 DNS에게근원지인증을제공하는데, 본문서에서는 DNSSEC 프로토콜확장내용을담고있음 - 이문서에서는서명된존개념과 DNSSEC을이용하는요구사항을담고있으며, 이러한기술들은보안-인식리졸버가 DNS RR들과공식 DNS 오류를인증할수있게함 - 65 -
제목 Domain Name System (DNS) Case Insensitivity Clarification 발표시기 2006. 1 특기사항 updates RFC 1034, RFC 1035, RFC 2181 내용요약 - DNS 의이름은대소문자의구별이없는데, 이문서에서는이러한대소 문자무구별의의미를설명하고, 규칙들에대한명확한정의를제공함 제목 Storing Certificates in the Domain Name System 발표시기 2006. 3 특기사항 obsoletes RFC 2538 내용요약 - 일반적으로암호화된공개키가배포되며, 그것들은인증서로인증됨. CERT RR 은이러한인증서와관련된인증서요청리스트를 DNS 에저 장하기위해정의됨 제목 Minimally Covering NSEC Records and DNSSEC On-line Signing 발표시기 2006. 4 특기사항 updates RFC 4035, RFC 4034 내용요약 - 이문서에서는 RFC 4034에의해작은영역의이름들을지원하는 DNSSEC NSEC RR이어떻게구성되는지설명함 - 요구에의해이러한 RR을생성하고서명하면, 공인된네임서버는존의내용을노출하는것을효율적으로중단시킬수있으며, 그렇지않은경우서명된존에서 NSEC 레코드체인을검색할수있음 - 66 -
제목 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 발표시기 2006. 5 특기사항 내용요약 - 이문서에서는 DNS 의 DS(Delegation Signer) RR 에서 SHA-256 축약 타입을이용하는방법을설명함. 부모존에저장된 DS 레코드는자식 존의 DNSKEY 를가리킴 제목 The Role of Wildcards in the Domain Name System 발표시기 2006. 7 특기사항 updates RFC 1034, RFC 2672 내용요약 - 이문서는 RFC 1034 에서정의한와일드카드문자정의에대한개정으 로서, 와일드카드와 CNAME 의상호작용에변화가있으며, 오류조건이 제거되고, 와일드카드의중요개념을정의한단어들에변화가있음 HMAC SHA (Hashed Message Authentication Code, Secure Hash 제목 Algorithm) TSIG Algorithm Identifiers 발표시기 2006. 8 특기사항 - DNS에서 TSIG RR을이용하기위해서는암호화된메시지인증코드에대한정의가필요함. 현재까지는 HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) 와 GSS (Generic Security 내용요약 Service) TSIG 알고리즘만정의됨 - 이문서에서는 HMAC SHA (Secure Hash Algorithm) TSIG 알고리즘을위한식별자와구현요구사항을표준화하고, TSIG에서 HMAC의결합을지원하는방안을정의함 - 67 -
제목 Derivation of DNS Name Predecessor and Successor 발표시기 2006. 9 특기사항 내용요약 - 이문서에서는정규순서로나열된선행자와후행자이름을유도할수있는 2가지방안을설명함. 이들방법은동적인 NSEC RR 합성에이용되며, 이것은보안-인식네임서버가 DNSSEC 보안존의이름들을노출하지않으면서인증된존재거부를지원할수있음 A DNS Resource Record (RR) for Encoding Dynamic Host 제목 Configuration Protocol (DHCP) Information (DHCID RR) 발표시기 2006. 8 특기사항 - DHCP 클라이언트는동일한 FQDN을수정하거나, 다른목적때문에 DNS에추가된 DNS FQDN을수정하려고할수있는데, DHCP 서버또는 DHCP 클라이언트가 DNS 수정을하려고하는경우충돌이발생내용요약할수있음 - 이러한충돌을해결하기위해 RFC 4703에서는 DNS에클라이언트의식별자를저장하여모호하게연계된도메인이름을제거하고자함 - 이문서는이러한목적으로정의된 DHCID RR을소개함 - 68 -
제목 Link-local Multicast Name Resolution (LLMNR) 발표시기 2007. 1 특기사항 내용요약 - IESG 메모 : 원래 proposed 표준으로진행할예정이었으나 IETF에서는이방식에대한합의에이르지못함. 현재많은검토의견과입력이있는상태이며, 초기버전에대한구현과적용이이루어짐 - LLMNR(Link-Local Multicast Name Resolution) 의목적은일반적인 DNS 이름레졸루션에서가능하지않은레졸루션을가능하게하는것임 - LLMNR은현재와미래에등장할모든 DNS 형식과타입, 클래스를지원할예정이며, 지역링크에서만동작할에정이므로 DNS를대체하는것으로생각할수는없음 제목 DNS Security (DNSSEC) Experiments 발표시기 2007. 7 특기사항 내용요약 - 이문서는실험적으로진행된, DNSSEC 의또다른, 비호환방법을설명 하고있음 제목 DNS Security (DNSSEC) Opt-In 발표시기 2007. 7 특기사항 내용요약 - 실험프로토콜 - DNSSEC 확장에서사인되지않은서브존에대한위임은암호로보안이제공되는데, 이러한암호를유지하는것은항상필요하거나실용적이지는않음. 이문서는커다란존에서관리자가암호화를생략하여, DNSSEC을적용하는비용을관리할수있는, 실험적인 Opt-In" 모델을설명함 - 69 -
제목 DNS Name Server Identifier Option (NSID) 발표시기 2007. 8 특기사항 - DNS anycast, 부하균등, 그리고다른메커니즘들은하나이상의네임서버가하나의 IP 주소를공유하는것을가능하게하는데, 이에따라특정질의에대해어떠한네임서버가응답했는지알려주는것이어렵내용요약게됨. 현재의 ad-hoc 메커니즘에서는구성을디버깅할필요가있는경우운영자가추가질의를할수있는데, 이러한네임서버의식별할수있는가장좋은방법은응답안에이러한정보를담고있는것임. 이문서는이를지원하기위한확장내용을담고있음. 제목 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover 발표시기 2007. 8 특기사항 내용요약 정보 - 모든 DNS 보안인식리졸버는 DNS 서명존으로부터의응답을확인하는기반으로이용하기위해적어도하나의트러스트앵커를가져야함 - 여러가지이유로인해대부분의 DNS 보안인식리졸버는여러개의트러스트앵커를갖는데, 이러한트러스트앵커에대한자동화된수정방법이필요함. 본문서에서는보안인식리졸버에서의자동화된트러스트앵커롤오버가만족해야하는요구사항들을정리함 제목 Automated Updates of DNS Security (DNSSEC) Trust Anchors 발표시기 2007. 9 특기사항 - 이문서는자동화되고, 인증되며적법한 DNSSEC 트러스트앵커 (trust 내용요약 anchor) 의수정방법을설명함. 이방법은리졸버관리행동의변화와 DNSKEY 레코드에하나의플래그비트추가를요구함 - 70 -
제목 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence 발표시기 2008. 3 특기사항 - DNSSEC 확장에서인증된존재거부를존재 NSEC RR을도입했는데, 이문서에서는또다른 NSEC3 RR을소개함. 이것은동일한인증된존내용요약재거부를지원하지만, 존목록에대한계량과존임존의단계적인확장을가능하게함 제목 발표시기 2008. 11 특기사항 obsoletes RFC 2929/updates RFC 1183, RFC 3579 내용요약 - DNS RR 타입, CLASSes, operation codes, error codes, DNS 프로토콜 메시지헤더비트, AFSDB RR 서브타입의할당은 IANA 인자를정하 는고려사항을명기한다. 제목 발표시기 2009. 1 특기사항 updates RFC 2181 - 현재인터넷에서의 DNS 는심각한위기에처해있고 DNS 프로토콜이완벽하게암호화되기전에네임서버를방해하는수단들이나오고있다. 내용요약 - 그러나, 이런상황에대처하기위한암호화된 DNS 에대한표준화가아직이루어지지않았다. 이문서에서는부정확한응답에탄력적으로대응할수있는 DNS에대해제안한다. - 이문서는 RFC 2181을업데이트한다. - 71 -
제목 발표시기 2009. 8 특기사항 내용요약 - 이문서는광대역게이트웨이와유사한네트워크장치에서발견되는 DNS 프록시를구현하기위한안내를제공한다. RFC 제목 범주 성격 2782 A DNS RR for specifying the location of services (DNS SRV) 기능 표준화대상 2845 Secret Key Transaction Authentication for DNS (TSIG) 개정 (3645) 2929 Domain Name System (DNS) IANA Considerations 개정 (draft) 2930 Secret Key Establishment for DNS (TKEY RR) 보안 표준화대상 2931 DNS Request and Transaction Signatures (SIG(0)) 보안 표준화대상 3007 Secure Domain Name System (DNS) Dynamic Update 개정 (4034) 3008 Domain Name System Security (DNSSEC) Signing Authority 폐지 (4034) 3090 DNS Security Extension Clarification on Zone Status 폐지 (4034) 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 보안 표준화대상 3123 A DNS RR Type for Lists of Address Prefixes (APL RR) 실험 3197 Applicability Statement for DNS MIB Extensions 정보 3225 Indicating Resolver Support of DNSSEC 개정 (4034) 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements 개정 (4034) 3363 Representing IPv6 addresses in DNS 기능 표준화대상 3364 Tradeoffs in DNS support for IPv6 기능 표준화대상 3425 Obsoleting IQUERY 기능 표준화대상 3445 Limiting the Scope of the KEY Resource Record out 폐지 (4034) - 72 -
3596 DNS Extensions to support IP version 6 기능 표준화대상 3597 Handling of Unknown DNS Resource Record (RR) Types 개정 (4034) 3645 GSS Algorithm for TSIG (GSS-TSIG) 보안 표준화대상 3655 Redefinition of DNS AD bit 폐지 (4034) 3658 Delegation Signer Resource Record 폐지 (4034) 3755 Legacy Resolver Compatibility for Delegation Signer 폐지 (4034) 3757 KEY RR Secure Entry Point Flag 폐지 (4034) 3833 Threat Analysis Of The Domain Name System 보안 표준화대상 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 폐지 (4034) 4033 DNS Security Introduction and Requirements 보안 표준화대상 4034 Resource Records for the DNS Security Extensions 보안 표준화대상 4035 Protocol Modifications for the DNS Security Extensions 보안 표준화대상 4343 Domain Name System (DNS) Case Insensitivity Clarification 기능 표준화대상 4398 Storing Certificates in the Domain Name System 기능 표준화대상 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing 보안 표준화대상 4471 Derivation of DNS Name Predecessor and Successor 보안표준화대상 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 보안 표준화대상 4592 The Role of Wildcards in the Domain Name System 기능표준화대상 4635 HMAC SHA (Hashed Message Authentication Code, 보안 Secure Hash Algorithm) TSIG Algorithm Identifiers 표준화대상 A DNS Resource Record (RR) for Encoding Dynamic 4701 Host Configuration Protocol (DHCP) Information 기능 표준화대상 (DHCID RR) 4795 Link-local Multicast Name Resolution (LLMNR) 실험적 4955 DNS Security (DNSSEC) Experiments 실험적 4956 DNS Security (DNSSEC) Opt-In 실험적 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover 보안 표준화대상 5001 DNS Name Server Identifier Option (NSID) 기능표준화대상 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors 보안 표준화대상 - 73 -
5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence 5395 5452 5625 보안 표준화대상 2 DNSOP WG (2009.10 ) - 74 -
예정또는완료여부 Done Done Done Done Done Done Done Done Done Done Done 내용 Submit I-D: revised Root Server Requirements. Submit I-D: revised version of Key Handling. Submit I-D: first version of Servers Sharing IP#. Submit I-D: first version of Performance and Measuring. Submit I-D: revised version of Key Handling. Submit I-D: revised version of Servers Sharing IP#. Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). Submit I-D: 2nd revised version of Servers Sharing IP#. Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational Submit Observed DNS Resolution Misbehavior to the IESG for Informational Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. Done Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. Done Done Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational Done Submit DNSSEC Operational Procedures to IESG for BCP Done Submit Identifying an Authoritative Name Server to IESG for - 75 -
Informational Done Done Sep 2007 Sep 2007 Sep 2007 Oct 2007 Dec 2007 Dec 2007 Feb 2008 Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Submit I'm Being Attacked by PRISONER.IANA.ORG! to IESG for FYI Submit Locally-served DNS Zones to IESG for BCP Submit DNS Response Size Issues to IESG for Informational Submit Considerations for the use of DNS Reverse Mapping to IESG for BCP Submit AS112 Nameserver Operations to IESG for Informational Submit Initializing a DNS Resolver with Priming Queries to IESG for BCP 제목 발표시기 2009. 5 특기사항 내용요약 Informational - 이문서는호환성을고려한네임서버관리시스템의요구사항과필요한시스템을언급한다. - 76 -
제목 발표시기 2009. 10 특기사항 내용요약 informational - 따라서, 이문서는방화벽운영자에게예기치않은응답에대처하기위한배경정보와기술적인충고를제공한다. 제목 발표시기 2009. 10 특기사항 내용요약 Informational - 이문서는새로운 AS112 노드를설치하기위해필요한과정과 AS112의운영에대해설명하고있다. - 77 -
제목 Root Name Server Operational Requirements 발표시기 2000. 6 특기사항 내용요약 Obsoletes: RFC 2010, 최근적용예 - 인터넷이전세계의사회적, 경제적하부구조로서중요도가높아짐에따라인터넷하부구조자체의정확하고, 안전하며, 안정되면서보안이강화된동작에초점이맞추어지고있는데, 루트도메인네임서버는기술적하부구조의가장중요한부분으로인식되고있음. - 이문서는루트네임서버의운영을위한가이드라인을제공하는데초점이맞추어져있는데, 다른주요 (gtlds, cctlds, 그외주요 ) 존서버운영자에게도유용하게쓰일수있을것임. 제목 Distributing Authoritative Name Servers via Shared Unicast Addresses 발표시기 2002. 4 특기사항 내용요약 Informational - 이문서는하나의네임서버운영자가여러지역에서하나의네임서버를접근할수있도록하는예들을설명함. 이러한실용예를개발하고적용하는목적은망위상에서서비스를받지못한영역까지 DNS 서버들을분산시키고, 그러한영역에서의 DNS 질의응답지연을줄이는데있음 제목 Preventing Use of Recursive Nameservers in Reflector Attacks 발표시기 2008. 10 특기사항 내용요약 최신적용예 - 이문서에서는 DoS 공격에서디폴트로재귀서버로설정된네임서 버가리플렉터로동작하는것을막기위한방안을설명함. - 78 -
제목 DNS IPv6 Transport Operational Guidelines 발표시기 2004. 9 특기사항 내용요약 최신적용예 - 이문서는 IPv4와 IPv6가혼재된환경에서질의와응답이교환되는현세계에서 DNS를운용하는방법에관련된최신의적용예와가이드라인을제공함 제목 Common Misbehavior Against DNS Queries for IPv6 Addresses 발표시기 2005. 5 특기사항 내용요약 Informational - DNS 서버가질의된 AAAA RR을처리하는과정중에일으키는오동작중잘알려진경우들이있는데, 그러한상황이벌어지면반드시가능해야하는 IPv4 통신을방해할수도있고, 네임레졸루션에심각한지연을초래하거나 DoS 공격을만들수도있음. - 이문서에서는이러한오동작중이미알려진것들과그들이끼치는영향을자세히설명함. 제목 IPv6 Host Configuration of DNS Server Information Approaches 발표시기 2006. 2 특기사항 Informational - 이문서에서는 IPv6 호스트에서 DNS 네임서버정보를설정하는 3가지각기다른접근방안을설명함. - 이중어떤방안이좋은지에대한합의는이루어지지않았으며, 이문서의분석은각접근방안의제안자들이수행한것으로서 IETF 전내용요약체의합의된내용은아님. - RA 옵션 방식과 잘알려진애니캐스트 접근방식은아직까지표준화가안이루어졌으며, 결과적으로이들방안에대한분석이미래에제안될특정제안에는완전히적용되지않는경우도발생할것임 - 79 -
제목 Operational Considerations and Issues with IPv6 DNS 발표시기 2006. 4 특기사항 내용요약 Informational - 이문서에서는 IPv6 DNS의운용측면의고려사항과문제들을설명하는데, 여기에는특정 IPv6 주소에대한정리, 이미알려진 DNS구현오류, DNS 리졸버가 IPv6를지원하기위해서비스도입은어떻게해야하고, 동작은어떻게해야하는지, DNS 갱신에대한고려, 기타고려사항등이포함됨. - 또한이문서는이미 IPv4 DNS 경험이있는이들이 IPv6 DNS를고려할수있도록하는정보들을담고있음 제목 DNSSEC Operational Practices 발표시기 2006. 9 특기사항 내용요약 Obsoletes: RFC 2541, Informational - 이문서에서는 DNSSEC을실제적용한사례들을담고있으며, 이문서의주대상은 DNSSEC을적용한존관리자들임. - 이문서에서는 DNS에서키와서명을이용하는측면들을논의하고, 키생성, 키보관, 서명생성, 키퇴역, 관련정책등에관련된내용을논의함 제목 Observed DNS Resolution Misbehavior 발표시기 2006. 10 특기사항최신적용예 - 이문서에서는상당한규모의질의가루트와 TLD 서버로보내졌을때발생하는 DNS 반복서버동작을설명하는데, 특히반복서버개발자에게이러한불필요한질의는줄이도록권고함. 내용요약 - 이문서는총 13개루트네임서버중 2개네임서버와 13개의모든 com/net TLD 네임서버의비정상적인질의트래픽패턴에대한관찰과분석을직접반영한것임 - 80 -
제목 Requirements for a Mechanism Identifying a Name Server Instance 발표시기 2007. 6 특기사항 Informational 내용요약 - DNS Anycast, 부하균형이나다른메커니즘의사용이증가하면서 하나이상의네임서버가하나의 IP 주소를공유하는경우가늘어나 고있는데, 이로인해특정질의에대해네임서버집단중어느서 버가응답했는지알려주는것이어려워졌음. 그러나특정질의에대 해응답한네임서버를식별할수있는표준화된방법은관리자에게 진단도구로아주유용할수있음. - 이를해결하기위한방안으로현재제시된메커니즘들은약점을가 지고있으며, 적어도그러한메커니즘이설계되고채택되어야하는 근본적인분석이결여되어있음. - 이문서에서는 DNS 프로토콜의구현에서널리쓰이고있는기존방 법들을설명하는데, 여기에는각방법의장단점과개선된메커니즘 의특성등이포함됨 - 81 -
1 Unicode DNS - 82 -
- 83 -
- 84 -
- 85 -
- 86 -
- 87 -
- 88 -
2 Anycast DNS - 89 -
- 90 -
- 91 -
- 92 -
- 93 -
- 94 -
- 95 -
- 96 -
- 97 -
- 98 -
IDNABIS Working Group Internet-Draft Intended status: Informational Expires: April 15, 2010 C. Park H. Paik Korea Internet & Security Agency of Korea E. Jung Anyang University X. Lee China Internet Network Information Center October 12, 2009 Unicode Resource Records of DNS Host Information for Internationalized Domain Names draft-park-idnabis-unirr-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference - 99 -
material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Although Internationalized Domain Names in Applications (IDNA) contributes the population of the Internationalized Domains, it forces human DNS managers to handle unreadable DNS records. In order to enable human managers to easily edit or modify DNS records, DNS servers should allow Unicode resource records. This document defines the formats of DNS Resource Records and a translation process that supports Unicode Resource Records without ruining the interoperability with existing DNS infrastructure. - 100 -
Table of Contents 1. Introduction.................................... 3 2. Terminology.................................... 3 3. Problem Statements............................... 4 3.1. Applicable types of DNS Resource Records............... 4 3.1.1. Administrative Resource Records.................... 4 3.1.2. Host Information Resource Records.................. 4 3.2. Translation Process.............................. 4 4. DNS Resource Records............................. 5 4.1. A Resource Record............................. 5 4.2. AAAA Resource Record.......................... 5 4.3. CNAME Resource Record.......................... 5 4.4. PTR Resource Record............................ 5 5. Translation Process................................ 5 6. Security Considerations.............................. 6 7. IANA Considerations............................... 7 8. References.................................... 7 8.1. Normative References............................ 7 8.2. Informative References........................... 7 Authors' Addresses.................................. 7 1. Introduction Internationalized Domain Names in Applications (IDNA) [RFC3490] [1] has applications use an "ACE label" (ACE stands for ASCII Compatible Encoding) to represent an Internationalized Domain Names (IDN). The main advantage of IDNA is that lower-layer protocols need not be - 101 -
aware of the existence of IDNA. For the reason, IDNA is widely accepted where IDN is needed, especially Web browsers. Though it does not require any changes of existing DNS actors including DNS servers, resolvers, and protocol elements, it demands the use of ACE label in DNS database. Since an ACE label is difficult for human to read or infer, human managers cannot directly edit DNS database and cannot easily examine the validness of DNS records. In order to use a Unicode label instead of an ACE label in the DNS database, several technical factors should be considered. First, the types of DNS Resource Records should be decided. Some types are not adequate to hold Unicode [3] label due to the interoperability with other DNS standards. Second, a translation process of DNS server that does not hurt the interoperability with IDNA should be considered. By inserting a thin translation process between DNS database and DNS protocols, the support of Unicode Resource Records is possible while maintaining the interoperability. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Unicode [3] is a coded character set containing tens of thousands of characters. A single Unicode code point is denoted by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two hexadecimal numbers separated by "..", with no prefixes. - 102 -
A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". (The zero-length root label described in [STD13], which can be explicit as in "www.example.com." or implicit as in "www.example.com", is not considered a label in this specification.) IDNA extends the set of usable characters in labels that are text. For the rest of this document, the term "label" is shorthand for "text label", and "every label" means "every text label". An ACE label is an internationalized label that can be rendered in ASCII and is equivalent to an internationalized label that cannot be rendered in ASCII. 3. Problem Statements 3.1. Applicable types of DNS Resource Records A large number of Resource Records have been defined over the 25 years of the DNS specification. However, applicable types are restricted due to not all Resource Records can hold IDN data. The applicable types can be grouped with the purpose of administrative and host information. 3.1.1. Administrative Resource Records SOA, NS, and MX Resource Records are defined for the administrative purpose. SOA Resource Record describes the global characteristics of the zone. NS Resource Record defines name servers that are authoritative for the zone. MX Resource Record defines the mail - 103 -
servers for the zone. These Resource Records are in close connection with other standards and this document does not have any intention to update the existing standards so IDNA standard does. Unless the related standards are revised to invite the use of IDNA, these Resource Records SHOULD NOT be the target of this standard. 3.1.2. Host Information Resource Records A, CNAME, PTR, and AAAA Resource Records are defined for holding host information of the zone. A and AAAA Resource Records are used to indicate IPv4 and IPv6 address for the target domain name respectively. CNAME Resource Record is used to allows one host be defined as the alias name for another host. PTR Resource Record stands for resolving IP address into host name. 3.2. Translation Process An ACE-encoded Resource Record is necessary to support the interoperability of existing DNS standards, but human mangers suffer for handling it. In order to resolve this issue, DNS Resource Records should be written with Unicode characters. However, this approach will conflict existing DNS infrastructure. To avoid this conflict, a DNS server should translate an ACE-encoded Resource Record in a DNS query packet into a Unicode Resource Record. Reversely, it should also translate a Unicode Resource Record into an ACE-encoded Resource Record in a DNS answer packet. By adopting this translation process into a DNS server, human managers can freely use Unicode Resource Records while maintaining the interoperability with IDNA. - 104 -
4. DNS Resource Records 4.1. A Resource Record In A Resource Record, the name field of host name MAY be written with Unicode character strings. 'hangang'{u+d55c U+AC15} represents Han River in Seoul, Korea. Actually, {U+D55C U+AC15} will be replaced with the corresponding Korean characters in DNS Resource Record. A sample record is as below. {U+D55C U+AC15} IN A 192.168.0.4 4.2. AAAA Resource Record In AAAA Resource Record, the name field of host name MAY be written with Unicode character strings. A sample record is as below. {U+D55C U+AC15} IN AAAA 2001:db8::1 4.3. CNAME Resource Record In CNAME Resource Record, the name field and the canonical-name of the host name MAY be written with Unicode character strings. A sample record is as below. 'Arisoo'{U+C544 U+B9AC U+C218} represents the ancient name of Han River. {U+C544 U+B9AC U+C218} IN CNAME {U+D55C U+AC15}.example.com 4.4. PTR Resource Record In PTR Resource Record, the right side of the PTR record can be - 105 -
written with Unicode character strings. 4 IN PTR {U+D55C U+AC15}.example.com 5. Translation Process When a Unicode-supporting DNS server receives a DNS query packet having an ACE-encoded Resource Record, the server extracts the Resource Record from the packet and translates it into the corresponding Unicode Resource Record. The converted Unicode Resource Record is used to find the matching host information in the DNS database. If the server finds the matching data, it makes a DNS answer packet containing an ACE-encoded Resource Record converted from the matching Unicode Resource Record. The components and interfaces between them can be represented pictorially as: +-----------------------------------+ +-----------------------------+ Application (ToASCII and ToUnicode operations may be called here) +-----------------------------+ ^ End system Call to resolver: ACE v +----------+ Resolver - 106 -
+----------+ ^ +---------------- ------------------+ DNS protocol: ACE +---------------- ------------------+ v +------------------------------+ Unicode/ACE label translator +------------------------------+ ^ DNS servers Resource Access: Unicode v +------------------------------+ Unicode Resource Records +------------------------------+ +-----------------------------------+ Figure 1: Translation process between DNS protocols and DNS database 6. Security Considerations All securuty issues related to IDNA should be samely considered. 7. IANA Considerations This document has no actions for IANA. - 107 -
8. References 8.1. Normative References [1] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [3] "The Unicode Consortium. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).". Authors' Addresses Chanki Park Korea Internet & Security Agency of Korea 11F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: ckp@kisa.or.kr - 108 -
Hyongjong Paik Korea Internet & Security Agency of Korea 3F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: hjpaik@kisa.or.kr Euihyun Jung Anyang University 102-3 Samsung-ri Buleun-myeon Ganghwa-gun Incheon, 417-833 Korea Email: jung@anyang.ac.kr Xiaodong Lee China Internet Network Information Center 4, South 4th Street, Zhongguancun, Haidian district Beijing, POB, Beijing 349, Branch 6 China Email: lee@cnnic.cn - 109 -
DNSOP Working Group Internet-Draft Intended status: Informational Expires: April 15, 2010 S. Shin H. Lee C. Park H. Paik Korea Internet & Security Agency of Korea October 12, 2009 Self-termination Mechanism for Anycast DNS Service draft-shin-dnsop-self_termination-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. - 110 -
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Anycast has in recent years become popular for DNS servers and widely applied to several root nams servers and to other commercial name servers. For Anycast-based DNS service reliability, this documents describes the use of self-termination mechanism in Anycast-based DNS service operation when the service becomes unavailable due to events such as hardware failures Table of Contents 1. Int ro d u ction......................... 3-111 -
2. Self-termination Mechanism.................. 3 3. Security C onsiderations.................... 5 4. IANA Considerations...................... 5 5. References.......................... 5 5.1. Normative References................... 5 5.2. Informative References.................. 5 Authors' Ad dresses........................ 5 1. Introduction DNS service is one of the most important factors in Internet infrastructures. Anycast-based[1] DNS service [2] has been discussed within related areas for providing stable service to the users for many years. Anycast-based DNS service has generally various advantages such as effective dealing with DDoS attack, overcoming the limit of authoritative name server's physical numbers and improving service stability and performance through a distribution of DNS traffic. More good points are described in other related documents. For that reason, the number of DNS nodes (e.g., Root DNS, TLD DNS and sub-level authoritative DNS) which ancyast-based DNS architecture applied has been increased greatly. In spite of these merits, one of the problems is that Anycast DNS service system would keep advertising of its normal condition even when it becomes unavailable. Particularly, Anycast DNS service with no self-monitoring system may not be able to respond to queries regionally for some time. - 112 -
In order to solve this problem, this documents describes selftermination mechanism of interfaces on hosts making queries go out to other mirror sites automatically. 2. Self-termination Mechanism As the DNS Server has a trouble in responding to queries, it can be self-monitored by using a simple script like the following. This script monitors the behavior of the DNS for 5 times and continuously alerts the DNS Administrator. The Self-termination process by using OSPF Link State Advertisements(LSAs), The DNS server itself could be Self-terminated by simply setting down network interfaces(e.g lo0). Then queries from the Anycast DNS would be bypassed to the shortest alternate Anycast DNS and the DNS Service would be reliable. #!/bin/ksh ExitProcess () { RETURN_STATUS=$1 exit $RETURN_STATUS dig @127.0.0.1 soa kr if [ $? -ne 0 ];then date > /tmp/link_down.txt echo "DNS Mirror Site OUT OF SERVICE!! - 1 time" >> /tmp/ link_down.txt - 113 -
sleep 120 dig @127.0.0.1 soa kr if [ $? -ne 0 ];then date >> /tmp/link_down.txt echo "DNS Mirror Site OUT OF SERVICE!! - 2 time" >> /tmp/ link_down.txt sleep 120 dig @127.0.0.1 soa kr if [ $? -ne 0 ];then date >> /tmp/link_down.txt echo "DNS Mirror Site OUT OF SERVICE!! - 3 time" >> /tmp/ link_down.txt sleep 120 dig @127.0.0.1 soa kr if [ $? -ne 0 ];then date >> /tmp/link_down.txt echo "DNS Mirror Site OUT OF SERVICE!! - 4 time" >> /tmp/ link_down.txt sleep 120 dig @127.0.0.1 soa kr if [ $? -ne 0 ];then date >> /tmp/link_down.txt echo "DNS Mirror Site OUT OF SERVICE!! - 5 time" >> /tmp/ link_down.txt echo "Check the BIND Service!!" >> /tmp/link_down.txt echo "It will be down the Interface lo0." >> /tmp/link_down.txt echo "You will be follow after coming up the Server." >> /tmp/ link_down.txt echo " === ifconfig lo0 up ===" >> /tmp/link_down.txt /bin/mailx -s "DNS Mirror Site OUT OF SERVICE!!" admin@dns.kr < /tmp/ link_down.txt - 114 -
/usr/sbin/ifconfig lo0 down /usr/sbin/ifconfig -a >> /tmp/link_down.txt ExitProcess 1 else date echo "DNS Mirror Site Runs Normally" fi else date echo "DNS Mirror Site Runs Normally" fi else date echo "DNS Mirror Site Runs Normally" fi else date echo "DNS Mirror Site Runs Normally" fi else date echo "DNS Mirror Site Runs Normally" fi 3. Security Considerations This document describes a mechanism for self-termination of Anycast DNS service on the Internet that can be used to cope with DDoS attack. - 115 -
4. IANA Considerations This document is only advisory, and does not have any IANA considerations. 5. References 5.1. Normative References [1] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [2] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. 5.2. Informative References [3] Abbley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra", 3 2004. Authors' Addresses Sungwoo Shin Korea Internet & Security Agency of Korea 11F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: ssw@kisa.or.kr - 116 -
Hansang Lee Korea Internet & Security Agency of Korea 11F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: leehs@kisa.or.kr Chanki Park Korea Internet & Security Agency of Korea 11F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: ckp@kisa.or.kr Hyongjong Paik Korea Internet & Security Agency of Korea 3F 398 Seochoro Seocho-gu Seoul, 137-857 Korea Email: hjpaik@kisa.or.kr - 117 -