From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6724 Path: news.gmane.org!not-for-mail From: Brad Conroy Newsgroups: gmane.linux.lib.musl.general Subject: mDNS and alternate hostname database backends Date: Mon, 15 Dec 2014 02:39:46 -0800 Message-ID: <1418639986.61320.YahooMailBasic@web160402.mail.bf1.yahoo.com> 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 1418640168 16002 80.91.229.3 (15 Dec 2014 10:42:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 10:42:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6737-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 15 11:42:44 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Y0T6w-0003oD-RF for gllmg-musl@m.gmane.org; Mon, 15 Dec 2014 11:42:42 +0100 Original-Received: (qmail 22350 invoked by uid 550); 15 Dec 2014 10:42:41 -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 22342 invoked from network); 15 Dec 2014 10:42:40 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 873434.70205.bm@omp1030.mail.bf1.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1418639986; bh=+eI9SrQTyf6+j8MKc7v3xW4HpLJPjN6RHOxolsRP0hc=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=N9Ge9+9j3w1HEQAflCcJjupTFCSPZZfZ1kD09qGOBj0TFz4fJ92qzI8o+HVUGMVs4Ugs2vym3px+GlDI+TdzgsnQNs77GE6iRwTNVuETmaM1njVJnX68SSZK6vMoZQDzKFBqaPlOYTb4/KG+f3aHP8cePK6KduDLn54DkLMmgoU= X-YMail-OSG: YREI1CkVM1mJmPcSimSVtxvtuhqyooXDqZGRYIXGXXmCw5C 1HKQyVL77lOgfLUITOYP5gxSHtYZY7kidOcCtX98u5pE43acWqmb5XQsXshI HixwDdMaWq4j3w3utYZVF1O0BXqAaKbM_p8q4BXu0t_3JhP0Aul7ql5PJmvU 86mq4RdFXmYwDSb2q5Pp4qD9ChrxQh7BtW9HEk84L85sGYpBDpSLyds5otF7 f0yLANEyF_KM.DlrxIOWw4w1wLyOyPh3kV4XdpkGj8SKRlM8h_Q96VdhvPPQ 1sZ5oCzWfZ_FU_OiDH8n8R4oO7KxMkRJsf_MfWEIvt0DyHKpMHzpw_IDe3sr DLub.8Jg_NSqf.EcTQ9cnhgpSLS9N0Yq5hp7M6yePuhY4BVSP9q.zSidmz8G _C1IHv6LWe1jpRTXlVCyuR3VUfqFmXrSs_U2dMs2UhQwcalc9YTseDVF_Xq7 NmHVDhx5rEor22lo2FPvHNAJuM7dwiFTzJAq1pdZmIFIMIw06hgO2usX.X49 kVu4Z1CwJvj6auCekSRHAdqKfK6bkgUUPstgX0Y_YEtZzINU3LC..3Xbs2eB fE_.NWIaDdkDlemIX7q7fpUZN_tynWtfGujj7cOKuIPnFkF1C6zeAnWDnzXw M4X3k7R_i3tx0n7pKSNW6XQfgBNhHHD.8X1Bqs9gZlqsgQvqpPjEX2JLXmp3 qZca_rnCsrCcgwcvI6EB_UpDqqNkCY3Sg42rarToHKDHdXygFyfxiT4IT_p1 QSwT927gNB6Qq8W9.H92jg5LV2eav6zxhQn_dbtumfmO794FNTfGg3LEd_kY 1 X-Rocket-MIMEInfo: 002.001,SSd2ZSBiZWVuIGxvb2tpbmcgaW50byB1c2luZyBhIHNpbXBsaWZpZWQgRE5TIGNhY2hpbmcgbWVjaGFuaXNtIHVzaW5nIHRoZSBmaWxlLQ0Kc3lzdGVtIGFzIHRoZSAiZGF0YWJhc2UiIGFuZCBjYW1lIGFjcm9zcyB0aGlzIGZyb20gdGhlIHdpa2k6DQoNCj4gVGhlIGluYWJpbGl0eSB0byB1c2UgbUROUyAoYSBtdWx0aWNhc3QtRE5TLWJhc2VkIHplcm8gY29uZmlnIHN5c3RlbSkgd2l0aCBtdXNsDQo.IGhhcyBiZWVuIHJhaXNlZCBhcyBhbiBpc3N1ZSBieSB1c2VycyBpbiB0aGUgcGFzdC4gT24gZ2xpYmMsIHUBMAEBAQE- X-Mailer: YahooMailClassic/897 YahooMailWebService/0.8.203.740 Xref: news.gmane.org gmane.linux.lib.musl.general:6724 Archived-At: I've been looking into using a simplified DNS caching mechanism using the file- system as the "database" and came across this from the wiki: > The inability to use mDNS (a multicast-DNS-based zero config system) with musl > has been raised as an issue by users in the past. On glibc, using mDNS is > accomplished with NSS; obviously musl does not have (or want) NSS. > > In principle, however, musl is fully extensible to use alternate hostname > database backends in place of normal DNS. All that's needed is a daemon that > runs on localhost, speaks DNS, and translates the requests to whatever backend > is needed. However it's unclear whether there are any existing tools of this > form. Developing one, adapting an existing DNS proxy program, or documenting > how to setup an existing program that's already capable could be a nice future > project. My idea is much simpler: store the data as file name by the hostname (in /tmp ?): /tmp/hosts/a for ipv4 (limit to 15/host so they can be stored in the inode*) /tmp/hosts/aaaa for ipv6 (limit to 3/host *) * of the filesystems capable of inlining data, ext4 has the lowest at 60 bytes. This means we can just read/write an array of uint32_t for ipv4 and uint128_t with something like: static int get_value(const char *path, void *buf,size_t len){ int fd = open(path, O_RDONLY); if (fd<0) return fd; len=read(fd,buf,len); close(fd); return len; } static int set_value(const char *path, void *buf,size_t len){ int fd = open(path, O_CREAT|O_WRONLY|O_TRUNC); if (fd<0) return fd; len=write(fd,buf,len); close(fd); return len; } The existing systems /etc/hosts* don't account for TTL, but using the filesystem we can hack this feature pretty simply using the filesystem by adding the TTL to the modification time. struct utimbuf ut={.actime=st.st_atime, .modtime=ttl+st.st_mtime}; utime(path,&ut); Note: I chose mod time for TTL since a file system may be mounted noatime initilization: if /tmp/hosts/a (or aaaa for ipv6) does not exist 1. mkdir 2. read in /etc/hosts to our format a.) for 0.0.0.0 and 127.0.0.1 and their mathing ipv6 counterparts :: and ::1, create a hard link to NULL and localhost b.)similarly create hard links for aliases. for example: /etc/hosts| 74.125.225.134 www.google.com google.com www.bing.com bing.com /tmp/hosts/a/www.google.com will contain a uint32_t representing 74.125.225.134 with a modification time set to INT_MAX /tmp/hosts/a/google.com --hardlink--> /tmp/hosts/a/www.google.com /tmp/hosts/a/www.bing.com --hardlink--> /tmp/hosts/a/www.google.com /tmp/hosts/a/bing.com --hardlink--> /tmp/hosts/a/www.google.com This seems pretty over-simplified, but it opens up some possibilities: 1. the network functions could be much smaller and rely on a single binary to do all of the hard work in a unix style. Before anyone argues that starting an external program takes too long, I must point out that this is typically insignificant compared to DNS query/response time and that keeping this functionality internal to the libc requires making certain tradeoffs to keep the overall code size and complexity down. Other functions already call /bin/sh IIRC, so this isn't a huge leap. ... though all code _could_ stay in the libc if there is a good argument for it. 2. sharing caches between clients now becomes as easy as using rsync or even tar or cpio. 3. A cron task can replace a running daemon to periodically clean up the cache If disk space is low, it can purge or it could even systematically recheck the DNS, update the TTL and even ping all the entries to get a response time so it can sort them from fastest to slowest entries 4. Ad-blocking can be as simple as: cd /tmp/hosts/a; ln NULL pagead2.googlesyndication.com 5. Filtering can also be accomplish using standard users/groups. blacklist filtering by making them hardlinks to NULL whitelist filtering by making /tmp/hosts read only 6. Because the cache is so simple, integrating it to work with other caching methods like nss/nscd, libresolvconf, dnsmasq, djbdns and bind _should_ be fairly straight forward. I've been working on my own rudimentary implementation to include with my own libc.h headers, (only for small, single file static apps) but I primarily use musl, so I'd be interested in hearing any feedback, especially if there is a possibility that it could become a standard practice. My guess is that it has probably already been done by Bell Labs for Plan. R, Brad Conroy