인터넷 기술의 보급을 향해서 IPv6, DNS, HTTP등 기본이 되는 프로토콜을 규정하고 왔다IETF(The Internet Engineering Task Force). 올해 11월에는 100차 회의(IETF 100)이 싱가포르에서 개최될 예정이다. IETF가 그동안 해온 인터넷 기술도 기술의 진보와 보급으로 현재도 많은 분야에서 논의가 계속되어 아직 눈을 못 떼고 있다.본 연재에서는, 인터넷의 보급과 발전을 목적으로 평소 IETF를 중심으로 활동을 하고 있다ISOC-JP(Internet Society Japan chapter)멤버 유지가 최근 IETF의 활동 상황에 대해서 소개한다.

　전회에 이어DNS프로토콜의 표준화 동향에 대해서 다룬다.이번에는 최근의 DNS Operations(dnsop)WG활동을 소개한다.

dnsop WG는 DNS운용에 관한 가이드 라인을 작성한다는 목적 외에 기존 또는 새로 생기고 DNS의 문제에 대응하는 장소를 제공한다는 역할을 한다.dnsop WG은 완료 조건이 없고, 명확한 이정표가 설정되지 않았지만 요즘 dnsop WG에서는 DNS프로토콜 확장 및 BCP문서를 적극적으로 작성하고 있으며 2015년에는 8개의 RFC를 발행하고 2016년에는 9개의 RFC를 발행했다.

2017년에는 8월 4일 현재 4개의 RFC를 발행하고 1개가 RFC발행 임박(IESG에 제출)이다.이러한 RFC의 발행 여부도 30년 전 낡은 사양인 RFC 1034/1035이 아직도 유효하며월 다수의 기능 확장(누더기)을 쌓아올리고 있다는 DNS의 상황을 뒷받침한다.

2015년 이후 발간된 RFC와 dnsop WG에서 IESG에 제출된 제안을 표에 나타낸다.

 

 

RFC번호	발행일	개요
RFC 7477	2015년 3월 13일	DNSSEC에서 DNS를 사용한 키 갱신
RFC 7534	2015년 5월 13일	AS112네임 서버(개인 주소의 역순 등)의 운용 가이드
RFC 7535	2015년 5월 13일	AS112네임 서버의 설정 변경
RFC 7583	2015년 10월 21일	DNSSEC에서 키 갱신의 타이밍
RFC 7646	2015년 9월 23일	DNSSEC설정 오류의 도메인 이름의 DNSSEC검증을 무효하는 설정
RFC 7686	2015년 10월 23일	Tor에서 사용된다. onion TLD의 예약
RFC 7706	2015년 11월 24일	루트 서버의 복사본을 풀 서비스 리솔버에 둔다
RFC 7719	2015년 12월 15일	DNS용어
RFC 7766	2016년 3월 3일	TCP의 사용법 변경(처음부터 TCP에서 통신해도 좋고, 등)
RFC 7793	2016년 5월 12일	100.64.0.0/10의 역순
RFC 7816	2016년 3월 22일	권위 서버에 새 정보를 최소화
RFC 7828	2016년 4월 6일	TCP를 잇는 채로 두고 좋은 시간을 지정하다
RFC 7871	2016년 5월 20일	CDN의 제어를 위해서 클라이언트의 주소를 권위 서버에 보내
RFC 7873	2016년 5월 27일	캐시 오염 공격에 대한 내성을 올리기 위해서 64비트의 Cookie를 추가
RFC 7901	2016년 6월 21일	DNSSEC검증을 효율적으로 실시하는 확장
RFC 8020	2016년 11월 8일	이름 부존재 응답을 적극적으로 사용 성능 향상
RFC 8027	2016년 11월 28일	DNSSEC대응 클라이언트의 실장 가이드의 1개
RFC 8078	2017년 3월 10일	DNSSEC에서 DNS를 사용한 키 갱신의 업데이트
RFC 8109	2017년 3월 15일	풀 서비스 리솔버가 루트 서버 정보를 갱신하는 구조
RFC 8145	2017년 4월 11일	DNSSEC validator에서 권위 서버에 trust anchor을 전해
RFC 8198	2017년 7월 25일	DNSSEC검증된 캐쉬 데이터를 적극적으로 사용하여 성능 향상

Draft	상태	개요
draft-ietf-dnsop-sutld-ps	IESG제출	프로토콜에서 사용하는 TLD예약에 대한 문제 제기

이들 중 몇 병에 대해서 소개한다.

 

TCP통신로(RFC 7766)에 대해서

 

RFC 7766에서는 DNS에서의 TCP통신로의 요구 사양의 업데이트를 했다.종래는 RFC 1123에 "MUST send a UDP query first"라고 씌어 있었지만, RFC 5966에서 "SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason"와 재정의된 뒤 RFC 7766에서는 "TCP MAY be used before sending any UDP queries."다시 정의하고 처음부터 TCP에서 문의해도 좋아졌다.

