使用 sortlist 參數

wxjsr

The sortlist Statement
The response to a DNS query may consist of multiple resource records (RRs) forming a resource records set (RRset). The name server will normally return the RRs within the RRset in an indeterminate order (but see the rrset-order statement in the section called “RRset Ordering”). The client resolver code should rearrange the RRs as appropriate, that is, using any addresses on the local net in preference to other addresses. However, not all resolvers can do this or are correctly configured. When a client is using a local server the sorting can be performed in the server, based on the client's address. This only requires configuring the name servers, not all the clients.
The sortlist statement (see below) takes an address_match_list and interprets it even more specifically than the topology statement does (the section called “Topology”). 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 a 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 the same as 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;                                   // IF   the local host
        { localnets;                               // THEN first fit on the
            192.168.1/24;                          //   following nets
            { 192.168.2/24; 192.168.3/24; }; }; };
    { 192.168.1/24;                                // IF   on class C 192.168.1
        { 192.168.1/24;                            // THEN use .1, or .2 or .3
            { 192.168.2/24; 192.168.3/24; }; }; };
    { 192.168.2/24;                                // IF   on class C 192.168.2
        { 192.168.2/24;                            // THEN use .2, or .1 or .3
            { 192.168.1/24; 192.168.3/24; }; }; };
    { 192.168.3/24;                                // IF   on class C 192.168.3
        { 192.168.3/24;                            // THEN use .3, or .1 or .2
            { 192.168.1/24; 192.168.2/24; }; }; };
    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
    };
};
The following example will give reasonable behavior 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; };
};
The sortlist Statement
The response to a DNS query may consist of multiple resource records (RRs) forming a resource records set (RRset). The name server will normally return the RRs within the RRset in an indeterminate order (but see the rrset-order statement in the section called “RRset Ordering”). The client resolver code should rearrange the RRs as appropriate, that is, using any addresses on the local net in preference to other addresses. However, not all resolvers can do this or are correctly configured. When a client is using a local server the sorting can be performed in the server, based on the client's address. This only requires configuring the name servers, not all the clients.
The sortlist statement (see below) takes an address_match_list and interprets it even more specifically than the topology statement does (the section called “Topology”). 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 a 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 the same as 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;                                   // IF   the local host
        { localnets;                               // THEN first fit on the
            192.168.1/24;                          //   following nets
            { 192.168.2/24; 192.168.3/24; }; }; };
    { 192.168.1/24;                                // IF   on class C 192.168.1
        { 192.168.1/24;                            // THEN use .1, or .2 or .3
            { 192.168.2/24; 192.168.3/24; }; }; };
    { 192.168.2/24;                                // IF   on class C 192.168.2
        { 192.168.2/24;                            // THEN use .2, or .1 or .3
            { 192.168.1/24; 192.168.3/24; }; }; };
    { 192.168.3/24;                                // IF   on class C 192.168.3
        { 192.168.3/24;                            // THEN use .3, or .1 or .2
            { 192.168.1/24; 192.168.2/24; }; }; };
    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
    };
};
The following example will give reasonable behavior 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; };
};


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/66966/showart_570185.html