Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting tito via Dng (dng@lists.dyne.org): > > Forgive me, but it's rather late at night in my time zone, and I am > > not at peak alertness, _but_ my guess is that Unbound got set up > > somehow configured to forward outbound recursive queries to those > > entities, leaving me perplexed about why anyone would do that. > > Just by following one of the many tutorials out there. > Initially I was just interested in using dns to filter out adservers > and the like. OK, sure. When I first encountered Unbound, I noticed that (like pdns-recursor) it functioned extremely well without any modification at all, by default, as a high-performance, high-security standalone recursive server, and it just hadn't occurred to me to go out of one's way to turn it into a forwarder. (I mean, if all you want is a forwarder, you can just use dproxy, pdnsd, or Dnsmasq, which are simpler and don't have recursive code.) On the other hand, if you want a fully autonomous recursive nameserver, then _don't_ configure it to forward all queries to some outsourced recursive nameserver elsewhere, but rather let it do its job, as implementing the RD (recursion desired) bit makes handling of queries faster and smarter. In case the reasons why aren't obvious, I tried to cover this humourously in my piece "The Village of Lan: A Networking Fairy Tale": http://linuxmafia.com/~rick/lan.html -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > Au contraire, I’m running unbound right now on my laptop. There are > some situations though where it’s not feasible to run one's own > recursive DNS resolver, such as a home router for non-technical people > that doesn’t support ddwrt/openwrt. On the basis of decades of experience, I deny the premise. > Unfortunately the current version of unbound packaged in Debian/Devuan > has an annoying bug when running under non-systemd+apparmor. > https://bugs.debian.org/947771 I'm minutely familiar with this fact. Fortunately for Devuan admins, they can either hotfix Unbound or use any of several other commodity recursive-only DNS nameservers, all of which I catalogue at http://linuxmafia.com/faq/Network_Other/dns-servers.html . Nota bene: I accept zero responsibility for ensuring that any or all of those recursive-only nameservers is binary-packaged for the current, past, or future releases of Devuan. I note in passing the fact that, if necessary, "./configure; make; make install" is not broken. > I attempted to install knot-resolver as an alternative but it appears > that the upstream packages have gained a hard dependency on systemd. Case in point. > MaraDNS/Deadwood packages in Debian are still using a release from > 2015 _Second_ case in point. > ...so I guess I’ll be trying powerdns-recursor next as that package > appears to be reasonably up to date. Whatever works for you. But local packages/compiles are also a thing. As the guy who wasted a metric lot of time futilely hating me on the Internet, Prof. Daniel J. Bernstein, memorably observed: "This is Unix. Stop acting so helpless." ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Tue, 2021-03-09 at 22:07 -0800, Rick Moen wrote: > Quoting Dimitris via Dng (dng@lists.dyne.org): > > > so, i would be interested to know, if there's a privacy issue with > > opennnic? > > I have no problem with people who decide to adopt alternate roots. > > What I was talking about upthread was outsourcing one's recursive > nameservice to OpenNIC's public recursive nameserver IPs, or any > other > stranger's. Because, well, why? Recursive service is dead-easy to > do > with one's local computing resources, protecting one's autonomy, > security, performance, and privacy just that tiny bit more. I agree actually. I run my own recursive nameserver (bind9) that points to opennic's root servers. I don't share it with opennic yet because I have yet to get doh and or dot setup yet. I got started on it but it had to take a back seat for a while. I've also been keeping logs for my own purposes and want to not keep logs when I advertise it on openvpn. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Στις 10/3/21 4:30 μ.μ., ο/η Dimitris via Dng έγραψε: but performance-wise is terrible if you're in some low latency connection correction: "high latency". OpenPGP_signature Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Στις 10/3/21 8:07 π.μ., ο/η Rick Moen έγραψε: What I was talking about upthread was outsourcing one's recursive nameservice to OpenNIC's public recursive nameserver IPs, or any other stranger's. Because, well, why? Recursive service is dead-easy to do with one's local computing resources, protecting one's autonomy, security, performance, and privacy just that tiny bit more. i'm all in for diy, but my house dsl connection isn't helping. i agree, dns is very easy to setup, but performance-wise is terrible if you're in some low latency connection...it's slow and so are all queries... tried that in the past, it's not worth the "torture" of waiting seconds for a single query.. caching helps, but up to a point. that's why i'm forwarding to "trusted" no-log policy servers, with some sort of query encryption (dnscrypt,DoT,torDNS). 2c, d. OpenPGP_signature Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Tue, 9 Mar 2021 22:07:07 -0800 Rick Moen wrote: > What I was talking about upthread was outsourcing one's recursive > nameservice to OpenNIC's public recursive nameserver IPs, or any other > stranger's. Because, well, why? Recursive service is dead-easy to do > with one's local computing resources, protecting one's autonomy, > security, performance, and privacy just that tiny bit more. Thanks a lot, Sir! Sometimes it's fully sufficient to get pointed to the (at closer inspection rather obvious) possibility of holding the spoon the other way around -_- In return, please accept one of my very favorite GIFs: https://i.postimg.cc/Vvb9rpVp/1st-level-support.gif libre Grüße, Florian -- "A map of the world that does not include Utopia is not even worth glancing at." Oscar Wilde ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Tue, 9 Mar 2021 23:02:31 -0800 Rick Moen wrote: > Quoting tito via Dng (dng@lists.dyne.org): > > > Hi, > > just for fast information, is it enough for unbound to remove: > > > > forward-zone: > > #forward-first: yes > > name: "." > > forward-tls-upstream: yes > > forward-addr: 1.1.1.1@853#cloudflare-dns.com > > forward-addr: 1.0.0.1@853#cloudflare-dns.com > > forward-addr: 8.8.4.4@853#dns.google > > forward-addr: 8.8.8.8@853#dns.google > > forward-addr: 9.9.9.9@853#dns.quad9.net > > forward-addr: 185.222.222.222@853#dns.sb > > forward-addr: 185.184.222.222@853#dns.sb > > Answer below. > > > Makes it sense to keep: > > > > server: > > tls-upstream: yes > > tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt > > On that: yes. > > On the former question, er, I'm actually a bit non-plussed about why > those forwarder lines are in your configuration file in the first > place. > > Forgive me, but it's rather late at night in my time zone, and I am > not at peak alertness, _but_ my guess is that Unbound got set up > somehow configured to forward outbound recursive queries to those > entities, leaving me perplexed about why anyone would do that. Just by following one of the many tutorials out there. Initially I was just interested in using dns to filter out adservers and the like. > That having been said, I personally would definitely _not_ want to > have that configuration detail in my recursive nameserver state, > without an extremely compelling reason, because doing that appears to > largely defeat the entire purpose of running one's own recursive > nameserver. Analogously, it would be like setting up a fully capable > SMTP smarthost on a stable public IP address with free routing to > 25/tcp anywhere in the world, but then configuring it to forward all > outbound SMTP traffic to an untrustworthy ISP external mail host. > Which would lead one to wonder, why? > > I hope that helps. I have no idea what else you might have in your > configuration that ought not to be there, obviously. > > > > I ask because after reading the thread I've tried on one > > of my home's net dns servers and it worked (I could browse the web) > > but browsing speed was noticeably slower, does it improve > > in the long run or do we have to choose between > > privacy and speed? > > I'm seriously not sure why operating a local recursive nameserver > would be expected to reduce speed. Obviously, at initial startup of > that process, it has nothing yet in cache and needs to do some > queries of often-used FQDNS, but I would expect that it would very > quickly improve DNS performance over _any_ nameserver on the far side > of your uplink, because obviously your speed of local DNS resolution > is really fast relative to your uplink, right? > I will try and report about this in a few days. Thanks, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
> On 10 Mar 2021, at 17:11, Rick Moen wrote: > Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > >> What’s the consensus on Quad9? Are they any better from a privacy >> standpoint? > > To say again, why outsource recursive nameservice to _anyone_? > > You seem like a large number of people who are weirdly resistant to > the notion of basic control of one's own fundamental network > infrastructure and looking for some stranger to outsource the task to, > and I keep wondering why the obvious alternative of running a recursive > DNS nameserver instance locally isn't even considered, let alone the > obvious default choice. > > But hey, whatever works for you. Au contraire, I’m running unbound right now on my laptop. There are some situations though where it’s not feasible to run one's own recursive DNS resolver, such as a home router for non-technical people that doesn’t support ddwrt/openwrt. Unfortunately the current version of unbound packaged in Debian/Devuan has an annoying bug when running under non-systemd+apparmor. https://bugs.debian.org/947771 I attempted to install knot-resolver as an alternative but it appears that the upstream packages have gained a hard dependency on systemd. MaraDNS/Deadwood packages in Debian are still using a release from 2015, so I guess I’ll be trying powerdns-recursor next as that package appears to be reasonably up to date.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting tito via Dng (dng@lists.dyne.org): > Hi, > just for fast information, is it enough for unbound to remove: > > forward-zone: > #forward-first: yes > name: "." > forward-tls-upstream: yes > forward-addr: 1.1.1.1@853#cloudflare-dns.com > forward-addr: 1.0.0.1@853#cloudflare-dns.com > forward-addr: 8.8.4.4@853#dns.google > forward-addr: 8.8.8.8@853#dns.google > forward-addr: 9.9.9.9@853#dns.quad9.net > forward-addr: 185.222.222.222@853#dns.sb > forward-addr: 185.184.222.222@853#dns.sb Answer below. > Makes it sense to keep: > > server: > tls-upstream: yes > tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt On that: yes. On the former question, er, I'm actually a bit non-plussed about why those forwarder lines are in your configuration file in the first place. Forgive me, but it's rather late at night in my time zone, and I am not at peak alertness, _but_ my guess is that Unbound got set up somehow configured to forward outbound recursive queries to those entities, leaving me perplexed about why anyone would do that. That having been said, I personally would definitely _not_ want to have that configuration detail in my recursive nameserver state, without an extremely compelling reason, because doing that appears to largely defeat the entire purpose of running one's own recursive nameserver. Analogously, it would be like setting up a fully capable SMTP smarthost on a stable public IP address with free routing to 25/tcp anywhere in the world, but then configuring it to forward all outbound SMTP traffic to an untrustworthy ISP external mail host. Which would lead one to wonder, why? I hope that helps. I have no idea what else you might have in your configuration that ought not to be there, obviously. > I ask because after reading the thread I've tried on one > of my home's net dns servers and it worked (I could browse the web) > but browsing speed was noticeably slower, does it improve > in the long run or do we have to choose between > privacy and speed? I'm seriously not sure why operating a local recursive nameserver would be expected to reduce speed. Obviously, at initial startup of that process, it has nothing yet in cache and needs to do some queries of often-used FQDNS, but I would expect that it would very quickly improve DNS performance over _any_ nameserver on the far side of your uplink, because obviously your speed of local DNS resolution is really fast relative to your uplink, right? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Tue, 9 Mar 2021 22:26:29 -0800 Rick Moen wrote: > Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > > > In the absence of a "community of dns server operators and users", > > is the optimal option to have everyone run their own recursive > > server? But then the upstream servers still get the birds-eye view > > and will very likely abuse that information like the big companies > > do now. > > Please pardon my being blunt, but I don't think you have a realistic > understanding of how typical patterns of authoritative nameservice > data and caching work. I rather suspect you haven't stopped to think > about that. > > Let's say I run a local recursive DNS nameserver on my local LAN for > use by my and all other local hosts. For the sake of discussion, let > us assume that it has what is misleadingly called an 'ICANN' root > hints file. > > At service startup time, the instance starts getting and caching TLD, > SLD, etc. authoritative data and caching it for the duration of > TTLs. Right, now, kindly tell me where on the planet is the network > node that provides a "birds-eye view" of query traffic processed by > my recursive server? The root nameservers? Nope, not hardly. All > they have is the hits where my nameserver followed the RD-bit-marked > queries to find various TLD nameservers. TLD zones' nameservers? > Nope, not hardly. They have only analogous logfile data when my > nameserver first located and then cached information about SLD > nameservers. > > In fact, the very fact that I am operating a recursive nameserver > means that I have greatly impoverished every possible spying vantage > point. The best of the bad choices in places to spy on my network's > port-53 activity is thus right on the far side of my network uplink, > at my local bandwidth provider. And, even there, because of > pervasive caching, even my uplink has extremely poor data about what > the machines on my local LAN are looking up. > > Ideally, one has a contractual relationship with a reputable good > provider who looks after customer interests in accordance to local > business practices and law, such as (to cite the USA local legal > concept) the implied covenant of good faith and fair dealing. > However, that contract concept is (naturally) not a shield for > privacy but rather a cudgel to wield in civil litigation, so the best > thing to do is to limit what your immediate uplink can learn about > your network traffic. Various crypto schemes help limit that data, > but -- my point -- so does operating a local recursive nameserver, > rather than outsourcing to -anyone- on the other side of the uplink. Hi, just for fast information, is it enough for unbound to remove: forward-zone: #forward-first: yes name: "." forward-tls-upstream: yes forward-addr: 1.1.1.1@853#cloudflare-dns.com forward-addr: 1.0.0.1@853#cloudflare-dns.com forward-addr: 8.8.4.4@853#dns.google forward-addr: 8.8.8.8@853#dns.google forward-addr: 9.9.9.9@853#dns.quad9.net forward-addr: 185.222.222.222@853#dns.sb forward-addr: 185.184.222.222@853#dns.sb Makes it sense to keep: server: tls-upstream: yes tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt I ask because after reading the thread I've tried on one of my home's net dns servers and it worked (I could browse the web) but browsing speed was noticeably slower, does it improve in the long run or do we have to choose between privacy and speed? Thanks in advance. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Gabe Stanton via Dng (dng@lists.dyne.org): > In the absence of a "community of dns server operators and users", is > the optimal option to have everyone run their own recursive server? But > then the upstream servers still get the birds-eye view and will very > likely abuse that information like the big companies do now. Please pardon my being blunt, but I don't think you have a realistic understanding of how typical patterns of authoritative nameservice data and caching work. I rather suspect you haven't stopped to think about that. Let's say I run a local recursive DNS nameserver on my local LAN for use by my and all other local hosts. For the sake of discussion, let us assume that it has what is misleadingly called an 'ICANN' root hints file. At service startup time, the instance starts getting and caching TLD, SLD, etc. authoritative data and caching it for the duration of TTLs. Right, now, kindly tell me where on the planet is the network node that provides a "birds-eye view" of query traffic processed by my recursive server? The root nameservers? Nope, not hardly. All they have is the hits where my nameserver followed the RD-bit-marked queries to find various TLD nameservers. TLD zones' nameservers? Nope, not hardly. They have only analogous logfile data when my nameserver first located and then cached information about SLD nameservers. In fact, the very fact that I am operating a recursive nameserver means that I have greatly impoverished every possible spying vantage point. The best of the bad choices in places to spy on my network's port-53 activity is thus right on the far side of my network uplink, at my local bandwidth provider. And, even there, because of pervasive caching, even my uplink has extremely poor data about what the machines on my local LAN are looking up. Ideally, one has a contractual relationship with a reputable good provider who looks after customer interests in accordance to local business practices and law, such as (to cite the USA local legal concept) the implied covenant of good faith and fair dealing. However, that contract concept is (naturally) not a shield for privacy but rather a cudgel to wield in civil litigation, so the best thing to do is to limit what your immediate uplink can learn about your network traffic. Various crypto schemes help limit that data, but -- my point -- so does operating a local recursive nameserver, rather than outsourcing to -anyone- on the other side of the uplink. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Wirelessduck wrote: >What’s the consensus on Quad9? Didn't The Temptations do that in 1969? SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting wirelessduck--- via Dng (dng@lists.dyne.org): > What’s the consensus on Quad9? Are they any better from a privacy > standpoint? To say again, why outsource recursive nameservice to _anyone_? You seem like a large number of people who are weirdly resistant to the notion of basic control of one's own fundamental network infrastructure and looking for some stranger to outsource the task to, and I keep wondering why the obvious alternative of running a recursive DNS nameserver instance locally isn't even considered, let alone the obvious default choice. But hey, whatever works for you. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Dimitris via Dng (dng@lists.dyne.org): > so, i would be interested to know, if there's a privacy issue with > opennnic? I have no problem with people who decide to adopt alternate roots. What I was talking about upthread was outsourcing one's recursive nameservice to OpenNIC's public recursive nameserver IPs, or any other stranger's. Because, well, why? Recursive service is dead-easy to do with one's local computing resources, protecting one's autonomy, security, performance, and privacy just that tiny bit more. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Sun, 7 Mar 2021 09:50:53 -0500 Steve Litt wrote among other things: |Likewise, when I used Ubuntu, I wanted to get rid of Plymouth, which |in my opinion is eye-candy for Windows Weenies. I tried and failed |with package-manager-fu. I tried and failed with several other |approaches. Finally I just renamed the Plymouth executable, and |BANG, things worked like I wanted them to. I can't believe that someone who knows what they're doing did this too. In my case it was Sparky JWM (Debian Testing NOT Ubuntu based), a fine, but systemd, distro BTW: I just couldn't fix the errors I kept getting on apt-get dist-upgrade, until I killed Plymouth. -- "While some hold that perfection is the enemy of the good, I've found that it is only in its pursuit that one avoids the mediocre." Larry De Coste Pawtucket RI EE.UU. Cell/Signal/Txt: +1(401) 275-3712 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>On Mon, 2021-03-08 at 06:40 -0700, Gabe Stanton via Dng wrote: >Oh, and one more thing since you mentioned icann, one thing to note is >that opennic also has their own tld system, independent of icann. As a >community of operators, they can do that. Of course no one can access >their tld's without pointing to an opennic server. Their main one is >.glue but they continue to add them. Anyway, having their own tld's is >another thing they're doing right in my opinion. If they don't end up >being the best solution to the problem, I feel like they're leading the >way. Wait a minute. This could be cool. Do iopennic TLDs conflict with icann's, or are they different? If they are different, couldn't I just add some of opennic's root servers to my Unbound root server file, so I can get the TLDs from either? How cool would that be? SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Mon, 2021-03-08 at 06:40 -0700, Gabe Stanton via Dng wrote: > On Mon, 2021-03-08 at 10:08 +0200, Dimitris via Dng wrote: > > Στις 8/3/21 12:29 π.μ., ο/η Rick Moen έγραψε: > > > Leaving aside my being disappointed about people willingly > > > outsourcing > > > their recursive DNS to the second-nosiest company on the > > > planet[1] > > > > +1.1.1.1 ... don't forget cloudflare bullies.. > > > > > > but i do forward local queries to opennic (w/ dnscrypt) and a > > couple > > more trusted sources.. eg. libreops.cc offer a public resolver and > > another DoT/DoH & i do also forward to tor-resolve occasionally... > > > > so, i would be interested to know, if there's a privacy issue with > > opennnic? > > leaving the overlord (=icann) aside, seems like a good idea to me.. > > I wonder the same thing. I guess what appeals to me about opennic is > that they address some of the problems with the way dns is handled > elsewhere. Of course running your own dns server is optimal. But it > doesn't do a better job to address privacy, and it doesn't make dns > into a community issue like opennic is trying to do. > As a dns server operator, with opennic you also get the opportunity > to > invite other anonymous (to you) people to share your dns server, thus > pooling your dns queries, which can be good for privacy. > > If you're not running your own dns server when using opennic, you're > relying on the truthfulness of the dns server operator when they > checked or didn't check the flags indicating if they keep logs. > That's > obviously not a very trustworthy indication, but it's nice that > they're > addressing privacy right up front. > > I don't know of anyone trying to do what opennic is trying to do. Are > there competing ideas in the realm of dns communities? > > In the absence of a "community of dns server operators and users", is > the optimal option to have everyone run their own recursive server? > But > then the upstream servers still get the birds-eye view and will very > likely abuse that information like the big companies do now. > > I don't mean just to defend opennic, if there are competing or better > ideas out there, that would be good to know. I'm just throwing out my > 2 > cents on the matter. Oh, and one more thing since you mentioned icann, one thing to note is that opennic also has their own tld system, independent of icann. As a community of operators, they can do that. Of course no one can access their tld's without pointing to an opennic server. Their main one is .glue but they continue to add them. Anyway, having their own tld's is another thing they're doing right in my opinion. If they don't end up being the best solution to the problem, I feel like they're leading the way. Of course the independent tld system is potentially problematic, but centralized icann is also a problem, so we should be looking for solutions and innovative ideas. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Mon, 2021-03-08 at 10:08 +0200, Dimitris via Dng wrote: > Στις 8/3/21 12:29 π.μ., ο/η Rick Moen έγραψε: > > Leaving aside my being disappointed about people willingly > > outsourcing > > their recursive DNS to the second-nosiest company on the planet[1] > > +1.1.1.1 ... don't forget cloudflare bullies.. > > > but i do forward local queries to opennic (w/ dnscrypt) and a couple > more trusted sources.. eg. libreops.cc offer a public resolver and > another DoT/DoH & i do also forward to tor-resolve occasionally... > > so, i would be interested to know, if there's a privacy issue with > opennnic? > leaving the overlord (=icann) aside, seems like a good idea to me.. I wonder the same thing. I guess what appeals to me about opennic is that they address some of the problems with the way dns is handled elsewhere. Of course running your own dns server is optimal. But it doesn't do a better job to address privacy, and it doesn't make dns into a community issue like opennic is trying to do. As a dns server operator, with opennic you also get the opportunity to invite other anonymous (to you) people to share your dns server, thus pooling your dns queries, which can be good for privacy. If you're not running your own dns server when using opennic, you're relying on the truthfulness of the dns server operator when they checked or didn't check the flags indicating if they keep logs. That's obviously not a very trustworthy indication, but it's nice that they're addressing privacy right up front. I don't know of anyone trying to do what opennic is trying to do. Are there competing ideas in the realm of dns communities? In the absence of a "community of dns server operators and users", is the optimal option to have everyone run their own recursive server? But then the upstream servers still get the birds-eye view and will very likely abuse that information like the big companies do now. I don't mean just to defend opennic, if there are competing or better ideas out there, that would be good to know. I'm just throwing out my 2 cents on the matter. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
> On 8 Mar 2021, at 19:08, Dimitris via Dng wrote: > > Στις 8/3/21 12:29 π.μ., ο/η Rick Moen έγραψε: >> Leaving aside my being disappointed about people willingly outsourcing >> their recursive DNS to the second-nosiest company on the planet[1] > > +1.1.1.1 ... don't forget cloudflare bullies.. > > > but i do forward local queries to opennic (w/ dnscrypt) and a couple more > trusted sources.. eg. libreops.cc offer a public resolver and another DoT/DoH > & i do also forward to tor-resolve occasionally... > > so, i would be interested to know, if there's a privacy issue with opennnic? > leaving the overlord (=icann) aside, seems like a good idea to me.. What’s the consensus on Quad9? Are they any better from a privacy standpoint? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Στις 8/3/21 12:29 π.μ., ο/η Rick Moen έγραψε: Leaving aside my being disappointed about people willingly outsourcing their recursive DNS to the second-nosiest company on the planet[1] +1.1.1.1 ... don't forget cloudflare bullies.. but i do forward local queries to opennic (w/ dnscrypt) and a couple more trusted sources.. eg. libreops.cc offer a public resolver and another DoT/DoH & i do also forward to tor-resolve occasionally... so, i would be interested to know, if there's a privacy issue with opennnic? leaving the overlord (=icann) aside, seems like a good idea to me.. d. OpenPGP_signature Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > If I had demanded of myself to change the root cause instead of > coathangering the symptom, I'd have needed to go to the Void Linux > developers and ask them to find a way to accommodate DNS, in a > travelling situation, without changing /etc/resolv.conf. [acknowledging your point, posted separately, that Void Linux devs could doubtless cite some way to do so, if you asked them.] > What I was trying to say was that if I wanted to change the *design* of > the system, I'd have to petition the Void Linux packagers and the (urk) > Freedesktop.org "upstream". [...] > I violently disagree with the design decision of having the likes of > wicd or NetworkManager modify my /etc/resolv.conf, at least on a > non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8 > and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's > suggested DNS servers. (I'll get to the 'no need' statement further down.) I doubt you _truly_ aimed at a system redesign to the effect that "Nothing shall be allowed to touch /etc/resolv.conf except me doing 'chattr -i /etc/resolv.conf; vi /etc/resolv.conf; chattr +i /etc/resolv.conf'." Because there are legitimate reasons to do otherwise. TCP/IP-networked systems fall into two broad classes, those that are DHCP clients and those statically IPed. Statically IPed systems are the easy case, I cannot presently think of any system software sysadmins are tempted to run that would want to alter /etc/resolv.conf . That leaves DHCP clients. There are three DHCP client implementations I'm aware of for Linux. My Resolvconf page (link posted earlier) explains how to control what each does to the nameserver line(s) in /etc/resolv.conf . So, I've documented how to override and control (if desired) those system utilities' mucking about. Likewise, My page details how to do likewise with either of the two competing Resolvconf implementations (which is why the page has that name). That leaves 'network managers' like GNOME NetworkManager, wicd, and all that lot. wicd appears to invoke Resolvconf to manage /etc/resolv.conf, so see above. GNOME NetworkManager keeps its grubby paws off /etc/resolv.conf if that file's a symlink (including but not limited to use of Resolvconf, which like wicd, GNOME NetworkManager relies on). So, do that. _Or_, create /etc/NetworkManager/conf.d/90-dns-none.conf containing [main] dns=none ...and restarted the damned GNOME NetworkManager thing. Theoretically, I could research and document how to do likewise for every goshdarned ill-advised tool that occasionally mucks with the nameserver line in /etc/resolv.conf -- systemd-resolvd, netctl, an endless variety of crummy little utilities. I won't, because (1) there's no end to that, but -- more to the point -- (2) people who run crummy little utilities like that need to understand the basics of how they work. Or, here's an idea: Don't have them. I have a standard joke about the "Facebook remedy". People ask me how I solve Facebook problems, and my cheery answer is "Simple! No Facebook; no Facebook problems!" I've not needed those crummy little network-administrative utilities. If I adopted one, I'd take the trouble to research its basics, including how to _properly_ instruct it to keep its grubby little paws off the nameserver line in /etc/resolv.conf . And, by the way, sadly, no you are incorrect that "you can DNS from 8.8.8.8 and 8.8.4.4 anywhere you go": Leaving aside my being disappointed about people willingly outsourcing their recursive DNS to the second-nosiest company on the planet[1] instead of just running a local recursive nameserver, sorry, you'll find that such a setup breaks when negotiating a "captive portal" on, e.g., most hotel and motel WiFi, where crummy artificial DNS on the WAP redirects any initial HTTP query to the portal Web site, where you prove that you're an authorised user before they give your client routing to outside the service network. Overriding that nameserver instruction means you won't see the login Web page, so you won't be able to prove you're a customer, so you won't get a usable connection. The above is a vexing problem for travelers w/laptops who prefer to specify their own choice of nameserver and still use hotel/motel WiFi (and wired ethernet, actually). Best case, you have to disable your nameserver IP override long enough to navigate the captive portal, and then can put the override back. But, no, you cannot just leave your choice of nameserver IPs in place (without disappointment). [1] Nor is it any better to outsource to OpenNIC, Cisco Umbrella, Comodo, Yandex, UncensoredDNS, etc. Here's an idea: How about not outsourcing recursive DNS to anyone? It's not like it's even difficult. We've had this conversation before. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>>Quoting Steve Litt (sl...@troubleshooters.com): >If I had demanded of myself to change the root cause instead of >coathangering the symptom, I'd have needed to go to the Void Linux >developers and ask them to find a way to accommodate DNS, in a >travelling situation, without changing /etc/resolv.conf. Before Rick says it, the preceding paragraph was slightly miswritten. I'm sure on Void Linux there's some package-manager-fu or some other raindance to get /etc/resolv.conf to do what you want it to, without making it immutable. What I was trying to say was that if I wanted to change the *design* of the system, I'd have to petition the Void Linux packagers and the (urk) Freedesktop.org "upstream". SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>Quoting Steve Litt (sl...@troubleshooters.com): > >> My philosophy: One big hammer prevents a 100 step packaging system >> raindance. > >The Big Hammer always seems a great idea for a temporary solution. >And I assume you know what the catch is with those. > >Every single time I've nailed down a sysadmin annoyance using the Big >Hammer, it's come back to haunt me later -- and, moreover, it turned >out that a further ten minutes of digging would have found a better >solution that didn't cripple the system's administrative framework but >would, instead, have worked with the framework. > >Setting /etc/resolv.conf immutable, the classic case that was the first >I saw you fall in love with, is a case in point. There are multiple >ways to ensure that a DHCP client respects and enforces your preference >of recursive nameserver, averting the need for breaking system >administration tools using the immutable bit. Did everyone read what Rick said? He restated, for a specific situation, the carved in granite troubleshooting rule that you never coathanger the symptom, but instead fix the cause. I teach this in every Troubleshooting course I teach. It's the stone truth. Rick speaks of the immutability of /etc/resolv.conf breaking admin tools. This is a specific instance of the more general principle that when you coathanger a symptom instead of eliminating the root cause, you create side-effects which are typically harmful. I've known audio techs who *solved* the problem of intermittent blown fuses by wrapping aluminum foil around the blown fuse and re-installing it. And of course, the next time the customer's speaker wires shorted at high volume, instead of blowing the fuse, all the output transistors and drivers would short, possibly along with the transformer and bridge rectifier (this was in the early 80's, remember), with the very real possibility of your beloved amplifier bursting into flames (I've seen this happen on another audio technician's service benche). So why do I violate the principle of eliminating the root cause instead of coathangering the symptom, in this particular case, when I tell my students never to coathanger the symptom? Troubleshooting, as defined on Troubleshooters.Com and my books and courses, is defined as "restoring the system to its as-designed behavior". When I chattr +i /etc/resolv.conf, I'm not troubleshooting, I'm redesigning. I violently disagree with the design decision of having the likes of wicd or NetworkManager modify my /etc/resolv.conf, at least on a non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8 and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's suggested DNS servers. If I had demanded of myself to change the root cause instead of coathangering the symptom, I'd have needed to go to the Void Linux developers and ask them to find a way to accommodate DNS, in a travelling situation, without changing /etc/resolv.conf. But of course the software wasn't written by Void, it was written by people who have drunk heavily of the FreeDesktop.org flavored drink. I'd have as much success there as I'd have demanding Redhat drop systemd. When I repaired consumer audio equipment for a living, we had Technical Service Bulletins. Occasionally a bulletin would ask me to coathanger a symptom, and I'd do so. Because the manufacturers and/or Pacific Stereo had studied the situation and determined that the coathanger has minimal side effects and that it's by far the cheapest solution. Likewise, when I used Ubuntu, I wanted to get rid of Plymouth, which in my opinion is eye-candy for Windows Weenies. I tried and failed with package-manager-fu. I tried and failed with several other approaches. Finally I just renamed the Plymouth executable, and BANG, things worked like I wanted them to. SteveT Steve Litt Spring 2021 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
I wrote: > Setting /etc/resolv.conf immutable, the classic case that was the first > I saw you fall in love with, is a case in point. There are multiple > ways to ensure that a DHCP client respects and enforces your preference > of recursive nameserver, averting the need for breaking system > administration tools using the immutable bit. Forgot to add: Have documented. http://linuxmafia.com/kb/Network_Other/resolvconf.html (scroll to '3. Tweaking Your DHCP Client's Operation without Resolvconf') ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > My philosophy: One big hammer prevents a 100 step packaging system > raindance. The Big Hammer always seems a great idea for a temporary solution. And I assume you know what the catch is with those. Every single time I've nailed down a sysadmin annoyance using the Big Hammer, it's come back to haunt me later -- and, moreover, it turned out that a further ten minutes of digging would have found a better solution that didn't cripple the system's administrative framework but would, instead, have worked with the framework. Setting /etc/resolv.conf immutable, the classic case that was the first I saw you fall in love with, is a case in point. There are multiple ways to ensure that a DHCP client respects and enforces your preference of recursive nameserver, averting the need for breaking system administration tools using the immutable bit. It has been ever thus. -- Cheers,HULK LIKE TO REMIND EVERYONE THAT "FEWER" MEAN YOU CAN COUNT IT, Rick Moen "LESS" MEAN MUST BE MEASURED. FEWER MISTAKES MEAN LESS SMASH! r...@linuxmafia.com -- @EditorHulk McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>Quoting Steve Litt (sl...@troubleshooters.com): >> >On Fri, 5 Mar 2021 22:01:33 +0100 (CET) k...@aspodata.se wrote: >> >> >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a >> >Odroid XU-4 with 2GB RAM. Tested with up to four participants and >> >running quite well. Downside: The reserved memory of the >> >videobridge is configured under /usr/share/ and thus is not >> >update-proof. >> >> chattr +i whatever_file > >Beware this seductive lure towards wielding the Big Hammer, O >Grasshopper. Dark is that path's attraction to any junior sysadmin, >for ultimately it leads to the Way of Hemsworth and to Cheesy Dialogue. My philosophy: One big hammer prevents a 100 step packaging system raindance. SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > >On Fri, 5 Mar 2021 22:01:33 +0100 (CET) k...@aspodata.se wrote: > > >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a > >Odroid XU-4 with 2GB RAM. Tested with up to four participants and > >running quite well. Downside: The reserved memory of the videobridge is > >configured under /usr/share/ and thus is not update-proof. > > chattr +i whatever_file Beware this seductive lure towards wielding the Big Hammer, O Grasshopper. Dark is that path's attraction to any junior sysadmin, for ultimately it leads to the Way of Hemsworth and to Cheesy Dialogue. -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Sat, 6 Mar 2021 12:45:41 +0100 Florian Zieboll via Dng wrote: > On Sat, 6 Mar 2021 04:27:21 -0500 > Steve Litt wrote: > > > >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a > > >Odroid XU-4 with 2GB RAM. Tested with up to four participants and > > >running quite well. Downside: The reserved memory of the > > >videobridge is configured under /usr/share/ and thus is not > > >update-proof. > > > > chattr +i whatever_file > > For me it seems to be more reasonable to 'apt-mark hold' the > videobridge and keep the manual change in mind - particularly as the > service just fails to start and its log points straight to this very > issue when the file gets reverted to its original state. > > BTW, I just tried it: When I 'chattr +i' a file to be updated, the > whole update (resp. reinstall in this test) fails and leaves /all/ > updated packages unconfigured. I just reinstalled jitsi-meet and found a more elegant solution resp. the original cause for the VIDEOBRIDGE_MAX_MEMORY issue: The sysv init script does 'include /etc/jitsi/videobridge/config' but then it doesn't export the variables defined there. Simply adding the line 'export VIDEOBRIDGE_MAX_MEMORY' at the beginning of the init script's 'start()' function solves the problem. Additional bonus: The init script can be 'chattr +i'ed without disturbing the update process. I ran into some another trouble with the videobridge, which may or may not have existed in my previous installation. Maybe I just didn't push hard enough for it to appear: When I dis- and re-connect several times in short intervals, the videobridge "goes down" for a while and needs some minutes to be available to jicofo again. If somebody has a quick hint on this, I'd be happy - otherwise I'll come back when I see more. Noteworthy is that both, videobridge and jicofo, run with 'MAX_MEMORY' of 512m. libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Sat, 6 Mar 2021 04:27:21 -0500 Steve Litt wrote: > >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a > >Odroid XU-4 with 2GB RAM. Tested with up to four participants and > >running quite well. Downside: The reserved memory of the videobridge > >is configured under /usr/share/ and thus is not update-proof. > > chattr +i whatever_file For me it seems to be more reasonable to 'apt-mark hold' the videobridge and keep the manual change in mind - particularly as the service just fails to start and its log points straight to this very issue when the file gets reverted to its original state. BTW, I just tried it: When I 'chattr +i' a file to be updated, the whole update (resp. reinstall in this test) fails and leaves /all/ updated packages unconfigured. libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>On Fri, 5 Mar 2021 22:01:33 +0100 (CET) >k...@aspodata.se wrote: > >> Anyone knows which one to choose for a smallish group (< 20 persons) >> ? > > >I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a >Odroid XU-4 with 2GB RAM. Tested with up to four participants and >running quite well. Downside: The reserved memory of the videobridge is >configured under /usr/share/ and thus is not update-proof. chattr +i whatever_file SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting k...@aspodata.se (k...@aspodata.se): > https://en.wikipedia.org/wiki/Comparison_of_web_conferencing_software > lists four open source systems: > > https://en.wikipedia.org/wiki/Jitsi > https://en.wikipedia.org/wiki/Jami_(software) > https://en.wikipedia.org/wiki/OpenMeetings > https://en.wikipedia.org/wiki/BigBlueButton Thank you, sir. > Anyone knows which one to choose for a smallish group (< 20 persons) ? Logically, the only people truly qualified to answer your question would be people who've setup/administered at least a large subset of the above four, or who are in close contact with someone who has. I'm not such a person; I've set up, administered, and used Jitsi Meet (only) -- and I've been a user of BigBlueButton instances used by Linux Users of Victoria (Aus.) and by Arizona Ubuntu LoCo. It would be wonderful if a qualified person is on this mailing list and can answer. Until then, I can only say that Jitsi Meet struck me as quite practical for a smallish group. The server software grabs gobs of RAM (judged by my old-school sysadmin standards), but that outcome is to be expected because it's Java. FWIW, I note that Jami does voice (SIP) and instant messaging, but not videoconferencing. The other three are generally similar WebRTC-based systems. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
On Fri, 5 Mar 2021 22:01:33 +0100 (CET) k...@aspodata.se wrote: > Anyone knows which one to choose for a smallish group (< 20 persons) ? I /had/ Jitsi Meet running (w/o local turn server and jigasi) on a Odroid XU-4 with 2GB RAM. Tested with up to four participants and running quite well. Downside: The reserved memory of the videobridge is configured under /usr/share/ and thus is not update-proof. libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
