[dns-operations] The strange case of fox.com

[Warren Kumari]

On Fri, Mar 4, 2016 at 9:04 PM Dave Warren <davew at hireahit.com> wrote:

> On 2016-03-04 07:05, Rich Goodson wrote:
>
> > Also, who is to say that I can't have a misconfigured domain if I want
> to?
>
> Probably your domain registration agreement would be an appropriate
> place for this language.
>
> >> Sure, some tiny percentage of domains might pack it up and take up a
> >> new hobby, but for any business that wants people to pay their bills,
> >> buy their services, view their ads, or otherwise do the things that
> >> justify the expense of a having an internet presence, they'll hire
> >> someone competent and fix the issue.
> > It appears that they hired someone competent who fixed it some 18
> > months later.
>
> Right, and for those 18 months that someone else had a misconfiguration,
> you and I hear from our customers, waste our customer service resources
> and technical resources dealing with someone else's misconfiguration.
> That's not acceptable. I want to cost-shift the fix back to the party
> that 1) has an incentive to make the site work, and 2) caused the
> problem in the first place.
>
> By placing a very real cost on misconfigurations that is paid by whoever
> set up the misconfigured domain it will become more practical to
> configure things properly than to stick with a "werks fer me!" attitude
> leaving the rest of us to explain to customer after customer why someone
> else's domain doesn't really work.
>
> > Plus, my job title at the time was not, "Person Assigned To Attempt To
> > Make Improvements To The Internet".  My job (or about 15% of my job)
> > was to make sure our customers could resolve DNS.  After multiple days
> > spent imitating Don Quixote on this issue already, my fake delegation
> > "fixed" the problem, at least for my customers.  I had no more time to
> > spend on the issue.
>
> This is true, except for the "no more time to spend on the issue" --
> You'll spend more time on this issue tomorrow, and the day after, and
> the day after that, every time you run into yet another misconfigured
> domain. Also, your fake delegation will fail one day too, when the
> domain switches hosting providers and suddenly your fake delegation is
> wrong while the domain itself is finally correct for once.
>
> And this is the whole point, you, me, and everyone else who runs a
> resolver shouldn't have to jump through hoops to make random domains
> work, or hear whining about how a website works properly on other
> networks but not ours when we're running standards compliant software.
> Rather than spending multiple days on such an issue, it would be quite
> convenient if registries or registrars did this automatically and
> notified their customers of problems, and if it goes unresolved, dropped
> the delegation.
>
>
Indeed.

However, registries and registrars make their money (and they claim very
little) from selling domains. Their view is that a: this is extra work and
costs money and b: results in pissed off customers.
They have no real inventive to do this -- if you want this done, it will
require a fundamental shift in culture / incentives, or a requirement in
registry / registrar requirements. If you would like to make this happen
(which I think would be great), you will have to show up at ICANN meetings
- this requires much sitting on planes (I'm currently in one in Marrakech),
and listening to much navel gazing and pontification...

I'm guessing that it is less annoying / cheaper to just live with the
problem... almost like this was by design :-P

W



> --
> Dave Warren
> http://www.hireahit.com/
> http://ca.linkedin.com/in/davejwarren
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160306/d1f6f9d9/attachment.html>