[Dnssec-deployment] DNSSEC validation errors in .gov
dougb at dougbarton.us
Sun May 9 16:02:11 EDT 2010
On 05/09/10 00:16, bert hubert wrote:
> On Sat, May 08, 2010 at 11:59:27PM -0700, Doug Barton wrote:
>>>> I am a bit worried about seeing these go seemingly unnoticed. I guess
>>>> it means most .gov sites are deploying DNSSEC on their auth servers,
>>>> but not on their resolvers. It also seems those who are signing are
>>> This indeed appears to be the case.
>> Bert, seriously, how could you possibly make that statement?
> I'm just echoing what Paul says, and what I hear from many places.
Ok, so you don't have any actual knowledge of the situation, you're just
spreading FUD. And that is helpful how?
> Running a validating resolver increases your problems right now.
To a very small degree, yes. As far as I can see the problems are
growing smaller by the day, although we are still unquestionably in the
early adopter phase. My feeling is that once the root is signed with a
real key and the trust anchors are imported into the root zone that we
will see a small bump in the road followed by a long tail as the
problems smooth out.
> Given the increased stringency of DNSSEC, this is not unexpected. It might even be welcome.
On this we actually agree. :)
>>> Validating .gov currently has very big
>>> operational downsides, like no longer being able to communicate with
>> Again, seriously? I am running a local validating resolver and have no
>> problem whatsoever here:
> $ dig -t mx uspto.gov @DNS2.uspto.gov +dnssec
> $ dig -t mx uspto.gov @DNS1.uspto.gov +dnssec
> .. plain do not work here.
You've already been taken to school on that one, I won't pile on.
> And haven't worked for *months*. I did not trawl
> the net for things that did not work, a research establishment here in
> The Netherlands discovered the hard way that their communications with
> USPTO were no longer arriving. Perhaps they can confirm on list, I know they
> are reading here.
Yes, this kind of real, operational data is welcome. I'm not sure how
repeating it 3rd hand is useful though, especially since for
significantly useful values of "broken," you're wrong.
>> So please, actual operational data, or nothing. FUD doesn't help the
>> situation (or your credibility).
> My credibility is with the operational DNS crowd.
In other words, the people who don't understand the issues well enough
to know that you're blasting FUD at them.
[snipping the stuff related to Paul V. since he spoke for himself.]
> Since DNSSEC is now mandatory,
Um, what? By this do you mean that "support for DNSSEC in 21st century
name server software" is now mandatory? If so, then we have found
another area of agreement.
> my goal is to provide solutions that are
> acceptable to those that have to run it. My interest is therefore to make
> things workable.
> And if that includes ways to make sure you can still talk to people that
> have DNSSEC problems, that is the way it is going to have to be.
> The PowerDNS Recursor may therefore for example offer a webinterface to
> operators to turn off DNSSEC for certain problematic zones.
Sorry, this just sounds like more FUD to me. "ooooohhh, DNSSEC is scary,
so there are knobs to turn it off, oooooohhhhh" IFF there was a
situation where you couldn't possibly configure a mail server to query a
name server that didn't have validation enabled, there are still other
forms of communication available other than e-mail. You're a reasonably
intelligent person Bert, so I have to believe that you understand this,
which is why for all your nice noises about supporting "the masses" it
still just sounds like FUD to me.
> I would also highly recommend that each registry configures an email address
> and a website that do NOT do DNSSEC, so that they can at least be reached in
> case of problems.
More FUD. And yes, in case it's not obvious, my tolerance for this kind
of cr^H^H stuff is at a pretty low cycle atm.
... and that's just a little bit of history repeating.
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
More information about the Dnssec-deployment