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 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
