How does that actually help with anything? The DNS traffic is not one way, but two way and unless everyone is setting DSCP on the DNS messages the incoming DNS messages will have same priority as incoming FTP traffic (to use your example).

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

On 29. 2. 2024, at 10:00, Wolfgang Riedel via bind-users <bind-users@lists.isc.org> 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’s dscp 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:



Hope that helps,
Wolfgang
______________________________________________________________________________________________
Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559


On 28. Feb 2024, at 22:01, Petr Menšík <pemen...@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to