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 <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
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://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
