Advanced DNS Course Module 4 DNS Load Balancing
Services (SRV) Record The Services RR allows a service to be associated with a host name. A user or application that wishes to discover where a service is located can interrogate for the relevant SRV RR that describes the service. The result of a successful SRV query will be one or more host names, the port that provides the service, and two values that can be used to select the relative priority and performance of the service. Having obtained the host name, a further A (or AAAA) query will be required to obtain the IP address of the selected service. The SRV RR is being increasingly supported as the means by which the location of a service at a particular domain may be discovered, notably with VoIP and LDAP applications. OpenLDAP (www.openldap.org) in particular supports the SRV record (and publishes an SRV RR) to discover the location of the LDAP service at a domain. The SRV RR is defined in RFC 2782. SRV RR Syntax srvce.prot.name ttl class rr pri weight port target _http._tcp IN SRV 0 5 80 www.example.com. Table 1 describes the various fields unique to the SRV RR. Table 1. SRV RR Fields Field srvce Description The srvce field defines the symbolic service name. Standard symbolic service name values are listed by IANA (under the port number list at www.iana.org/assignments/port-numbers), but there is a specific SRV list currently being maintained (see note that follows) outside of IANA. Service names are case insensitive and are always prepended with _ (underscore). Common values are _http for web service, _ftp for File Transfer Protocol, _sip for Session Initiation Protocol, and _ldap for LDAP service. This srvce field
may also take a local value its scope is local to the user and therefore may take any desired value that does not conflict with the IANA list earlier. The IANA list also defines the port assigned to the service, but the port field within the SRV RR allows this port number to be changed for the particular service instance if required. prot name pri weight port target The prot field defines the case-insensitive protocol name (see www.iana.org/assignments/servicenames) prepended with a _ (underscore). Common values are _tcp for the TCP protocol and _udp for the UDP protocol. The name field is optional. If not present, then normal $ORIGIN substitution rules will occur. See the examples that follow. The pri field defines the relative priority of this service (range 0 to 65535). Lower numbers are higher priority as in the MX RR type. The weight field is used when more than one service with same priority is available. weight is a 16-bit unsigned integer in the range 0 to 65535. The value 0 indicates no weighting should be applied. If the weight is 1 or greater, it is a relative number in which the highest is most frequently delivered; that is, given two SRV records, both with a priority of, say, 10, one with a weight of 1, the other a weight of 6, the one with weight 6 will have its RR delivered first six times out of seven by the name server. The port field defines the port number that delivers the service on the target (see the target entry). This would normally be the port assigned to the symbolic service (srvce field), but this is not a requirement; for instance, it is permissible to define an _http service with a port number of 8100 rather than the more normal port 80. The target field defines the name of the host that will provide this service and will typically require a query to obtain the IP address (A or AAAA RR query). The target host may lie within this domain or in an external or foreign domain. The following fragment shows use of the priority and weight fields to define a web service with load balancing: ; zone file fragment for example.com. $TTL 2d ; zone TTL default = 2 days $ORIGIN example.com. @ SOA server.example.com. hostmaster.example.com. ( 2010080800 ; serial number 1d12h ; refresh = 1 day 12 hours 15m ; refreshretry = 15 minutes 3w12h ; expiry = 3 weeks + 12 hours 2h20m ; nx= 2 hours + 20 minutes... _http._tcp ) SRV 10 1 80 slow.example.com. SRV 10 3 80 fast.example.com. ; if neither slow or fast available, switch to ; an external backup web server but use port 8100 not port 80 SRV 20 0 8100 backup.example.net. slow A 192.168.254.3 fast A 192.168.254.4 In the preceding fragment, both fast.example.com and slow.example.com have equal priorities; the weight values are 1 and 3, respectively, which will result in fast.example.com being returned three times to every one return of slow.example.com. Thus fast.example.com will theoretically receive 75% of the load. If neither fast nor slow is available, the externally hosted backup.example.net should be used with port 8100,
not the more normal HTTP port of 80. The following fragment shows use of the SRV RR to discover the host for the LDAP service at example.com: ; zone file fragment for example.com. $TTL 2d ; zone TTL default = 2 days $ORIGIN example.com.... ; defines an ldap service available at the host jim.example.com _ldap._tcp.example.com. IN SRV 0 0 389 ldap.example.com. ; the preceding record could have been written as ; _ldap._tcp IN SRV 0 0 389 ldap... ldap IN A 192.168.254.2... To discover whether an LDAP service is available at example.com, an SRV query would be sent for _ldap_.tcp.example.com, which in the preceding case would return 0 0 389 ldap.example.com; ldap.example.com would then be queried for its A RR (or AAAA RR if IPv6), and communication could commence.
rrset-order rrset-order { order_spec ; [ order_spec ;... ] rrset-order { type A order cyclic; }; rrset-order defines the order in which RRsets multiple records of the same type are returned in the ANSWER and ADDITIONAL SECTION of responses. This statement applies to any RR type in which the records are similar (their name, class, and type are the same). The default is cyclic. The rrset-order defines the order in which similar RRs are returned from the name server. The sortlist statement controls the order in which the RRs are returned to a client, for instance, a resolver. An order_spec is defined as follows: [ class class_name ][ type type_name ][ name "domain_name"] order ordering where class_name is the record class, for instance, IN (default is any); type_name is the RR type (defaults to any); and domain_name limits the statement to a specific domain suffix and defaults to root (all domains). ordering may take one of the following values: fixed records are returned in the order they are defined in the zone file; random records are returned in a random order; cyclic records are returned in a roundrobin fashion. fixed needs BIND to be built using the configure option --enable-fixedrrset which is not the done on standard BIND packages for either Ubuntu or FreeBSD. For practical purposed only random and cyclic ordering values are available. See also the acache-enable statement under BIND Performance Statements for aditional restrictions. Only one such statement may appear in any clause the last defined will be used in the case of multiple statements. This statement may be used in a view or global options clause. The following example shows that MX RRs for example.com only will be returned in random order; all others responses will use the default cyclic order. rrset-order { type MX name "example.com" order random; order cyclic;};
sortlist The sortlist statement is used to order RRsets (groups of RRs whose name, class, and type values are the same) for use by a resolver (a client). It is the client-side equivalent of the rrset-order statement and can work against the rrset-order statement when being used as part of a load-balancing configuration: rrset-order carefully delivers RRsets in its order of preference to a remote resolver that may then proceed to reorder them with a sortlist statement when responding to its client resolver. The sortlist statement attempts to order returned records based on the IP address of the client that initiated the request. sortlist Statement Syntax sortlist { address_match_list }; sortlist { {10.2/16; } ;}; The address_match_list is used very differently from the way it is used in all other statements and assumes that each element of the address_match_list is itself an address_match_list, that is, it is a nested address_match_list and is enclosed in braces. Processing depends on whether there is one or more than one element in the nested address_match_list. In the simple case of one element, as in the preceding example, if the client s IP address matches 10.2/16 (that is, lies in the range 10.2.0.0 to 10.2.255.255) and there are any IP addresses in the response in the same range, they will be the first records supplied in the response. Any remaining records will be sorted according to the rrset-order (default is cyclic). If no match is found, the
records are simply returned in the order defined by the rrset-order or its default value (cyclic). If two elements are provided in the address_match_list, then the second element is assumed to be an ordered list of preferences. This is best illustrated by an example. Assume the zone example.com has a zone file with multiple A RRs for lots.example.com: // zone file example.com $ORIGIN example.com. lots IN A 192.168.3.6 IN A 192.168.4.5 IN A 192.168.5.5 IN A 10.2.4.5 IN A 172.17.4.5 The client-side server has a sortlist statement, as shown here: options {... sortlist { {// 1st preference block start 192.168.4/24; // 1st client IP selection matches any of these {10.2/16; // return any of these response IPs as 1st preference 172.17.4/24; // 2nd preference }; }; // end first block { // second preference block 192.168.5/24; // 2nd client IP selection matches any of these {192.168.4/24; // return any of these response IPs as 1st preference 172.18.4/24; // 2nd preference 10.2/16; // 3rd preference }; }; // end second block }; // end sortlist }; If the client, say a resolver, with an IP address of 192.168.5.33 issues an A query for lots.example.com, then the RRs will be returned in the following order: 192.168.4.5 10.2.4.5 192.168.3.6 192.168.5.5 172.17.4.5 The preceding order is computed using the following process: The top level of the address_match_list is searched against the client IP (192.168.5.33) address and matches the IP address in the sortlist statement with a comment beginning with 2nd client IP selection ; the nested address_match_list of the second block is then treated as an ordered list for the A query result RRset IPs (not the client IP). The IP address in the sortlist statement with a comment ending with 1st preference matches, so 192.168.4.5 becomes first in the returned list. The IP address in the sortlist statement with a comment of 2nd preference does not match any of the returned IPs. The IP address in the sortlist statement with a comment of 3rd
preference matches, so 10.2.4.5 becomes second in the returned list. The remaining three RRs do not match, so they are returned according to the rrset-order statement or its default (cyclic) if not defined. The sortlist statement may be used in a view or global options clause.