Using DSCP With BIND

First introduced as one of the premium features available to subscribers in BIND 9.9 Subscription Version, DSCP was subsequently added to public releases of BIND beginning with BIND 9.10.0.

DSCP gives operators the ability to influence service differentiation by setting a specified value in the IPv4 or IPv6 headers of outgoing traffic sent by the BIND server.

What is DSCP?

A full description of the use of DSCP in IP networks is well beyond the scope of this document, but in basic terms the DSCP, or Differentiated Services Code Point, is a six-bit field in the IP header which can be used by compliant routers to assign different per-hop behavior for traffic based on the DSCP value. Typically the intent is to treat traffic as belonging to different quality of service (QoS) classes based on the value in the DSCP. The actual behavior, however, is completely dependent on the configuration of the routers the tagged traffic passes through. The DSCP is simply an integer value; it is up to the routers carrying traffic to enforce whatever policy the network designer has defined for traffic according to the value in its DSCP field.

Using DSCP in BIND

To support service differentiation according to DSCP, BIND 9 Subscription Version adds a new configuration file element, ip_dscp.  An ip_dscp is an integer number from 0 to 63 (in decimal representation, or 0x00 - 0x3f in hexadecimal) which is provided as the argument to a dscp modifier on a declaration of an ip address or addresses.

For example, "notify-source" is an optional element of a zone declaration that controls the (IPv4) source address from which notify messages are sent.  In the BIND 9 Subscription Version, an extra element is added to the syntax for notify-source (quoted from the BIND Administrator's Reference Manual):

[ notify-source (ipv4_addr | *) [port ip_port] [dscp ip_dscp] ; ]

This should be read as saying that if the keyword "dscp" and a legal ip_dscp value (i.e. 0 - 63) are added to the statement, then traffic controlled by that feature (in this case, notify messages between servers) will be tagged in the outgoing packet headers with the DSCP value specified.

Traffic that is not tagged with an explicitly-specified DSCP value will receive the default DSCP value of 0.

A full list of controls which accept the "dscp ip_dscp" modifier is available in the BIND 9 Administrator's Reference Manual, which is provided in HTML and PDF format with your distribution, but in general any function which controls outgoing traffic now allows a DSCP value to be specified for that outgoing traffic.

ISC has already seen one example of a difficult-to-troubleshoot communication problem between servers in different organizations where traffic between the two servers was being unpredictably dropped in some cases because the receiving organization's routers were configured to give a low priority to traffic tagged with the DSCP value that was being set. When congestion occurred, therefore, the low priority traffic was the first to be dropped, resulting in difficult to characterize problems with notify messages and zone transfers between the servers.



It is most appropriate to use DSCP within the organizational boundaries of your own network, where routers' DSCP-based traffic-handling policies are known to you. Other organizations' policies may differ, resulting in different treatment than you expect based on the DSCP value that you have assigned.)