dnsreport's WARNs and FAILs?

neorder

Verified User
Joined
Oct 1, 2003
Messages
392
i did a dnsreport to my DA server, and got these warnings and errors when i search my domain at dnsreport, how can i clear them all one by one? i have done reverse DNS, what's more i can do?

thanks in advance.

Glue at parent nameservers WARN

Missing (stealth) nameservers FAIL

Missing nameservers 2 FAIL

All NS IPs public FAIL

Stealth NS record leakage FAIL

Nameservers on separate class C's WARN

NS TTL discrepancy WARN

SOA MNAME Check WARN

All MX IPs public FAIL

Multiple MX records WARN

Mail server host name in greeting WARN

Acceptance of domain literals WARN

All WWW IPs public FAIL
 
Can't tell until you give us the IP#s and names of your nameservers, and the name of the domain you're tracing.

Jeff
 
If you don't give out the details publicly, no one else is being helped but you. That's not really fair to the community.

Since you're publishing your DNS for the entire world to see (or at least you're trying to) what do you think you're hiding?

Anyway ...

You can ignore the "Glue at Parent Nameservers" warning; if you read the details you'll see this info:

<snip>
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.
</snip>

The only way you can avoid this is if you use nameservers in the .info top level domain.

After that I get "Nameservers Fail" and can't continue.

