[dns-operations] google DNS doing validation?

Warren Kumari warren at kumari.net
Fri Jul 27 17:31:15 UTC 2018


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



>
> JT
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



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




More information about the dns-operations mailing list