[Pdns-users] Re: Verify PowerDNS answers?

[Alex van den Bogaerdt]

On Fri, Oct 13, 2006 at 04:33:45PM +0200, bert hubert wrote:

> Dan referred me to: 
>  
>  http://groups.google.com/groups?selm=199912080700.XAA18392%40bb.rc.vix.com
>  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01586.html
>  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01600.html


> It is somewhat muddy.

This I do not agree with.  Reading _only_ those three messages and you
could believe that, but reading the rest of the responses shows how this
is simply clear as can be.

The first "evidence" (groups.google.com/...) was recalled by Paul Vixie.
He made a mistake. See
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01595.html

The other thread shows how rfc 2308 does NOT say NXDOMAIN is allowed.
Only djb thinks this is the case.  He somehow thinks rfc 2308 altered the
behaviour of rfc 1034, despite several people telling him this is not
the case.

Apparently he is still using the *mistake* of Paul Vixie as evidence to
support his claim, eventhough he must be aware Vixie came back on his
earlier words.  I cannot tell what I think of djb's actions, as that
would probably end up in someone's sig ...


Also: I see a couple of claims from djb that "a huge number of servers
use NXDOMAIN...".  So far, I only noticed pdns myself, and I am sure
djb's stuff will also do it the wrong way.  Are you aware of any
significant products that use NXDOMAIN in the case where the domain
actually does exist and does not have a CNAME RR attached?  Buggy bind
versions don't count, as they have acknowledged the bug and repair it.

> It is somewhat muddy. For now, that means we are not going to overhaul
> PowerDNS to comply with behaviour nobody actually uses, or can even rely on.

Well, this nobody started looking for pdns because his provider's
name server did not behave as expected.

Indeed, if bugs aren't fixed, I cannot rely on proper behaviour.

> Normally I'm all in favour of following RFCs as closely as possible, but I
> don't see a solution to this problem that does not kill our database
> performance w/o overhauling our storage model.

Now this is something I can understand.  I mean the statement, not the
technical cause for the statement.

> To comply while retaining performance, we'd need to reverse our name storage
> so 'www.powerdns.com' gets stored as com.powerdns.www, and we'd have to
> start using 'like' queries.

I don't see the problem.

If "www.x.powerdns.example" needs to be added, and if "x.powerdns.example"
does not yet exist, can't you just add this domain to the same database?
It doesn't have to be at query time.

1: Strip one label; "www.x.powerdns.example" becomes "x.powerdns.example"
2: Does the domain exist?
2a: no: add the domain to the database
2b: yes: do nothing
3: add the original domain to the database

After all, this is what's happening: two domains are created at the same
time.  Only one of these domains has one or more resource records.

Now queries will work.  The RFC2308 case does not apply, as there is
no CNAME record that could point to a non-existing domain. 

> Perhaps someone else, smarter than I am, can come up with a solution. As
> nobody noticed our possible non-compliance for 7 years straight, I'm rather
> unwilling to overhaul things as you might understand.

There's this new protocol, that uses "exists".  It does not look at the
resource records at all, it only cares if the domain does or does not
exist and uses that information.

This protocol did not exist for the larger part of those 7 years. The
protocol was written with RFCs in mind.  Apparently pdns was not used
in tests; until I happened to stumble upon it.

You can probably see why I don't consider your statement to be a
valid argument.  The bug stayed hidden for 7 years.  That does not
necessarily mean the bug won't be noticed during the next 7 years.

regards
Alex