DNS contamination

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.