Re: Deprecated DSCP support

[Evan Hunt]

On Thu, Feb 29, 2024 at 10:34:42AM +0100, Borja Marcos wrote:
> But bear in mind that this is only guaranteed to work inside your
> network/ASN. It’s not unusual to scrub DSCP at the network border.

Same problem would also apply to DSCP values set internally by named,
of course.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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

Re: Deprecated DSCP support

[Robert Franklin]

Hello,


> On 29 Feb 2024, at 09:34, Greg Choules via bind-users 
>  wrote:
> 
> But regarding your comment "It’s not easy for the network to guess the 
> requirements of an application," I would disagree. Traffic classification and 
> setting of DSCP values is something that edge routers have been capable of 
> for decades. I would even argue that this is the place you *want* to do it, 
> rather than trusting what the application itself says it wants.
> 
> If you must do the whole QoS thing at all, use something like a policy-map 
> (other manufacturers are available), match all port 53, set DSCP to an 
> appropriate value for *your* network and prioritise/police as appropriate in 
> the core.

I think the solution is a combination of those things -- the application can 
set DSCP values to indicate to the network how it would like its traffic 
treated.  The network should then apply policies on what it's then happy to 
accept: it may say "I don't care you think this is high priority, I don't and 
I'm going to remark it as 'default'".  That policy can be based on anything: IP 
addresses, port numbers, DSCP values, etc.

In our case, we allow people to mark traffic in certain ways, including a 
'below best efforts' level for things like bulk software installs or data 
transfers, where you want the network to only give it spare bandwidth.  Also, 
in the case of the phone system, certain operations, like firmware updates, are 
not marked as a priority compared to call audio or signalling.

In some cases, this can be determined by the network by looking at port numbers 
but, in other cases (as with our phone system), it's not possible for the 
network to tell the difference as there is no clear separation - only the phone 
systems knows what is what.  Still, at the network level, we might have to fix 
up broken DSCP values, ignore others, etc.  We certainly don't just trust 
everything coming in: if it doesn't match an allowed policy, it gets remarked 
as 'best efforts'.


In this case, however, I don't see the point in this unless certain domain name 
lookups are more (or less) important than others.  If all DNS traffic is to be 
treated specially (compared to other traffic) but the same (as other DNS 
traffic), you can just do it in the OS (iptables et al) or at the network level.

The other point, as someone else made, is that you probably need the queries 
from the clients to be marked appropriately and I suspect most won't be doing 
that, so you'll be fixing those up in the network anyway.


Generally QoS seems to have fallen out of favour as it's easier to solve most 
problems with more bandwidth, and it's not clear what's important anyway (and 
you can often only tell at layer 7), but there are still cases where it's 
necessary.

  - Bob


-- 
Robert Franklin  / (+44 1223 7) 48479
University Information Services: Network Systems, University of Cambridge

-- 
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

Re: Deprecated DSCP support

[G.W. Haywood]

Hi there,

On Thu, 29 Feb 2024, Wolfgang Riedel wrote:


In my case it?s dscp 24 in named.conf ...

If you don't set it, ...


ns9:~# >>> man named.conf | grep dscp
   dscp ; // obsolete

--

73,
Ged.
--
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

Re: Deprecated DSCP support

[Borja Marcos]

> On 29 Feb 2024, at 10:21, Petr Špaček  wrote:
> 
> On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:
>> 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.
> 
> Could you please explain why it's not possible?
> 
> Maybe I'm naive, but something like
> 
> iptables -t mangle -A ... -p udp --dport 53 -j DSCP --set-dscp-class ...
> 
> seems like sensible approach to me, and actually in the right place of 
> networking stack.

Actually I’ve sometimes done the same on FreeBSD using its internal firewall 
facility. 

03000 setdscp cs7 ip from me to table(53)

But bear in mind that this is only guaranteed to work inside your network/ASN. 
It’s not unusual to scrub DSCP at the network border.





