Am Sonntag, den 26.10.2008, 11:17 +0400 schrieb Stephane Bortzmeyer:
> On Fri, Oct 24, 2008 at 08:50:41AM +0200,
>  Marco Schumann <[EMAIL PROTECTED]> wrote 
>  a message of 74 lines which said:
> > 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?
> It's not any random third party. It is the DNS provider choosen by
> Digex. So, it makes perfect sense to test it. 

the authoritative nameservers of digex.com are mia01.digex.com and
mia02.digex.com. The verizonbusiness.com nameservers are responsible for
hosts mentioned as MX RRs.

zonechecks "business" is to check the digex.com nameservers, not any
third party nameservers. So it's not up to you to decide whether any
zone in the world is configured correctly in your eyes. If mia* respond
correctly, accept it.

> > So there is no technical problem at all.
> SERVFAIL is not a technical problem? We disagree here.

zonecheck searches for a CNAME which is not present. Maybe it is a
software configuration to respond with a SERVFAIL on "unknown" RR types?
Why does zonecheck have to judge a software works correctly or not?
Additionally, to not miss it, there was an A RR present. So the only
"problem" was to not respond to a silly question. 

> > Maybe I miss some point, but why is an admin of one domain held
> > responsible for possible mistakes in foreign name servers at all? 
> It is not FOREIGN! It is the provider they use!

Yes, appearantly they are bound to a mail service provider, but the
nameserver configuration of the mail service provider is not the job of
the digex.com admins. In this way they are foreign. And nobody is
allowed to force me to not use _my_ provider due to a "lack" in _their_
nameserver config (which isn't one at all).

Kind regards

zonecheck-tests mailing list

Reply via email to