From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-user+bounces-168688-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A64C01384B4 for <garchives@archives.gentoo.org>; Thu, 3 Dec 2015 22:39:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33C6D21C0C1; Thu, 3 Dec 2015 22:38:59 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1B3B8E08C5 for <gentoo-user@lists.gentoo.org>; Thu, 3 Dec 2015 22:38:57 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 82AC8207B1 for <gentoo-user@lists.gentoo.org>; Thu, 3 Dec 2015 17:38:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 03 Dec 2015 17:38:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ue4n+MQgXmUAKML NNweVnSGqmmg=; b=mjYcGbf6rn4AulIE9b1LJAERkuOLRMKWcJ91AkV0RHprFxW K8dpQzaigHRpooXbQeBm11iCL+1DgmveR83m2gKZFGE2ktTOpPfRZJbLey5TlupC q2LeAcIN0Jvj44P2FxAYgLJvWZ1DC809vMQojMbt3Uuk9WSuFG77hSBkh58I= X-Sasl-enc: 3+erZ43MUKEuG8/Ma54aIIDYo+AzbmdIHRAtvwH6MEAr 1449182337 Received: from [192.168.10.144] (dhcp-wils-epb28.public.engin.umich.edu [141.212.23.228]) by mail.messagingengine.com (Postfix) with ESMTPA id 35B8168017D for <gentoo-user@lists.gentoo.org>; Thu, 3 Dec 2015 17:38:57 -0500 (EST) Subject: Re: [gentoo-user] resolving names of local hosts locally To: gentoo-user@lists.gentoo.org References: <87egf4y741.fsf@heimdali.yagibdah.de> <565F4C0E.6090303@gmail.com> <87mvtrw4vq.fsf@heimdali.yagibdah.de> From: Alec Ten Harmsel <alec@alectenharmsel.com> Message-ID: <5660C497.2020507@alectenharmsel.com> Date: Thu, 3 Dec 2015 17:39:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <87mvtrw4vq.fsf@heimdali.yagibdah.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 9c595589-027c-4d07-89f4-477cd652d0f4 X-Archives-Hash: 8c37cb0d3c0daf84d056d976c728e055 On 2015-12-03 17:20, lee wrote: > Alan McKinnon <alan.mckinnon@gmail.com> writes: >> Secondly, nothing else on your network can know your auth server is >> authoritative without first being informed so by the delegating server. > The name server itself knows this from its configuration, and it's the > only thing that needs to know this because it's the only thing > everything on the network is asking. > >> Or in other words, if you own example.com and an auth server for >> example.com is on your network, you have to first go via .com to know >> that. Weird, but that's how it works. > The name server doesn't know what domains it's supposed to give answers > for without asking others first? If you have a DNS server that is serving DNS info for example.com, it *does* know that. However, what Alan is saying is that none of the resolvers (not even the resolver running on your example.com DNS server) knows which DNS server serves records for example.com without a few more queries. Assume a resolver (for example, the resolver in glibc) that has no cached knowledge. To look up www.example.com, it first queries for '.com' from the root DNS servers. Next, it queries for 'example' from the '.com' DNS servers. Finally, from the 'example.com' DNS server, it can get the IP for www.example.com. > >> DNS was designed to need a network connection because most of the DNS is >> out there somewhere else > Then how do you solve the problem of being unable to even resolve the > names of hosts on the LAN when the connection goes down? Ideally, your caching name server has cached the record for your domain by the time your connection goes down. Alec