public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "madalexonline at yahoo dot co dot uk" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/4692] New: Tuning failure to resolve non-existent domain names - a counterpart to the /etc/resolv.conf ndots option Date: Sat, 23 Jun 2007 15:49:00 -0000 [thread overview] Message-ID: <20070623154851.4692.madalexonline@yahoo.co.uk> (raw) The ndots option may be set in /etc/resolv.conf to control when the resolver tries looking up a name directly before considering the search list. This can be used to tune the performance of lookups using knowledge of the local DNS setup and the expected frequency of different types of lookup. However there is no counterpart to allow the resolver to be told when it may take initial "as-is" lookup failure as final and skip trying the search list. Such an option would tune the performance of lookups of non-existent domains. An example will probably aid comprehension and illustrate when and why this might be useful: Consider the domain example.com with nameserver ns.example.com, mail gateway mx.example.com and an internal server int.example.com. Suppose that all other hosts in the domain are at most sub-sub domains, that is all names in the domain are of the form x.y.example.com. Assume that all machines have the domain and/or search option in their /etc/resolv.conf set to example.com. The internal server almost only ever looks up local domain names (within example.com) and so has ndots set to 2 in its /etc/resolv.conf so that for any query of the form x or x.y the resolver first looks for x.example.com and x.y.example.com respectively. Since this is usually what is meant this speeds lookups and keeps down the load which int.example.com places on the nameserver. However the mail gateway is almost always looking up external domain names so has ndots set to 1; the name x will probably be x.example.com (and this is still tried first) but x.y is more likely to external (but still might be internal and is still tried if the "as-is" query fails). In the case of the mail gateway many failed lookups of the form x.y.z (or with more dots) are expected (since example.com receives mountains of spam) and it would be nice to skip the search list in these cases since it is known that there are no names of the form x.y.z.example.com (but we still want to try x.y.example.com for the query x.y) so that they fail faster and to reduce the load on the nameserver. I therefore propose a new option called, for the sake of argument, maxdots to control the maximum number of dots in a name before the resolver considers it to be absolute. In the example, mx.example.com would have maxdots set to 3 as this is the maximum number of dots that may occur in a local domain. I have produced a patch to implement this feature, and provide it here on the off-chance that it should be considered useful by others. It ignores any item on the search path such a that the new name to lookup would have more than maxdots dots. So in the example above, when looking up x.y.z the search path item example.com is ignored because x.y.z.example.com has four dots and maxdots is three. The default setting for the new maxdots options is zero which means no limit, i.e. the existing behaviour. Alex -- Summary: Tuning failure to resolve non-existent domain names - a counterpart to the /etc/resolv.conf ndots option Product: glibc Version: unspecified Status: NEW Severity: enhancement Priority: P3 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: madalexonline at yahoo dot co dot uk CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=4692 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
next reply other threads:[~2007-06-23 15:49 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-06-23 15:49 madalexonline at yahoo dot co dot uk [this message] 2007-06-23 15:56 ` [Bug libc/4692] " madalexonline at yahoo dot co dot uk 2009-02-20 0:17 ` madalexonline at yahoo dot co dot uk
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070623154851.4692.madalexonline@yahoo.co.uk \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).