To be clear these are:

unbound-ib01.fedoraproject.org
unbound-cc-rdu01.fedoraproject.org
unbound-osuosl01.fedoraproject.org

I am hearing the first time we offer some open resolvers to public. Even Stubby package has not listed anything from fedora domain in offered configuration. Does a community actually know about it? Does it have any more user friendly names? Is it documented somewhere in public article?

Unbound package does not offer any hint Fedora offers DoT servers. systemd also contains just Cloudflare, Quad9 and Google servers.

Are those servers used by dnssec-trigger only, @pwouters ?

Would it make sense to actually propagate their use as a DoT provider? Do we provide some kind of privacy statement?

They all seem to be offline now. If we want to keep them running, we should use them in more packages than dnssec-trigger. Especially as dnssec-trigger could actually use Google, Quad9 or Cloudflare servers as well. Which are I assume better monitored.

If they are part of fedora infrastructure targeted to community in general, I would vote for CentOS Stream 9 if possible.

Found the only reference to them here:
https://src.fedoraproject.org/rpms/dnssec-trigger/blob/rawhide/f/dnssec-trigger-workstation.conf#_79

If that is true, they never run as DNS over TLS fallback, which might be actually more useful today. They offer just DNSSEC enabled recursive server AFAIK. Were any TLS encryption ever enabled to them?

So, I set these up, but it was more than 11 years ago now, so my memory could be faulty.

They only listen on port 80 and 443. I guess ssl on port 443 only.
They should be up, do you not get any answers from them? You are using port 443 and tls right?

(Most of the logs from them are https scanners that hit that port and get an error from unbound in negotiation).

I/m open to moving them to rhel9 and/or reconfiguring them. But if they are also not too useful, we could just retire them.

I have tried from fedorapeople.org server to try also IPv6. They seem dead now. Not doing their work needed for dnssec-trigger.

domain port is closed both on udp and tcp.

$ for NS in {unbound-ib01,unbound-cc-rdu01,unbound-osuosl01}.fedoraproject.org; do dig -4 +dnssec @$NS; done 

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> -4 +dnssec @unbound-ib01.fedoraproject.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> -4 +dnssec @unbound-cc-rdu01.fedoraproject.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> -4 +dnssec @unbound-osuosl01.fedoraproject.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Likewise DoT nor DoH is provided, according to dig tests

$  for NS in {unbound-ib01,unbound-cc-rdu01,unbound-osuosl01}.fedoraproject.org; do dig +https -4 +dnssec @$NS; dig +tls -4 +dnssec @$NS; done
;; Connection to 152.19.134.150#443(152.19.134.150) for . failed: ALPN for HTTP/2 failed.
;; Connection to 152.19.134.150#443(152.19.134.150) for . failed: ALPN for HTTP/2 failed.
;; Connection to 152.19.134.150#443(152.19.134.150) for . failed: ALPN for HTTP/2 failed.
;; Connection to 152.19.134.150#853(152.19.134.150) for . failed: host unreachable.
;; Connection to 152.19.134.150#853(152.19.134.150) for . failed: host unreachable.
;; Connection to 152.19.134.150#853(152.19.134.150) for . failed: host unreachable.
;; Connection to 8.43.85.74#443(8.43.85.74) for . failed: ALPN for HTTP/2 failed.
;; Connection to 8.43.85.74#443(8.43.85.74) for . failed: ALPN for HTTP/2 failed.
;; Connection to 8.43.85.74#443(8.43.85.74) for . failed: ALPN for HTTP/2 failed.
;; Connection to 8.43.85.74#853(8.43.85.74) for . failed: host unreachable.
;; Connection to 8.43.85.74#853(8.43.85.74) for . failed: host unreachable.
;; Connection to 8.43.85.74#853(8.43.85.74) for . failed: host unreachable.
;; Connection to 140.211.169.201#443(140.211.169.201) for . failed: ALPN for HTTP/2 failed.
;; Connection to 140.211.169.201#443(140.211.169.201) for . failed: ALPN for HTTP/2 failed.
;; Connection to 140.211.169.201#443(140.211.169.201) for . failed: ALPN for HTTP/2 failed.
;; Connection to 140.211.169.201#853(140.211.169.201) for . failed: host unreachable.
;; Connection to 140.211.169.201#853(140.211.169.201) for . failed: host unreachable.
;; Connection to 140.211.169.201#853(140.211.169.201) for . failed: host unreachable.

