QWEST.NET can you fix your nameservers

Thu Sep 15 23:30:56 UTC 2016

In message <CAEE+rGp5BG=qyDfka2KYVfYmZdjC9EZBDD=OkZCNC7264Xt48A at mail.gmail.com>
, "Aaron C. de Bruyn" writes:
> 
> On Thu, Sep 15, 2016 at 2:45 PM, Mark Andrews <marka at isc.org> wrote:
> >
> > Aaron,
> >        How am I supposed to know which DNS vendor to contact?  DNS
> >
> 
> Sorry--I should have added a /sarcasm tag.  :)
> 
> 
> > The best way to get this fixed would be for nameservers to be checked
> > for protocol compliance, by the parent zone operators or their
> > proxies regularly.  That the child zone operator be given a short
> > (< 3 months) to fix it then all zones with that server get removed
> > from the parent zone until the server is fixed (apply the final
> > step in the complaints proceedures from RFC 1033) which forces the
> > owner of the zone to fix the server or to move to someone who follows
> > the protocol.  The servers for new delegations be checked immediately
> > and the delegation not proceed unless the delegated servers are
> > protocol compliant.
> >
> 
> Seems a bit harsh, but I'm new to the conversation.  What is being out of
> compliance actually hurting other than the nameserver operator and the
> zones they host?

So your helpdesks don't get problem reports when people can't look
up domain names?  Recursive DNS vendors don't get bug reports when
domain names can't be looked up.  We don't get fixes developed
because there are too many broken servers out there.

Because some servers don't answer EDNS requests this leads to false
positives on servers not support EDNS when they do.  This in turn
leads to DNSSEC validation failures as you don't get DNSSEC answers
without EDNS.

IPv6 deployment was put back years because AAAA DNS lookups got
wrong answers.

DANE deployment is slow because DNS servers give bad answers to
_<port>._tcp.<server-name>/TLSA.

Then there is SPF.  A fare portion of the reason why the SPF record
failed, despite it being architectually cleaner than using TXT
records, is that some nameservers gave bad responses to SPF queries.

I could go find more examples of the cost of non DNS protocol
compliance.

