While this is interesting for experimentation I think we shouldn't add it after all... Closing this but leaving the branch in case we ever want to have it for yet unknown reasons.

On a quick glance this doesn't seem bad, except it's missing the extraFeatures override, without which the module won't load AFAIK.

BTW, why do you think it would be better not to add the support? (with default off) Trying not to encourage this protocol? I'm not really happy with DoH myself, so in the end I hesitated and haven't added a similar change so far.

I do not see much point in DoH after looking at it more closely. The point I dislike most is probably the whole protocol stack that is involved and doesn't make it any easier to implement / debug / run / …. From a resolver perspective DoT provides (probably) all the benefits with less stuff in between. For consumers it is probably fine (if they are happy with HTTP2 & json).

I guess I am also influenced by the upstreams (so probably at least partially you) documentation discouraging it.

If things change around DoH we could still easily add the option. If someone needs it today they might just add that one socket unit themselves.

I think adding the webmgmt socket option to the module would probably be of more value.

OK, I see. I had been thinking about adding a generic config scheme where you can uniformly use any kind (ATM there's dns, dot, doh and webmgmt), though maybe it would be nice to have some similarity with nixos configs for other servers.

Nitpick: DoH as standardized uses old DNS wire-format inside, and kresd does not support this JSON (currently).

IIRC the only protocol "benefit" significantly discussed now is that DoH is more difficult to block... though there's a strife on whether that's actually good, and you'd get much of that effect by serving DoT on port 443 (simple config change). A practical benefit is that some clients only support DoH, notably Firefox and Chrom*... which is basically the main reason there's a support in kresd, to decrease the push to use one of a handful of huge DNS providers. (Though I'm very much in favor of system-wide and not per-app DNS.)