On Thu, 1 Feb 2001, Derek J. Balling wrote:
According to RFC1035, it's ALWAYS been bogus. It's just been a bug that BIND's parser that accepted the bogus data.
Out of curiosity, why? Okay, we'll accept that that's the way it is, and I'm not going to rail about how it shouldn't be, but let's try to understand Mr. Mockapetris' reasoning in this. I see this from the RFC (that lists P. Mockapetris as author, for those who don't place the name): The format of these files is a sequence of entries. Entries are predominantly line-oriented, though parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text. also: ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. The only clue I can find to his reasoning is: Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. ...which is patently untrue, given that BIND didn't need those special encodings; it worked just fine without the particular one that we're all beyond bored of hearing about. So: Why? The fact that pre-8.3 versions of BIND will accept @ IN SOA ( ns.whomever.com and etc. does not seem like a huge issue to me, though fixing that in thousands of issues does. What's the big deal with leaving it non-compliant? Matthew Devney