Date: Mon, 7 Dec 1998 16:48:43 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: alk@pobox.com, net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <199812080048.QAA10175@salsa.gv.tsc.tdk.com> In-Reply-To: Tony Kimball <alk@pobox.com> "Re: resolver behaviour" (Dec 7, 1:52pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 7, 1:52pm, Tony Kimball wrote: } Subject: Re: resolver behaviour } Provide a configuration option such that the administrator of } a host may specify that negative responses from a nameserver are } to be tried again against a fallback nameserver. This applies at } the application level, and not to named. } } For the typical case (when configured) of a single fall-back, this } proposal results in one additional query per NXDOMAIN reply. This } cost would only be incurred in cases where the administrator of the } host had determined that nameservice was sufficiently unreliable to } warrant this cost. The cost of unreliable name service is this: When } a lookup fails, the user must issue a manual query in order to get the } mapping. Hence the cost of the additional query is incurred in all } cases, and hence the incremental cost (in units of queries issued) of } implementing my proposal is actually zero. What do you do when the first server returns NXDOMAIN and the second server doesn't answer? Do you bounce the email because all the responses that you got were NXDOMAIN? In the case of connecting to multiple disjoint networks that use split DNS, I don't believe your scheme is flexible enough. If example.com lives in network A, and example.org lives on network B, an MX query for example.org sent to network A's internal servers may well return the external DNS information (instead of NXDOMAIN) for network B, when in fact you want the internal DNS information for network B. Your proposal would accept the undesired DNS information and return it to the application. Even if you hack FreeBSD so that it does this, what are you going to do when your boss tells you to make this work with the Windoze, MAC, or other closed-source machine on his desk? I think a better scheme would be to write an application that listens on port 53 and forwards queries to the appropriate server. It could do pattern matching on the query name to figure out where to forward the query. This has the advantage of not being limited to running on FreeBSD, and you can point other machines running any arbitrary OS at it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812080048.QAA10175>