[DNSCrypt] systemd sockets disabled and dnscrypt-proxy-resolvconf file.

[ghost]

Hello.

First, the most important thing: I want to thank Mr Frank Denis (and other Developers) for creating such an amazing and important application. Without your works, DNS privacy could depend only on two solutions explored by, amongst others, the IETF.

I have a question about the DNSCrypt with systemd sockets disabled and dnscrypt-proxy-resolvconf.service file. Is this file needed or can it be disabled along with dnscrypt-proxy.socket file? I'm asking because it seems, that this is file is not needed. DNSCrypt works okay and there are such an informations in Status:

[NOTICE] Now listening to 127.0.2.1:53 [UDP]
[NOTICE] Now listening to 127.0.2.1:53 [TCP]

Because dnscrypt-proxy-resolvconf.service file is used to gather a nameserver IP address (vide ExecStart{,Stop} options) from the dnscrypt-proxy.socket file and this address is already added, defined in dnscrypt-proxy.toml file (via listen_addresses option), it seems that dnscrypt-proxy-resolvconf.service file is not needed. Am I right?

Or maybe it's opposite and this file is needed because of lo.dnscrypt-proxy? (dnscrypt-proxy-resolvconf.service file, contains /sbin/resolvconf command, used twice with -a and -d options etc.) There are such possibilities:

• leave dnscrypt-proxy.service and dnscrypt-proxy-resolvconf.service file.
• leave dnscrypt-proxy.service only and disable dnscrypt-proxy-resolvconf.service file (what about lo.dnscrypt-proxy? Is it important, necessary?)

So, what should be done with dnscrypt-proxy-resolvconf.service file? In case when systemd sockets are disabled, of course.

Sorry, for such a long message.

Best regards.

[welwood08]

These files do not exist in the official releases of dnscrypt-proxy, so you'll probably find better luck asking the maintainer of the package you're using or their package-specific support channel. For what it's worth, I use dnscrypt-proxy.socket without dnscrypt-proxy-resolvconf.service because I don't use resolvconf.

[ghost]

Hi, welwood08. Thank You for an answer.

Asking Maintainer of the package seems to be a really good idea. dnscrypt-proxy-resolvconf.service file is also mentioned here, on Wiki (however, I don't remember where exactly).

Anyway, my question is for Users who have all three files. I'm glad, that You're using dnscrypt-proxy.socket file even if it's unsupported and dropping privileges is not working with systemd sockets (vide Mr Frank Denis statements and so on).

So, anyone else knows the answer? ;- )

Best regards.

[welwood08]

Using GitHub's search function, it appears these files are mentioned on the systemd wiki page which suggests they might come from Arch. I don't run dnscrypt-proxy on an Arch-based system and I built my own custom package, so there's probably some minor differences.

Assuming your package contains the same contents as shown on the wiki, it looks like it relies on dnscrypt-proxy.socket to dynamically add a resolvconf entry. If you're not using systemd sockets then I don't think dnscrypt-proxy-resolvconf.service will work properly. You might need to manually add a resolvconf entry for the listening address you configured.

[ghost]

Hi, welwood08.

Okay, I understand. However, after disabling dnscrypt-proxy.socket and dnscrypt-proxy-resolvconf.service (and, of course, update dnscrypt-proxy.toml file with a proper changes etc.) DNSCrypt, after service restart, works normally. I have an impression, that without systemd sockets, internet seems to be... faster. But, it's only my personal feeling - nothing more, nothing less.

So welwood08, are You suggesting to re-enable dnscrypt-proxy-resolvconf.service? I'm refering to: "If you're not using systemd sockets then I don't think dnscrypt-proxy-resolvconf.service will work properly." Do You mean, that *-resolvconf.service will not work properly without systemd sockets?

Thank You very, very much for your time and answers.

Best regards.

[welwood08]

I'm just looking at what it does based on what's shown in the systemd page of the wiki here. It runs systemctl show dnscrypt-proxy.socket to discover the listening address, so if you've manually configured a different listening address it won't know that.

As I said, I don't use the resolvconf program so I don't use dnscrypt-proxy-resolvconf.service either - I was relying on you to know if you use resolvconf. If you rely on resolvconf and don't want to use dnscrypt-proxy.socket then you probably have to set it up yourself. If everything is working fine then you probably aren't using resolvconf.

[ghost]

Hi, welwood08.

Yes, you're right - dnscrypt-proxy-resolvconf file use resolvconf(8) command to check an IP address (and two additional options: -a and -d for lo.dnscrypt-proxy etc.)

I'm also not using resolvconf(8) program and dnscrypt-proxy-resolvconf.service file neither. And yes, everything works okay (so your statement seems to be right, vide "If everything is working fine then you probably aren't using resolvconf.")

Anyway, the question is: should dnscrypt-proxy-resolvconf.service be used when systemd sockets are disabled? (I think, that the most important question, according to the use of dnscrypt-proxy-resolvconf, is: what about lo.dnscrypt-proxy? Because if it's needed, then dnscrypt-proxy-resolvconf should be used, even with systemd sockets disabled etc.)

The best way to get an answer on this issue, is a User who knows what should be done (with dnscrypt-proxy-resolvconf in respect of systemd sockets) and so on.

Thanks, best regards.

[welwood08]

I'm not sure how else to explain it. No, you shouldn't use dnscrypt-proxy-resolvconf.service when dnscrypt-proxy.socket is disabled because dnscrypt-proxy-resolvconf.service explicitly makes use of dnscrypt-proxy.socket.

According to the resolvconf(8) documentation I've read, lo.dnscrypt-proxy is simply a name for the resolvconf record. In this case it is being generated using systemctl show dnscrypt-proxy.socket.

If you disable dnscrypt-proxy.socket and still want to use resolvconf, you should disable dnscrypt-proxy-resolvconf.service and generate your own lo.dnscrypt-proxy record from the listening address you defined in dnscrypt-proxy.toml.

If you don't use resolvconf then none of this matters.

[ghost]

Hello, welwood08.

I think, that we just misunderstand each other. Well, things happen ;- )

Yes, you're right "dnscrypt-proxy-resolvconf.service explicitly makes use of dnscrypt-proxy.socket" but when all options related to systemd sockets - After/Require/Also are commented, then dnscrypt-proxy-resolvconf.service can still be used, even when systemd sockets are disabled. DNSCrypt just works normally etc.

Honestly, everything was just a matter of lo.dnscrypt-proxy and thankfully You explained it very well.

Summarizing: dnscrypt-proxy-resolvconf.service can be disabled[1] along with dnscrypt-proxy.socket (unless somebody "disable dnscrypt-proxy.socket and still want to use resolvconf, (...)", right?)

Thank You, best regards.

[1] And even enabled but with all dnscrypt-proxy.socket related options commented.

[welwood08]

I think, that we just misunderstand each other. Well, things happen ;- )

I had the same concern, but it looks like your concerns are resolved now.

Yes, you're right "dnscrypt-proxy-resolvconf.service explicitly makes use of dnscrypt-proxy.socket" but when all options related to systemd sockets - After/Require/Also are commented, then dnscrypt-proxy-resolvconf.service can still be used, even when systemd sockets are disabled. DNSCrypt just works normally etc.

By "explicitly" I was really referring to the systemctl show dnscrypt-proxy.socket part. I believe this will still return an answer when dnscrypt-proxy.socket is disabled, it just won't necessarily agree with your running configuration. It will appear to work when in fact it is not doing what you would want. Hence my advice to disable it when disabling the sockets and configure resolvconf manually.