[conspire] What happens when 75% of your domain's nameservers refuse to do TCP

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 2 Mar 2016 13:07:03 -0800
From: Rick Moen <rick at linuxmafia.com>
To: Edie Stern
Cc: Mark Olson, Joe Siclari
Subject: Re: Help me Obi-Wan!
Organization: If you lived here, you'd be $HOME already.

Quoting Edie Stern:

> We will look into both of your recommendations.  Ok with you if I
> forward your note to x7?

No problem -- and there's a third result below.  I figured you'd need to
send my comments to them, so I _tried_ to make it so you could.
(Honestly, I should have written it more concisely and with less of a
tutorial bent.)

Here's an observation that will _not_ be pragmatically useful to you,
but might be interesting for its own sake:  This is a rare case where
hobbyists routinely do a better job than the pros do.

I started doing Unix computing back in the middle 1980s when I was just
a peon staff accountant without any IT background -- because nobody told
me I couldn't.  I quickly learned how to do key Internet services
including DNS _right_, at the same time many computer hobbyist friends
did.  And knowing how to do it right, when I check how alleged
professionals are doing it, I am often appalled at how badly they muff
it.

This is why my own domains get their primary DNS nameservice from my own
nameserver in my garage, and secondary nameservice from three of my
friends.  They do secondary DNS for my domains, I do secondary for
theirs, and all of us get significantly better DNS than paid
'professional' DNS typically provides.

But, wait, news flash.  (Back to pragmatic matters.)  I just noticed
a huge glitch in x7hosting's DNS, one that's worse than the other two.
If you open a trouble ticket with them, you should include this.


RESULT #3:  Three out of x7hosting's four nameservers fail to support
TCP tranport(!).  Only nameserver #3 responds.

I'll explain this below, but basically this is what happens if you
repeat my very first basic query with the '+tcp' flag added:

  $ dig  -t soa  fanac.org @NS1.X7HOSTING.COM +short +tcp

  ; <<>> DiG 9.8.3-P1 <<>> -t soa fanac.org @NS1.X7HOSTING.COM +short +tcp
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  $ dig  -t soa  fanac.org @NS2.X7HOSTING.COM +short +tcp

  ; <<>> DiG 9.8.3-P1 <<>> -t soa fanac.org @NS2.X7HOSTING.COM +short +tcp
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached

  $ dig  -t soa  fanac.org @NS3.X7HOSTING.COM +short +tcp
  ns1.carrierzone.com. admin.carrierzone.com. 1007 86403 3600 3600000 86400

  $ dig  -t soa  fanac.org @NS4.X7HOSTING.COM +short +tcp
  ;; Connection to 64.49.104.96#53(64.49.104.96) for fanac.org failed:
  connection refused.
  $  
 
Explanation:  DNS traffic moves across TCP/IP-type networking.  The
datagrams (basic transfer units) in TCP/IP that carry most traffic are
structured as one of two types:  UDP or TCP.  

Most DNS traffic moves across the Internet as UDP-type datagrams
(because it is faster and less complex), _but_ some queries must instead
be transacted using TCP-type datagrams because of UDP limitations.
Specifically, if the size of the query ends up exceeding 512 bytes, or
the answer size exceeds 512 bytes, TCP _must_ be used.  _Therefore_, it
is absolutely necessary that DNS nameservers be able and willing to
respond using TCP-type answers.

The dig tool's '+tcp' flag means 'Use TCP-type querying, rather than the
default UDP-type otherwise used for most DNS.'  This also forces the
response to likewise be over TCP rather than UDP.  And the point is:
75% of x7servers do not comply, acting as if they are unreachable.

Often this problem is the provider shooting itself in the foot with a
badly configured firewall that erroneously permits only UDP-type DNS
traffic through, but not also TCP-type -- a classic bonehead error
frequently committed with firewalls.

Again, I consider this a more serious problem than the other two I
mentioned yesterday.


> Thanks so much for the detailed look and analysis.   Like I said, you
> rock!   Do you have any recommendations for other hosting companies?

Here's an odd thing:  I've been doing this stuff since the 1980s, and
these days even do senior system administrator work for a living
(stopped being a staff accountant in the late 1980s), and have done this
work as internal operations for big companies -- but I have really no
experience at all with retail hosting companies.  Because I've never
used one.

I can suggest this:  If you wish to see how well a particular domain's
DNS so that you might consider switching to that domain's DNS
provider(s), you can run this automated report on the domain's DNS:

'DNSreport' on http://www.dnsstuff.com/tools 

Direct links to two example 'DNSreport' reports:

http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=fanac.org
http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=linuxmafia.com

Like many automated reports, this one produces some percentage of
erroneously reported information.  Unfortunately, you need to understand
DNS to spot the bits that are slightly wrong (or unimportant).  But it's
a good starting point.

Note:  The operator of http://www.dnsstuff.com/ wants people to start
paying for use of the tool after several uses.  To reset the count of
how many times you've used it, go into your Web browser's preferences
and clear stored cookies and other Web site data for domain 
dnsstuff.com .

Maybe you can find fannish domains that 'DNSreport' claims are being
served competently, and take fanac.org to one of those domains' DNS
providers.

Personally, I think it would make excellent sense for fannish
organisations to just start running DNS nameservers and use them to help
do each others' DNS -- and stop outsourcing it.  The task is not actually
difficult, and all you need is a terrible obsolete computer that's 24x7
on the Internet on a static IP address.  Mine is a 2001 Pentium III junk
machine in my garage, for example.

----- End forwarded message -----