Borja.

-- 
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

Re: Deprecated DSCP support

[Greg Choules via bind-users]

Hi Wolfgang.
Firstly let me say that I have never been a fan of QoS. So I'm slightly
biased against the whole thing in the first place.

But regarding your comment "It’s not easy for the network to guess the
requirements of an application," I would disagree. Traffic classification
and setting of DSCP values is something that edge routers have been capable
of for decades. I would even argue that this is the place you *want* to do
it, rather than trusting what the application itself says it wants.

If you must do the whole QoS thing at all, use something like a policy-map
(other manufacturers are available), match all port 53, set DSCP to an
appropriate value for *your* network and prioritise/police as appropriate
in the core.

Cheers, Greg

On Thu, 29 Feb 2024 at 09: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:
>
> [image: 640px-IETF_Logo.svg.png]
>
> RFC 4594-Based 12-Class QoS Model
> 
> f1-consult.com 
> 
>
> —
> Hope that helps,
> Wolfgang
> __
> 
> Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559
>
>
> On 28. Feb 2024, at 22:01, Petr Menšík  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_keywords=yes=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 

Re: Deprecated DSCP support

[Ondřej Surý]

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  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:<640px-IETF_Logo.svg.png>RFC 4594-Based 12-Class QoS Modelf1-consult.com
—Hope that helps,Wolfgang__Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559
On 28. Feb 2024, at 22:01, Petr Menšík  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,Petr1. https://docs.libuv.org/en/v1.x/search.html?q=dscp_keywords=yes=default2. https://docs.libuv.org/en/v1.x/udp.htmlOn 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šíkSoftware Engineer, RHELRed Hat, http://www.redhat.com/PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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

Re: Deprecated DSCP support

[Petr Menšík]

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 


f1-consult.com 



—
Hope that helps,
Wolfgang
__
Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559



On 28. Feb 2024, at 22:01, Petr Menšík  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_keywords=yes=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 

Re: Deprecated DSCP support

[Petr Špaček]

On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:

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.


Could you please explain why it's not possible?

Maybe I'm naive, but something like

iptables -t mangle -A ... -p udp --dport 53 -j DSCP --set-dscp-class ...

seems like sensible approach to me, and actually in the right place of 
networking stack.


We are hesitant to (re)introduce complexity and layering violations 
without rock solid use-case without existing alternatives.


--
Petr Špaček
Internet Systems Consortium
--
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

Re: Deprecated DSCP support

[Wolfgang Riedel via bind-users]

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:

https://www.f1-consult.com/qos/rfc4594/
RFC 4594-Based 12-Class QoS Model
f1-consult.com

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


> On 28. Feb 2024, at 22:01, Petr Menšík  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_keywords=yes=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



signature.asc
Description: Message signed with OpenPGP
-- 
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

Re: Deprecated DSCP support

[Stacey Marshall]

Not familiar with DSCP, Differentiated Services Code Point, a means of 
classifying and managing network traffic and of providing quality of 
service (QoS) in modern IP networks [D].


Google search found me a libuv conversation `Setting DSCP per UDP 
datagram` [A] which links to `Extending the uv_udp_send_t to hold a 
"before_send" callback` #2536 [B] and `unix,win: introduced 
uv_udp_send_ex and uv_udp_try_send_ex` #2558 [C].

Work-in-progress, but not complete.

A. https://groups.google.com/g/libuv/c/8b0lvUqnGaM
B. https://github.com/libuv/libuv/issues/2536
C. https://github.com/libuv/libuv/pull/2558
D. https://en.wikipedia.org/wiki/Differentiated_services

--
Stace

On 28 Feb 2024, at 21:01, Petr Menšík 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_keywords=yes=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

Re: 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_keywords=yes=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

Deprecated DSCP support

[Balazs Hinel (Nokia) via bind-users]

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
-- 
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