Either that functionality should be restored fast or we should change dnssec-trigger to use different server in default configuration. I am not sure what were 443 ports used for. Would Paul @pwouters know?

Oh, I have not met a network recently that does not DNSSEC working on it, so haven't tested this feature for some time.

At least SSL part seems to be working:
for NS in {unbound-ib01,unbound-cc-rdu01,unbound-osuosl01}.fedoraproject.org; do dig +tls -p 443 -4 +dnssec @$NS; done

But it should have had open also http and domain port AFAIK. At least according to https://pagure.io/fedora-infra/ansible/blob/main/f/roles/unbound/files/unbound.conf#_47

It seems to me we should provide a way to use DoT over port 853, so it could run on common providers of DNS over TLS.

Hi @pemensik I may be misunderstanding your request for restored functionality, but port 53 and 853 has been closed to the world since at least 2014. They have only allowed port 80 and 443 for a long time and I think only 443 after some other time.

My faded memory was that the original intent was that these were last resort servers for some package sets and not for general every day use.

The only host which could get to port 53 was the nagios host, and I believe we got a warning from a site at one point when we had the firewall off because open DNS relays are not allowed.

If the service is no longer well known in Fedora configs, it might be best to transition the last configs away and stop the service.

@smooge Whole point of those servers were to provide open DNS relay for networks, which do not provide DNSSEC enabled servers themselves. I think majority of networks does that these days, with just few exceptions. That may be a reason, why noone complained so far. I admit this package is likely not very popular. Even though it is hidden in port 443 SSL traffic, it is still open relay. That was its purpose from the beginning. It should have been used only on networks not providing decent resolver itself.

Though I were not the one requesting and configuring those servers back then. Maybe I miss important details.

It never had port 853 open. The version on which it runs now does not use port 853 by default. dnssec-trigger The service is still required by the dnssec-trigger package even in latest rawhide. But I am not sure how to do automatic testing to ensures it actually works.

Upstream provides host zus.nlnetlabs.nl in their package. I guess we could stop providing our Fedora one and fallback to their servers again, unless we had different agreement. They do not listen on UDP, but provide the service on domain tcp port, http port and https port. Providing DNS over TCP only should be safe in our case too.

Do we have any statistics of traffic to these hosts? Can we at least guess if it is used rarely or never at all?

These servers were added to allow fedora hotspot detection and dnssec to work toegether if the local network mucked up dnssec. It was part of dnssec-trigger's configuration since at the time we didnt want to point to other people's DNS servers.

At this point, 1.1.1.1, 8.8.8.8, 9.9.9.9 et all support DNSSEC. Additionally, there are now DoH and DoT transports that make DNSSEC reliable as well.

I see no further reason to run these servers anymore. Especially because dnssec-trigger is also a solution that didn't gain traction and systemd-resolved doesn't use it or these fedora DNS servers either.

Just shut them down.

ok, Thanks.

And they are retired. Thanks.

Prepared updates to Fedora packages, built updates already, still pending: https://src.fedoraproject.org/rpms/dnssec-trigger/pull-request/7

But I have found RHEL8 package would be more difficult to update. It references Fedora servers only in default configuration. RHEL7 package references still reference original upstream server, which does not work as well.

:(

Does that mean we should bring them back up for now?
Or will them being missing cause any particular issues for rhel8 users?

I think we can wait for some time, whether anyone would actually notice. I guess support article might solve it enough. It requires just configuration change on both RHEL7 and RHEL8 afaik.

I am afraid we have absolutely no idea whether and how much it were used. Maybe it is safe, maybe it is not. Maybe at least one still kept up for few months would be nice, if possible. It should be tested how much it would work with only one of servers available. Maybe creating just a bug explaining the situation and providing links to required configuration changes would be enough.

ok. Lets wait and see if there's any notice.

I can bring one (or all of them) back if needed, but I would prefer not to. I saved their disk/virt xml, so I just need to redefine them and start them and then re-add them to ansible.

So, let us know if anyone complains and we need to bring them back.

Thank you.