Paul A Vixie writes:
In my book, it is better to conform to the protocol, or change it, then to have implementations drift in all directions.
No-question-asked consumption of bogus information can hardly be called a better conformity to the protocol. And, as I see it, there's nothing inherently wrong with the good old RFC-1034/1035/1123. Granted, some places could be more clear, but an implementation of the protocol can rather easily deal with the ambiguities and omissions. As of my stop gap (I emphasise - _stop gap_) patch and your examples of when it doesn't work - I never wrote it's _the_ solution, and it doesn't exactly jibe with the RFC-1034's wording about the behaviour of a delegating server WRT glue records - it relies on the delegating server's ability to respond with queries about A records of the servers it delegates the authority to as if these records were validly cached records (and named does exactly that). In the note accompanying my patch I wrote about what the correct (IMHO) behaviour should be like. Your example when my proposal doesn't work is effectively a loop in the chain of hierarchy, and is not better, in my view, than loops in CNAME chains. As of the financing the bind project - if asked, I wouldn't recommend to participate in it, as it's one mess of a project and the amount of time and money necessary to produce a robust operational product is comparable with the amount of time and money necessary to create a new product from scratch, addressing the operational issues in its very design. Too bad the major OS vendors don't usually have a clue and stick to the freely available product of an experimental, demonstration-of-concept project. Dima