New server DNS issues.

[Petedatalab]

Hello to the forum.

As im new on Plesk (many years on Cpanel) i would like some help on a DNS issue i have:

the server is new installation and i have created nameservers on the domain registrant website to the IPs of the server.

the primary domain is www.example.com and

ns1.example.com ip 1 (dedicated)
ns2.example.com ip 2 (shared)
ns3.example.com ip 3 (shared)

i have created the records in the main dns template adding A and NS and then i created new customers....... good as far.

i have spited all websites to the 2 shared ips.

NOW, the issue.

Google cant "see" none of the websites with nslookup. Sometimes the nslookup works for the .com domains but never for the GR domains.
I cant PING any of the nameserver or the main domain of the server!

Please help on this cause none of my clients websites appear in google anymore........

What can it Be?

 

[Faris Raouf]

i have created the records in the main dns template adding A and NS and then i created new customers....... good as far.

For example.com ONLY, you need three A records in the DNS settings in Plesk for that domain:
ns1.example.com A > ip1
ns2.example.com A > ip2
ns3.example.com A > ip3
(you also need the three NS records as outlined below)


For the main Plesk dns template, you do not need (should not have) any A records relating to example.com
You only need to remove the default NS record and replace it with the three:
ns1.example.com
ns2.example.com
ns3.example.com

Next, check the host/glue records you created at your Registrar have been created correctly. Remember, you don't do this in the DNS section of their control panel (i.e. you do not add A records or anything like that). It is usually in a totally separate section to where you adjust DNS.

Use DNSreport or some other online DNS checking system to see if any obvious problems are shown.

 

[Petedatalab]

Thanks for the reply Faris, but i think this is what i have done. you want access with pm to have a look????

 

[Faris Raouf]

I'd rather not get involved with a third party system. But if you run a dns report and post the results here, the answer may become clear. e.g. www.dnsstuff.com

 

[Petedatalab]

Status Test Name Information
WARN Parent zone provides
NS records
Parent zone does not provide glue for nameservers, which will cause delays in resolving your domain name. The following
nameserver addresses were not provided by the parent 'glue' and had to be looked up individually. This is perfectly acceptable
behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server
of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records
that are in the same TLD as your domain.
ns2.datalab-web.com. | No Glue | TTL=10800
ns3.datalab-web.com. | No Glue | TTL=10800
ns1.datalab-web.com. | No Glue | TTL=10800
PASS Number of
nameservers
At least 2 (RFC2182 section 5 recommends at least 3), but fewer than 8 NS records exist (RFC1912 section 2.8 recommends that you
have no more than 7). This meets the RFC minimum requirements, but is lower than the upper limits that some domain registrars
have on the number of nameservers. A larger number of nameservers reduce the load on each and, since they should be located in
different locations, prevent a single point of failure. The NS Records provided are:
ns2.datalab-web.com. | No Glue | TTL=10800
ns3.datalab-web.com. | No Glue | TTL=10800
ns1.datalab-web.com. | No Glue | TTL=10800
NS
Status Test Name Information
PASS Unique nameserver IPs
All nameserver addresses are unique. The Nameservers provided are nameservers that supply answers for your zone, including those
responsible for your mailservers or nameservers A records. If any are missing a name (No Name Provided), it is because they did not
send an A record when asked for data or were not specifically asked for that data:
PASS All nameservers
respond
All nameservers responded. We were able to get a timely response for NS records from your nameservers, which indicates that they
are running correctly and your zone (domain) is valid. The Nameservers provided are nameservers that supply answers for your zone,
including those responsible for your mailservers or nameservers A records. If any are missing a name (No Name Provided), it is
because they did not send an A record when asked for data or were not specifically asked for that data:
PASS Open DNS servers
Nameservers do not respond to recursive queries. Your DNS servers do not announce that they are open DNS servers (i.e. answering
recursively). Although there is a slight chance that they really are open DNS servers, this is very unlikely. Open DNS servers increase
the chances of cache poisoning, can degrade performance of your DNS, and can cause your DNS servers to be used in an attack, so it
is imperative that externally facing DNS servers do not recursively answer queries.
PASS All nameservers
authoritative
All nameservers answered authoritatively for the zone. This indicates that the zones for this domain are set up correctly on your
nameservers and that we should be able to get good responses to further queries.
PASS NS list matches parent
list
NS list matches list from parent zone. This indicates that your parent nameservers are 'aware' of the correct authoritative
nameservers for your domain. This ensures less overhead for DNS queries, because an extra DNS resolution step is not required.
PASS NS address list matches
parent zone
NS addresses matches list from parent zone. This indicates that your parent nameservers are 'aware' of the correct authoritative
nameservers for your domain. This ensures less overhead for DNS queries, because an extra DNS resolution step is not required.
PASS Stealth nameservers
No stealth nameservers discovered. There is very little chance that there will be 'confusion' when resolving your domain records from
the parent nameservers. There appear to be no 'extra' nameservers listed that the parent might try to refer to and cause DNS
resolution delays.
INFO Stealth nameservers
respond
No stealth nameservers to test. This is simply a note to indicate that you do not have any stealth nameservers to test, which is what
is normally expected of domains.
PASS TCP allowed All nameservers respond to queries via TCP. It is important that your DNS servers respond to both TCP and UDP connections. TCP Port
53 is used for large queries and responses, zone transfers, and is part of the DNSSEC standard.
PASS Nameserver software
version
Responses from nameservers do not appear to be version numbers. While version information is important internally, DNS version
information displayed externally can leave your servers vulnerable to version-specific exploits. Your servers appear to hide this
information and are likely safer.
PASS All nameservers have
identical records All of your nameservers are providing the same list of nameservers.
PASS All nameserver
addresses are public All of your nameserver addresses are public. If there were any private IPs, they would not be reachable, causing DNS delays.
SOA
Status Test Name Information
FAIL SOA record check No nameservers provided an SOA record for the zone. You should configure your nameservers to have a master slave relationship.
The update of the zone information to the slave nameservers should be handled through the SOA record.
MX
Status Test Name Information
FAIL MX records check No MX records exist within the zone. This is legal, but if you want to receive E-mail on this domain, you should have MX record(s). The
program can't continue in a case like this, so we are assuming you don't receive mail on this domain.
WWW
Status Test Name Information
INFO WWW record check Domain has no WWW hostname record.
INFO Domain record The domain literal has no address records.
DNSSEC
Status Test Name Information
INFO DNSSEC records check
No DNSSEC records created for this zone. Many major institutions and government agencies are planning to move to DNSSEC. You
may want to consider an implementation plan for the zone specified. If you implemented DNSSEC for your zone we would be able to
run further tests.
SPF
Status Test Name Information
INFO SPF record check
This domain does not have an SPF record, nor an SPF formatted TXT record. SPF stands for Sender Policy Framework and is intended
as an anti-forgery email solution (See RFC4408). Many spammers have adopted this mechanism and SPF records alone may not be

 

