I would imagine "its a hoax" is code for we dont want to bother remediating.
On Fri, Jan 18, 2019, 3:20 PM Warren Kumari <war...@kumari.net wrote: > > > On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell <ben.crosw...@gmail.com> > wrote: > >> I would say we had one provider go as far as saying this whole flag day >> thing is a hoax. >> > > That's a weird stance / position. "The whole flag day thing is > [stupid|overblown|annoying|confusing|on a Friday]" are all positions I can > understand - not agree with (modulo the Friday one), but at least > understand. 'tis a hoax is just confusing... > Flag Day been discussed at length, and presented at multiple DNS events - > it seems that a DNS provider who hasn't seen any of the presentations and > recognized at least one person pushing this isn't well connected to the > community, and should probably be avoided... > > W > P.S: Unless they think it is simply a *very* subtle, long running, > widespread hoax... and now I'm wondering if I'm the patsy here :-P > > > > >> Not sure what option there is other than voting with your wallet and >> moving to a different provider. >> > >> May even be worth looking at 2 providers. I see DNS provider redundancy >> as being a huge priority after the Dyn DDoS event. >> >> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey <jlight...@dsservices.com >> wrote: >> >>> On checking I find that any of our domains that use Network Solutions’ >>> Worldnic.com nameservers are reporting failures when checked. >>> >>> For example this result: https://ednscomp.isc.org/ednscomp/e30c6cf0ea >>> >>> Other people online have posted about Network Solutions as they also saw >>> failures. >>> >>> On calling Network Solutions today they told me they are compliant >>> despite what was reported by https://dnsflagday.net/ >>> >>> >>> >>> This issue is with domains registered at Network Solutions and using >>> their Advanced DNS (i.e. their Worldnic name servers). Other domains we >>> have registered with them but pointing to other name servers (i.e. our own >>> BIND servers) displayed as compliant. >>> >>> When I sent them the links they saw what I saw but still claimed they >>> are compliant. They refused to send me something in writing stating that >>> so I suggested they reach out to ISC regarding the checker’s results if >>> they believe they are compliant, but they said they don’t see the need. >>> I’ve asked them to escalate and they say they have but I suspect I’ll not >>> hear back from them. >>> >>> Is there a list of known edns compliant Registrar name severs for the >>> larger Registrars? >>> >>> Is it possible the failures seen are false? If so, are there alternate >>> edns compliance checkers that might show different responses than >>> dnsflagday.net? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* bind-users <bind-users-boun...@lists.isc.org> * On Behalf Of *Ben >>> Croswell >>> *Sent:* Friday, January 18, 2019 12:19 PM >>> *To:* bind-users@lists.isc.org >>> *Subject:* Re: DNS flag day >>> >>> >>> >>> I shouldn't have posted so closely to responding to the other user. >>> >>> >>> >>> I am not running 9.8. I was replying to them about firewalls in regards >>> to their 9.8 issues. >>> >>> >>> >>> Was just hoping for a statement of 9.x or greater supports the needed >>> badvers signaling etc. >>> >>> >>> >>> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk <vi...@isc.org wrote: >>> >>> >>> >>> On Jan 18, 2019, at 9:09 AM, Ben Croswell <ben.crosw...@gmail.com> >>> wrote: >>> >>> >>> >>> Has ISC released minimum viable BIND version for flag day? >>> >>> >>> >>> Most versions of BIND authoritative servers, going back years, are EDNS >>> compatible. Certainly ALL currently supported versions are compatible. I >>> see you are running 9.8, which has been EOL since September, 2014. I think >>> that is probably fine, as far as EDNS, however. >>> >>> >>> >>> The change in BIND related to DNS Flag Day is removing workarounds from >>> resolvers, that will retry without EDNS or otherwise try to proceed even >>> when EDNS fails. This change came in the BIND 9.13 development version, and >>> will be in BIND 9.14, which is not yet released. >>> >>> >>> >>> The problem you are seeing is most likely firewall-related. >>> >>> >>> >>> Vicky >>> >>> >>> >>> >>> >>> I looked around and couldn't find anything. >>> >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >> _______________________________________________ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users