From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5182 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Requirements for new dns backend, factoring considerations Date: Sun, 1 Jun 2014 02:31:03 -0400 Message-ID: <20140601063103.GA12091@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1401604284 27803 80.91.229.3 (1 Jun 2014 06:31:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 06:31:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5187-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 01 08:31:18 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WqzIb-0008S2-3h for gllmg-musl@plane.gmane.org; Sun, 01 Jun 2014 08:31:17 +0200 Original-Received: (qmail 13571 invoked by uid 550); 1 Jun 2014 06:31:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13563 invoked from network); 1 Jun 2014 06:31:15 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5182 Archived-At: I'm partly just writing this as my own notes to document the design process, and partly looking for feedback on some of these decisions for the new dns backend. With that said, here's a lost of components that will be using it: 1. __lookup_name (getaddrinfo/gethostbyname* backend), which must be able to perform parallel lookups of A and AAAA records, and multiple search domain suffixes. For A/AAAA, both answers are needed. For search domains, all results except the best for each can be thrown away. 2. getnameinfo, which only needs a single PTR query. 3. res_search and res_query, whose requirements are similar to those of __lookup_name. 4. res_send, which makes a single query using a caller-provided query packet. At first it seems like __lookup_name's dns backend could be implemented on top of res_search, which could be implemented as multiple calls to res_query in the search order, which could in turn be implemented as a call to res_send. The problem however is the different parallelism requirements. It's suboptimal to implement res_search in terms of res_query because you have to wait for one search suffix to fail before trying the next one. At the res_search/res_query level it's not so bad though. The parallel search can be the fundamental operation, and res_search and res_query can just call a common back-end with an argument for whether to search or not. The problem however is implementing this on top of something that looks like res_send. Even if not for search paths, res_search and res_query need parallel A and AAAA queries, whereas res_send has no means to request both. We could imagine implementing res_send on top of a hypothetical "res_multisend" with a count of 1. While this would work, it's not a very friendly interface for implementing res_search or res_query since they would have to provide a large number of pre-generated query packets (6 search domains * 2 RR types * up to 280 bytes per query packet = 3360 bytes of stack usage) despite it being trivial to generate the Nth packet in just 280 bytes of storage. The storage requirements for storing all the results are even worse (6*2*512 = 6144) compared to what's actually needed (2*512 = 1024). The alternative I see is some sort of "res_multisend" that uses a callback to let the caller generate the Nth packet and a callback to notify the caller of replies. Then res_send could be implemented with callbacks that just feed in and save out the single query/response. And res_search would generate all the query packets but only save the "current best match" for each address family. As another alternative, we could drop the goal of doing search suffixes in parallel. This would have no bearing on lookups of fully qualified names using the default settings (ndots:1) since the presence of a dot suppresses search. Where it would negatively impact performance, though, is for users who want to have several search domains (think: home network, university network, department-specific university network, etc.) for quick shortcuts to machines on multiple different networks. Another option still is leaving search domains unimplemented (musl has not supported them up til now, and there hasn't been much request for them). But if there is, or will be, demand for them, I don't want the resolver overhaul design to preclude doing them (or preclude making them perform decently). Anyway, if we do decide that parallel search suffixes are not important, parallel A/AAAA queries are still needed and outside the scope of what res_send can do. It would be plausible to make an interface like res_send, in terms of which res_send could be implemented, but which has an extra boolean argument for "send both A and AAAA versions of this query". Or we could just accept the cost of having two copies of the query packet (an extra 280 bytes is negligible, I think) and make a trivial res_multisend that does N(=2) queries in parallel using packets provided by the caller. Rich