[dns-operations] Why utopian ideals die on the shores of operations ... Re: Typo in fox.com and an Akamai squatter

[Mark Andrews]

In message <D2D5125E.13213%edward.lewis at icann.org>, Edward Lewis writes:
> 
> On 2/1/16, 12:45, "dns-operations on behalf of Paul Hoffman"
> <dns-operations-bounces at dns-oarc.net on behalf of phoffman at proper.com>
> wrote:
> 
> >On 1 Feb 2016, at 8:08, Edward Lewis wrote:
> 
> >Sure there is. A hoster can scan the NS records for all their clients
> >and note when one of those records isn't pointing to the hoster's name
> >servers. This would be a service that I bet some customers (such as
> >Fox?) would very much like.
> 
> Unless they aren't supposed to.  There are many factors in operating a DNS
> hosting service that may not be obvious.
> 
> In my experience, smart, well-heeled and well-funded customers would not
> rely on a single provider.  My old frim decided to recommend this to
> customers so we could build in a technological monoculture and leave
> diversity to using someone else.  For that reason, inspecting the NS
> records that don't match would be raising false alarms.  In the case that
> I recall, the issue was the transpositioning of some letters inside a
> label, not the TLD, like "s/the/teh/".  Sure, the name didn't match the
> hoster, but there's no telling if it is the name of a host of another
> operator.
> 
> >That should not prevent the hoster from not only alerting their
> >customer, but suggesting that the customer use a better registrar (for
> >some probably-slated definition of "better", like "registrars with whom
> >we have a business relationship").
> 
> In my case, one hand of the business was concerned with being neutral to
> the registrars.  So, that's out.
> 
> >In the current case, Akamai could make an arrangement with some
> >registrars (certainly with one the size and reputation of MarkMonitor)
> >to have a high-urgency communication channel when there is something
> >wrong happening with their mutual customers.
> 
> Generally that's so.  Once you know there's a problem.  Operators did talk
> to each other, but come to think of it, never with the registrars.
> 
> >> Only the domain name owner is in position to check this.
> >
> >This entire list was able to check this. :-)
> 
> Post-haste.
> 
> It's like something I heard in the search for MH370 - why is it we have
> spy satellites that can read a newspaper on a porch but they can't find a
> Boeing 777?  It's easy once you spot it to see it.
> 
> >Note that the registrar is also able to check this. Pseudocode:
> >for each customer:
> >   Collect all NS records
> >   for each NS record in set:
> >     Check for name that is not run by the same admin as the rest
> >   if state == fishy:
> >     Check if we have talked to the customer about this before
> >     if first_time or not dont_bug_us_about_fishiness:
> >       Escalate
> 
> A long time ago a quote was attributed to Vijay Gill regarding service
> calls to AOL.  It went something like this: a single call blows the profit
> margin for the year, a second (or an escalation) blows the profit for the
> lifetime of the account.  (In 2014 I asked him if he could recall where
> the quote might be archived, he did not.)  The point is that operators are
> not likely to go out "looking for trouble" for a few reasons.
> 
> One, most broken situations don't matter.  I.e., they belong to unused
> domain names.  Two, if you try to contact customers, you'll be waiting on
> the phone a lot.  Even active customers are reluctant to respond, much
> less to those who've forgotten they are paying for the service.
> 
> Setting this up is that at a DNS hoster, there's no prerequisite for a
> domain name to have any correlation to the WhoIs.  (Recall SAC 057 - when
> certs were issued for .CORP, etc?  One can configure DNS hosters with
> names the same way.  It would be a bad idea to ban that, it would make
> transitioning hosters a delicate dance as an example.)
> 
> There are a couple of factors against tighter coupling.
> 
> 1) Economics.  The businesses involved are competing on price already and
> there's known churn rate.  When you know your customers will only be
> around a few years regardless of what you do, it's unwise, financially, to
> invest in trying to keep them.
> 
> 2) Technology.  The Internet is vast.  The protocols are not easily
> manageable.  It's hard enough to find a symptom, it's impossible to make a
> diagnosis relying solely on in-band information.
> 
> 3) Scale.  One major factor in the success of DNS is it's looseness.  I
> bet, and this is a bet, if the DNS was as tightly coupled as many other
> systems of the era in which it emerged for the sake of name management, we
> wouldn't working on the DNS today.  I.e., tightening the system now could
> crimp the scale, encouraging consolidation into a smaller set of
> operators.  (This is totally opinion.)

It really depends on how you tighten it.

Would checking that NS records matched 5 minutes after the have
been updated in the parent zone actually slow anything down? No.
Would it catch errors in a reasonably timely manner? Yes.  Would
it make the DNS a more reliable system overall? Yes.

Would checking the NS records every month help? Yes.

Would checking that A and AAA glue records matched 5 minutes after
the have been updated in the registry actually slow anything down?
No.  Would it catch errors in a reasonably timely manner? Yes.  Would
it make the DNS a more reliable system overall? Yes.

Would checking the A and AAAA glue records every month help? Yes.

Is it really that expensive to do? No.  Is it hard to send email
to the registered contact addresses? No.  Will some of them bounce?
Yes.  Will most registrants be happy that their errors have been
caught? Yes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org