Skip to main content ↑ ↓
Topic: Cloudflared no artix wiki (Read 779 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Cloudflared no artix wiki

Hello, i'm trying to use cloudflared (DoH) as i saw from arch wiki it's very convenient and light like a feather  ;) no extra dependencies needed. Problem is cloudflared arch wiki refers to a config file nowhere to be found on a artix linux runit system

/etc/cloudflared/config.yml.

Also i saw it does not have a workable service that can be enabled and no cloudflared-runit package to make it work. My question, is cloudflared supported or will ever be taken into consideration to ever be supported or we are on our own? As a side note I didn't find any useful info on gentoo about cloudflared DNS over HTTPS either. Is cloudflared something that bad that i can't find almost no reference in artix/gentoo wiki's?  :o

Couple of links related
https://wiki.archlinux.org/title/Cloudflared
https://github.com/cloudflare/cloudflared

Thanks!

Re: Cloudflared no artix wiki

Reply #1 –
That's a poor quality Arch wiki article imho.

It references editing a config file (/etc/cloudflared/config.yml) which isn't in the package, though possibly is created on first run?
It references enabling a service (cloudflared.service) which isn't in the package.

The packages content as from here
Quote
Package Contents

    usr/
    usr/bin/
    usr/bin/cloudflared
    usr/share/
    usr/share/man/
    usr/share/man/man1/
    usr/share/man/man1/cloudflared.1.gz
So even on Arch getting it going would require a little effort.

If what you are trying to achieve is just encrypting your DNS queries then I'd recommend stubby or unbound. Both of which have runit service files.
But it's DoT (DNS over TLS) not DoH. Or at least stubby is. Maybe unbound does both ? I can't remember.
stubby is the more lightweight of the two as unbound also caches DNS.
stubby is easier to set up.
I use unbound on my router.

If you want the functionality described on https://github.com/cloudflare/cloudflared , which is more of a tunnel into the cloudflare network (from a skim of it) then you'll need to create the config file yourself I guess, and write your own runit service. Unless someone else steps up.

Re: Cloudflared no artix wiki

Reply #2 –
Yeah i'll take into consideration unbound but saw it creates its own user and group and i'm not very happy when programs do that.

Also another downside about unbound is that and i quote from nextdns short note: "as a recursive resolver, Unbound chases CNAMEs. This may result in unexpected behavior when used in conjunction with a blocking DNS resolver like NextDNS. See github issues"

However the link seems to be broken or moved perhaps that issue being solved. Tnx for the suggestion i'll see what's the better one, unbound or stubby.

Re: Cloudflared no artix wiki

Reply #3 –
Quote from: Surf3r – on
Yeah i'll take into consideration unbound but saw it creates its own user and group and i'm not very happy when programs do that.

That's an generally an advantage not a disadvantage. As far as security is concerned anyway. What makes you unhappy about it ?

Re: Cloudflared no artix wiki

Reply #4 –
Tried stubby too but not only it creates also its user and group but stubby has as dependency unbound probably used for cashing that also needs/creates its own user/group. And both conflict listening by default on port 53.  ??? The default config file seems to be broken and it doesn't resolve any domains.

It's like saying sysv init has as dependency systemd and both do not work by default.

 Having over the counter users and groups that we don't quite know what they truly do could probably ultimately hit a privilege escalation bug or stumble on an exploit that nobody would be curious about. My non expert but average networking related opinion is that these guys don't really know what they are doing with these encrypted dns clients one more buggy than the other. So in conclusion i guess i'll stick with the built in firefox noobish DoH that does not need to create a shit ton of users/groups tweaks tickling and enchantments.

I'm gonna give an example and mention chrony that simply works and encrypt with ease time it retrieves from the servers while these so called resolvers simply put it do not work.

