[dns-operations] uspto.gov

[Casey Deccio]

On Tue, May 18, 2010 at 12:24 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr>wrote:

>
> > I don't believe it's a lack of interest, just a lack of experience
> > and resources.  It really is a non-trivial extension to plain DNS.
>
>
> I strongly disagree. The problem with uspto.gov is not a DNSSEC one
> (the signatures are valid, the chain trust is OK) but a *network*
> one. A broken middlebox prevents large responses to come in.
>
> ...
> Their network setup has been broken for ten years (when EDNS was
> introduced)
> and DNSSEC is just a lame excuse.
>

Technically speaking, you're correct.  But my point is that DNSSEC and its
requirements add a new level of complexity, and those braving adoption for
whatever reason are still learning the rules--in particular those who were
simply complying with requests from higher up.  OARC's objective is to bring
"together key operators, implementors, and researchers on a trusted platform
so they can ... share information and learn together."  We should be careful
about accusations as it inhibits "learning together", in my opinion.

Yes, EDNS has been around, but support for large buffer sizes was not nearly
as necessary in the pre-DNSSEC world.  And this is only one example of
previously "working" but improperly configured setups that break with
DNSSEC.  Another example is missing delegation records in parent zones.
There are large number of zones with this setup, and they mostly work if the
authoritative servers are authoritative for both the parent and child
zones.  However, when validating resolvers begin querying for DS RRs of
those child zones, the authoritative response comes from the parent zones,
instead of the child zone, so the server returns NXDOMAIN if there are no
records by that name in the parent zone.  This results in a SERVFAIL from
the resolvers.

Regards,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20100518/988fdfb4/attachment.html>