I used to use "dlint" for this, but the package no longer builds easily - is there any equivalent package as dig is not ideal to find what the problem actually is?
BillK On 27/08/13 19:53, Alan McKinnon wrote: > On 27/08/2013 12:30, Grant wrote: >> I use a fairly well-known (free) DNS provider. I just checked my DNS >> settings at dnscheck.pingdom.com and I got: >> >> 1. No SOA record was found when querying the name server. This is most >> probably due to a misconfiguration at the name server - a zone must >> have a SOA record. >> >> 2. Nameserver * does not do DNSSEC extra processing. >> >> Are either of these something to worry about? > > > Yes. Without an SOA record you don't actually have a zone. > > You should stop using those crappy dns checker sites, they tend to be > full of shit, unreliable and operate off someone's idea of how DNS > should be instead of reading the actual RFCs on the matter. Our abuse > team has long ticket lists from people trusting those sites and now > think there's something with how we do glue. Hint: Our glue is right and > proper :-) > > > Instead just use dig, using google.com as an example get the NS records > first: > > $ dig ns google.com +short > ns3.google.com. > ns2.google.com. > ns1.google.com. > ns4.google.com. > > > Then query each of those name server in turn directly for the SOA: > > $ dig soa google.com +short @ns3.google.com > ns1.google.com. dns-admin.google.com. 2013081400 7200 1800 1209600 300 > > That's a correct SOA record. > > What could have happened with that test site is the query timed out and > the site assumed the universe was therefore about to explode. Use such > if you want but always verify the results yourself using dig. > > The DNSSEC message is not a problem. It means your provider does not use > DNSSEC. Again, the universe will not explode from this, we all got along > just fine with plain unsigned DNS transfers for 30 years. DNSSEC is a > way to digitally sign zone transfers and updates. Nothing to do with > zone resolution. >
