DNS flag day

[Ben Croswell]

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 <warren at kumari.net wrote:

>
>
> On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell <ben.croswell at 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 <JLightner at 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-bounces at lists.isc.org> * On Behalf Of *Ben
>>> Croswell
>>> *Sent:* Friday, January 18, 2019 12:19 PM
>>> *To:* bind-users at 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 <vicky at isc.org wrote:
>>>
>>>
>>>
>>> On Jan 18, 2019, at 9:09 AM, Ben Croswell <ben.croswell at 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 at 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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190118/59cf7b87/attachment.html>