Using DSCP With BIND
- Updated on 20 Apr 2018
- 3 minutes to read
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.
Handling of DSCP-tagged Traffic Is Dependent on Network Configuration
Before making use of this feature, operators are advised to be mindful of the fact that handling of DSCP-tagged IP traffic is completely dependent on local routing policies. In particular this means that while assigning a non-zero DSCP value may help prioritize traffic within your own organizational network (where the per-hop behavior rules for traffic tagged with a given DSCP value behave as you expect) the behavior for a specific DSCP value may be completely different in another organization.
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.
© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.