F23 System Wide Change: Default Local DNS Resolver

Miloslav Trmač mitr at redhat.com
Thu Jun 18 13:51:06 UTC 2015


> > VPNs... done like 2 years ago. From what we discussed the connectivity
> > checking is not really perfect in NM, since it assumes that DHCP
> > provided resolvers are in resolv.conf because NM obviously uses system's
> > stub resolver.
> > 
> > If there are any valid integration pieces, please be specific.
> 
> I don't want, in the Network panel, to be talking to 2 pieces of software that
> I'll need to aggregate myself to get a complete picture.

That’s kind of surprising; users should see a view that makes sense to them, not a reflection of the underlying implementation stack.  Isn’t it anyway a pretty common situation to talk to two or more services in one dialog? E.g. the sharing panel definitely talks to several services.

I agree that you don’t want to talk to two pieces of software which tell you different answers to the same question—but AFAICS that should be an argument in favor of integrating with dnssec-trigger directly instead of having NetworkManager proxy (and possibly modify) everything. (Well, assuming dnssec-trigger and NM talk to each other enough to keep in sync, but the dnssec-trigger<->NM interface does not need to be the same as GUI<->NM nor GUI<->dnssec-trigger one.)
    Mirek


More information about the devel mailing list