This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/4692] New: Tuning failure to resolve non-existent domain names - a counterpart to the /etc/resolv.conf ndots option


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]