또 1개의 TCP세션에서 여러 쿼리를 연속하고 보내는 것(응답을 기다리지 않아도 되는)이나 여러 쿼리를 보낼 경우 응답은 순서 부동에서 UDP와 같다는 것, TCP세션을 치기만 하고 가끔 쿼리를 보낼 수 있는 것, TCP close등에 대해서 명확화됐다.

또 통신이 흐르지 않는 TCP세션을 끊고 타임 아웃 값을 지정하는 EDNS0옵션이 RFC 7828에서 정의된.TCP의 취급에 관한 확장 목적의 1개는 DNS over TLS등을 효율적으로 실현하기 위해서이다.

 

쿼리 정보 누설을 최소화(RFC 7816)에 대해서

 

RFC 7816에서는 풀 서비스 리솔버 이름 해결 때에, 권위 DNS서버로 유출되는 정보를 최소화하는 이름 해석 알고리즘이 실험적 프로토콜로서 표준화되었다.

종래, 풀 서비스 리솔버는 이름 해결 때에 스텁 리솔버(클라이언트)에서 받은 쿼리 이름·쿼리 형식을 그대로 경로나 TLD, 각 조직 등의 권위 DNS서버에 보내고 있었지만, 결과로서 최종 사용자가 문의한 구체적인 이름 또는 쿼리 타입이 경로나 TLD등의 권위 DNS서버에 고스란히 전해지고 있었다.실제로는 풀 서비스 리솔버의 현금 기구 때문에 모든 것이 경로나 TLD에 전해지는 것은 아니지만 루트, TLD의 쿼리 정보를 조사하면서 많은 정보를 얻을 수 있었다.

거기에서 루트 서버에는 TLD의 NS리소스 레코드를 듣고 TLD의 권위 서버에는 각 조직(두번째 수준과 서드 수준, 포스 수준)의 NS를 듣고 각 조직의 권위 DNS서버에만 쿼리 이름·쿼리 타입을 밝히도록 하자는 제안이다.존 모양은 도메인 이름 레이블의 구분에 반드시 존재하는 것이 아니기 때문, 제안 기법에서는 상당한 낭비가 발생할 가능성이 있지만 루트 서버와 TLD의 권위 서버에 최종 사용자가 문의한 쿼리 이름 또는 쿼리 타입을 송신하지 않고 정보의 노출을 줄일 수 있다.

 

 

이름 해결의 성능 향상(RFC 8020)에 대해서

 

 

 

RFC 8020에서는 이름 해결 때에 받은 이름 부존재 에러(NXDOMAIN, NameError)를 캐시 하게 그 후손의 이름 모두 존재하지 않습니다(NXDOMAIN)로서 다루는 것이 규정된.기존 DNS표준에서는 캐시 된 정보 중 부존재 정보의 취급은 매우 한정적이어서 큰 변경 점이다.

예:풀 리솔버가 example.jp의 NXDOMAIN을 받고 캐시 하고 있는 경우에, sub.example.jp쿼리를 받자 NXDOMAIN을 갚다

 

 

DNS용어(RFC 7719)에 대해서

 

 

2015년 이후 발간된 RFC중 필자가 관여한 것이 2개 있다.

필자가 2014년 11월에 DNS용어에 모호함이 있음을 보여Internet Draft을 기고한 곳, 그런 일을 생각했던 Paul Hoffman씨에게 권유를 받아 Andrew Sullivan씨와 3명으로 DNS용어를 정리한 draft를 진행하게 되었다. IETF에서 맹활약하고 있는 두와 문서를 추진함으로써 최초 제안에서 1년에서 RFC로서 발행되었다.아이디어의 표준화에는 요구나 좋은 아이디어다
농담이 아니라 좋은 공저자가 중요하다. 현재는 더 용어를 수집하는 용어의 재정의하고 있다.특히"domain name"의 정의를 바꾸려고 하는 것이, 코멘트를 청하다.

 

DNSSEC검증시의 성능 향상(RFC 8198)에 대해서

 

RFC 8198은 DNSSEC의 부존재 정보를 이용하여 이름 해결을 효율화하는 것으로 구현하면 루트 DNS서버에 쿼리를 극적으로 줄일 수 있다. 필자와 게이오 기주쿠 대학/WIDE프로젝트의 카토로 선생님이 2015년 3월에 draft-fujiwara-dnsop-nsec-aggressiveuse로 제의하자 점차 흥미를 받았고, 1년 후에는 루트만 대응한다는 단순한 대항 안이 제안되었다.2016년 4월 미팅에서 우리의 제안과 단순한 제안의 어느 쪽이 좋냐는 논의가 이루어지고 우리의 제안을 선호했다.

