zonecheck-tests
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [zonecheck-tests] incorrect failure for "hostmaster MX is not an al


From: Marco Schumann
Subject: Re: [zonecheck-tests] incorrect failure for "hostmaster MX is not an alias"
Date: Fri, 24 Oct 2008 08:50:41 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi,

Stephane Bortzmeyer schrieb:
> On Thu, Oct 23, 2008 at 03:56:40PM +0000,
>  Salemme, Mary E <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]