Re: error - exiting (due to assertion failure)
Hi, I’m running BIND 9.18.30-0ubuntu0.22.04.2-Ubuntu in production on a university network. Recently, we have been experiencing the error shown below: named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_assertion_failed+0x10) [0x7fe1b4e1d7c0] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_assertion_failed+0x10) [0x7fe1b4e1d7c0] named[4787]: /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x3a2f5) [0x7fe1b4c0c2f5] named[4787]: /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x3a2f5) [0x7fe1b4c0c2f5] named[4787]: /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(dns_cache_create+0x1e4) [0x7fe1b4c0cdc4] named[4787]: /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(dns_cache_create+0x1e4) [0x7fe1b4c0cdc4] named[4787]: /usr/sbin/named(+0x33524) [0x562bd4cd3524] named[4787]: /usr/sbin/named(+0x33524) [0x562bd4cd3524] named[4787]: /usr/sbin/named(+0x41e6f) [0x562bd4ce1e6f] named[4787]: /usr/sbin/named(+0x41e6f) [0x562bd4ce1e6f] named[4787]: /usr/sbin/named(+0x43771) [0x562bd4ce3771] named[4787]: /usr/sbin/named(+0x43771) [0x562bd4ce3771] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_task_run+0x2bf) [0x7fe1b4e4553f] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_task_run+0x2bf) [0x7fe1b4e4553f] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x1e993) [0x7fe1b4e09993] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x1e993) [0x7fe1b4e09993] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26368) [0x7fe1b4e11368] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26368) [0x7fe1b4e11368] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26b77) [0x7fe1b4e11b77] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26b77) [0x7fe1b4e11b77] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26d96) [0x7fe1b4e11d96] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26d96) [0x7fe1b4e11d96] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x91ad) [0x7fe1b468e1ad] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x91ad) [0x7fe1b468e1ad] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x250fe) [0x7fe1b46aa0fe] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x250fe) [0x7fe1b46aa0fe] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x678) [0x7fe1b4693c48] named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x678) [0x7fe1b4693c48] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x2720a) [0x7fe1b4e1220a] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x2720a) [0x7fe1b4e1220a] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc__trampoline_run+0x1a) [0x7fe1b4e4d50a] named[4787]: /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc__trampoline_run+0x1a) [0x7fe1b4e4d50a] named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3] named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3] named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850] named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850] named[4787]: exiting (due to assertion failure) named[4787]: exiting (due to assertion failure) Please advise, I have checked online with no luck. Thanks with kind regards, Paul Ssekamatte Directorate for ICT Services (DICTS) Makerere University Mob: 0782-094368 -- 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: Survey on the impact of software regulation on DNS systems
> > ! Users of Open Source projects are responsible themselves for what > ! they use. You want to use a free image editor? fine, go ahead! > > Exactly, that is the idea! And I love it - it allows me to NOT > depend on service providers, to run my infrastructure in the way > I like it, and to be in control. I don't like it when people want > to tell me what is best for me to eat, or what is best for me to > buy, or what is best for me to run my computers. I don't like it > when people think they know better than me what is good for me. > And anyway, what qualification do these people have? > > But this is exactly what will disappear, and the road map is clear. > You have to get the bigger picture. Everything requires regulation otherwise big tech is going to fuck you. There are enough examples out there. -- 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: Survey on the impact of software regulation on DNS systems
On Wed, Jan 29, 2025 at 03:43:23PM +, Marcus Kool wrote: ! I participated in the survey and think it is good to also have a ! public discussion. I tried to, but got the impression that the target audience is rather commercial providers of infrastructure services, like domain registrars and dns service providers. Not somebody like me who just runs a cloud infrastructure for their own purposes. ! Users of Open Source projects are responsible themselves for what ! they use. You want to use a free image editor? fine, go ahead! Exactly, that is the idea! And I love it - it allows me to NOT depend on service providers, to run my infrastructure in the way I like it, and to be in control. I don't like it when people want to tell me what is best for me to eat, or what is best for me to buy, or what is best for me to run my computers. I don't like it when people think they know better than me what is good for me. And anyway, what qualification do these people have? But this is exactly what will disappear, and the road map is clear. FOSS doesn't matter anymore. Already, a bunch of the FOSS software you get cannot run on Unix (Berkeley). See for example that "Dart" compiler. If you happen to develop Web applications, you may likely need it. But it can run only on Windows/ Linux/Applestuff. It is open source, but it is incredible big, and even if you manage to port it to Unix, Google will not support this. Instead they will flood you with continuous changes, which you then have to continuously integrate in your fork. It is an impossible task. As big as software packages nowadays have become, there are now other means to make proprietary software - it is no longer necessary to protect or hide the source. As I said, the road map is clear: the mass of people, the so-called "consumers" will only have the choice between the three big brands, and then these control the software - either because it is already proprietary, or because it is just too big to maintain on your own. And this includes the developers, because for development stuff the same applies. Or maybe you need a forum to discuss with your co-developers - discourse forum for instance, is open source, but runs only in a container on a specific brand of linux. FOSS is no longer the point, the market converges by itself (due to reasons I could elaborate on). So those are the consumers, Tha other part is, logically, the providers. These are more or less what was until recently called the FAANG. An oligarchy. Then why do we need regulation? The really big players are not bothered by regulations. Afaik Mastercard was never punished for distributing their customer records (including mine) on the darknet (search 'priceless specials' for details). Too-big-to-fail can basically do what they want, privacy laws or not. But there are actors in between. Corps or NGOs or whatever entities who are not as big to influence the game, but big enough to go their own way. Big enough to do some investment and make things possible which might not be in line with the road map. And that is where the regulations come in - to keep these entities in the reins. Because, for ordinary people, regulations are not necessary. Already now, if you want to get affordable prices at the supermarket, you have to buy a smartphone from one of only two software providers - and none of them gives you root access. (Or more cleariy, if someone doesn't get it yet: you DON'T OWN the thing, you merely pay for it). So, at some point not so far in the future, I imagine, running your own computer will simply become prohibited. Just like, you can be perfectly able to build a helicopter, but you will not be allowed to fly it. So why should one be allowed to run their own computer on the internet, and potentially pose a risk to the other users? ! If a government wants to impose rules for special/critical software that cost ! time or money for these open source projects, then the government must be as ! restrictive as possible with regulation, must pay for all costs to comply to ! these rules to the open source projects, and must have patience for ! implementation of compliance. Note that the government does not have to Hey! What money is it that governments are so willing to spend? Right, it's taxpayer money. It's YOUR money. Catch-22. cheerio, have fun PMc -- 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: error - exiting (due to assertion failure)
Hi, first of all, you are running outdated version of BIND 9. You can either ask Ubuntu to update to the latest 9.18.33 version or use ISC official packages Secondly, it’s very hard to debug anything without debug symbols. You need to have a backtrace (and ideally a coredump) with debug packages installed, see here: https://documentation.ubuntu.com/server/reference/debugging/debug-symbol-packages/ 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 1. 2. 2025, at 12:22, Paul Ssekamatte via bind-users > wrote: > > Hi, > I’m running BIND 9.18.30-0ubuntu0.22.04.2-Ubuntu in production on a > university network. > Recently, we have been experiencing the error shown below: > > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_assertion_failed+0x10) > [0x7fe1b4e1d7c0] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_assertion_failed+0x10) > [0x7fe1b4e1d7c0] > named[4787]: > /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x3a2f5) > [0x7fe1b4c0c2f5] > named[4787]: > /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x3a2f5) > [0x7fe1b4c0c2f5] > named[4787]: > /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(dns_cache_create+0x1e4) > [0x7fe1b4c0cdc4] > named[4787]: > /lib/x86_64-linux-gnu/libdns-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(dns_cache_create+0x1e4) > [0x7fe1b4c0cdc4] > named[4787]: /usr/sbin/named(+0x33524) [0x562bd4cd3524] > named[4787]: /usr/sbin/named(+0x33524) [0x562bd4cd3524] > named[4787]: /usr/sbin/named(+0x41e6f) [0x562bd4ce1e6f] > named[4787]: /usr/sbin/named(+0x41e6f) [0x562bd4ce1e6f] > named[4787]: /usr/sbin/named(+0x43771) [0x562bd4ce3771] > named[4787]: /usr/sbin/named(+0x43771) [0x562bd4ce3771] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_task_run+0x2bf) > [0x7fe1b4e4553f] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc_task_run+0x2bf) > [0x7fe1b4e4553f] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x1e993) > [0x7fe1b4e09993] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x1e993) > [0x7fe1b4e09993] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26368) > [0x7fe1b4e11368] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26368) > [0x7fe1b4e11368] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26b77) > [0x7fe1b4e11b77] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26b77) > [0x7fe1b4e11b77] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26d96) > [0x7fe1b4e11d96] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x26d96) > [0x7fe1b4e11d96] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x91ad) [0x7fe1b468e1ad] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x91ad) [0x7fe1b468e1ad] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x250fe) [0x7fe1b46aa0fe] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(+0x250fe) [0x7fe1b46aa0fe] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x678) [0x7fe1b4693c48] > named[4787]: /lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x678) [0x7fe1b4693c48] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x2720a) > [0x7fe1b4e1220a] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(+0x2720a) > [0x7fe1b4e1220a] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc__trampoline_run+0x1a) > [0x7fe1b4e4d50a] > named[4787]: > /lib/x86_64-linux-gnu/libisc-9.18.30-0ubuntu0.22.04.2-Ubuntu.so(isc__trampoline_run+0x1a) > [0x7fe1b4e4d50a] > named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3] > named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7fe1b42b3ac3] > named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850] > named[4787]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850) [0x7fe1b4345850] > named[4787]: exiting (due to assertion failure) > named[4787]: exiting (due to assertion failure) > > Please advise, I have checked online with no luck. > Thanks > > with kind regards, > > Paul Ssekamatte > Directorate for ICT Services (DICTS) > Makerere University > Mob: 0782-094368 > > -- > 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 fr
Re: Survey on the impact of software regulation on DNS systems
On Saturday, February 1, 2025 3:33:35 PM CET Peter 'PMc' Much wrote: > I tried to, but got the impression that the target audience is > rather commercial providers of infrastructure services, like > domain registrars and dns service providers. Not somebody like > me who just runs a cloud infrastructure for their own purposes. In all fairness, that is more or less how I currently run the software too. The end goal is commercial, sure, but it's still a few years off to get the legal kinks sorted out. Until then, this is a small individual operation just like yours. > Exactly, that is the idea! And I love it - it allows me to NOT > depend on service providers, to run my infrastructure in the way > I like it, and to be in control. I don't like it when people want > to tell me what is best for me to eat, or what is best for me to > buy, or what is best for me to run my computers. I don't like it > when people think they know better than me what is good for me. > And anyway, what qualification do these people have? > > But this is exactly what will disappear, and the road map is clear. That is a sentiment that I share, strongly so. We should be able to use our computers however we want. And if we can perform the protocols involved, we should be able to go on the internet ourselves to perform them. Gate-keeping that should never be the norm. I'll return to this later. > Because, for ordinary people, regulations are not necessary. Already > now, if you want to get affordable prices at the supermarket, you > have to buy a smartphone from one of only two software providers - > and none of them gives you root access. (Or more cleariy, if someone > doesn't get it yet: you DON'T OWN the thing, you merely pay for it). This is something that I think deserves a bit more nuance. What you're referring to (rooting) is something I do think is by and large missing in the mobile market. Whether that is for security reasons or otherwise is a debate in its own right. Personally I share the sentiment of LineageOS on this matter. Keep root access available over ADB, but do not support root access managers like Magisk. It's just too easy for people to ruin their systems with those, because they don't necessarily see or even understand the commands being executed. It's hard to argue against that being risky, but that doesn't mean that it should be excluded entirely. Another point worthy of nuance is that even if you do have root access to the device, you still don't necessarily control it. The argument I'm going to make here is the Tivo case. It's the "look but don't touch" argument. Even if you have root access, that doesn't necessarily mean that the system is open source. So you're still looking at unmodifiable binary blobs. Or even if you have the source code, it may not be able to build.. looking at you Mediatek, for what little source code of theirs is public to begin with. Or even if it is open source and it builds, you may not be able to flash it. That would be the case with Tivo, Samsung, and AVM to name a few. With Samsung, there's hardware in place now (so-called e-fuses) that trip when the bootloader is unlocked. That, in turn, voids your warranty.. even for hardware failures that the software had nothing to do with. Even Google pulled that stunt before with their Nexus 6P fiasco. Lawsuit forced Google to issue refunds, but only to Americans with a receipt, and on devices that could prove the fault on official firmware. You had to disable half the CPU cores in a modified recovery to boot at all, so that was a catch-22. And it was vile. Those phones were a disaster. With AVM meanwhile, I have one of their Fritz!Box 7490 routers. The firmware for that is based on Linux, and source code is available. Some people have even hacked on that firmware to create Freetz, a modified version of AVM's original firmware. But the forums are dead, were all in German, and the version of Ubuntu that was used to build the firmware is well out of date. So I couldn't build that firmware, much less flash it. And it's not like I can replace that router, because it's one of the few devices that Belgacom (the 50%+1 share government-owned company that owns the phone lines) has whitelisted. Needless to say, that is next to their own devices which are even more locked in. So yeah... Even if you have the source code, there are many compounding factors that still make it a case of "good luck using it". Look but don't touch. > So, at some point not so far in the future, I imagine, running your > own computer will simply become prohibited. > Just like, you can be perfectly able to build a helicopter, but you > will not be allowed to fly it. So why should one be allowed to run > their own computer on the internet, and potentially pose a risk > to the other users? Now, to be fair, when actual safety is involved, that's perhaps a case where regulation is justified. It's more or less like that with the radi
Primary/Secondary (Was: Master/Slave)
Hey, since you've asked about ISC recommendations and good practice, we prefer to use the current DNS terminology as defined in RFC 8499[1] that says: > Although early DNS RFCs such as [RFC1996] referred to this as a "master", > the current common usage has shifted to "primary". and > Although early DNS RFCs such as [RFC1996] referred to this as a "slave", > the current common usage has shifted to calling it a "secondary". The configuration and documentation in BIND 9 has also shifted to use the up-to-date terminology, so speaking of the best practice, I would recommend using the current naming of the server roles and current naming of the configuration options. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org 1. https://datatracker.ietf.org/doc/html/rfc8499 My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 31. 1. 2025, at 22:03, Karol Nowicki via bind-users > wrote: > > Hi Everyone > > With design where one ISC Bind DNS server is a master for domain example1.com > while in same time acts like as Slave for another one lets say example2.com > do we breaks any ISC recomendations or good practice ? > > > Wysłane z Yahoo Mail do iPhone > -- > 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
