[dns-operations] google DNS doing validation?

[Wessels, Duane]

> On Jul 27, 2018, at 10:31 AM, Warren Kumari <warren at kumari.net> wrote:
> 
> On Fri, Jul 27, 2018 at 1:03 PM John Todd <jtodd at quad9.net> wrote:
>> 
>> On 26 Jul 2018, at 8:29, Frank Bulk wrote:
>> 
>>> Thank for hosting that zone and breaking it again. =)
>>> 
>>> There's only two zones that I know that are intentionally broken
>>> (servfail.nl and www.dnssec-failed.org -- I'd love to have a few
>>> more), but they provide at least some indication that our
>>> customer-facing DNS resolvers are properly performing DNSsec
>>> validation.
>>> 
>>> Frank
>> [snip]
>> 
>> We see quite a bit of DNSSEC traffic that is “broken” but seems to
>> be intentionally non-operational. Intentionally broken DNSSEC is by far
>> the largest source of DNSSEC failure traffic we see on our resolvers (we
>> perform strict validation on 9.9.9.9/2620:fe::fe but not on
>> 9.9.9.10/2620:fe::10)
>> 
>> Since there was a request for some additional broken domains, here are a
>> few that we see frequently:
>> 
>>  Domains that seem to be “intentionally” broken in a programmatic
>> way that appears to be testing:
>> 
>>  bogus.[string].rootcanary.net
>>  [string]-[string]-[string]-[string]-[string]-bogus-dnssec-bd.gexperiments3.com
>>  [string]-[string]-[string]-[string]-[string]-[string].lae.dotnxdomain.net
>> 
>> 
>>  Fixed addresses that come up quite often which seem to be intentional:
>> 
>>  bogus.ripe-hackathon2.nlnetlabs.nl
>>  prefetch.validatorsearch.verisignlabs.com
>>  test-ns.bogus.internet.nl
>>  dnssec-failed.org
>>  trasigdnssec.se
>>  bad.dnssec-or-not.com
>> 
>> 
>> Of course, there are many domains that consistently fail DNSSEC lookups
>> which give no indication via the name that it is intentional.
> 
> Perhaps it would be useful to have a *convention* where people include
> a string making it clear that this was intentional.
> 
> I have 'invalid.ksk-test.net' as an intentionally invalid name, but
> from looking  at the above, it seems that 'bogus' is more common.
> 
> It's actually somewhat annoying to keep a name bogus / invalid --
> every time I make a change to ksk-test.net I resign it, and my invalid
> record becomes valid. I then edit the signed zone file and monkey with
> the signature to make it invalid again[0].
> I also want to serve ksk-test.net over TLS, including web resources
> from www.ksk-test.net and invalid.ksk-test.net. The obvious solution
> is LetsEncrypt with either multiple names in the SAN, or a wildcard.
> LE does DNSSEC validation, and so will not issue for
> invalid.ksk-test.net, so I figure I'll do a wildcard. This involves a
> DNS challenge, which the Certbot utility does using dynamic updates --
> which resignes the zone and makes 'invalid' be valid again :-). Yes,
> this could be fixed, but it will require redoing whenever certificate
> renewal happens....
> 
> W
> [0]: Yup, I could / should write a script to automate this (probably
> by passing the signed zone through sed and awk) but I always figure
> I've touched the zone for the last time and that it isn't worth the 15
> minutes it will take to do so...
> 


Yes you should!

I'm proud to say that I've earned the "cream of the crop" award [1] from ianix.com with 4.5 years continuous downtime of validatorsearch.verisignlabs.com!

[1] See the very bottom of https://ianix.com/pub/dnssec-outages.html

DW



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4675 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180727/1855bc7d/attachment.bin>