Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, mif mailing list <firstname.lastname@example.org>, mif chair <email@example.com> Subject: Protocol Action: 'Improved Recursive DNS Server Selection for Multi-Interfaced Nodes' to Proposed Standard (draft-ietf-mif-dns-server-selection-12.txt) The IESG has approved the following document: - 'Improved Recursive DNS Server Selection for Multi-Interfaced Nodes' (draft-ietf-mif-dns-server-selection-12.txt) as Proposed Standard This document is the product of the Multiple Interfaces Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mif-dns-server-selection/
Technical Summary A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. Working Group Summary There was no controversy about this document, but there were fears that this document is actually “promoting use of split-brain DNS”. After discussions the concern was tackled in Section 7 “Considerations for network administrators” with text: ”Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3).” Another major area that caused lots of discussion was security implications caused by risks related to attacker redirecting some DNS queries to bad places. This is addressed in Section 4.4. “Limitations on use” and in Section 4.1, especially with help of DNSSEC. Document Quality There are two implementations of the protocol, one from Nokia, the other from NTT. Microsoft also has Name Resolution Policy Table implementation. There were thorough reviews of the document, but these reviews did not lead to important changes. There are no substantive issues. Personnel Hui Deng <firstname.lastname@example.org> is the document shepherd. Ralph Droms <email@example.com> is the responsible AD.