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

[Edward Lewis]

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.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160201/f772a99d/attachment.bin>