[bind10-dev] Resolver testing

[Shane Kerr]

Jerry,

On Wed, 2010-11-03 at 08:09 -0700, Jerry Scharf wrote:
> > On Tue, 2010-11-02 at 08:21 -0700, Jerry Scharf wrote:
> >> I will point out one interesting aspect for this.
> >>
> >> There are things out there that are at best ambiguous relative to the
> >> RFCs. In these cases, if it works for BIND 9, it needs to work for BIND
> >> 10. I remember at one point that merit.edu had a very strange setup that
> >> really made no sense. But since it worked with BIND 9, it had to be made
> >> to work on all other recursive servers. So having tests that compare
> >> answers from BIND 10 with BIND 9 may be an useful.
> >
> > This is indeed interesting. To be honest, I think we will discover all
> > kinds of unanticipated behavior with BIND 9 and have to make some
> > decisions about how closely to follow it. We may even take the
> > opportunity to document these as an informational RFC....
> >
> > Like with your merit.edu example, Jelte tells me that a big problem with
> > Unbound development is that people say "it works with BIND" and expect
> > all other products to follow, regardless of what standards say.
> >
> > Fun times!
>
> The reason the "It works with BIND 9" argument works so well is that we 
> want people to convert. If we cut a BIND 10 user off from people they 
> want to interact with, it usually doesn't matter to them what some RFC 
> says. As they see it, they want to talk to XYZ and you are stopping them.
> 
> A clarification to the RFC is a good thing and there is a precedent for 
> that in DNS. It may make some people change to do the right thing. 
> Unfortunately, I see it as independent of the conversion problem above.

I think you misunderstood me slightly.

My point was not that we should ignore BIND 9 compatibility, but rather:

     1. There may be cases where BIND 9 is WRONG. In these cases it
        becomes more problematic to simply say "we will be BIND
        9-compatible". Our options here will depend on the specifics.
        For example in AXFR setup we may default to BIND 9 compatibility
        and warn about it, or perhaps require a "BIND 9
        bug-compatibility" option be set, since these will require
        administrator setup anyway. For query behavior, we probably want
        to default to silently ignoring brokeness (as opposed to
        spamming logs or other unproductive behavior, like when some
        versions of BIND complaint about lameness). In all cases we can
        probably rely on the BIND 9 team to fix problems that we find,
        but that doesn't solve the code running in the wild.
     2. No matter how we decide to address these issues, it makes sense
        to document the behavior of BIND 9 rather than relying on
        developers having hard-won secret knowledge about various corner
        cases.

--
Shane