Good BIND design. was RE: PLEASE READ: BIND 8.2.2 problem

Tony Earnshaw tearnshaw at landis.nl
Sat Apr 29 12:57:40 UTC 2000


Adam Augustine wrote:

> If you intend to respond to this post, I would politely ask you to read the
> entire post carefully, then think about it for a few moments, before
> responding.

Well, I have done. Actually, I'm rather jumping in at the deep end.
since I always start at the last posting and work my way backwards. So I
haven't followed this thread, which at this point, unfortunately, has
been broken.

My own thoughts on your notes are, that they are well thought out,
plausible and convincing.

However. As a Unix/Microsoft network administrator (Microsoft is forced,
Unix is and will continue as my first love - it's an attitude) in the
full sense of the word, I'm subjected to an ever increasing number of
ISPs and administrators who cannot configure their nameservers.

I've deliberately chosen to run BIND 8.2.2-P5 on account 1: of CERT
recommendations, 2: configurability and 3: keeping up with the Joneses.

My primary complaint is that people deliberately bodge up their
configurations in the holy name of 'progress and diversity' in a manner
that makes it impossible to cope with the services they're attempting to
offer.

The primary complaint is against organizations who have zone A records
but no PTR records referring backe to them.

I don't yet have problems with other, broken, name servers, because the
marvellous 'bogus' possiblility gives me the chance of multiple
exclusions, should I so wish. And I do make full use of it.

I'm all in favour of any future measures taken to enforce admins to read
up on and adhere to any rules stipulated in the relevant RFCs, or face
exclusion from the Internet. I don't care how it's done, as far as I'm
concerned, it can be done by the nameserver software itself or a higher
authority.

I'm sick of reading that Microsoft solutions provide extensions to RFCs
in the name of progress and inovation. A single reading of the Halloween
papers should be enough to frighten the life out of most network
administrators.

I believe that any flexibility in the existing rules should stem
inexorably from RFC and IETF based recommendations, with CERT additions.
I also believe that admins who cannot be bothered to adhere to them
should be made to suffer.

I find it hard enough to have to accept that people with minimalist
qualifications in their profession may run about and call themselves
'engineers'. Why should one have to accept that doctors of medicine
should be pardoned from making mistakes that kill their patients? Why
should one accept that automobiles capable of speeds in excess of 300
Km/hour should be allowed to do so when the drivers consider it
necessary?

By all means introduce means of constraining the doctors from carrying
out their intentions (recently, Dr. Harold Shipman in England was
convicted of killing at least 50 people, who he considered should be
dead, whether or not they were sick or healthy,  with overdoses of
morphine. He is not likely to appeal against the conviction) and some
kind of speed control on those automobiles.

By all means make it possible to correct errors made in DNS
configurations at the time of implementing DNS servers. But do not make
it possible for people without the necessary knowledge to force their
presence on the rest of the community, making life more than necessarily
difficult than it is for the latter.

Summing up: more adherence to present rules, less possibility for
anarchistic deviation and punishment for those that break the rules.
Rules should be made by the rule makers and any proposal for deviation
from present rules should be submitted to the rule makers and NOT their
agents.

Tony
Frustrated

-- 

****************************************************************
  Landis ICT Systems
  Tony Earnshaw
  Systems Administrator		e-mail: tearnshaw at landis.nl

  Randstad 21-57
  1314 BH  Almere-Stad		tel: +31 (0) 36 548 50 10
  The Netherlands		fax: +31 (0) 36 534 05 34
********************* http://www.ilion.nl **********************



More information about the bind-users mailing list