[dns-operations] .PL DNSSEC broken again

[Mark Andrews]

> On 18 Jun 2019, at 8:03 am, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Tue, Jun 18, 2019 at 03:11:37AM +0530, Mukund Sivaraman wrote:
> 
>> Perhaps most are like that. It has been 14 years since RFC
>> 4033/4034/4035 have been published. DNSSEC is not a separate space - it
>> works compatibly within the DNS. So why is adoption low? Is it because
>> of:
>> 
>> (a) Complexity of understanding/operating DNSSEC (this has reduced over
>>    the years)
>> 
>> (b) Lack of knowledge/interest
>> 
>> (c) Lack of software implementation
>> 
>> (d) Risk of operational problems (considered vs. risk of poisoning)
> 
> I vote for:
> 
>  (e) Long capital infrastructure replacement cycles.
> 
> The DNS load-balancers that front-end large web "properties" don't
> support on-the-fly signing, and have to all be replaced to enable
> DNSSEC for these.

I’ve yet to see a case where “on the fly” signing is necessary.  All
you need to do is be able to publish different RRsets with their matching
RRSIGs all of which can be precomputed.

>> In my slightly dated Alexa top 500 list of domains scanned today, 16
>> (3.2%) are signed.
> 
> Alexa ranks large web "properties", these are the ones where (e)
> is an obstacle.

GLB’s aren’t harder in theory than any other servers for DNSSEC (or
anything else DNS related) but they disproportionately cause issues.

>> Many of the top websites are quick to adopt new
>> technologies.
> 
> That works provided the technology can be deployed one node or one
> service at a time, but signing a domain requires all the nameservers
> to be ready.

After 14 years this excuse wears thin. The root zone itself was signed
~9 years ago and that required multiple implementations to be available.

>> It is unlikely the DNS operators managing these zones have
>> not heard of DNSSEC, or are incapable of signing them. What is the
>> factor that stops them from signing their domains?
> 
> See (e).  In the mean-time, new infrastructure they're deploying,
> (e.g. "cloud.goog", "smtp.goog", ...) are in many cases signed.
> 
>> E.g., Google is quick to deploy extensions / new algorithms into its TLS
>> support in its web service and Chrome.
> 
> That works one node at a time.
> 
>> Why, then, has it not signed google.com to lead by example?
> 
> It does in "cloud.goog", "smtp.goog", ...
> 
>> Mozilla has pushed DoH (something very new) quickly into Firefox.
> 
> A retrograde step in the eyes of many.
> 
>> As
>> an organization, it appears very security and privacy conscious with
>> services like the observatory.mozilla.org. Why, then, has it not signed
>> mozilla.com to lead by example?
> 
> The allizom.org domain is signed.
> 
>> It'd be interesting to watch how quickly DNS transport security
>> (authoritative) is adopted by operators. The effect of operational
>> mistakes may be different and it may have a higher rate of adoption.
> 
> I am mostly skeptical about the wisdom of DoT and DoH, they tunnel
> DNS queries out of the local network, where there may be good reasons
> to use an internal DNS view.  They may be OK on networks which just
> provide transit, but are not so good on networks (e.g. corporate,
> or other private) where the network provides internal services.
> 
> -- 
> 	Viktor.
> _______________________________________________
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org