Re: [DNG] I kinda sorta got opennic DNS working
Quoting tito via Dng (dng@lists.dyne.org): > Hi, > can this opennic.cache file be downloaded freely or do you need > to register? As mentioned, I have not experimented with alternative DNS roots in decades. I could try to answer your question for you, but, seriously, if you are going to start experimenting with advanced DNS topics, you really need to be prepared to do basic data-discovery for yourself at _bare_ minimum. If you are not, I would advise staying away from such matters. I am _not_ prepared to spoon-feed novices on such topics. ___ 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] I kinda sorta got opennic DNS working
On Tue, 9 Mar 2021 22:02:47 -0800
Rick Moen wrote:
> Quoting Steve Litt (sl...@troubleshooters.com):
>
> > When I added four opennic root servers to my unbound's root.hints
>
> {laughs}
>
> Oh, you sweet summer child. Experimenting with alternative DNS roots,
> eh?
>
> It's been decades since I've done so, but ISTR that the correct way to
> do that is to re-point the root-hints line in your Unbound conf file
> to opennic.cache.
>
> > I'd really like to have both icann and opennic root servers in my
> > root.hints.
>
> No, you don't.
>
> opennic.cache should include the standard TLD nameservers.
>
Hi,
can this opennic.cache file be downloaded freely or do you need
to register?
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?)
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] I kinda sorta got opennic DNS working
Quoting Steve Litt (sl...@troubleshooters.com):
> When I added four opennic root servers to my unbound's root.hints
{laughs}
Oh, you sweet summer child. Experimenting with alternative DNS roots,
eh?
It's been decades since I've done so, but ISTR that the correct way to
do that is to re-point the root-hints line in your Unbound conf file
to opennic.cache.
> I'd really like to have both icann and opennic root servers in my
> root.hints.
No, you don't.
opennic.cache should include the standard TLD nameservers.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi-meet server in DMZ
On Tue, 09 Mar 2021 23:02:11 + g4sra via Dng wrote: > ‐‐‐ Original Message ‐‐‐ > On Tuesday, March 9, 2021 4:00 PM, Florian Zieboll via Dng > wrote: > > > On Tue, 09 Mar 2021 14:18:34 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > > > > The meeting being hosted on the server needs to be simultaneously > > > accessible as two different domains, internal.com and > > > external.com. Anyone achieved this yet or know a better way ? > > > > > Not sure if "better", but works for me: I connect to the DMZ'ed > > server from the LAN using its external FQDN. > > > > > libre Grüße, > > Florian > > Thanks for the reply Florian. > > Decided to use the external FQDN and implement BIND's > response-policy' lying to the internal domain. If anyone can think of > a good reason why this is a bad idea please shout. My external router does NAT, only required ports (443, 5349, 1) are forwarded. No DNS magic necessary here, I just commented the 'org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES' line in the videobridge's 'sip-communicator.properties' and instead added the following two: org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS= org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS= ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi-meet server in DMZ
‐‐‐ Original Message ‐‐‐ On Tuesday, March 9, 2021 4:00 PM, Florian Zieboll via Dng wrote: > On Tue, 09 Mar 2021 14:18:34 + > g4sra via Dng dng@lists.dyne.org wrote: > > > The meeting being hosted on the server needs to be simultaneously > > accessible as two different domains, internal.com and external.com. > > Anyone achieved this yet or know a better way ? > > Not sure if "better", but works for me: I connect to the DMZ'ed server > from the LAN using its external FQDN. > > libre Grüße, > Florian Thanks for the reply Florian. Decided to use the external FQDN and implement BIND's response-policy' lying to the internal domain. If anyone can think of a good reason why this is a bad idea please shout. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Strange behaviour with last version of grub
In der Nachricht vom Saturday, 6 March 2021 19:16:13 CET schrieb fsmithred via Dng: > I could not reproduce the problem on a system that boots legacy bios and > uses grub-pc. ...my machine where it happened is a Legacy-BIOS-MBR-Installation. signature.asc Description: This is a digitally signed message part. ___ 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] Strange behaviour with last version of grub
> On 3/4/21 11:08 PM, wirelessduck--- via Dng wrote: >>> >>> And now the question. Has anyone reported the error in Devuan? Has >>> anyone haved this problem? >> >> Seems to be a bit of news about the latest update. >> https://9to5linux.com/patches-for-multiple-new-grub2-security-flaws-start-rolling-out-to-linux-distros-update-now >> >> The changelog mentions changes to secure boot. Could that be related >> to the issue? Same problem here. I think we were bitten by this known Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925309 "Wrong prefix directory hardcoded in signed GRUB image" Signed grub assumes that the initial grub.cfg is in EFI/debian/grub.cfg and not in wherever grub-install put it (usually EFI/devuan/grub.cfg or EFI/BOOT/grub.cfg). You can verify this by entering "set" on the grub command line and checking the default value of the "prefix" and "root" variables. Workaround for me is to manually enter configfile (hd2,gpt1)/EFI/devuan/grub.cfg every time I boot my machine. cheers, David ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi-meet server in DMZ
On Tue, 09 Mar 2021 14:18:34 + g4sra via Dng wrote: > The meeting being hosted on the server needs to be simultaneously > accessible as two different domains, internal.com and external.com. > > Anyone achieved this yet or know a better way ? Not sure if "better", but works for me: I connect to the DMZ'ed server from the LAN using its external FQDN. libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Jitsi-meet server in DMZ
The meeting being hosted on the server needs to be simultaneously accessible as two different domains, internal.com and external.com. Anyone achieved this yet or know a better way ? publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please [SOLVED] ish
‐‐‐ Original Message ‐‐‐ On Tuesday, March 9, 2021 1:00 PM, al3xu5 wrote: > Mon, 08 Mar 2021 22:01:53 + - g4sra g4...@protonmail.com: > > > It turns out 80 of the issue was a syntax error in the ALSA > > configuration. For an unknown reason this mostly only caused an issue > > for web browsers. In fact I only detected it when running some third > > party alsa software that displayed a warning. > > Hi > > Being interested about audio (ALSA), may I ask you which were the third > party alsa software that displayed a warning? > > Thanks > al3xu5 I copied the 'c' code from here... https://stackoverflow.com/questions/40346132/how-to-properly-set-up-alsa-device#40363505 None of the alsa-utils gave any hint that there was a configuration issue, whereas the above program barfed. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Jitsi advice please [SOLVED] ish
Mon, 08 Mar 2021 22:01:53 + - g4sra : > It turns out 80 of the issue was a syntax error in the ALSA > configuration. For an unknown reason this mostly only caused an issue > for web browsers. In fact I only detected it when running some third > party alsa software that displayed a warning. Hi Being interested about audio (ALSA), may I ask you which were the third party alsa software that displayed a warning? Thanks al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B pgpaBxepbyTUj.pgp Description: Firma digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