> > My bet is the DNS vendor has issued a update already and that it
> > hasn't been applied.  If not Qwest can inform them that their product
> > is broken.  Fixing this should be about 10 minutes for the DNS
> > vendor then QA.
> >
> 
> Yeah, but the business upgrade cycles are the killer.
> Why dedicate resources to fix it unless there's a pretty clear
> line-of-sight to lost profits?
> That's why so many of my clients refuse to upgrade away from XP.  It still
> works for what they basically need, and it's not really impacting their
> profit in a way the CFO can directly see.  (i.e. he doesn't see people like
> me who will walk out of a dental office and never come back when I see a
> 2-plus-year-out-of-date XP machine handling patient information.)
> 
> I'm sure the same is happening in a large bureaucracy like Qwest.
> 
> Maybe you're right with a harsher penalty.  Be standards compliant or
> you'll get a warning, then be cut off.
> 
> 
> 
> > If you (collectively) haven't already checked your servers go to
> > https://ednscomp.isc.org and check your servers.  While you are
> > there look at some of the reports.
> >
> 
> Tested.  I'm compliant.  I definitely think more comprehensive tools that
> are easily accessible to admins and CFOs would help.
> 
> For example, when I explain various zone-related things to CFOs, I'll use
> http://intodns.com/.  It's sorta flashy, and contains some sorta helpful
> information that a CFO can sorta understand.
> 
> And a big red 'X' when someone is wrong.
> 
> Unfortunately it doesn't do DNSSEC.  For that, there's another tool.
> ...and if you want EDNS testing, there's your tool.
> 
> A tool that tests compliance for everything and spits out errors, warnings,
> and recommendations might go a long ways towards getting people to solve
> the problem.
> 
> Just my $0.02.
> 
> Nice graphs by the way.
> 
> -A
> 
> --001a11394e2c845079053c9314bd
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
> hu, Sep 15, 2016 at 2:45 PM, Mark Andrews <span dir=3D"ltr"><<a href=3D"=
> mailto:marka at isc.org" target=3D"_blank">marka at isc.org</a>></span> wrote:=
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">Aaron,<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0How am I supposed to know which DNS vendor to co=
> ntact?=C2=A0 DNS<br></blockquote><div><br></div><div>Sorry--I should have a=
> dded a /sarcasm tag. =C2=A0:)</div><div>=C2=A0</div><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
> ft:1ex">The best way to get this fixed would be for nameservers to be check=
> ed<br>
> for protocol compliance, by the parent zone operators or their<br>
> proxies regularly.=C2=A0 That the child zone operator be given a short<br>
> (< 3 months) to fix it then all zones with that server get removed<br>
> from the parent zone until the server is fixed (apply the final<br>
> step in the complaints proceedures from RFC 1033) which forces the<br>
> owner of the zone to fix the server or to move to someone who follows<br>
> the protocol.=C2=A0 The servers for new delegations be checked immediately<=
> br>
> and the delegation not proceed unless the delegated servers are<br>
> protocol compliant.<br></blockquote><div><br></div><div>Seems a bit harsh, =
> but I'm new to the conversation.=C2=A0 What is being out of</div><div>c=
> ompliance actually hurting other than the nameserver operator and the</div>=
> <div>zones they host?</div><div><br></div><div>=C2=A0</div><blockquote clas=
> s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
> ding-left:1ex">My bet is the DNS vendor has issued a update already and tha=
> t it<br>
> hasn't been applied.=C2=A0 If not Qwest can inform them that their prod=
> uct<br>
> is broken.=C2=A0 Fixing this should be about 10 minutes for the DNS<br>
> vendor then QA.<br></blockquote><div><br></div><div>Yeah, but the business =
> upgrade cycles are the killer.</div><div>Why dedicate resources to fix it u=
> nless there's a pretty clear line-of-sight to lost profits?</div><div>T=
> hat's why so many of my clients refuse to upgrade away from XP.=C2=A0 I=
> t still works for what they basically need, and it's not really impacti=
> ng their profit in a way the CFO can directly see. =C2=A0(i.e. he doesn&#39=
> ;t see people like me who will walk out of a dental office and never come b=
> ack when I see a 2-plus-year-out-of-date XP machine handling patient inform=
> ation.)</div><div><br></div><div>I'm sure the same is happening in a la=
> rge bureaucracy like Qwest.</div><div><br></div><div>Maybe you're right=
>  with a harsher penalty.=C2=A0 Be standards compliant or you'll get a w=
> arning, then be cut off.</div><div><br></div><div>=C2=A0</div><blockquote c=
> lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
> padding-left:1ex">
> If you (collectively) haven't already checked your servers go to<br>
> <a href=3D"https://ednscomp.isc.org" rel=3D"noreferrer" target=3D"_blank">h=
> ttps://ednscomp.isc.org</a> and check your servers.=C2=A0 While you are<br>
> there look at some of the reports.<br></blockquote><div><br></div><div>Test=
> ed.=C2=A0 I'm compliant.=C2=A0 I definitely think more comprehensive to=
> ols that are easily accessible to admins and CFOs would help.</div><div><br=
> ></div><div>For example, when I explain various zone-related things to CFOs=
> , I'll use <a href=3D"http://intodns.com/">http://intodns.com/</a>.=C2=
> =A0 It's sorta flashy, and contains some sorta helpful information that=
>  a CFO can sorta understand.</div><div><br></div><div>And a big red 'X&=
> #39; when someone is wrong.</div><div><br></div><div>Unfortunately it doesn=
> 't do DNSSEC.=C2=A0 For that, there's another tool.</div><div>...an=
> d if you want EDNS testing, there's your tool.</div><div><br></div><div=
> >A tool that tests compliance for everything and spits out errors, warnings=
> , and recommendations might go a long ways towards getting people to solve =
> the problem.</div><div><br></div><div>Just my $0.02.</div><div><br></div><d=
> iv>Nice graphs by the way.</div><div><br></div><div>-A</div></div></div></d=
> iv>
> 
> --001a11394e2c845079053c9314bd--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org