Re: [cobalt-users] Need DNS Entry EXAMPLES

["Steve Werby" <steve-lists@xxxxxxxxxxxx>]

"John D. Gorena" <Support@xxxxxxxxxxxxxxxxxxx> wrote:
> You can use my domain as an example at www.jmg-enterprises.com.  I get
> the same error here too.  I was using the example so that if found in
> the archives that it would help.

Your intent is good, but without real info. it's hard to troubleshoot and I
didn't want to assume it was the hostname in your email address.  First I
got your name servers from whois (content snipped throughout when not
relevant).  FYI, "whois" may not be installed on your RaQ by default.  It's
not on RaQ1/2/3/4, not sure about 550.  Easy to install though or just use
one of the hundreds of services online that have a whois tool.  I recommend
http://www.samspade.org/ since they have several other related useful tools.

[admin@befriend2 admin]$ whois jmg-enterprises.com
[whois.crsnic.net]

NS1.JMGENTERPRISES.COM       65.169.119.101
NS2.JMGENTERPRISES.COM       65.169.119.102

Side note: both name servers are on the same subnet, which means they're
almost definitely at the same physical location, with the same connection to
the Internet.  If that network is inaccessible all your name servers will be
inaccessible.  I also suspect they are in fact on the same physical machine
(based on experience, not necessarily true though).  If that machine becomes
inaccessible then the domain will have no authoritative name servers which
are accessible.  It's a common misconception that "it doesn't matter because
all  of my domains are on the same server so if the name server isn't
accessible my sites, email, etc. aren't either".  There are several reasons
this doesn't hold true.  I'll address two.  If a machine attempts to email a
user on your server and an authoritative name server can't be reached, the
machine will assume your user is on a host which doesn't actually exist.
The machine may or may not try to redeliver the email later depending on how
it's configured.  Result - lost email.  If it can reach at least one
authoritative name server, but the user can't be reached because the machine
isn't accessible, it will know the user's host does exist, but it will
assume it's temporarily inaccessible and most mail servers are configured to
try again repeatedly for X days at an interval of Y hours (all configurable
of course).  Result - email delivered when machine is reachable.  Same
scenario, but with a search engine spider.  Potential result is that instead
of being requeued future spidering, a site on your server may be removed
from the search engine index the spider is associated with and/or the site
may not be spidered in the next run.  Though DNS in most cases is not very
CPU intensive, having two real name servers (separate physical boxes) not
only gives you the redundancy that is recommended in the relevant RFC (I
don't recall the number offhand), but it spreads the load somewhat randomly
across your authoritative name servers.

Back to the problem at hand.  Now I know your name servers, so I can query
them for DNS records associated with the domain jmg-enterprises.com.  To do
that I use the program "dig".

[admin@befriend2 admin]$ dig @NS1.JMGENTERPRISES.COM jmg-enterprises.com

;; ANSWER SECTION:
jmg-enterprises.com.    10800   IN      A       65.169.119.101

Now I know the IP for the domain.  Next is to see if there is a reverse DNS
record for the IP.  Scroll down to the "dig -x" line below since I take a
little detour first.

;; AUTHORITY SECTION:
jmg-enterprises.com.    10800   IN      NS      ns1.jmgenterprises.com.

This is good, however it should also list ns2.jmgenterprises.com as
authoritative.  You can add that through the Cobalt's GUI DNS section.  It's
what I was referring to previously as an NS record.  As an example of what
it will look like for 2+ name servers I'll list the record for my company
domain.

[admin@befriend2 admin]$ dig @befriend2.dnsservers.us befriend.com

;; AUTHORITY SECTION:
befriend.com.           86400   IN      NS      befriend3.dnsservers.us.
befriend.com.           86400   IN      NS      befriend1.dnsservers.us.
befriend.com.           86400   IN      NS      befriend2.dnsservers.us.

As you can see I have 3 listed name servers.  These match the same 3 listed
name servers (those I set for the domain record at my registrar) in the root
name servers.

;; ADDITIONAL SECTION:
befriend1.dnsservers.us. 86400  IN      A       207.218.238.21
befriend2.dnsservers.us. 86400  IN      A       64.246.20.65
befriend3.dnsservers.us. 86400  IN      A       12.5.50.226

And the three name servers are separate physical machines on separate
networks.

[admin@befriend2 admin]$ dig -x 65.169.119.101

;; QUESTION SECTION:
;101.119.169.65.in-addr.arpa.   IN      PTR

There is no hostname on the RHS of "PTR" so there is no reverse DNS.  This
is your problem.  This needs to be fixed.

;; AUTHORITY SECTION:
169.65.in-addr.arpa.    7200    IN      SOA     ns1-auth.sprintlink.net.
dns-admin.sprint.net. 2002112201 43200 3600 2419200 7200

This tells me that Sprint is authoritative for the reverse DNS for the
65.169/ subnet.  In case that's misleading or incorrect, the first step is
to contact the company who allocated you the IPs.  That should be your data
center, but if you're a reseller of a reseller of..., well, then it may be
someone further upstream.  You'll need to contact them and request a reverse
DNS record for your IP.  While you're at it do it for *all* of your IPs.
It's the right thing to do, they shouldn't have a problem doing it and as
you've found out lack of reverse DNS can cause problems.  And most of the
problems will be very difficult for a novice RaQ admin to detect or
associate with lack of reverse DNS.  Not that I'm saying you're a novice RaQ
admin - don't take it personally.

Here's what dig on the main IP for the box I'm running dig from looks like.

[admin@befriend2 admin]$ dig -x 64.246.20.65

;; ANSWER SECTION:
65.20.246.64.in-addr.arpa. 38400 IN     PTR     befriend2.dnsservers.us.

That means 64.246.20.65 has reverse DNS of befriend2.dnsservers.us.  There
are multiple hosts with A records pointing to that IP, but one and only one
hostname should be associated with each IP for reverse DNS.  In my case, I
chose to name my machines befriend1-befriendN.dnsservers.us.

I realize that DNS is somewhat difficult to understand.  Fortunately most of
us have very basic DNS needs and it's fairly simple to get everything in
order once we understand the proper DNS and the consequences of not
implementing proper DNS.  Hope that helps.

--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/