From nobody Thu Oct 13 09:15:57 2022 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mp3m92HVvz4fWGq for ; Thu, 13 Oct 2022 09:16:09 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "prime.gushi.org", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mp3m828GXz3xdn for ; Thu, 13 Oct 2022 09:16:08 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from smtpclient.apple ([IPv6:2601:602:87f:b05d:d18:4e03:ac9e:4997]) (authenticated bits=0) by prime.gushi.org (8.16.1/8.16.1) with ESMTPSA id 29D9G2Sj037970 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Oct 2022 02:16:03 -0700 (PDT) (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 29D9G2Sj037970 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1665652563; bh=IyfXG/kceaAsfjh48M0ftaOSnYTSj6cVtVvFfAyYFIY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20resolv.conf=20question|From:=20Dan=20Mahoney=20< freebsd@gushi.org>|In-Reply-To:=20<20221012185254621820516@bob.pro ulx.com>|Date:=20Thu,=2013=20Oct=202022=2002:15:57=20-0700|Cc:=20F reeBSD=20Questions=20Mailing=20List=20|References:=20=0D=0A=20=0D=0A=20=0D=0A=20<20221012185254621820516@bob. proulx.com>|To:=20Doug=20Denault=20; b=gEr1tatbf4WNk+Saq8Z6xII/1x8dzZoHbc2WfgHWXE7LWsVcQ1rzVLZhBorfE6+vY u8l875hceqEn6XaUg82jP9YW2hZPhas2TBnlP4RwK/K+toOFuLFWjXKFEuiYoGfr5E EOmzTWWThID70qxP2RVmi2H2RUdRirsrsnUVEh3Xbx7OATc6vZLXxDeQLpyj6SZy5C KfrRSJMxbAVo+FsNMK5eHfGyGYWyq+rwNsfyqfEKQ08FjlpbV+VrC4UHIQ3qYLn+lh Zsnfx4kgYNrdbgaJfzbV1mKDNBbtI3+kdpTloQvpgLVU0GOocZdSSOrjw9mfCtlIwf 1oWX91DPm8IBw== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2601:602:87f:b05d:d18:4e03:ac9e:4997] claimed to be smtpclient.apple Content-Type: text/plain; charset=us-ascii List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: resolv.conf question From: Dan Mahoney In-Reply-To: <20221012185254621820516@bob.proulx.com> Date: Thu, 13 Oct 2022 02:15:57 -0700 Cc: FreeBSD Questions Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7F000833-031D-41D9-8C49-F999F1A9AD73@gushi.org> References: <20221012185254621820516@bob.proulx.com> To: Doug Denault X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4Mp3m828GXz3xdn X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gushi.org header.s=prime2014 header.b=gEr1tatb; dmarc=pass (policy=none) header.from=gushi.org; spf=pass (mx1.freebsd.org: domain of freebsd@gushi.org designates 2620:137:6000:10::142 as permitted sender) smtp.mailfrom=freebsd@gushi.org X-Spamd-Result: default: False [-6.20 / 15.00]; DWL_DNSWL_MED(-2.00)[gushi.org:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gushi.org,none]; RCVD_IN_DNSWL_MED(-0.20)[2620:137:6000:10::142:from]; R_DKIM_ALLOW(-0.20)[gushi.org:s=prime2014]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US]; TO_DN_ALL(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gushi.org:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Oct 12, 2022, at 18:56, Bob Proulx wrote: >=20 > Doug Denault wrote: >>> Doug Denault wrote: >>> So I tried to RTFM, /usr/src/contrib/ldns/resolver.c in this = case. It is >>> almost certain that the system was up but bind did not respond. = The source >>> is a bit above my pay grade but it did seem possible that if = that was the >>> case, the second server was never tried. This is what actually = happened. >>>=20 >>> There were no other issues as each of the jails started fine = with a manual >>> boot. Does anyone know if the timeout and/or retry setting = offer a way >>> around this. >>=20 >> For performance reasons, especially if the first listed server is = always >> used, I want that in our data center. Aside from speed, no hacking is >> possible. My purpose here is to figure how resolv.conf works. If more = than >> one entry is effectively useless, I would be tempted to use 8.8.8.8. = Also >> the jail mother had not been booted in several months and only now = because I >> f-ed up changing the root password. >=20 > I still have a physical copy of DNS and BIND by Paul Albitz & Cricket > Liu published by O'Reilly 1992. I have no idea if the way this was > described there still matches the way it is resolved now. But I think > it likely it is still at least similar. >=20 Long message snipped. I really wish the DNS resolver libraries in the system stack supported = quicker failover, or perhaps randomizing the list of servers. If you're falling back to the second line in your resolv.conf, something = has gone terribly wrong. In practice, the 5 seconds * 3 tries failover = delay to hit that second server is pretty unusable on a normal system. = I like having it there in the SOLE case that if my primary resolvers are = down, that I can still authenticate my IP address enough to log in, but = by that point many servers that depend on DNS (including sshd, which = tries to resolve the connecting ip; mail servers, which do the same; = database servers, which may rely on DNS to connect to a database, as = well as any dynamic web code) are all hopefully broken. If you're doing any kind of mail service that depends on RBL's or depend = on any kind of server that does geolocation, do not use 8.8.8.8 or any = of the other public open resolvers, they will rate limit you when you = least expect it, and they do not faithfully give you information that's = geographically relevant to you. It's trivially easy to run an unbound caching resolver on localhost, and = it gives you the benefit of DNSSEC as well. Since you say "Data Center" you may want to anycast your caching = resolver. Using modern routing protocols, you can put an IP address on = lo0, and announce it with OSPF/BGP into your network stack, with a = simple script that removes the IP address from lo0 if it detects the = nameserver not answering. There are also hardware load balancers you = can put such things behind. Finally, you might find different results asking your question on = bind-users@lists.isc.org. The people here are great too, no doubt, but = the focus is on DNS there, if that's your line of questioning. -Dan