[dns-operations] RFC 6975 (was: Re: Algorithm 5 and 7 trends (please move to 8 or 13))

Mark Andrews marka at isc.org
Tue Jun 9 23:05:14 UTC 2020


It really is time for all nameservers for zones delegated from TLDs (and other
similar zones) to be tested for protocol compliance at the DNS message level
and their operators to be informed that their servers are out of compliance.
It does not take long to test every server.  One can test thousands of servers
a second from a single machine.

It just takes willingness to do this.  When it has been done by some TLD operators
in the past they see a large improvement in a short period of time.  Also there
is very little back sliding.

As for ECS it’s time for all operators to stop white-listing servers so that the
zones with broken servers fail for everybody body that sends ECS queries.  Collectively
resolver operators have more power in enforcing protocol compliance but only if
they act collectively.

Mark

> On 9 Jun 2020, at 15:16, Brian Somers <bsomers at opendns.com> wrote:
> 
> We turned this up again on Friday and turned it down yet again today.  There
> are issues with sacks.com and I’m told there are a bunch of other support
> tickets (although details haven’t been given yet).
> 
>    $ dig +noall +answer +tries=1 +ednsopt=5:08 zacks.com @208.65.116.45                                  
>    ;; connection timed out; no servers could be reached
>    $ dig +noall +answer +tries=1 +subnet=1.2.3.0/24 zacks.com @208.65.116.45
>    ;; connection timed out; no servers could be reached
>    $ dig +noall +answer +tries=1 zacks.com @208.65.116.45
>    zacks.com.              1200    IN      A       208.65.116.3
> 
> I’m now looking at re-implementing the code we had in place for EDNS
> probing prior to flag day 2019:
> - FORMERR/SERVFAIL/NOTIMP - try without any EDNS codes
> - No response - try with no EDNS codes on the third attempt
> 
> Still trying to think of a way to make this negatively affect the domain that
> misbehaves without negatively affecting our support folks :(
> 
> Any tips around this would be helpful (any resolvers do ECS probing for
> example?).
> 
>> Brian
> 
>> On Jun 3, 2020, at 1:52 AM, Petr Špaček <petr.spacek at nic.cz> wrote:
>> 
>> On 03. 06. 20 7:18, Brian Somers wrote:
>>> On May 28, 2020, at 10:35 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>>> 
>>>> Enough time has passed since the need to abandon SHA-1 has become
>>>> more pressing to discern at least a couple short-term trend-lines.
>>> 
>>> Along these lines, have any of the large resolvers implemented
>>> RFC 6975 (DAU/DHU/N3U EDNS codes)?  OpenDNS/Cisco
>>> enabled these a couple of weeks ago but had to disable them
>>> pending qq.com being fixed (its nameservers returned
>>> SERVFAIL).  Now that the fix is there, we’re planning to turn
>>> it up again at the end of the week.
>>> 
>>> Just curious about its adoption… it feels like we testing new
>>> waters here.
>> 
>> I believe you are the first, congrats! :-)
>> 
>> It was not feasible to implement before https://dnsflagday.net/2019/ and then, you know, nobody asked for it ...
>> 
>> Please report other issues you eventually encounter, I would bet there will be couple more lurking somewhere.
>> 
>> -- 
>> Petr Špaček  @  CZ.NIC
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
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