From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aanJZ-00054e-Mc for mharc-grub-devel@gnu.org; Tue, 01 Mar 2016 11:38:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aanJW-00051H-Hn for grub-devel@gnu.org; Tue, 01 Mar 2016 11:38:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aanJS-0001aF-7q for grub-devel@gnu.org; Tue, 01 Mar 2016 11:38:22 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:18947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aanJR-0001Zb-Vs for grub-devel@gnu.org; Tue, 01 Mar 2016 11:38:18 -0500 Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u21GZKtN030456; Tue, 1 Mar 2016 08:38:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=subject : to : references : cc : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=facebook; bh=J8pBDepb6N7vnfG75r2MFgdqHIBXp+SGgK57iwxcEPw=; b=AyP9ox6k8Pp/bwbUxk+6szHnhI9xTBUYQc0Kv7Dz6GX4mxWVzYRKnCnGnoO9XodMhTbA LqQraF4VA9zBRAOfuiHf891EOZXwOBMhSU+iq93Z3HZxfTTvxr1WI7HBwW9NfYI9bQci isfe/6xeiMX9O5FZN18UEs0M8v6sGG3KBec= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21dd83rg8d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 01 Mar 2016 08:38:16 -0800 Received: from localhost.localdomain (192.168.52.123) by mail.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 1 Mar 2016 08:38:12 -0800 Subject: Re: [PATCH] dns: realloc address buffer after each packet To: Andrei Borzenkov , The development of GNU GRUB References: <1456341072-13356-1-git-send-email-jbacik@fb.com> <56D058B3.6060202@fb.com> <56D1DF39.5060005@gmail.com> From: Josef Bacik Message-ID: <56D5C572.3020600@fb.com> Date: Tue, 1 Mar 2016 11:38:10 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D1DF39.5060005@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-01_09:, , signatures=0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-00082601.pphosted.com id u21GZKtN030456 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 67.231.145.42 Cc: Kernel Team X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:38:23 -0000 On 02/27/2016 12:39 PM, Andrei Borzenkov wrote: > 26.02.2016 16:52, Josef Bacik =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 02/26/2016 05:22 AM, Andrei Borzenkov wrote: >>> On Wed, Feb 24, 2016 at 10:11 PM, Josef Bacik wrote: >>>> Sometimes DNS responses come in slower than we poll for them which >>>> can lead us >>>> to process multiple DNS packets which overflows the addresses array. >>>> So instead >>>> realloc the array each time to make sure we are accounting for any >>>> answers we >>>> currently have in the address array. We also move the caching of th= e >>>> addresses >>>> outside of the recv hook so we can be sure to cache all the response= s >>>> at once >>>> instead of one packet at a time. Thanks, >>>> >>> >>> This still does not address the problem that we stop waiting for >>> further packets as soon as we get any response, so we still depend on >>> delivery order to get correct record. >>> >>> What about following >>> >>> - send both A and AAAA query concurrently if requested >>> - keep track of both requests (i.e. have data.id[2] and >>> data.addresses[2]) >>> - reset request ID (or otherwise mark it as "received") as soon as we >>> got reply. Note that reply may contain no addresses - NXDOMAIN is >>> prerfectly valid - so condition should not be "got any record of type >>> A or AAAA" as it is now but rather simply "got reply to request with >>> id XX". This also allows us to implement negative caching at some >>> point :) >> >> So we check the rcode so a NXDOMAIN response will just be discarded, w= e >> don't have to worry about this case. >> >>> - return both A and AAAA results separately to grub_net_dns_lookup() >>> - combine them in grub_net_dns_lookup() depending on preference - i.e. >>> put either A or AAAA first in final result. >>> >>> This seems to cover all issues so far - we do not wait too long, we >>> are guaranteed to get both A and AAAA if we request them and we retur= n >>> them in proper order for further processing. >>> >>> Do I miss something? >>> >> >> So my patch previous to this one changes it so DNS servers we get from >> dhcp are bound to either ipv4 or ipv6, so the only way we get >> PREFER_IPV* is if an admin sets it. > > In this case I do not follow why you want to collect multiple answers i= n > the first place. The only reason for me was to make sure we have both A > and AAAA replies; otherwise every reply packet is supposed to contain > exactly the same content. Following this logic the right thing to do is > to just drop all subsequent duplicated replies. I don't want to collect multiple answers. We bail as soon as we get an=20 answer we care about. If a user sets --prefer-ipv6 then they must have=20 an environment that also gives them an ipv4 address so they can handle=20 an A record response. I want to make sure that we only get both an A=20 and AAAA record when we have both kinds of ipvX interfaces, and if not=20 we bail as soon as we get one we want. > >> So now the only time we'll get both >> an A _and_ an AAAA record is if we have both types of interfaces on th= e >> system, so it won't matter which answer is first as we'll be able to >> send traffic to either. > > User can set preference using net_add_dns --prefer-ipvX | --only-ipvX. > We should respect it. > And we still will, prefer means we try but we don't make guarantees and=20 the --only will work as it has always worked. Thanks, Josef