matt at netfire.net
Wed Mar 22 13:25:51 UTC 2023
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.harris at netfire.net
On Wed, Mar 22, 2023 at 3:36 AM Saku Ytti <saku at ytti.fi> wrote:
> Am I correct to understand that 18.104.22.168 only does support via community
> They had just enough interest in the service to collect user data to
> monetise, but 0 interest in trying to figure out how to detect and
> solve problems?
> Why not build a web form where they ask you to explain what is not
> working, in terms of automatically testable. Like no A record for X.
> Then after you submit this form, they test against all 22.214.171.124 and
> some 126.96.36.199 and 188.8.131.52 and if they find a difference in behaviour,
> the ticket is accepted and sent to someone who understands DNS? If
> there is no difference in behaviour, direct people to community
> This trivial, cheap and fast to produce support channel would ensure
> virtually 0 trash support cases, so you wouldn't even have to hire
> people to support your data collection enterprise.
> Very obviously they selfishly had no interest in ensuring 184.108.40.206
> actually works, as long as they are getting the data. I do not know
> how to characterise this as anything but unethical.
> If you can't due to resources or competence support DNS, do not offer one.
When something is provided at no cost, I don't see how it can be unethical
unless they are explicitly lying about the ways in which they use the data
Ultimately, you're asking them to provide a costly service (support for
end-users, the vast majority of whom will not ask informed, intelligent
questions like the members of this list would be able to, but would still
demand the same level of support) on top of a service they are already
providing at no cost. That's both unrealistic and unnecessary. There's an
exceedingly simple solution, here, after all: if you don't like their
service or it isn't working for you as an end-user, don't use it.
On the same token as network operators, it might be nice if
cloudflare's admins were accessible to address potential issues that may
actually be related to legitimate network misconfigurations or other
problems on their end that result in issues resolving some folks' resources
- and I suspect they may in fact be via this list or other similar ones, or
other open resources that are widely available to folks who are in the
know. That said, with regards to any specific case, we don't know whose end
the issue lies on. It's possible that the folks managing the Cypress
government resources have taken steps actively, or passively misconfigured,
their systems in such a way that causes the root problem that you're
pointing out. As I administer neither of the related networks, I can't
speak to this, but I think it's just as likely based on a coin flip that
they are responsible for the issue as it is that cloudflare is responsible
for the issue. On top of that, I suspect getting technology help from a
random government entity may be far less fruitful than even a public forum
Good luck getting a resolution to your resolution.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG