|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Reasons why BIND isn't being upgraded
[ On Thursday, February 1, 2001 at 22:16:13 ( -0800), [email protected] wrote: ] > Subject: Re: [NANOG] Re: Reasons why BIND isn't being upgraded > > Out of curiosity, why? Because (as you quoted from RFC 1035): > 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. I.e. I thought it was self-obvious. Records are one per line unless an open parenthesis `(' or double quote `"' is encountered in which all fields up to the closing `)' or `"' are part of the current record even if there are intervening newlines. What more justification do you need? The parenthesis aren't part of the record -- they're just a way of getting the additional values onto separate lines. If you put all those numbers on the same line with the rest of the record then you don't need the parenthesis at all. This was one of the very first lessons I learned when I wrote my very first zone file and tried to do something with parenthesis that didn't work like I naively expected it to. Yes the master file format goes against the grain of modern data file interpretations, but, well, nobody's written a new RFC and proposed that it replace 1035 yet, so we're still stuck with it. Personally I'd like to at least do away with the semi-colon as the comment character, but I'm not going to write a new RFC and push it through the IETF just for that! ;-) > 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. well you might want to look at the date on RFC 1035, and even more particularly at the dates of the RFCs it supercedes. Back in 1983 the tools available to deal with this kind of data were very different and possibly much more restricted. All the world was not yet a VAX back then, it was still a PDP-11! :-) However the real clue is (again from RFC 1035): 5.1. Format [[ ... ]] The following entries are defined: [[ ... ]] <domain-name><rr> [<comment>] <blank><rr> [<comment>] [[ ... ]] The last two forms represent RRs. If an entry for an RR begins with a blank, then the RR is assumed to be owned by the last stated owner. If an RR entry begins with a <domain-name>, then the owner name is reset. I.e. if a line begins with whitespace then it is a new record that defaults to having the same domain name (and class) as the previous record. So, a modified example like the one you've used for the SOA: @ IN SOA master contact ( 1 2 3 4 5 ) is interpreted as this: @ IN SOA master contact @ IN 1 2 3 4 5 Now what? Both records are broken, with missing fields for the SOA, and an invalid type (`1') and probably too many fields for the next line! > ...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. Sure, BIND was OK when handling this one very special case, but since the master file format is intended to be portable to other implementations, the question to as is whether some other conforming implementation could mis-interpret this kind of error and cause the zone to be rejected, and the answer is most certainly YES! Sure BIND could do away with support for RFC 1035 standard master file formats, but where would that get us with so many other tools generating and parsing these files? > So: Why? The fact that pre-8.3 versions of BIND will accept > @ IN SOA > ( ns.whomever.com I'm not so sure they all can. You might want to check the pre-8.x versions before asserting this. IIRC this sloppyness is a relatively recent abberation in BIND. -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|