From owner-freebsd-bugs@freebsd.org Wed Dec 30 01:52:36 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40E224D177A for ; Wed, 30 Dec 2020 01:52:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5DnJ19X1z4RKF for ; Wed, 30 Dec 2020 01:52:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 283434D1779; Wed, 30 Dec 2020 01:52:36 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 27F744D1778 for ; Wed, 30 Dec 2020 01:52:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5DnJ0Lzzz4R9n for ; Wed, 30 Dec 2020 01:52:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F38391642F for ; Wed, 30 Dec 2020 01:52:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0BU1qZ83092372 for ; Wed, 30 Dec 2020 01:52:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0BU1qZqA092371 for bugs@FreeBSD.org; Wed, 30 Dec 2020 01:52:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252278] Default net.link.ether.inet.maxhold not Happy Eyeballs DNS resolution compatible Date: Wed, 30 Dec 2020 01:52:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: freebsd@phil.spodhuis.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 01:52:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252278 Bug ID: 252278 Summary: Default net.link.ether.inet.maxhold not Happy Eyeballs DNS resolution compatible Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd@phil.spodhuis.org net.link.ether.inet.maxhold is how many packets we'll hold onto while waiti= ng for ARP/NDP resolution to occur, per entry which we're trying to resolve.=20 Since the sysctl was introduced, the value has been kept at 1, for compatibility. An RFC 8305 Happy Eyeballs compliant DNS resolver will send out concurrent = DNS queries for both A and AAAA records. When the MAC needed to reach the DNS resolver is not currently in the neigh= bor cache, with the default maxhold of 1 the first DNS query is dropped, to be replaced by the second. The resolver then has to retry DNS to get that ans= wer. If the first qtype resolution is for the only address-family which exists in DNS, then the real answer is lost and there's a DNS timeout delay before connections can proceed. If the DNS client is looking up "A and AAAA" records before returning, this then leads to spurious 5 second delays in DNS resolution (assuming default timeouts, default system tuning, etc). The Golang DNS resolver by default does concurrent DNS resolution. This le= d to strange delays in connecting to a server for my client tool, but only on FreeBSD. It took ... "a lot of debugging" to trace back to "it's DNS", "it= 's DNS being retried", "we're only seeing the second request go out", "this is= BSD documented behavior". The Go maintainers are now looking at how to adapt f= or FreeBSD compatibility (I filed https://github.com/golang/go/issues/43398 and traced the issue down there). The equivalent control option in Linux is /proc/sys/net/ipv4/neigh/default/unres_qlen which Linux man-pages document = as being 3, but the kernel Documentation/networking/ip-sysctl.rst file documen= ts as being 101, and that's the real value. If we could raise the default value of `net.link.ether.inet.maxhold` on FreeBSD, it would reduce spurious DNS failures in a world where there are increasing numbers of concurrent queries because application concurrency is increasing and standards-track RFCs are encouraging this behavior. I've used sysctl.conf to raise this for me locally, but this is going to be= a broader hard-to-debug problem for many people. The problem was aggravated = for me by using Jails with vnet and the role-specific jail being idle much of t= he time, until I interacted with it. The description in arp(4), second paragraph, talks about the limit being 1 without mentioning the sysctl; if this problem report is fixed, that should= be changed too. If changing the kernel default is not acceptable then perhaps this should b= e a default uncommented entry in sbin/sysctl/sysctl.conf instead. --=20 You are receiving this mail because: You are the assignee for the bug.=