Date: Mon, 7 Dec 1998 13:52:40 -0600 (CST) From: Tony Kimball <alk@pobox.com> To: net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <13932.10856.425298.58899@avalon.east> References: <13929.39477.406338.806610@avalon.east> <199812052221.RAA10079@khavrinen.lcs.mit.edu> <13930.17883.922553.625725@avalon.east> <3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com> <13931.34728.540828.941706@avalon.east> <366BF19F.6B8B267E@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Louis A. Mamakos on Mon, 7 December: : You propose to break one of the fundamental DNS scaling mechnaisms by : injecting way too many queries into the system for no good reason. No, I do not. This is a straw man. What motivates it? : The : problem you have is broken or misconfigured zones, perhaps out of your : control; broken is broken. Exactly. : Fix these things before breaking the architecture of the DNS. Reconsider your own analysis, please: "out of your control". I cannot fix what I cannot control. : I haven't had : these problems such that doing unnecessary queries would have helped. Doing unnecessary queries will never help. Doing necessary queries which are not currently being done will help. Therefore, I propose to focus on the issue of how best to issue these necessary queries. My most recent proposal was something like this: 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. Having made the cost/benefit very clear and explicit (a ratio of zero, according to my analysis), I invite comment on the trade-off. Is it optimal? If not, what would be more nearly optimal, and why? Quoth Wes Peters on Mon, 7 December: : This seems odd, since DNS isn't yet 15 years old. Okay, 14 years and 2 months if you want to be pedantic:-). : In most cases, trying all configured nameservers isn't going to net : anything, since the servers are pretty much heirarchical anyhow. My : network, which I consider typical, has a local nameserver which is : secondary for my own network. The primary is at my ISP, which is also : the second nameserver listed in resolv.conf. My local nameserver is : configured with my ISP nameserver as the forwarding site. The "fix" : you have described would be incredibly redundant and would only : increase traffic on my limited PPP connection. It would be slightly silly for you to configure your system to fallback to its original information source, but not completely -- it would amount to adding a retry. Would adding a retry be "incredibly redundant" and "only increase traffic". I think that's for you to decide: Configure it if you wish. I know of no reason to make this behaviour default. I don't think your comments apply to my current working proposal, although the fact that it has evolved through the course of this thread probably explains why you are missing that moving target. : You seem to be confusing "nobody cares about what *I think* my problem : is" with "nobody cares that a problem exists." You have described to : us a special case, which applies to your custom network and multi- : homed hosts on disjoint networks, and then expect us to leap to the : code to fix this problem not encountered by most FreeBSD users? I confused you by mentioning two related issues in one email. I apologize again for doing this. Please allow me to help you overcome this confusion by being very very explicit: The problem I described as bullet item 2 is present for everyone who has no control over their nameservice. This is the majority of users. The problem, restated, is this: For reasons which are not always evident, but probably relating to cache pollution, individual nameservers have bad data. NXDOMAIN replies occur for valid names. Applications relying on libc in FreeBSD are thereby prevented from making necessary connections. The occurrence is rare, but has become sufficiently annoying to me over time so that I am willing to fix it. I don't expect anyone to write any code, I wish to write it myself. I do seek constructive dialog regarding the correct way to solve the problem. : Since the problem is not technically difficult to solve, we will : patiently wait for YOUR patches to review, and then we can discuss : what is the most constructive way to make them available for other : FreeBSD users who might need them. I'll supply patches when there is a reasonable consensus as to what the correct solution is, and not before. I believe in analysis before design before programming, and in peer review at all phases. 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?13932.10856.425298.58899>