There was a guy here that once stated "If that's the solution i want my problem back" this is exactly where these resolvers fit . So in conclusion i think those clients are not maintained properly, buggy poorly written and they should seriously check out how firefox is doing it and go that route instead.

 >:( 

Re: Cloudflared no artix wiki

Reply #5 –
You are right that stubby as packaged depends on unbound. Or at least it's dependency getdns does.
It remains easier to set up than unbound (imho) and if you just want to use stubby you don't have to also setup unbound.
I imagine getdns is just using some features of libunbound as why reinvent the wheel.
So you don't actually have to run unbound to run stubby.
It's natural that both would use port 53 by default as that's the default port for dns.

It's not that unusual to have to edit the default config to get things working.
From memory stubby has a well commented config file but you need to uncomment some lines to chose a resolver.

I'd disagree that "that these guys don't really know what they are doing with these encrypted dns clients" but it's not a given and you are entitled to your opinion.

New users and groups cannot on their own do anything bad. Only the programs that run under them.
You want to avoid things running as root where possible. Any network facing service running as your own user has access to all your personal files so should also be avoided (Though makes little difference unless your users home has permission 700 or at least 760).
So you can have them all run as user 'nobody', or similar, or give them their own users and groups.

You are also right that if you only want to encrypt your browsing DNS you are better of sticking to the Firefox implementation. It's far simpler.

But to say they are unmaintained is just wrong. The last stubby commit was Aug 19th, the last unbound commit 25 minutes ago.

With the greatest respect the fact that you cannot make something work, out of the box, without some effort and configuration is not proof that they are 'buggy poorly written'. I've used both and they both work well.

Re: Cloudflared no artix wiki

Reply #6 –
I did not manage to make any of dns encryption clients work properly (dnscrypt-proxy, stubby, unbound, cloudflared) and i can say i'm having my firewall setup default deny in/out and had headache to make granular rules for chrony to work. But was piece of cake to make it work with just adding  servers and just few more minimal things without the firewall part.

Even mpv plays with ease encrypted video links, streams or not and it doesn't say it conflicts with whatever port. A port can be used by hundreds if not more connections, i ve never received an error saying my 443 port is used by whatever app and have to create users and groups for that to work. I don't see any reasons why port 53 can't listen and create connections whenever needed like port 443 or other system port  ??? And also i don't get it why port 53 listen to anything at all since we're talking about encrypted traffic that eventually has business with port 443 (DoH) or 853 (DoT) and nothing with the port 53. The way they implement is wrong. Firefox did it right. They just have to take that model and implement it system wide not only for the browser.

There's no need to make a connection via port 443 or 853 and link them locally to port 53 on another layer. Making it that way it's still hybrid and that's why it's buggy. The only use of port 53 should be that to resolve the ip from the DoH domain at best.

Basically dnscrypt-proxy/unbound/stubby/ as i understand it opens port 443 or 853 then redirects that traffic locally (on address 127.0.0.1) via port 53. Why would you send encrypted traffic toward port 53 that is built to have only udp unencrypted traffic. This is my non expert opinion. Redirecting traffic toward lower level network layer means wasted resources for no benefit.

Re: Cloudflared no artix wiki

Reply #7 –
You are misunderstanding the concept of sending to a remote port, any number of say browsers can be sending to remote port 443 at the same time.
And listening on a local port, like a web server on port 80 and port 443. Or DNS on port 53. Only one program at a time on one local port. It's just how it works.

Re: Cloudflared no artix wiki

Reply #8 –
Unbound is using remote port 853 (DoT) use whatever local port in the range 1024-65535 then feeds this to the localhost (127.0.0.1) to the 'remote-local' port 53 that listens and use the sort to speak 'local-local' port again between 1024-65535 same to the local host (127.0.0.1)

                                                                 Listens
Remote             Local                          Local                       Local
  853-------->(1024-65535)------------>53------------>(1024-65535)
(DoT)------->(192.168.x.y)----->(127.0.0.1)-------->(127.0.0.1)

But we need different approach like firefox does

retrieve DoH ip address
53-------->(1024-65535)---->send encrypted dns queries to the pointed ip--->receive encrypted queries responses

The reason current solutions do not properly work is because many other programs (like browsers) listen or make queries via port 53 and a browser if receive info from local address 127.0.0.1 interprets it like an attack end denies traffic as it suppose to do. so in order to make it work you have to downgrade browser security so it accepts traffic thru localhost (127.0.0.1)

So to fix this we need firefox approach and query only domain name where DoH servers can be found. Also to fix that we can edit hosts file so it doesn't need to go outside at all to have that domain ip

DoH should not be very different than how mpv or firefox chrony solve this job sure mpv still relies on classic dns

Re: Cloudflared no artix wiki

Reply #9 –
I almost give up  :)

Quote
programs (like browsers) listen or make queries via port 53
No a browser doesn't listen on port 53. It sends DNS queries to DNS servers that are listening on port 53. Depending on how you have setup the computers DNS that may be a fully remote DNS server on port 53, your routers DNS server on port 53 or localhost on port 53.
And to complicate matters slightly if you set your browser up to do so (if it has such a feature) it will bypass the settings in /etc/resolv.conf and do DoH to whatever you set in the browser.

You don't well understand the concepts of ports yet feel qualified to state that the folks writing programs such as stubby and unbound are doing it wrong.

The way I see it your options are.
  • Create issues on the relevant github's and explain how they are doing it wrong
  • Write your own program that does it properly as you think it should be done
  • Learn how to setup stubby, or similar, properly and use it even though it's suboptimal in your view
  • Just use DoH from the browser

In the short term I'd suggest 4. In the longer term 3 would be worthwhile as you'll probably learn some useful stuff.
gripped out.

 

Re: Cloudflared no artix wiki

Reply #10 –
Yeah definitely worth rising the problem on github. I'm puzzled no current DoH try at the most mimic what firefox does absolutely impeccable.

I'll be wrapping it up by saying that i don't recommend as far as my knowledge go to use any DoH/DoT clients at least not in the way are currently implemented. Choose a VPN or firefox DoH  8)

Also editing resolv.conf and placing localhost where it should be a lan ip it makes things smell as a disaster in the making in terms of security.

Re: Cloudflared no artix wiki

Reply #11 –
Quote from: Surf3r – on
Yeah definitely worth rising the problem on github. I'm puzzled no current DoH try at the most mimic what firefox does absolutely impeccable.
My friend I was being slightly sarcastic. Don't do that.

I'm trying my best to be polite but you simply don't understand the concepts you are raising.
Quote
Also editing resolv.conf and placing localhost where it should be a lan ip it makes things smell as a disaster in the making in terms of security.
To me that sentence proves it.

Just use Firefox DoH and be at peace.

Re: Cloudflared no artix wiki

Reply #12 –
Good luck mate with what you think you're doing down there. All the best stick with stubby that needs unbound that needs who knows what. Looks like i'm not the average dude in this thread after all but anyone can throw an eye  and make its own opinion.

Use stubby and be happy.