In message <5a89161c-702d-4093-af15-966cbc724...@cornell.edu>, John Wobus writes: > I assume ISC does not deliberately insert aborts > triggerable by bad data in DNS queries and answers. > Much more likel,y they do it when something happens > that is supposed to be logically impossible whatever the > incoming data, and implies continuing to run is > potentially insecure and/or will just create a > subsequent, more obscure crash. I assume the fact > that bad data triggered an abort is due to a bug. > > That said, in this case they might be changing this > specific abort to a warning, fixing up what state > they can and crossing their fingers. > > John
Data errors are supposed to be non fatal. We just reject bad data. The INSIST/REQUIRE/ENSURE assertions are there to detect coding errors or logic errors. They are very good at catching coding errors very early in the development process. This INSIST was there to catch something that was logically impossible. At the moment we are trying to work out how the logically impossible happened and then if we want to stop it or to say that our logic was wrong and this is a reasonable state for the cache to get into. The patch assumes the latter. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users