Deprecated DSCP support

Thu Feb 29 09:30:05 UTC 2024

What I do not understand is, why is not matching always port 53 either 
on source ports or destination ports as enough to set dscp marks. Unless 
you need to differentiate dscp based on domain names, used views or 
something similar, iptables rules should be able to set dscp very 
similar way. Without special code needed inside named. Source or 
destination port 853 would be very similar.

For example dnsmasq can set fwmark based on used domain names. It can 
set different marks to different domain name tree parts, which cannot be 
replaced by simple rules in firewall. I am not aware of similar 
functionality in named, related to dscp.

Perhaps the only thing, where addresses are not explicitly known, is 
setting catalog zones dscp numbers. There you do not have in advance 
addresses used.

When reading bind 9.11 ARM [1], I haven't found much, which should not 
be trivial to replace in firewall outside of named. I understand that is 
extra work for any users of DSCP. But I fail to see serious reason, why 
bind9 should implement it internally. Other resolvers lack it as well.

It seems just simple source or destination address paired with source or 
destination ports would be enough to set correct dscp values for leaving 
packets.

Is that correct observation?

1. https://downloads.isc.org/isc/bind9/9.11.37/doc/arm/Bv9ARM.ch06.html

On 2/29/24 09:59, Wolfgang Riedel wrote:
> Hi Folks,
>
> OK let me help you a bit as it’s really essential for DNS traffic 
> which need to be go through in all situations!!!
>
> Within the OS networking stack as also within the network there is 
> always a prioritisation of packets within the queues to serialise the 
> packets of an application to go on the wire. This prioritisation is 
> being done based on DSCP within a L3 domain and on COS when in a L2 
> domain.
>
> It’s not easy for the network to guess the requirements of an 
> application, therefore best case the application is setting the DSCP 
> itself and the network is just trusting the DSCP or if smart enough 
> the checking and in case of violation doing reclassification.
>
> In my case it’sdscp 24 in named.conf options but the value may be 
> different based on deployment scenarios and therefore needs to be a 
> configureable option.
>
> If you don't set it, it will default to 0 and all other traffic will 
> get higher priority. Saying if you do an ftp download with large 
> frames, your DNS request which will be running in parallel will not be 
> making it through and either get delayed or typically drooped.
>
> Maybe have a look at the following classification scheme:
>
> 640px-IETF_Logo.svg.png
> RFC 4594-Based 12-Class QoS Model 
> <https://www.f1-consult.com/qos/rfc4594/>
> f1-consult.com <https://www.f1-consult.com/qos/rfc4594/>
>
> <https://www.f1-consult.com/qos/rfc4594/>
>
> —
> Hope that helps,
> Wolfgang
> ______________________________________________________________________________________________
> Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559
>
>
>> On 28. Feb 2024, at 22:01, Petr Menšík <pemensik at redhat.com> wrote:
>>
>> We may want to help fixing DSCP features, but I personally do not 
>> know any usage, where this feature would be used and what for 
>> exactly. Recent bind9 uses libuv to back its network core, instead of 
>> custom networking core maintained by ISC. But I haven't found any 
>> trace of DSCP support at libuv docs [1]. I haven't found a way to set 
>> at least type of service on UDP [2].
>>
>> I think that would be the first place to support DSCP values for 
>> connections or sockets. Then, once libuv can use it, its support 
>> could be added back into named.
>>
>> It would help though if you were more verbose about why iptables 
>> cannot replace it and what is use-case, when it is useful. Without 
>> simple alternatives present. If you would describe it, it might 
>> motivate more people to work on DSCP support. I haven't seen 
>> important reason, why it needs to be done by the daemon itself. 
>> Perhaps we can find alternative way to set DSCP tags for you, if you 
>> are more verbose about how you use it?
>>
>> Regards,
>> Petr
>>
>> 1. 
>> https://docs.libuv.org/en/v1.x/search.html?q=dscp&check_keywords=yes&area=default
>> 2. https://docs.libuv.org/en/v1.x/udp.html
>>
>> On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:
>>> Hi,
>>> I am working on a product in Nokia, and we currently use BIND 
>>> provided by Rocky Linux 8 with security patches. Recently the 
>>> requirement came that we should upgrade to at least 9.16. During the 
>>> testing of this version we realized that a feature we used, DSCP, 
>>> has stopped working. Reading about the topic, we found the article 
>>> about it non-operational in 9.16, and removal in 9.18.
>>>  We also saw the email on this mailing list, stating that "so far, 
>>> nobody has noticed" it is missing. Well, we noticed it just now, and 
>>> I would like to state that our product and most probably other 
>>> telecom equipments using BIND would miss it greatly. As I read in 
>>> that mail, there was an alternative plan which would re-implement 
>>> this functionality. If it is feasible, please consider doing it. The 
>>> alternative options, e.g. setting it via iptables cannot work in our 
>>> use-case.
>>>  Best regards,
>>> Balazs Hinel
>>
>> -- 
>> Petr Menšík
>> Software Engineer, RHEL
>> Red Hat, http://www.redhat.com/
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
>> -- 
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> ISC funds the development of this software with paid support 
>> subscriptions. Contact us at https://www.isc.org/contact/ for more 
>> information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240229/b36b1191/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 640px-IETF_Logo.svg.png
Type: image/png
Size: 23934 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240229/b36b1191/attachment-0001.png>