Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Reasons why BIND isn't being upgraded

  • From: Greg A. Woods
  • Date: Fri Feb 02 02:38:58 2001

[ On Thursday, February 1, 2001 at 22:16:13 ( -0800), 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

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
>                     (

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      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.