BIND 'sortlist' preferred IP address

[Joseph S D Yao]

> Sorry, I didn't make it clear.  What I mean by '1-and-only-1
> IP address' is returnining '1-and-only-1 IP address' to the
> DNS client based on the DNS client source IP/network.  So,
> if the DNS client is at network A, my DNS server would
> return x.x.x.x EVERYTIME, and if the DNS client is at
> network B, my DNS server would return y.y.y.y EVERYTIME.
> I notice that although the 'sortlist' could sort the
> response based on the DNS client source network address,
> however, it might return the sorted list in a round-robin
> fashion which means that it might return different IP
> address everytime instead of the '1-and-only-1 IP address'
> EVERYTIME.  So, Is it possible to return the '1-and-only-1
> IP address' EVERYTIME ???
> 
> > >>>>> "Edmund" == Edmund Lam <elam99 at hongkong.com> writes:
> > 
> >     Edmund> Is there any way to make BIND 8.2.1 to return the
> >     Edmund> 'sortlist' sorted most preferred 1-and-only-1 IP address
> >     Edmund> EVERYTIME instead of the 'sortlist' sorted round-robin list.
> > 
> > Eh? If there is "1-and-only-1 IP address", what is there to sort or
> > round-robin?

I didn't find any documentation for 'sortlist' in named.conf.5, just in
CHANGES and the comments - where it said that "sortlist" is experimental
and may be subsumed into the "topology" keyword.

At the end of this message are the "documenting" comments.  The code in
ns_sort.c, on rough glance, appears to implement what the comments say.

I think the only way you're going to get this implemented is (a) have a
separate copy of BIND only allowing access on a specific IP address and
for specific addresses, for each unique address you want to return [and
I'm not even sure that would work], or (b) wait for views to be
implemented in [per what I hear] BIND 9.

Comments:

=======================================================================
 * How "topological closeness" is defined (for the purposes of this routine):
 *    Ideally, named could consult some magic map of the Internet and
 *    determine the length of the path to an arbitrary destination.  Sadly,
 *    no such magic map exists.  However, named does have a little bit of
 *    topological information in the form of the sortlist (which includes
 *    the directly connected subnet(s), the directly connected net(s), and
 *    any additional nets that the administrator has added using the "sortlist"
 *    directive in the bootfile.  Thus, if only one of the addresses matches
 *    something in the sortlist then it is considered to be topologically
 *    closer.  If both match, but match different entries in the sortlist,
 *    then the one that matches the entry closer to the beginning of the
 *    sorlist is considered to be topologically closer.  In all other cases,
 *    topological closeness is ignored because it's either indeterminate or
 *    equal.

...

/*
 * Sorting should really be handled by the resolver, but:
 *  1) There are too many brain dead resolvers out there that can't be replaced.
 *  2) It would be a pain to individually configure all those resolvers anyway.
 *
 * Here's the scoop:
 *
 * To enable address sorting in responses, you need to supply the sortlist
 * statement in the config file.  The sortlist statement takes an
 * address match list and interprets it even more specially than the
 * topology statement does.
 *
 * Each top level statement in the sortlist must itself be an explicit
 * address match list with one or two elements.  The first element
 * (which may be an IP address, an IP prefix, an ACL name or nested
 * address match list) of each top level list is checked against the
 * source address of the query until a match is found.
 *
 * Once the source address of the query has been matched, if the top level
 * statement contains only one element, the actual primitive element that
 * matched the source address is used to select the address in the response
 * to move to the beginning of the response.  If the statement is a list
 * of two elements, then the second element is treated like the address
 * match list in a topology statement.  Each top level element is assigned
 * a distance and the address in the response with the minimum distance is
 * moved to the beginning of the response.
 * 
 * In the following example, any queries received from any of the addresses
 * of the host itself will get responses preferring addresses on any of
 * the locally connected networks.  Next most preferred are addresses on
 * the 192.168.1/24 network, and after that either the 192.168.2/24 or
 * 192.168.3/24 network with no preference shown between these two networks.
 * Queries received from a host on the 192.168.1/24 network will prefer
 * other addresses on that network to the 192.168.2/24 and 192.168.3/24
 * networks.  Queries received from a host on the 192.168.4/24 or the
 * 192.168.5/24 network will only prefer other addresses on their
 * directly connected networks.
 *
 * sortlist {
 *            {
 *              localhost;
 *              {
 *                localnets;
 *                192.168.1/24;
 *                { 192,168.2/24; 192.168.3/24; };
 *              };
 *            };
 *            {
 *              192.168.1/24;
 *              {
 *                192.168.1/24;
 *                { 192.168.2/24; 192.168.3/24; };
 *              };
 *            };
 *            {
 *              192.168.2/24;
 *              {
 *                192.168.2/24;
 *                { 192.168.1/24; 192.168.3/24; };
 *              };
 *            };
 *            {
 *              192.168.3/24;
 *              {
 *                192.168.3/24;
 *                { 192.168.1/24; 192.168.2/24; };
 *              };
 *            };
 *	      {
 *              { 192.168.4/24; 192.168.5/24; };
 *            };
 * };
 *
 * 
 * The following example will give reasonable behaviour for the local host
 * and hosts on directly connected networks.  It is similar to the behavior
 * of the address sort in BIND 4.9.x.  Responses sent to queries from the
 * local host will favor any of the directly connected networks.  Responses
 * sent to queries from any other hosts on a directly connected network will
 * prefer addresses on that same network.  Responses to other queries will
 * not be sorted.
 *
 * sortlist {
 *            { localhost; localnets; };
 *            { localnets; };
 * };
 *
 * XXX - it wouldb e nice to have an ACL called "source" that matched the
 *       source address of a query so that a host could be configured to
 *       automatically prefer itself, and an ACL called "sourcenet", that
 *       would return the primitive IP match element that matched the source
 *       address so that you could do:
 *          { localnets; { sourcenet; { other stuff ...}; };
 *       and automatically get similar behaviour to what you get with:
 *          { localnets; };
 *
 */
=======================================================================

--
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.