[Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[bert hubert]

On Fri, Feb 17, 2017 at 02:33:37PM +0100, Peter van Dijk wrote:
> >Call me confused, but it happened every day this week.
> 
> Because OVH put those records in the .net zone. OVH did this. OVH needs to
> fix this. There is no ‘security issue’, there is no ‘CVE needed’. There is
> just OVH that needs to fix these records.

And to really finalise this discussion, PowerDNS could of course utilize a
split cache to segregate glue from actual data.  This would however likely
again break other things, and we'd be doing that to benefit operators
putting wrong data in DNS.

In this case, the .NET servers told us about data in .NET and we believed
the .NET servers. That data was put in the .NET zone by OVH and as a result
OVH email delivery stopped working. 

Way back when in January 1980, Jon Postel wrote in RFC791:

"In general, an implementation should be conservative in its sending
 behavior, and liberal in its receiving behavior."

This sentence has guided a lot of resolver development where BIND, Unbound,
Knot resolver and PowerDNS etc accept a Lot of broken stuff in the interest
of keeping the internet working. 

Less frequently quoted is the second part of that paragraph from RFC 791:

"That is, it should be careful to send well-formed datagrams, but should
 accept any datagram that it can interpret (e.g., not object to technical
 errors where the meaning is still clear)."

This looks decidedly worse. This does not look like decent design. In the
OVH case, I'm not even sure that "the meaning is still clear" if you publish
two different IP addresses for a name. Which is right?

In 2015, Martin Thomson wrote an Internet Draft "The Harmful
Consequences of Postel's Maxim".  In this draft, he argues that the
'robustness principle' actually causes protocol decay:

"An implementation that reacts to variations in the manner advised by
 Postel sets up a feedback cycle:

   o  Over time, implementations progressively add new code to constrain
      how data is transmitted, or to permit variations what is received.

   o  Errors in implementations, or confusion about semantics can
      thereby be masked.

   o  As a result, errors can become entrenched, forcing other
      implementations to be tolerant of those errors."

[https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00]

What you are doing in your emails is asking us to do take further steps in
this protocol decay, to benefit the people sending wrong data.

And for now, we have better things to do. 

	Bert