bind-9.5.0b1 problem on ppc64 : rbtdb.c:1532: REQUIRE(prev > 0) failed

[Res]

On Tue, 5 Feb 2008, Fajar A. Nugraha wrote:

>> route to a primary end user DNS, IOW, eg: end users are all asigned
>> ns3.blah and ns4.blah, ns3, is duplicated in every PoP, all has the same
>> IP but each PoP has a route for that IP locally so it doesnt have to
>> traverse the country back to our data centre,
>
> Aha. Good setup. I might try this. I believe this is also how the local root
> name server in my country was setup.

Yep, much the same.

> Similar setup, but we don't recommend our users adding authoritative DNS to
> their resolver.

ours too, and they cant, our auth servers only respond for their domains 
if tehy try us eit for anything else they get refused.

> Is this a best-practice? How does bind handle this situation anyway?

I think so :) distributes the load nicely
also found it a good idea to run a local cached version of bind on 
loopback interface only on any front end MTA servers that are busy, saves 
lots of time with RBL tests.


> e.gwhen this happens :
> - user add an authoritative DNS as their resolver, as well as a caching one
> - user query a domain not in authoritative DNS
> - authoritative DNS rejects the query
>
> will the user automagically try again to other DNS servers (in this case the
> caching one), or will the query fail?

this all depends on how well their client is written, but 99% of the times 
yes, it moves on to the next dns server in their list, the only time it 
will fail to move through the list is if the auth server returns NXDOMAIN

> Yes, I do have query logging enabled.

that will impact soon enough :(


> I wouldn't say we have "instant lookup", but "dig" usually show lines
> similar to these :
> ";; Query time: 221 msec"


221ms? are you querying your own server?
it should be only a few, mines 3ms, I get 200 odd if I use A-root which is 
fair enough since its in another country :)


>> A P4 isn't sufficient for that (not in my experince, anyway)
>>
>> well, I dont recommend it, but it shows it can be done if you have nothing
>> else available in the middle of the night :) It handled it very well.
>
>
> Your hardware is obviously enough to serve all your needs then.

always handy to have a P4 at PoP's that we can use to play with, dirt 
cheap and rather handy as a short term emergency server, but as desktop 
hardware is not designed for real server loads, its best as short as 
possible lol.

> Thanks for sharing information about your setup.

no probs, glad your all sorted out now.

-- 
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';