[dns-operations] The strange case of fox.com

Mark Andrews marka at isc.org
Thu Mar 3 03:25:58 UTC 2016


In message <56D79CE5.3060707 at gronkulator.com>, Rich Goodson writes:
> Mark,
> 
> In the instance that I brought up, undergoing excommunication of the 
> zone successfully might have made the DNS better as a whole (making the 
> world a better place), but it would not have solved my problem.

Actually it would have.  The point of excommunication is to make
people *act*.  Your problem was that they weren't fixing the broken
delegation because it worked partially requiring you to put in
workarounds.  Breaking it completely would have forced them to act.

The process of getting to the excommunication process also gives
them fair warning that they need to fix the issue.  That they can't
just ignore the issue as there are major consequences to doing that.

> My problem was that users couldn't get to a web site some of the time to 
> pay their credit card bill or check their balance (more accurately, my 
> problem was having to listen to the complaining that ensued).  If I, 
> instead of implementing a workaround, got domain excommunicated, then 
> instead of my users not being able to get to a web site some of the 
> time, now they can't get to it ever.

No. They can't get to it until they fix the issue and get the
delegation re-instated.  The point of going through the process is
to give them warning.  Fixing most delegation issues only takes a
couple of minutes.  Its getting someone to do the update that is
difficult.

> The only benefit to me would have been no longer hearing "it works on 
> Google's DNS".
> 
> Rich
> 
> On 3/2/16 4:28 PM, Mark Andrews wrote:
> > In message <3c1ba59ee6484aec9ac3fa8bb3e97d81 at PMBX112-W1-CA-1.PEXCH112.ICANN
> .ORG
> >> , Leo Vegoda writes:
> >> Mark Andrews wrote:
> >>
> >> [...]
> >>
> >>> Which is why you should have continued with the proceedures in RFC
> >>> 1033 and requested excommunication.
> >> In the context of the DNS, what does excommunication mean?
> > The delegation and any glue records below it are removed from the
> > published zone.  I would think it would only be until such time as
> > the underlying problem is addressed.
> >
> > This is documented in RFC 1033 as the step of last resort:
> >
> > COMPLAINTS
> >
> >     These are the suggested steps you should take if you are having
> >     problems that you believe are caused by someone else's name server:
> >
> >
> >     1.  Complain privately to the responsible person for the domain.  You
> >     can find their mailing address in the SOA record for the domain.
> >
> >     2.  Complain publicly to the responsible person for the domain.
> >
> >     3.  Ask the NIC for the administrative person responsible for the
> >     domain.  Complain.  You can also find domain contacts on the NIC in
> >     the file NETINFO:DOMAIN-CONTACTS.TXT
> >
> >     4.  Complain to the parent domain authorities.
> >
> >     5.  Ask the parent authorities to excommunicate the domain.
> >
> >
> >> How would it make the world a better place?
> > It makes people fix problems but raising them to a level that they
> > cannot ignore if they intend to still have the name be visible in
> > the DNS.
> >
> > The parent also becomes a neutral third party who presumably would
> > not act on the request without evidence of a problem.
> >
> >> Regards,
> >>
> >> Leo
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the dns-operations mailing list