Doing dig on both the nameservers (sorry I'd like to show the answers; it would make things a lot clearer, but you want to hide your domain name and IP#s) shows that neither have been registered with the registrar that registered their domain name.

So until that's done you can't use them.

I can't help anymore unless (a) you get those nameservers (the ones begining with ns and ending in .net) registered, and are willing to expose the information here.

It's a lot of work to trace this for you; if I'm going to do it here in the forums at no charge to anyone I'd like it to remain in the archives for everyone to learn from.

Or you could hire a DNS expert to get it taken care of for you. Men & Mice charge about $250/hour if I recall correctly; we charge significantly less.

Jeff
 
Just check you have done everything correctly... go through it again. More than likely many of them errors are simply misconfiguration, the glue for example is simple due to not having A records for the nameservers... lots of simple little initial setup things, the warns you are usually ok to leave, fails you will need fixed.

Chris
 
With all respect, Chris, the lack of glue is due to exactly what DNS reports says it is; it's due to the fact that the top level domains are different.

It's also not a real issue, again, as DNS reports says.

The nameservers failed when I did the check.

I've found the error, now, with a bit more time spent.

The NS records are misconfigured. Without being allowed to give out the domain name it's rather hard to explain, but let me explain this way:

Given his domain as hisdomain.info and his nameservers as ns1.nameserver.net and ns2.nameserver.net...

When I do a dig on the root nameserver for his domain I get no answer, but I get authority records showing tld1.ultradns.net and tld2.ultradns.net, which are correct for the .info tld. Then when I do a dig on tld1.ultradns.net I get no answer, but I get authority records showing ns1.nameserver.net and ns2.nameserver.net.

When I do a dig on nsI.nameserver.net I get what I presume is the correct IP#, but when I do a dig on ns2.nameserver.net I get no answer at all; "Connection timed out; no servers could be reached".

However, the dig on ns1.nameserver.net, though it shows the correct A record, shows improper authority; it shows ns2.nameserver.net (the one that can't be reached) correctly, but it shows ns1 (the one that can be reached) as ns1.nameserer.net.hisdomain.info

So he doesn't have correct NS records and he's got a bad nameserver.

Both of these issues need to be fixed before we can go further.

Jeff
 
jlasman said:
the lack of glue is due to exactly what DNS reports says it is; it's due to the fact that the top level domains are different.

WARNING. The parent servers (I checked with ns7.nic.uk.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records

I have fixed every glue problem I have seen previously, by creating A records for the nameservers the domain is using, of course the nameservers have to be setup correctly elsewhere, and that is simply the glue problem.

Chris
 
ProWebUK said:
I have fixed every glue problem I have seen previously, by creating A records for the nameservers the domain is using, of course the nameservers have to be setup correctly elsewhere, and that is simply the glue problem.
There are A records for both ns1.nameserver.net and for ns2.nameserver.net; that was the first thing I checked.

Of course you've just proved my point, that it's pretty hopeless to try to help someone when he requests his details not be given out.

I was making false assumptions before he PM'd me with his details. It's easy to see how that could happen.

Jeff
 
hi, friend, i was advised by my other friend that not to give out my host name and ip cause it may attrack attack. since i'm relatively new to server admin, i'm quite cautious on everything.

here is the details:

apple.asia-secure.net 65.75.183.160
ns1.apple.asia-secure.net 65.75.183.161
ns2.apple.asia-secure.net 65.75.183.162

you can use wangxin.info to test. i've done DNS setting and reverse DNS. not sure what caused so many other warnings and fails.

thanks.
 
Thanks, neorder. There's nothing as public as DNS, and we can't really help if we don't have everything available to us.

That said, I've already said what needs to be fixed.

If you need me to rewrite it with the correct info that will have to wait until Saturday evening PDT at the earliest, as I'm just too busy between now and then.

Jeff
 
btw, i did double check with enom, and my ns1/ns2.apple.asia-secure.net are registered with my disired ip correctly.

i've also hosted a few website at my server, no problem yet...yesterday i was unable to send email to hotmail due to no rdns, but rdns was setup by datacenter on yesterday too.

yeah...what else can i do? i also added these ips to DA's IP manegement, althrough the status of these ip doesnt' show "NS" but "free", DA support says that's correct...?

thanks in advance.
 
jlasman said:
Thanks, neorder. There's nothing as public as DNS, and we can't really help if we don't have everything available to us.

That said, I've already said what needs to be fixed.

If you need me to rewrite it with the correct info that will have to wait until Saturday evening PDT at the earliest, as I'm just too busy between now and then.

Jeff

thank you, i will read your post more carefully. :)
 
hi, i heard some ISPs won't recieve email unless i've A record for my DNS, my dns domain is hosted at enom, so yesterday i login to enom and simply created 2 A record for "ns1.apple" and "ns2.apple"

today i use a .net domain to check, want4me.net, the results looked better. i've 9 warns and fails

Glue at parent nameservers WARN
Nameservers on separate class C's WARN
All NS IPs public FAIL
NS TTL discrepancy WARN
All MX IPs public FAIL
Multiple MX records WARN
Mail server host name in greeting WARN
Acceptance of domain literals WARN
All WWW IPs public FAIL

after that, i checked your domain, jlasman's nobaloney.net, i got these Warns only:

NS TTL discrepancy
SOA MINIMUM TTL value
Multiple MX records
Mail server host name in greeting
Acceptance of domain literals

so i believe some of the warns are normal, i cancelled those warns which you also have from my fails and warns list, and left these 5:

1.Glue at parent nameservers WARN
2.Nameservers on separate class C's WARN
3.All NS IPs public FAIL
4.All MX IPs public FAIL
5.All WWW IPs public FAIL

for the 1st Warn, why i still receiving it since i also use a .net name to check? wait4me.net

for the 2nd Warn, i think it's because that asia-secure.net is hosted at enom, and they use
dns1.name-services.com
dns2.name-services.com
dns3.name-services.com
dns4.name-services.com
dns5.name-services.com
so can it be ignored?

for the 3.4.5 fail, why my IPs are not public, i don't get it...

thanks for any help.



:)
 
I just did a report at dnsreport.com, and every warn or fail I got was extremely self explanatory.

Please ask specific questions about what you don't understand about the specific descriptions given.

Thanks.

Jeff
 
yeah, thanks, here are the questions:

1, why am i still getting "Glue at parent nameservers" warning, even if i use a .net domain to check?

i mean i read "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."

2. why am i getting "Nameservers on separate class C's" warning?is it because i use enom's dns for asia-secure.net and those dns are in same class C IP range?
dns1.name-services.com
dns2.name-services.com
dns3.name-services.com
dns4.name-services.com
dns5.name-services.com

3. all my ips are got from datacenter, why the report says my IPs are not public?

thanks in advance.
 
Again you gave us incorrect information; you didn't tell us about wait4me.net.

You're getting this warning because the nameservers are the third level of a second-level domain name and as such can't be registered with the root-servers.

The only way to avoid the warning is to register nameservers in a domain directly registered with a registrar, instead of as a subdomain, and then register the nameservers with the same registrar.

The "Nameservers on separate class C's" warning is because there's no glue records, as stated. However, even if there were glue records, you'd still see this warning, because both IP#s are on the same subnet. The only way to avoid this warning is to have your nameservers on separate networks. Either rent another server somewhere else, buy one and colocate it somewhere else, make arrangements with someone else to slave their DNS in exchange for them slaving yours (warning: DA does not allow this through the gui although it will support it if you enter the zone files into the named.conf file manually and restart named), or use a commercial slave DNS service (such as ours).

The "All NS IPs public" warning is spurious; obviously not true; if it was DNS Report couldn't tell you what Bind versions they're using, because it couldn't reach them to find out.

Are you by any chance on a DSL or cable-company connection? That's a common possible reason for the error, according to a gent I know who's Senior Network Engineer at Florida's largest ISP. I don't know how to eliminate the error; you'd have to get in touch with the NS Report people and ask them.

NS TTL Discrepancy is because the NS records at the nameservers for asia-secure.net, the ones that delegate the domain to the nameservers at ns1.apple.asia-secure.net and at ns2.apple.asia-secure.net, have a different TTL than the NS records at ns1.apple.asia-secure.net, and at ns2.apple.asia-secure.net. To fix it you'll have to get the same information into the zone files at both locations.

The "Mail server host name in greeting" warning is self-explanatory. The name of the machine is apple.asia-secure.net, so that's what the mailserver needs to be identifying itself as, to get rid of this warning. As to how or why that happened I couldn't tell you without logging into the server. Whoever built the server for you should be able to help you; if you did it yourself perhaps DA support can help you.

The Acceptance of Domain Literals warning is because exim servers by default don't allow email to domain literals. Most spam-fighters think that accepting email addressed to IP addresses is outmoded, so even though it's in the RFCs, we don't do it.

If you have root access, you could turn this on (instructions are in the well-documented exim.conf file), but if you do, you're out of sync with many of the rest of us.

The "All WWW IPs public" warning, again is a spurious warning; see my suggestions above for getting it resolved.

I hope this helps.

Jeff
 
Back
Top