[Faris Raouf]

FAIL SOA record check No nameservers provided an SOA record for the zone. You should configure your nameservers to have a master slave relationship.

FAIL MX records check No MX records exist within the zone. This is legal, but if you want to receive E-mail on this domain, you should have MX record(s). The program can't continue in a case like this, so we are assuming you don't receive mail on this domain.

INFO WWW record check Domain has no WWW hostname record.

There is also no Glue. That may be significant depending on which domain you actually tested against.

Otherwise, the implication is that the server that your ns records point to (hopefully your Plesk box) has no DNS records for the domain you checked. The IP address are normally shown in the report.

Check the domain isn't suspended, that DNS is set to Master mode, and that records are written to disk. Check /var/named/chroot/var (11.5) and something like /var/named/run-root/var/ in older versions (I forget the exact path).

Also, I note that datalab-web.com is suspended at the registrar. Could this be the root of your problems?

 

[runtim23]

Has anyone fixed this?
I am also using dnsstuff.com and can't clear up these warnings:

Parent zone does not provide glue for nameservers, which will cause delays in resolving your domain name. The following nameserver addresses were not provided by the parent 'glue' and had to be looked up individually.

One or more stealth nameservers discovered. This means that one or more nameservers are not listed at both the parent and authoritative nameservers. This can be confusing and can cause delays or other hard to diagnose inconsistencies.

One or more SOA fields are outside recommended ranges. Values that are out of specifications could cause delays in record updates or unnecessary network traffic.

What I don't understand is, I have the same templates across servers, records set up the same way, and DO NOT receive these warnings on those servers, just this one. Is this something at the registrar? or hosting provider's network? or a plesk thing? I've tried several different combinations with no change in results.
I have researched a lot, but some of these are still not clear to me.

 

[runtim23]

Has anyone fixed this?
I am also using dnsstuff.com and can't clear up these warnings:

Parent zone does not provide glue for nameservers, which will cause delays in resolving your domain name. The following nameserver addresses were not provided by the parent 'glue' and had to be looked up individually.

One or more stealth nameservers discovered. This means that one or more nameservers are not listed at both the parent and authoritative nameservers. This can be confusing and can cause delays or other hard to diagnose inconsistencies.

One or more SOA fields are outside recommended ranges. Values that are out of specifications could cause delays in record updates or unnecessary network traffic.

What I don't understand is, I have the same templates across servers, records set up the same way, and DO NOT receive these warnings on those servers, just this one. Is this something at the registrar? or hosting provider's network? or a plesk thing? I've tried several different combinations with no change in results.
I have researched a lot, but some of these are still not clear to me.

 

[runtim23]

Fixed the first two. Turns out parent name server can't have a different TLD.
As far as the SOA serial # warning, why the hit? I have checked the "Use serial number format recommended by IETF" but still no fix.

 

[Faris Raouf]

The parent nameserver can have a different TLD to the domain. It is done all the time. Our nameservers, or example. are .org but we use them with all sorts of domains. It is still a "pass" and not an issue in any way. Of course having nameservers for each domain type is supposedly "better" but I don't see the point for a femtosecond difference.

The third issue is nothing to do with serial numbers but rather the value of one of the TTL, expire, etc etc values. It will tell you exactly which item and what the problem it is just underneath the error message.

 

[runtim23]

Thanks Faris,
I was assigned the task to clear as many warnings as possible, and the only way I could for this particular one, was to use the same TLD.
The 3rd issue is mname. Not sure why. To make it more frustrating, it doesn't appear every day. I know the registrar was down last week, so this
may have had something to do with it.

I agree, ease of management at the cost of a couple warnings, might not be so critical, but we have a lot of accounts, and some external networks are very picky with dns records, which will determine if they will communicate with our servers. This can cause parties to not reach other parties. Adjusting some seemingly unrelated records have cleared up communication in the past, such as removing stealth name servers. This is why we are trying to clear up as many warnings as possible in an attempt to simplify the network, though this may complicate internal administration across our many domains and servers.

Thank you for advice though. I do appreciate it.