Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"

[Ondřej Surý]

Hello,

In line with ISC's deprecation policy, I am notifying the mailing list
of our intent to deprecate the "sortlist" options and a value "fixed"
for "rrset-order" option.

These options allow to specify a on order of the resource records
in the responses.

The "fixed" value for "rrset-order" option will make named to record
the order the records are defined in the zone file and it's disabled at
the compile time because it blows up memory use. Relying on the
order of the resource records in the DNS responses has been always
wrong, but we are still keeping the "rrset-order" option, but please
don't use it.

The "sortlist" option allows to define a complicated rules when and
how to reorder the resource records in the responses. The same
caveats as with the "rrset-order" apply - relying on any specific
order of resource records in the DNS responses is wrong.

We are not aware of any other (major) DNS server that would have
similar behaviour as this was never specified in the DNS protocol.
If you know of any software or hardware relying on any specific
order of the resource records in the DNS messages, it needs to
be reported as a bug to the respective vendor.

They will be deprecated as of BIND 9.20 and removed in BIND 9.22.

Cheers,
--
Ondřej Surý (He/Him)
ond...@isc.org

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

-- 
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: Problem upgrading to 9.18 - important feature being removed

[Ondřej Surý]

> On 26. 2. 2024, at 22:41, Al Whaley  wrote:
> 
> A lot of pain and suffering in this world comes from people being sure they 
> have a 'better idea' and everybody needs to do whatever.  This feels a bit 
> like that.  A command that gives choice and real certainty would be great.

Hi,

I wanted to address this comment. We (the developers) don't remove the features 
out of convenience or because we have 'better idea'. A maintainable software 
can't look like Katamari[1]. Yes, sometimes we have better ideas (without the 
quotes) and we implement them, because they make things simpler, better, more 
stable, faster, ... add your own. Sometimes we even break things. But 
ultimately, the developers working on BIND 9 are just a few people and it's 
absolutely reasonable to remove rarely used features - especially if there's a 
replacement either in or out of BIND 9. Giving a choice is great, but then 
**who** will carry the costs of giving the choice? Maintaining all kind of 
knobs and options does come with burden and that burden might ultimately lead 
to a situation where all the time and resources are spent on maintaining those 
old features, and there's not enough left to add new improvements.

For every decision we make, be it adding a new feature or removing an old 
feature, we do carefully consider the implications it has on the users, on the 
developers, and on the world as a whole. And it is kind of hurtful to imply 
that we do things just because "we know better" (paraphrasing).

1. https://en.wikipedia.org/wiki/Katamari_Damacy

Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

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

[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: fixed rrset ordering - is this still a thing?

[Matt Nordhoff via bind-users]

On Fri, Mar 1, 2024 at 12:38 AM Matt Nordhoff  wrote:
> On Thu, Feb 29, 2024 at 9:40 PM Ondřej Surý  wrote:
> > Hey,
> >
> > BIND 9 supports a fixed rrset ordering (that is keeping the order of the 
> > RRSets from the zone file). It has to be configured
> > at the compile time, it takes more memory (to record that order) and it's a 
> > #ifdef all over the places.
> >
> > So, henceforth, my question - does anyone still uses that? And if yes, what 
> > are the use cases?
> >
> > I think BIND is the only server that actually supports this, so it doesn't 
> > feel like the DNS can't function without it.
>
> For what it's worth, Knot DNS is fixed by default. I know because the
> first setting in my knot.conf file is "answer-rotation: on". :-)

Correction: It's fixed but sorted, rather than fixed in the original
zone file order. Which is not necessarily the same as any of BIND's
settings?

I'll go hide in a cave and wish emails could be edited now. :-)

> NSD also has a "round-robin" setting, which is also off by default.
>
> So other nameservers do support fixed order, but I personally don't
> use it and don't mind if you remove it.
>
> > Thanks,
> > Ondřej
-- 
Matt Nordhoff
-- 
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: fixed rrset ordering - is this still a thing?

[Matt Nordhoff via bind-users]

On Thu, Feb 29, 2024 at 9:40 PM Ondřej Surý  wrote:
> Hey,
>
> BIND 9 supports a fixed rrset ordering (that is keeping the order of the 
> RRSets from the zone file). It has to be configured
> at the compile time, it takes more memory (to record that order) and it's a 
> #ifdef all over the places.
>
> So, henceforth, my question - does anyone still uses that? And if yes, what 
> are the use cases?
>
> I think BIND is the only server that actually supports this, so it doesn't 
> feel like the DNS can't function without it.

For what it's worth, Knot DNS is fixed by default. I know because the
first setting in my knot.conf file is "answer-rotation: on". :-)

NSD also has a "round-robin" setting, which is also off by default.

So other nameservers do support fixed order, but I personally don't
use it and don't mind if you remove it.

> Thanks,
> Ondřej
-- 
Matt Nordhoff
-- 
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

fixed rrset ordering - is this still a thing?

[Ondřej Surý]

Hey,

BIND 9 supports a fixed rrset ordering (that is keeping the order of the RRSets 
from the zone file). It has to be configured
at the compile time, it takes more memory (to record that order) and it's a 
#ifdef all over the places.

So, henceforth, my question - does anyone still uses that? And if yes, what are 
the use cases?

I think BIND is the only server that actually supports this, so it doesn't feel 
like the DNS can't function without it.

Thanks,
Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

-- 
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: occasional SERVFAIL error

[Peter Davies]

Hi Ludovit,

   It looks like you have two version of the jiscd.sk zone.

host -C jiscd.sk
Nameserver 2001:67c:1bd4:8080::20:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 195.49.191.160:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 2001:67c:1bd4:8080::10:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400

Nameserver 195.49.191.162:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400



Kind Regards Peter

On 29/02/2024 15.20, Ludovit Koren wrote:


Hi,

occasionally I get the following SERVFAIL error:

dig www.jiscd.sk

; <<>> DiG 9.18.24 <<>> www.jiscd.sk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good)
;; QUESTION SECTION:
;www.jiscd.sk.  IN  A

;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 14:27:16 CET 2024
;; MSG SIZE  rcvd: 69



I can get rid of it only after issuing:

rndc flush

Afterwards it works for uncertain time.

Could it be I have a configuration problem of my server (I have prefetch
0 set in options section of my server)? Is it a problem of the
authorized domain server?

Thank you very much.

Regards,

lk


--
Peter Davies

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

occasional SERVFAIL error

[Ludovit Koren]

Hi,

occasionally I get the following SERVFAIL error:

dig www.jiscd.sk

; <<>> DiG 9.18.24 <<>> www.jiscd.sk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good)
;; QUESTION SECTION:
;www.jiscd.sk.  IN  A

;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 14:27:16 CET 2024
;; MSG SIZE  rcvd: 69



I can get rid of it only after issuing:

rndc flush

Afterwards it works for uncertain time.

Could it be I have a configuration problem of my server (I have prefetch
0 set in options section of my server)? Is it a problem of the
authorized domain server?

Thank you very much.

Regards,

lk
-- 
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&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 h

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&check_keywords=yes&area=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
bind-users@l

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

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



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