On Mon, Sep 28, 2020 at 12:44 am, Paul Wouters wrote:
My fedora
mail server uses DNSSEC based TLSA records to prevent MITM attacks
on the STARTTLS layer, which is now completely broken. My IPsec VPN
server uses dnssec validation using the specified nameserves in
/etc/resolve.conf that now point
On 28/09/2020 14:30, Zbigniew Jędrzejewski-Szmek wrote:
What was the setup you were using? If this is something that we can
reliably detect, I think it it would make sense to adjust the scriptlet
that enables systemd-resolved to print a hint about needing to set DNSSEC=yes.
(Or maybe even set
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Instructions were already posted by Vitaly, so I won't repeat that here.
> > I'll just note that the scriptlet in systemd.rpm looks for
> > 'Generated by NetworkManager' in
On Monday, 28 September 2020 at 15:30, Zbigniew Jędrzejewski-Szmek wrote:
[...]
> What was the setup you were using? If this is something that we can
> reliably detect, I think it it would make sense to adjust the scriptlet
> that enables systemd-resolved to print a hint about needing to set
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >Instructions were already posted by Vitaly, so I won't repeat that here.
> >I'll just note that the scriptlet in systemd.rpm looks for
> >'Generated by NetworkManager' in
On Mon, Sep 28, 2020 at 01:45:02PM +0100, Tom Hughes wrote:
> On 28/09/2020 12:47, Zbigniew Jędrzejewski-Szmek wrote:
>
> >You're mixing a few different things here. We decided to not enable
> >DNSSEC in resolved with this change, at least initially. For most
> >users, DNSSEC is problematic
On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
Instructions were already posted by Vitaly, so I won't repeat that here.
I'll just note that the scriptlet in systemd.rpm looks for
'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
the file is autogenerated.
Which is
On 28/09/2020 12:47, Zbigniew Jędrzejewski-Szmek wrote:
You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't
On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>
> >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
>
> I was just hit by the first bug in systemd-resolved 4 days after I
> upgraded to fedora33. I will file a bug report for that, but I w
On 28.09.2020 06:44, Paul Wouters wrote:
> Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
> to systemd-resolved. I want to remove it from my system, but I cannot
> because it is not even a sub-package of systemd, it is part of the
> core systemd package.
You can always
Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.
systemd-resolved has a number of architectural
This is just a data point:
F31 Workstation clean installed (Live ISO), then updated to current
F31, then upgraded to F33 (no interim F32).
/etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] resolve
[!UNAVAIL=return] myhostname dns
And
lrwxrwxrwx. 1 root root39 Sep 10
On Tue, Sep 1, 2020 at 10:50 pm, Nico Kadel-Garcia
wrote:
And oh, "files" always comes first because local config files should
always take priority over upstream network based services.
Zbigniew wound up moving files first in the end, but his justification
for putting resolve first is here:
On Tue, Sep 01, 2020 at 08:17:49AM -0400, Nico Kadel-Garcia wrote:
> > >> Big Brother will be happy. :-)
> > >
> > > Sure, those two companies will be thrilled, I'm sure. This is a huge
> > > disservice to our users. Why in the world does systemd try to force DNS
> > > servers when none are
On Tue, Sep 01, 2020 at 07:50:46AM +0800, Ed Greshko wrote:
> I don't think the DHCP server for the QEMU VMs is supplying a domain.
> However, Network Manager
> will add a "search" option to resolv.conf when "hostname" returns a FQDN.
Ed opened
* John M. Harris, Jr.:
> On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote:
>> * John M. Harris, Jr.:
>>
>>
>> > Sure, those two companies will be thrilled, I'm sure. This is a huge
>> > disservice to our users. Why in the world does systemd try to force DNS
>> > servers when
On 2020-09-02 11:00, Neal Gompa wrote:
> On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia wrote:
>> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr
>> wrote:
>>> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
On 2020-09-02 11:06, John M. Harris Jr wrote:
> On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote:
>> On 2020-09-02 10:21, John M. Harris Jr wrote:
>>
>>> I don't know what you're talking about here. Am I missing something? Is
>>> this a F33 Change? Exact content of my /etc/nsswitch:
On Tuesday, September 1, 2020 7:29:44 PM MST Ed Greshko wrote:
> On 2020-09-02 10:21, John M. Harris Jr wrote:
>
> > I don't know what you're talking about here. Am I missing something? Is
> > this a F33 Change? Exact content of my /etc/nsswitch:
>
>
> Is your system an upgrade of an earlier
On Tue, Sep 1, 2020 at 10:51 PM Nico Kadel-Garcia wrote:
>
> On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr
> wrote:
> >
> > On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> > > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> > > wrote:
> > >
> > > > Michael,
>
On Tue, Sep 1, 2020 at 10:21 PM John M. Harris Jr wrote:
>
> On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> > On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> > wrote:
> >
> > > Michael,
> > >
> > > The file is /etc/nsswitch.conf.
> >
> >
> > You're wasting
On 2020-09-02 10:21, John M. Harris Jr wrote:
> I don't know what you're talking about here. Am I missing something? Is this
> a
> F33 Change? Exact content of my /etc/nsswitch:
Is your system an upgrade of an earlier version?
In my case I have an F32 system which has been around for a few
On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote:
> * John M. Harris, Jr.:
>
>
> > Sure, those two companies will be thrilled, I'm sure. This is a huge
> > disservice to our users. Why in the world does systemd try to force DNS
> > servers when none are configured? If no DNS
On Tuesday, September 1, 2020 7:22:49 AM MST Michael Catanzaro wrote:
> On Tue, Sep 1, 2020 at 8:17 am, Nico Kadel-Garcia
> wrote:
>
> > Hiding it inside yet another systemd structure without following the
> > existing standards is, sadly, typical of systemd. It also puts at risk
> > restricted
On Tuesday, September 1, 2020 7:14:35 AM MST Michael Catanzaro wrote:
> On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
> wrote:
>
> > Michael,
> >
> > The file is /etc/nsswitch.conf.
>
>
> You're wasting everyone's time with these low-effort spam posts.
I don't see how this could
Den mån 31 aug. 2020 kl 22:40 skrev Michael Catanzaro :
> On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek
> wrote:
> > I can't get that command to do anything useful in either F32 or F33.
>
> You should see something like:
>
> $ resolvectl query example.com
> example.com:
On Tue, Sep 1, 2020 at 8:17 am, Nico Kadel-Garcia
wrote:
Hiding it inside yet another systemd structure without following the
existing standards is, sadly, typical of systemd. It also puts at risk
restricted environments where providing no DNS is deliberately used to
restrict outbound network
On Mon, Aug 31, 2020 at 11:49 pm, John M. Harris Jr
wrote:
Michael,
The file is /etc/nsswitch.conf.
You're wasting everyone's time with these low-effort spam posts. Lest
anyone become confused, there is a big warning at the top of that file
warning you that it is managed by authselect,
* Roberto Ragusa:
> Standard DNS has a hierarchical structure with roots and delegation.
> The idea of asking somebody to do DNS resolution for you comes from
> the widespread tendency to centralize everything (i.e. inability to
> understand how the Internet was originally designed).
DNS
* John M. Harris, Jr.:
> Sure, those two companies will be thrilled, I'm sure. This is a huge
> disservice to our users. Why in the world does systemd try to force DNS
> servers when none are configured? If no DNS servers are configured, there
> should be no DNS servers in use.
Acutally, the
On Tue, Sep 1, 2020 at 3:34 AM Roberto Ragusa wrote:
>
> On 2020-09-01 08:52, John M. Harris Jr wrote:
> > On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote:
> >> On 31.08.2020 17:07, John M. Harris Jr wrote:
> >>
> >>> ship a release with "fallback" to Google and
On 2020-09-01 08:52, John M. Harris Jr wrote:
On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote:
On 31.08.2020 17:07, John M. Harris Jr wrote:
ship a release with "fallback" to Google and Cloudflare DNS?
Big Brother will be happy. :-)
Sure, those two companies will
On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote:
> On 31.08.2020 17:07, John M. Harris Jr wrote:
>
> > ship a release with "fallback" to Google and Cloudflare DNS?
>
>
> Big Brother will be happy. :-)
Sure, those two companies will be thrilled, I'm sure. This is a huge
On Monday, August 31, 2020 1:39:37 PM MST Michael Catanzaro wrote:
> On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek
> wrote:
>
> > I can't get that command to do anything useful in either F32 or F33.
>
>
> You should see something like:
>
> $ resolvectl query example.com
> example.com:
On 2020-09-01 01:18, Michael Catanzaro wrote:
>
> On Mon, Aug 31, 2020 at 9:36 pm, Ed Greshko wrote:
>> But with that symlink it seems there is no integration with NetworkManager.
>> So, if one has configured (which is
>> the default) to acquire addresses automatically then DNS server info
>>
On Mon, Aug 31, 2020 at 10:19 pm, Andreas Tunek
wrote:
I can't get that command to do anything useful in either F32 or F33.
You should see something like:
$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: tun0
93.184.216.34 -- link: tun0
--
Den mån 31 aug. 2020 kl 00:55 skrev Michael Catanzaro :
> On Sun, Aug 30, 2020 at 12:30 pm, Andreas Tunek
> wrote:
> > On my F33 test system (new install yesterday) I can see my NAS but I
> > can't connect to it. Could that be due to this change?
>
> Possibly! Try using 'resolvectl query' and
On Mon, Aug 31, 2020 at 9:36 pm, Ed Greshko
wrote:
But with that symlink it seems there is no integration with
NetworkManager. So, if one has configured (which is
the default) to acquire addresses automatically then DNS server info
supplied by DHCP is ignored.
Is my take incorrect?
On 31.08.2020 17:07, John M. Harris Jr wrote:
> ship a release with "fallback" to Google and Cloudflare DNS?
Big Brother will be happy. :-)
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
On Monday, August 31, 2020 6:43:37 AM MST Ed Greshko wrote:
> On 2020-08-31 21:40, John M. Harris Jr wrote:
>
> > On Monday, August 31, 2020 1:22:58 AM MST Ed Greshko wrote:
> >
> >> On 2020-08-30 18:30, Andreas Tunek wrote:
> >>
> >>
> >>
> >>> On my F33 test system (new install yesterday) I
On 2020-08-31 21:40, John M. Harris Jr wrote:
> On Monday, August 31, 2020 1:22:58 AM MST Ed Greshko wrote:
>> On 2020-08-30 18:30, Andreas Tunek wrote:
>>
>>> On my F33 test system (new install yesterday) I can see my NAS but I can't
>>> connect to it. Could that be due to this change?
>> Could
On Monday, August 31, 2020 1:22:58 AM MST Ed Greshko wrote:
> On 2020-08-30 18:30, Andreas Tunek wrote:
>
> > On my F33 test system (new install yesterday) I can see my NAS but I can't
> > connect to it. Could that be due to this change?
>
> Could you me a bit more specific?
>
> I just
On 2020-08-31 21:18, Michael Catanzaro wrote:
> On Mon, Aug 31, 2020 at 1:09 pm, Vitaly Zaitsev via devel
> wrote:
>> You system is not using systemd-resolved.
>
> It mostly is, though, via nss-resolve. Only stuff that uses resolv.conf
> directly is broken and not using resolved, which is
>
On Mon, Aug 31, 2020 at 1:09 pm, Vitaly Zaitsev via devel
wrote:
You system is not using systemd-resolved.
It mostly is, though, via nss-resolve. Only stuff that uses resolv.conf
directly is broken and not using resolved, which is
https://bugzilla.redhat.com/show_bug.cgi?id=1873856.
On 31.08.2020 10:22, Ed Greshko wrote:
> [egreshko@f33g ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> search greshko.com
> nameserver 192.168.122.1
You system is not using systemd-resolved.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 2020-08-30 18:30, Andreas Tunek wrote:
> On my F33 test system (new install yesterday) I can see my NAS but I can't
> connect to it. Could that be due to this change?
Could you me a bit more specific?
I just installed from Fedora-Workstation-Live-x86_64-33-20200829.n.0.iso to a
VM and
On Sunday, August 30, 2020 8:36:46 AM MST Michael Catanzaro wrote:
> On Sun, Aug 30, 2020 at 9:06 am, Michael Catanzaro
> wrote:
>
> > I don't know what to do about this. Ideally we would figure out
> > what's wrong and sneak a freeze exception into the beta release. If
> > the file in 3. is
On Sunday, August 30, 2020 3:30:22 AM MST Andreas Tunek wrote:
> On my F33 test system (new install yesterday) I can see my NAS but I can't
> connect to it. Could that be due to this change?
If you used your own DNS servers, yes. You'll need to fix this file:
Remove the systemd thing:
`rm
On Sun, Aug 30, 2020 at 12:30 pm, Andreas Tunek
wrote:
On my F33 test system (new install yesterday) I can see my NAS but I
can't connect to it. Could that be due to this change?
Possibly! Try using 'resolvectl query' and see what it says
___
On 30.08.2020 16:04, Michael Catanzaro wrote:
> The file should not be generated by NetworkManager. NetworkManager
> should notice that the file is a symlink to
> /run/systemd/resolve/stub-resolv.conf and leave it alone. (In point 3.
> the file should be a symlink.)
Network Manager can be
On my F33 test system (new install yesterday) I can see my NAS but I can't
connect to it. Could that be due to this change?
Best regards
Andreas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Sun, Aug 30, 2020 at 9:06 am, Michael Catanzaro
wrote:
I don't know what to do about this. Ideally we would figure out
what's wrong and sneak a freeze exception into the beta release. If
the file in 3. is not a symlink, then that would be what's wrong, but
it ought to be a symlink.
I
On Sat, Aug 29, 2020 at 3:12 pm, Chris Murphy
wrote:
Are these the expected behavior?
4. is unexpected. The file should not be generated by NetworkManager.
NetworkManager should notice that the file is a symlink to
/run/systemd/resolve/stub-resolv.conf and leave it alone. (In point 3.
the
On Sun, Aug 30, 2020 at 9:04 am, Michael Catanzaro
wrote:
4. is unexpected. The file should not be generated by NetworkManager.
NetworkManager should notice that the file is a symlink to
/run/systemd/resolve/stub-resolv.conf and leave it alone. (In point
3. the file should be a symlink.)
I
Observations based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
1. The ext4+squashfs image on media has no /etc/resolv.conf at all;
this is what forms the basis of /dev/mapper/live-base, and is the
source for installations (copied by rsync).
2. The installation live environment uses
On Friday, August 28, 2020 9:55:18 PM MST drago01 wrote:
> On Saturday, August 29, 2020, John M. Harris Jr
>
> wrote:
> > On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> > > On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> > >
> > > wrote:
> > > > Zbigniew, do you agree
On Saturday, August 29, 2020, John M. Harris Jr
wrote:
> On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> > On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> > wrote:
> >
> > > Zbigniew, do you agree that we should remove the script if and only
> > > if it is generated by
On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> wrote:
>
> > Zbigniew, do you agree that we should remove the script if and only
> > if it is generated by NetworkManager? Otherwise, the change is only
> >
On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
wrote:
Zbigniew, do you agree that we should remove the script if and only
if it is generated by NetworkManager? Otherwise, the change is only
partially-implemented for users upgrading from F32 and earlier.
We agreed to go with this
On Tue, Jul 28, 2020 at 5:23 pm, Zbigniew Jędrzejewski-Szmek
wrote:
Right now there's the following scriptlet:
grep -q 'Generated by NetworkManager' /etc/resolv.conf 2>/dev/null &&
\
echo -e '/etc/resolv.conf was generated by
NetworkManager.\nConsider removing it to let
On Tue, Jul 28, 2020 at 06:45:06PM -0500, Michael Catanzaro wrote:
> On Tue, Jul 28, 2020 at 4:35 pm, John M. Harris Jr
> wrote:
> > I haven't found any systems where that's the case, though my systems
> > have been
> > upgraded all along through from ~F24. Looking at my latest install,
> > which
On Tue, Jul 28, 2020 at 4:35 pm, John M. Harris Jr
wrote:
I haven't found any systems where that's the case, though my systems
have been
upgraded all along through from ~F24. Looking at my latest install,
which has
been upgraded from F30, /etc/resolv.conf is still just a file by
default.
On Tuesday, July 28, 2020 9:22:58 AM MST Michael Catanzaro wrote:
> I agree we should not replace /etc/resolv.conf if it's not already a
> symlink (although this will not be a common case, since by default it
> is a symlink managed by NetworkManager).
I haven't found any systems where that's
On Tuesday, July 28, 2020 11:47:27 AM MST Ian Pilcher wrote:
> On 7/28/20 12:31 PM, Michael Catanzaro wrote:
>
> > I think we should remove it if it's generated by NetworkManager, and
> > leave it untouched otherwise. If NetworkManager is managing DNS then it
> > will just push all its settings
On 7/28/20 12:31 PM, Michael Catanzaro wrote:
I think we should remove it if it's generated by NetworkManager, and
leave it untouched otherwise. If NetworkManager is managing DNS then it
will just push all its settings to systemd-resolved anyway after
upgrade, right?
Don't assume that the
On Tue, Jul 28, 2020 at 5:23 pm, Zbigniew Jędrzejewski-Szmek
wrote:
I.e. only a hint is emitted. I'm open to suggestions how to improve
it.
I think we should remove it if it's generated by NetworkManager, and
leave it untouched otherwise. If NetworkManager is managing DNS then it
will just
On Tue, Jul 28, 2020 at 11:22:58AM -0500, Michael Catanzaro wrote:
> I agree we should not replace /etc/resolv.conf if it's not already a
> symlink (although this will not be a common case, since by default
> it is a symlink managed by NetworkManager).
>
> On Tue, Jul 28, 2020 at 11:07 am, Neal
I agree we should not replace /etc/resolv.conf if it's not already a
symlink (although this will not be a common case, since by default it
is a symlink managed by NetworkManager).
On Tue, Jul 28, 2020 at 11:07 am, Neal Gompa wrote:
We can be smart here and replace the file when we detect
On 28 July 2020 17:07:14 CEST, Neal Gompa wrote:
>> To prevent brutally overwriting configuration, it would be best not to
>> replace
>> /etc/resolv.conf with a symlink on upgrade, ignoring user configuration, but
>> to do so on all new installs.
>>
>
>We can be smart here and replace the
On Tue, Jul 28, 2020 at 10:58 AM John M. Harris Jr wrote:
>
> On Tuesday, July 28, 2020 5:11:31 AM MST Lennart Poettering wrote:
> > On Mo, 27.07.20 09:20, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> >
> > > That *is* what will happen. In this scenario, systemd-resolved creates
> > > a file in
On Tuesday, July 28, 2020 5:11:31 AM MST Lennart Poettering wrote:
> On Mo, 27.07.20 09:20, Neal Gompa (ngomp...@gmail.com) wrote:
>
>
> > That *is* what will happen. In this scenario, systemd-resolved creates
> > a file in /run that is populated with the required information for
> >
On Mo, 27.07.20 09:20, Neal Gompa (ngomp...@gmail.com) wrote:
> That *is* what will happen. In this scenario, systemd-resolved creates
> a file in /run that is populated with the required information for
> applications to request name resolution from resolved through the
> standard DNS protocol.
On Monday, July 27, 2020 6:43:23 AM MST Simo Sorce wrote:
> On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
>
> > On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce wrote:
> >
> > > On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> > >
> > > > On Sun, Jul 26, 2020 at 6:15 pm, John M.
On Monday, July 27, 2020 6:57:07 AM MST Solomon Peachy wrote:
> Additionally, Fedora's default configuration (for many, many, many years
> now) has had /etc/resolv.conf dynamically generated by NetworkManager.
> Local changes made directly to resolv.conf could (and would) get blown
> away at any
Once upon a time, Neal Gompa said:
> That *is* what will happen. In this scenario, systemd-resolved creates
> a file in /run that is populated with the required information for
> applications to request name resolution from resolved through the
> standard DNS protocol.
I modify that to say:
On Mon, Jul 27, 2020 at 09:43:23AM -0400, Simo Sorce wrote:
> Thanks, I guess I misunderstood because of alarmist tones.
I think it's fair to say that there's a lesson to be learned here.
> This will work just fine, writing to resolv.conf is indeed something
> advanced, and a user that can set
On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
> On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce wrote:
> > On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> > > On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> > > wrote:
> > > > Please do not disable reading from
On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce wrote:
>
> On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> > On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> > wrote:
> > > Please do not disable reading from /etc/resolv.conf. If you do so,
> > > please
> > > limit that to the Spins
On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> wrote:
> > Please do not disable reading from /etc/resolv.conf. If you do so,
> > please
> > limit that to the Spins that it won't affect people on, such as
> > Workstation,
> >
* Michael Catanzaro:
> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> wrote:
>> Please do not disable reading from /etc/resolv.conf. If you do so,
>> please
>> limit that to the Spins that it won't affect people on, such as
>> Workstation,
>> if you believe people there don't set their own
On Sunday, July 26, 2020 7:47:08 PM MST Gordon Messmer wrote:
> On 7/26/20 6:15 PM, John M. Harris Jr wrote:
>
> > Please do not disable reading from /etc/resolv.conf.
>
>
>
> Where did you get the impression that the change would do that?
>
> Relevant quotes:
>
>
> > In short,
On Sunday, July 26, 2020 7:06:48 PM MST Michael Catanzaro wrote:
> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> wrote:
>
> > Please do not disable reading from /etc/resolv.conf. If you do so,
> > please
> > limit that to the Spins that it won't affect people on, such as
> >
On 7/26/20 6:15 PM, John M. Harris Jr wrote:
Please do not disable reading from /etc/resolv.conf.
Where did you get the impression that the change would do that?
Relevant quotes:
In short, '''applications that read /etc/resolv.conf will continue to
work as before.'''
/etc/resolv.conf
On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
wrote:
Please do not disable reading from /etc/resolv.conf. If you do so,
please
limit that to the Spins that it won't affect people on, such as
Workstation,
if you believe people there don't set their own DNS servers.
Except:
*
On Tuesday, April 14, 2020 12:23:27 PM MST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
>
> == Summary ==
>
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
>
> == Owner ==
> * Name:
migrating a couple of local servers to, atm, F32, i noted this planned/accepted
'systemd-wide change' for switching to systemd-resolved as default in >= F33,
here, and
https://fedoraproject.org/wiki/Changes/systemd-resolved
again, i understand it's default @ >= F33.
iiuc, tho, it
On Fri, Apr 17, 2020 at 8:34 AM Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
> > The DNS servers in edge routers are awful at supporting
> > either. i.e. the DNS servers you usually get informed about in DHCP
> > leases are typically too crap at supporting either kind of
Once upon a time, Lennart Poettering said:
> The DNS servers in edge routers are awful at supporting
> either. i.e. the DNS servers you usually get informed about in DHCP
> leases are typically too crap at supporting either kind of DNSSEC (and
> that for a reason actually, these devices generally
On Do, 16.04.20 19:53, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > Again, we do not support DNSSEC from client to the stub. If you set CD
> > we'll return NOTIMP as rcode, indicating that. We do not implement a
> > full DNS server, but just enough for
Once upon a time, Lennart Poettering said:
> On Do, 16.04.20 07:45, John M. Harris Jr (joh...@splentity.com) wrote:
> > If there are no servers configured... Shouldn't it use no servers?
>
> Well, our assumption is that working DNS is better than DNS that
> doesn't work.
Talking to servers the
Once upon a time, Lennart Poettering said:
> Again, we do not support DNSSEC from client to the stub. If you set CD
> we'll return NOTIMP as rcode, indicating that. We do not implement a
> full DNS server, but just enough for local stub clients (such as the
> one implemented in glibc or Java) to
On Thu, Apr 16, 2020 at 8:07 pm, Florian Weimer
wrote:
I don't think this change is ready for Fedora, then.
Florian, isn't this a quite specialized use-case of the sort where you
can simply write your own /etc/resolv.conf and let resolved consume
that? Or just disable resolved?
How? The
* Matthew Miller:
> On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
>> > If there are no servers configured... Shouldn't it use no servers?
>> Well, our assumption is that working DNS is better than DNS that
>> doesn't work.
>
> I hope no one is using lack of configured DNS as
On Do, 16.04.20 14:07, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
> > > If there are no servers configured... Shouldn't it use no servers?
> > Well, our assumption is that working DNS is better than DNS that
> > doesn't
* Lennart Poettering:
> On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote:
>
>> > I don't think we can reliably determine whether people have deployed
>> > things in a way that relies on /etc/resolv.conf only listing a fully
>> > blown DNS server or who are fine with it being a
On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
> > If there are no servers configured... Shouldn't it use no servers?
> Well, our assumption is that working DNS is better than DNS that
> doesn't work.
I hope no one is using lack of configured DNS as a security measure! But I
On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote:
> > I don't think we can reliably determine whether people have deployed
> > things in a way that relies on /etc/resolv.conf only listing a fully
> > blown DNS server or who are fine with it being a more restricted stub
> > like
On Do, 16.04.20 07:45, John M. Harris Jr (joh...@splentity.com) wrote:
> If there are no servers configured... Shouldn't it use no servers?
Well, our assumption is that working DNS is better than DNS that
doesn't work.
Lennart
--
Lennart Poettering, Berlin
On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote:
>
> Really, it may be best to go about this in the same way as Ubuntu, with nss-
> dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done
> on Fedora, especially on servers. In fact, I never knew that
* Tomas Mraz:
> On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote:
>> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer
>> wrote:
>> > Not sure if that's compatible with the new split DNS model because
>> > VPN1
>> > could simply start pushing longer names in the scope of VPN2, thus
>>
201 - 300 of 386 matches
Mail list logo
