From rambiusparkisanius at gmail.com Sun May 5 16:06:00 2024 From: rambiusparkisanius at gmail.com (Ivan "Rambius" Ivanov) Date: Sun, 5 May 2024 16:06:00 -0400 Subject: [talk] Question about DNSSEC Message-ID: Hello, I recently bought a new Turris Omnia wireless router https://www.turris.com/en/products/omnia/. The router has its own DNS resolver with DNSSEC, but by default it uses the ISP's DNS resolver with DNSSEC turned on. Spectrum is my ISP and I tried their DNS resolver with DNSSEC and it did not work. I had to disable DNSSEC to make it work. I called Spectrum and they told me they did not support DNSSEC. I was wondering what you guys would recommend - shall I use the router's own DNS resolver with DNSSEC or shall I use my ISP's one without DNSSEC? Regards Ivan -- Tangra Mega Rock: http://www.radiotangra.com From george at ceetonetechnology.com Sun May 5 16:12:23 2024 From: george at ceetonetechnology.com (George Rosamond) Date: Sun, 5 May 2024 16:12:23 -0400 Subject: [talk] Question about DNSSEC In-Reply-To: References: Message-ID: <1ddb64b6-fe15-4fcd-b5ee-6a031f487b49@ceetonetechnology.com> On 5/5/24 16:06, Ivan "Rambius" Ivanov wrote: > Hello, > > I recently bought a new Turris Omnia wireless router > https://www.turris.com/en/products/omnia/. The router has its own DNS > resolver with DNSSEC, but by default it uses the ISP's DNS resolver > with DNSSEC turned on. Spectrum is my ISP and I tried their DNS > resolver with DNSSEC and it did not work. I had to disable DNSSEC to > make it work. I called Spectrum and they told me they did not support > DNSSEC. > Oh shocking! From their commercials, you would thing they invented the internet and DNSSEC. > I was wondering what you guys would recommend - shall I use the > router's own DNS resolver with DNSSEC or shall I use my ISP's one > without DNSSEC? So this is an interesting question, because the ISPs definitely sell the DNS lookup data they get. I think it depends. Usually the ISP resolvers are much faster and reliable. I would wonder what the upstream DNS resolver is for the device. Assume Google,Cloudflare? If the speed of lookups was priority, I would probably run a lot of lookups with time(1). If DNSSEC was what you wanted, then the question is answered. I'm wondering about sane public DNS that people are using, outside of the usual suspects.... g From mwl at mwl.io Sun May 5 17:44:05 2024 From: mwl at mwl.io (Michael W. Lucas) Date: Sun, 5 May 2024 17:44:05 -0400 Subject: [talk] Question about DNSSEC In-Reply-To: References: Message-ID: On Sun, May 05, 2024 at 04:06:00PM -0400, Ivan "Rambius" Ivanov wrote: > Hello, > > I recently bought a new Turris Omnia wireless router > https://www.turris.com/en/products/omnia/. The router has its own DNS > resolver with DNSSEC, but by default it uses the ISP's DNS resolver > with DNSSEC turned on. Spectrum is my ISP and I tried their DNS > resolver with DNSSEC and it did not work. I had to disable DNSSEC to > make it work. I called Spectrum and they told me they did not support > DNSSEC. > > I was wondering what you guys would recommend - shall I use the > router's own DNS resolver with DNSSEC or shall I use my ISP's one > without DNSSEC? > > Regards > Ivan Personal bias: Run your own DNS resolver with DNSSEC validation. If the router's implementation works, use it. If it's buggy, skip the router and put a resolver somewhere you control. recursive DNS load is so trivial on modern systems, and configuration so straightforward, there's no reason not to. ==ml -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Absolute FreeBSD, Butterfly Stomp Waltz, TLS Mastery, etc... ### New books: DNSSEC Mastery, Letters to ed(1), Prohibition Orcs ### From carton at Ivy.NET Sun May 5 18:23:49 2024 From: carton at Ivy.NET (Miles Nordin) Date: Sun, 5 May 2024 18:23:49 -0400 Subject: [talk] Question about DNSSEC In-Reply-To: <1ddb64b6-fe15-4fcd-b5ee-6a031f487b49@ceetonetechnology.com> References: <1ddb64b6-fe15-4fcd-b5ee-6a031f487b49@ceetonetechnology.com> Message-ID: <20240505222349.GA23321@castrovalva.Ivy.NET> > I was wondering what you guys would recommend - shall I use the > router's own DNS resolver with DNSSEC or shall I use my ISP's one > without DNSSEC? I don't think DNSSEC matters because the web does not use DANE, but I would not use the ISP's nameserver regardless, as George says. Since names are bound to endpoints by TLS certificates the relevant attack today is unregulated ISP logging, not cache poisoning. it could make sense to use DNSSEC as part of some ssh intranet, putting ssh fingerprints in DNS, but this is a special thing that has to be configured so it's hypothetical while the ISP logging is real. I do not really understand all the DNSSEC modes, do endpoints have to support it, do you have to request fail-closed per query, what is the latency penalty, etc., so besides not being meaningful on the web, I'm not sure offhand how to go about setting up such a hypothetical ssh-fp scheme. DNSSEC seems kinda irrelevant to me, like IPv6, though this is "sad," or whatever. > I'm wondering about sane public DNS that people are using, outside of > the usual suspects.... I use a local resolver, and it's garbage. I think BIND is buggy, and besides the terrible security track record it wedges sometimes. My gut feeling is that there are a lot of broken recursive resolvers out there causing pages to load slowly. If I were setting up something from scratch I'd probably try to use DNS-over-TLS to Cloudflare or Google to evade the logging. If I decided it was just too yucky to depend on a megacorp and that I want to keep running a local resolver, it would not be BIND if I were doing it all over. ISTR the logging policy for honestdns is sane and Google is well-watched by many litigious governments because of European protectionism and US political grandstanding. I guess the same is true of Cloudflare but less. Of ISPs, obviously, we know they are not watched or effectively controlled at all. They are the most hated companies in the country and scoff at other regulations and pay the wrist-slap fines, they illegally overcooperate with government wiretaps then receive retroactive immunity from Congress. Maybe ISPs are not watching local resolver traffic, only recursive traffic, because weirdos like us are too rare and irrelevant to bother with the implementation, but if Apple put a local resolver in airport by default they would start watching that traffic so DNS-over-TLS is a real move in the game, solving a real problem that running a local resolver does not solve: if you can get your web traffic to a CDN without the ISP seeing the URL, you can gain a little more privacy without the speed, flakiness, dollar, and sketchiness cost of a VPN. It's a sensible default, which I think is what you're looking for here, how do I provide an unopinionated but "good" interweb connection. so I would take option (c) other, DNS-over-TLS, though it's not what I do myself. For CDNs it's important your DNS queries come from near where the https request will come from, so one thing you should definitely not do is somehow shove DNS into a privacy VPN but then make https requests outside the privacy VPN. I think I was doing this at one point, not sure how noticeable it was, but it's "incorrect" in terms of unopinionated-but-good. From pete at nomadlogic.org Mon May 6 16:49:09 2024 From: pete at nomadlogic.org (Pete Wright) Date: Mon, 6 May 2024 13:49:09 -0700 Subject: [talk] Question about DNSSEC In-Reply-To: <20240505222349.GA23321@castrovalva.Ivy.NET> References: <1ddb64b6-fe15-4fcd-b5ee-6a031f487b49@ceetonetechnology.com> <20240505222349.GA23321@castrovalva.Ivy.NET> Message-ID: On Sun, May 05, 2024 at 06:23:49PM UTC, Miles Nordin wrote: > > I'm wondering about sane public DNS that people are using, outside of > > the usual suspects.... > > I use a local resolver, and it's garbage. I think BIND is buggy, and > besides the terrible security track record it wedges sometimes. My gut > feeling is that there are a lot of broken recursive resolvers out there > causing pages to load slowly. i run local-unbound on all my unix systems, and serve my network with unbound as well where it acts as a validating/caching resolver. i've had zero issues with it. > > If I were setting up something from scratch I'd probably try to use > DNS-over-TLS to Cloudflare or Google to evade the logging. If I decided > it was just too yucky to depend on a megacorp and that I want to keep > running a local resolver, it would not be BIND if I were doing it all over. > if you are going to give someone all of your internet traffic i'd suggest using quad9 (9.9.9.9). in theory they aren't aggregating data which goog and cloudflare are most certainly doing. ibm is (was?) a backer of quad9 - but at least in theory there are some legal controls to not mine your internet usage: https://www.quad9.net/ bonus points for it doing a decent job of filtering out malware. -pete From mcevoy.pat at gmail.com Fri May 17 18:08:05 2024 From: mcevoy.pat at gmail.com (Pat McEvoy) Date: Fri, 17 May 2024 18:08:05 -0400 Subject: [talk] Next NYC*BUG: June 5th Message-ID: <9121E96F-17C0-41B5-A79A-146B53FE0074@gmail.com> https://www.nycbug.org/index?action=view&id=10697 20th BSDCan Recap meeting, with George Rosamond and other NYC*BUG members 2024-06-05 @ 18:45 EDT (22:45 UTC) We plan to gather after the 20th BSDCan and share notes. Possible subjects of discussion: BSDCan 20th recap (speakers thoughts welcome) next steps fist time conference attendees thoughts also very welcome. *BSD community growth ideas streaming / recordings production report. [your suggestions here] -------------- next part -------------- An HTML attachment was scrubbed... URL: From phelanm at gmail.com Fri May 17 20:09:42 2024 From: phelanm at gmail.com (Mark Phelan) Date: Sat, 18 May 2024 00:09:42 +0000 Subject: [talk] Invitation: Next NYC*BUG: June 5th @ Wed Jun 5, 2024 (talk@lists.nycbug.org) Message-ID: [talk] Next NYC*BUG: June 5th Wednesday Jun 5, 2024 Join with Google Meet https://meet.google.com/tmy-msph-byo?hs=224 https://www.nycbug.org/index?action=view&id=10697 20th BSDCan Recap meeting, with George Rosamond and other NYC*BUG members 2024-06-05 @ 18:45 EDT (22:45 UTC) We plan to gather after the 20th BSDCan and share notes. Possible subjects of discussion: BSDCan 20th recap (speakers thoughts welcome) next steps fist time conference attendees thoughts also very welcome. *BSD community growth ideas streaming / recordings production report. [your suggestions here] _______________________________________________ talk mailing list talk at lists.nycbug.org https://lists.nycbug.org:8443/mailman/listinfo/talk Organizer Mark Phelan phelanm at gmail.com Guests Mark Phelan - organizer mcevoy.pat at gmail.com talk at lists.nycbug.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=MGxsODNzdnJtdGljajY4NDV2NHVjcG5sYnQgdGFsa0BsaXN0cy5ueWNidWcub3Jn&tok=MTcjcGhlbGFubUBnbWFpbC5jb201NmZjZmYzYzZlZmEyNzJjODliY2JhYzNmOTVhMGIxYTE5MWJiMjNi&ctz=America%2FNew_York&hl=en&es=0 Reply for talk at lists.nycbug.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=MGxsODNzdnJtdGljajY4NDV2NHVjcG5sYnQgdGFsa0BsaXN0cy5ueWNidWcub3Jn&tok=MTcjcGhlbGFubUBnbWFpbC5jb201NmZjZmYzYzZlZmEyNzJjODliY2JhYzNmOTVhMGIxYTE5MWJiMjNi&ctz=America%2FNew_York&hl=en&es=0 Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2061 bytes Desc: not available URL: From mwl at mwl.io Sun May 19 16:40:29 2024 From: mwl at mwl.io (Michael W. Lucas) Date: Sun, 19 May 2024 16:40:29 -0400 Subject: [talk] BSDCan Train Message-ID: This list in particular needs to know: https://www.cbc.ca/news/canada/montreal/cn-amtrak-deal-service-suspension-1.7208721 -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Absolute FreeBSD, Butterfly Stomp Waltz, TLS Mastery, etc... ### New books: DNSSEC Mastery, Letters to ed(1), Prohibition Orcs ###