Re: Deprecated DSCP support
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: DNSSec mess with SHA1
Hi Folks, Many thanks for you feedback and insights. I didn’t wanted to say that this is an ISC issue or something I expected someone to fix. I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-) Yes, it may be a distribution packing or installation issue outside of BIND but nevertheless it’s impacting DNS resolution in a negative way. Anyway, the easy solution to get it working without creating DNSSEC exceptions lists is: update-crypto-policies --set LEGACY … but I still think the right way would be getting people signing their zones with ED25519 or ED448 as mentioned by Scott. The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA]. +++-+---+ | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | +++-+---+ | 1 | RSAMD5 | MUST NOT| MUST NOT | | 3 | DSA| MUST NOT| MUST NOT | | 5 | RSASHA1| NOT RECOMMENDED | MUST | | 6 | DSA-NSEC3-SHA1 | MUST NOT| MUST NOT | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | | 8 | RSASHA256 | MUST| MUST | | 10 | RSASHA512 | NOT RECOMMENDED | MUST | | 12 | ECC-GOST | MUST NOT| MAY | | 13 | ECDSAP256SHA256| MUST| MUST | | 14 | ECDSAP384SHA384| MAY | RECOMMENDED | | 15 | ED25519| RECOMMENDED | RECOMMENDED | | 16 | ED448 | MAY | RECOMMENDED | +++-+---+ I still puzzled why root zones can’t get it done to re-singn their zones with a decent algorithm and that organisations like NIST are still on SHA1… Cheers and many thanks, Wolfgang On 15. Dec 2023, at 23:11, Mark Andrews wrote: They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews On 16 Dec 2023, at 01:09, Scott Morizot wrote: On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček mailto:pspa...@isc.org>> wrote: We do runtime detection at startup because it's configurable, build time would not work properly. Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime error or at least report that DNSSEC validation has been disabled. The description involved removing support for SHA1 entirely from the underlying system configuration. If that's the case then I don't see how DNSSEC validation can be reliably performed at all. It's not like introducing a new DNSSEC algorithm or removing support for an older DNSSEC algorithm. SHA1 is used to generate the hash label in NSEC3. I know that's been discussed on dnsops, but it hasn't changed. And from algorithm 8 on, there haven't been separate algorithms with and without NSEC3. Rather it's an option that can be configured for signing on a zone by zone basis. So if SHA1 isn't available, I don't see how any of the DNSSEC algorithms could truly be considered supported on the system. That's making me curious enough that I might see if I can set up a system where I could reproduce that scenario and see what happens. Unless it's already part of your test suite and you know the answer, of course. Scott -- 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
Re: DNSSec mess with SHA1
Hello, To answer my own question, the following will work: <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> [shadowman-200.png] Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise Linux 8 | Red Hat Customer Portal<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> access.redhat.com<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening> With:dnssec-validation auto; Not working: sudo update-crypto-policies —show DEFAULT working: update-crypto-policies --set LEGACY sudo update-crypto-policies --show LEGACY — Cheers, Wolfgang __ Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users wrote: Hello Petr, The issue is not just BIND local, as you can see on dnsviz.net<http://dnsviz.net/>. The whole chain of trust is broken. <https://dnsviz.net/d/nist.gov/dnssec/> nist.gov<https://dnsviz.net/d/nist.gov/dnssec/> dnsviz.net<https://dnsviz.net/d/nist.gov/dnssec/> <https://dnsviz.net/d/nist.gov/dnssec/> My question is more how you all deal with the fact on current and updates systems??? Attached the requested information. 1) Error Messages: 15-Dec-2023 12:36:38.772 lame-servers: info: insecurity proof failed resolving 'nist.gov/DNSKEY/IN': 2600:1480:800::43#53 15-Dec-2023 12:36:39.302 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1401:1::42#53 15-Dec-2023 12:36:40.151 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2610:20:6b01:3::10#53 15-Dec-2023 12:36:40.681 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1401:2::d8#53 15-Dec-2023 12:36:40.779 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1480:9000::40#53 15-Dec-2023 12:36:41.304 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1406:32::43#53 15-Dec-2023 12:36:41.321 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2600:1480:f000::41#53 15-Dec-2023 12:36:41.784 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2610:20:6005:92::10#53 15-Dec-2023 12:36:41.828 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 2.22.230.67#53 15-Dec-2023 12:36:43.094 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 132.163.3.10#53 15-Dec-2023 12:36:43.148 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 193.108.91.216#53 15-Dec-2023 12:36:43.237 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 72.246.46.64#53 15-Dec-2023 12:36:43.288 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 23.61.199.67#53 15-Dec-2023 12:36:43.305 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 184.26.160.65#53 15-Dec-2023 12:36:43.771 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 129.6.92.10#53 15-Dec-2023 12:36:43.823 lame-servers: info: no valid RRSIG resolving 'nist.gov/DNSKEY/IN': 23.211.133.66#53 15-Dec-2023 12:36:43.824 lame-servers: info: broken trust chain resolving 'www.nist.gov/A/IN': 2610:20:6005:92::10#53 15-Dec-2023 12:36:45.905 lame-servers: info: broken trust chain resolving 'www.nist.gov/A/IN': 2600:1480:f000::41#53 15-Dec-2023 12:36:47.403 lame-servers: info: broken trust chain resolving 'csrc.nist.gov/A/IN': 2600:1480:f000::41#53 15-Dec-2023 12:38:26.064 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3a::1#53 15-Dec-2023 12:38:26.880 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3d::1#53 15-Dec-2023 12:38:27.148 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.62.1#53 15-Dec-2023 12:38:27.415 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.60.1#53 15-Dec-2023 12:38:27.753 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.61.1#53 15-Dec-2023 12:38:27.770 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.63.1#53 15-Dec-2023 12:38:28.037 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3c::1#53 15-Dec-2023 12:41:23.114 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3d::1#53 15-Dec-2023 12:41:23.380 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 2a01:8840:3a::1#53 15-Dec-2023 12:41:23.648 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.62.1#53 15-Dec-2023 12:41:23.986 lame-servers: info: no valid RRSIG resolving 'apple/DNSKEY/IN': 65.22.61.1#53 15-Dec-2023 12:41:24.003 lame
DNSSec mess with SHA1
Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others simply removed SHA1 from the code so if you're running BIND with "dnssec-validation auto" all those domains fails to resolve and the only way is to "dnssec-validation no" which eliminated the whole idea of DNSSec! The worst is that even nist.gov fails WFT! https://dnsviz.net/d/nist.gov/dnssec/ Any advice or ideas? Thank you, Wolfgang Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559 Am Leitenbruennlein 22 | D-91056 Erlangen | Bayern | Germany phone: +49-9131-610-310 fax: +49-9131-610-333 email: wolfgang.rie...@f1-consult.com web: www.f1-consult.com OpenPGP key: CAF005CEC96C30CF4DBA5AFA3DBAFBAF63364 Zoom: https://zoom.us/j/5776157658 WebEx: https://f1-consult.webex.com/meet/wolfgang.riedel __ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. -- 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
