Deprecated DSCP support

[Petr Menšík]

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