Re: [Add] add-enterprise-split-dns and split horizon DNS

[Geoff Huston <[e-mail]>]

> On 3 Dec 2021, at 11:34 am, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Thu, Dec 2, 2021 at 11:27 AM Michael Richardson <[e-mail]> wrote:
> 
> I have just watched the ADD-20211108-1600 session from IETF112.
> I had a conflicting session.
> 
> What I took from the conversation is that many people would like to solve DDR
> in a split-horizon situation, and that if we could find a solution that
> solved typo-squatting by local resolvers that would also be very welcome.
> (typo-squatting is of course trivially solved by DNSSEC, which I'm told
> browsers refuse to implement because miliseconds...)
> 
> I don't know who told you this, but that's not the reason that browsers do not
> implement DNSSEC. The primary reason that browsers do not implement DNSSEC is
> because of concerns that otherwise valid resolutions will fail due to recursive
> resolvers/middleboxes incorrectly handling DNSSEC records, thus resulting
> in increased user-visible error rates.
> 

Hi Eric,

Each time this topic comes up (why browsers do not use DNSSEC, or the related topic
as to why browsers do not use DANE) I hear different “primary reasons”. 

- It takes too long,  
- RSA-1024 is insecure, 
- the DNS does not cope with large responses,
- the DNS provisioning infrastructure does not support DS records,

and now I am reading here from your message that:

- middleboxes (I assume you mean DNS forwarders?) and recursive resolvers erroneously fail. 


So can I take it from your message here that this concern that recursive resolvers
got DNSSEC all wrong is “the primary reason” why browsers do not use DNSSEC, 
and also the related topic as to why browsers do not use DANE.

Over the years, I have picked up this sense that each time this topic is raised, a
different “primary reason” is offered as to why the browserverse appears to be
avoiding use of DNSSEC. So if we headed into pinning down the behaviours of DNS
resolution infrastructure and their DNSSEC capabilities with measurement we could
replace these vague dataless assertions with data that could prove or disprove this
“primary reason”. Would you agree?

Thanks,

 Geoff