그 후, 대항 안의 저자 중 한 명인 Google의 Warren Kumari씨에 공저자가 되셔서 dnsop WG에서 표준화를 진행했다.그 과정에서 훌륭한 의견이 다수 전해져, 세세한 절차 등의 기재를 삭제하고 RFC 4035나 RFC 5155에 쓰인 방법으로 검증하는 간소한 표현으로 변경할 수 있었다.

또 Google에서는 Google Public DNS에 제안 수법을 구현하고 루트에 대한 쓸데없는 부존재 응답이 되는 쿼리가 급감했다.그 결과 표준화 작업이 진전되어 최초 제안에서 2년에서 IESG에 제출할 수 있고, 2017년 6월 8일에 IESG에서 발행이 승인되고 7월 25일 RFC 8198으로 발행되었다.

 

프로토콜에서 사용하는 TLD의 예약에 대해서

 

2014년경부터 dnsop WG에서 활발한 논의가 이루어지고 있는 주제의 1개는 최상위 도메인(TLD)의 예약이다. Tor에서 사용된다. onion은 널리 사용되고 공식 증명서가 발행됐다.프로토콜에서 사용하는 TLD로. local예약을 깨달은 사람들이 Tor등에서 사용하고 있는 많은 TLD,. onion이나. exit등의 예약을 제안한 것이 논란의 원인이며. local의 반성으로 dnsop WG이 논의를 다루게 되었다.

TLD의 위임 및 예약에 대해서는 ICANN의 수비 범위이며, IETF에서는 취급하고 싶지 않다는 의견과 ICANN에 등록하면 높은 돈이 들어 IETF에서 무료로 예약하고 싶다는 의견이 있고 결론이 나오지 않고 논란이 이어지고 있었다.

. onion에 대해서는 공식 증명서가 발행되어 증명서 발행의 업계 단체에서 예약되지 않을 경우의 발행제 증명서의 무효화 시한을 표시되자 2015년 10월에 RFC 7686에서. local과 같은 방법으로 예약된.

또 가정의 네트워크 환경을 실현하는 homenet WG에서는 RFC 6761의 절차 없이. home라는 TLD를 예약하고 쓴다는 RFC 7788을 표준화되면서 큰 문제로 최종적으로 IETF좌석이 잘못을 인정하는 사태로. homenet TLD를 예약하는 제안으로 변경했다.

그 후에도 TLD예약은 결론이 나지 않는 논란이 됐지만 IAB(Internet Architecture Board)이 2017년 3월 30일 IETF의 프로토콜에서 사용하는 특수 용도의 도메인 이름을. ARPA TLD이하에 준비하는 것이 적절하다는 성명을 발표했다.그래서 homenet WG은. home.arpa를 사용하자는 제안으로 변경했다.

 

최신 논의

 

IPv6의 실장에 따른 2000년경부터 1개의 쿼리에서 A와 AAAA의 양쪽을 얻고 싶다는 요구가 여러 차례 제의 받았지만 표준화에는 이르지 않았다. 또 dane WG에서 표준화된 TLSA리소스 레코드를 서버의 IP주소와 동시에 얻고 싶다는 요구도 있다.TLSA의 경우 쿼리 이름이 있는데"_443._tcp. 서버의 도메인명"이다.

최근 들어 1개의 쿼리에서 여러 응답을 돌려주는 제안 논란이 재개됐다. 지금까지 여러 유형의 쿼리를 동시에 보내제안(draft-bellis-dnsext-multi-qtypes)지역 관리자가 Additional section에 응답을 추가하는 제안(draft-wkumari-dnsop-multiple-responses), 통상의 쿼리에 다른 쿼리를 추가해서 보내고, 복수 응답을 1개 DNS응답에 섞어 제안(draft-yao-dnsop-accompanying-questions)이 있고 그 이외에도 몇가지 방법이 있다.앞으로 더 깊은 논의가 이루어질 전망이다.

또 DNS의 응답 코드(RCODE)은 4비트이며 0부터 15의 값만 갚지 않지만, EDNS0에는 8비트의 EXTENDED-RCODE가 마련되어 있어 이를 사용하고 DNSSEC검증에 대한 상세한 에러 코드 등을 돌려줄 제안되고 있다(draft-wkumari-dnsop-extended-error).

DNS에 큰 영향을 줄 수 있는 제안도 이루어지고 있다.존 정점

 

끝

 

DNS는 30년 이상 사용되는 매우 낡은 프로토콜이지만, 현재도 활발한 기능 확장이 계속되고 있다. 종래와 호환성을 유지한 기능 추가나 공격 내성 향상을 위한 도전은 매우 흥미 깊기 때문에 동참하는 사람이 늘기를 기대한다.또한 변경되면 곤란한 사람도 논의에 참여한다.