Hi, Stephane Bortzmeyer schrieb: > On Thu, Oct 23, 2008 at 03:56:40PM +0000, > Salemme, Mary E <[EMAIL PROTECTED]> wrote > a message of 47 lines which said: > >> As an example, testing digex.com returns this result: > > Zonecheck appears to be correct and you can test with dig, too: > > % dig @NS1.verizonbusiness.com CNAME esmtp00.verizonbusiness.com > > ; <<>> DiG 9.5.0-P2 <<>> @NS1.verizonbusiness.com CNAME > esmtp00.verizonbusiness.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64175
NS1.verizonbusiness.com != /mia0[12]\.digex\.com/, thus it's not a failure of the digex.com zone, yes? So why throw a fatal error for digex.com on a SERVFAIL of a third party? Silly... This _is_ a bug in zonecheck as another zone is checked, and that must not be the job at this point in time. At most it is worth a hint. Even worse, esmtp00.verizonbusiness.com can be resolved: > dig +short @NS1.verizonbusiness.com esmtp00.verizonbusiness.com 199.249.25.205 198.4.8.173 So there is no technical problem at all. >> ---- fatal ---- >> [TEST MX is not an alias]: server failure (IN/CNAME: >> esmtp00.verizonbusiness.com.) >> mia01.digex.com./216.255.129.249 > > The error message is not perfect (it should indicate the authoritative > name server of verizonbusiness.com not of digex.com) but there is > indeed a server failure on your side. zonecheck must not care! >> the target of the MX record >> for verizonbusiness.com is not an alias. > > That's not the point: Zonecheck wanted to check that ("MX is not an > alias") and it was impossible (because of the spurious SERVFAIL). Whose problem is that? One of AFNIC? NO! Maybe I miss some point, but why is an admin of one domain held responsible for possible mistakes in foreign name servers at all? Whose responsibility is the correctness of zone entries? IMHO _no_ registry should take care about zone configurations of either "own" zones or even foreign zones. Additionally, if one wants to have a certain configuration, one can set up the desired configuration after a domain registration, thus these attempts could be skipped due to pointlessness. To summarize, when zonecheck checks a zone, it should be limited to exactly that zone. Tests of foreign zones must generate a hint at most, they must not raise a fatal error. Kind regards -- Marco _______________________________________________ zonecheck-tests mailing list zonecheck-tests@nongnu.org http://lists.nongnu.org/mailman/listinfo/zonecheck-tests