grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 10/14] dns: poll card between each dns request


From: Josef Bacik
Subject: Re: [PATCH 10/14] dns: poll card between each dns request
Date: Tue, 16 Feb 2016 11:16:57 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 02/15/2016 01:45 AM, Andrei Borzenkov wrote:
On Thu, Feb 11, 2016 at 12:21 AM, Josef Bacik <address@hidden> wrote:
If we have dns servers that we prefer to get AAAA records from we'll send a
packet and immediately check data.naddresses to see if we got a response.  If we
didn't we'll then send a request for an A record, and _then_ we'll poll the
card.  So if the DNS server doesn't respond between us sending the packet and
checking data.naddresses we'll send a request for the A record and then poll the
card.  Instead we need to make sure we poll after we issue each request to make
sure we give the server enough time to respond to our initial request.

Signed-off-by: Josef Bacik <address@hidden>
---
  grub-core/net/dns.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/net/dns.c b/grub-core/net/dns.c
index 82a3307..86e609b 100644
--- a/grub-core/net/dns.c
+++ b/grub-core/net/dns.c
@@ -587,12 +587,12 @@ grub_net_dns_lookup (const char *name,
                    grub_errno = GRUB_ERR_NONE;
                    err = err2;
                  }
+             grub_net_poll_cards (200, &data.stop);

One consideration is that it will increase timeouts in case of
non-responsive servers, as now they are processed sequentially.

But more importantly, this is still hit and miss - we rely on delivery
order which is non-deterministic. We really need to ask for all and
filter on receiving side. Two possible implementations are

1. Keep track of IPv4 and IPv6 answers separately; if non-preferred
answer is received, continue to wait for preferred one until timeout.

2. Queries for both A and AAAA in the same packet and filter out answers.

The 2 looks better. It avoids extra timeouts (at least if we assume
that all DNS servers are equally authoritative) because as soon as we
get any response we can stop polling.

This will also indirectly fix another reported issue as we now can
ignore any duplicate packet.

Would you consider implementing it?


Yeah that sounds reasonable, I'll take a crack at it in a few days.  Thanks,

Josef




reply via email to

[Prev in Thread] Current Thread [Next in Thread]