Bug 510290

This report is a dup of https://bugzilla.redhat.com/show_bug.cgi?id=523973

I agree that named.conf should not be modified by software ... this is a "user"
defined configuration file.  BUT, if it is modified, then the modification
should WORK!  It currently does not.

Yes, it works for simplistic cases but does not handle the actual free-form
officially allowed for named.conf.  Specifically, it does not parse "options"
correctly.  If the left-brace after options is on a separate line, it screws
up.  If (as in my case) I use multiple physical lines for lists of ip-numbers
with "};" on a separate line, it screws up.

Yes, you can edit named.conf so the problem will not occur but this should not
be necessary.

Even if "options {" is in the same line it will break

Below our original config, the 3 kines are inserted into allow-recursion-block instead after or before and that is not the last problem

Even if this change would work it makes troubles of a forward-server to enable dnssec implicit, this machine did not resolve external domains with dnssec because if there are no settings in named.conf they are implicit set to yes

I had to set the new lines manually to "no" to get forwarder working again and this is a real problem - Fine that dnssec is fully supported, but never ever it should enabled by a update. In this case it was nt soo bad to see the wrong lines because they pointed my what i have to disable to get all working again but this is luck in one specific case

options {
 directory             "/var/named";
 dump-file             "/var/named/data/cache_dump.db";
 statistics-file       "/var/named/data/named_stats.txt";
 forward first;
 forwarders            {85.124.176.242; 195.206.96.86;};
 allow-transfer        {10.0.0.6; 10.0.0.41; 10.0.0.245; 10.0.0.106;};
 listen-on             {10.0.0.6; 10.0.0.106; 127.0.0.1;};
 notify                yes;
 also-notify           {10.0.0.106;};
 allow-update          {none;};
 cleaning-interval     60;
 max-ncache-ttl        60;
 querylog              no;
 recursion             yes;
 dnssec-enable         no;
 dnssec-validation     no;
 allow-recursion
 {
  local-network;     /* 10.0.0.x Netzwerk */
  127.0.0.1;         /* localhost */
  84.112.188.198;    /* stock-home */
  62.178.218.100;    /* harry-home */
  80.108.8.51;       /* peter-home */
  195.202.178.123;   /* ingo-home */
  91.113.241.194;    /* flow-home */
  88.117.199.142;    /* office.alufenster.at */
  195.34.140.69;     /* Lounge-IP nach aussen */
  195.34.141.18;
  195.34.141.19;
  195.34.141.20;
  195.34.141.21;
  195.34.141.22;
  195.34.141.23;
  195.34.141.24;
  195.34.141.25;
  195.34.141.26;
  195.34.141.27;
  195.34.141.28;
  195.34.141.29;
  195.34.141.30;
  195.34.141.31;
  195.34.141.32;
  195.34.141.33;
  195.34.141.34;
  195.34.141.35;
  195.34.141.36;
  195.34.141.37;
  195.34.141.38;
  195.34.141.39;
  195.34.141.40;
  195.34.141.41;
  195.34.141.42;
  195.34.141.43;
  195.34.141.44;
  195.34.141.45;
  195.34.141.46;
  195.34.141.47;
  195.34.141.48;
  195.34.141.49;
  195.34.141.50;
  195.34.141.51;
  195.34.141.52;
  195.34.141.53;
  195.34.141.54;
  195.34.141.55;
  195.34.141.56;
  195.34.141.57;
  195.34.141.58;
  195.206.96.86;
  195.206.96.87;
  195.206.96.88;
  195.206.96.89;
  195.206.96.90;
 };
};

can you try with "allow-recursion {" instead of
"allow-recursion
 {
" ?

I guess that the problem is not related with "option" or "allow-recursion" but with the fact that the '{' if not on the same line than "option" or "allow-recursion".

I also agree that automatic updates should not kill config files.

Sorry, i cannot reproduce because all or 16 fedora-installations are already updated except our main-nameserver but this upgrade has to wait until F10 is out of support because this machine is really critical and i'm not on best health this time

I have been looking into this problem.  The problems are with the /usr/sbin/dnssec-configure program which is part of the dnssec-conf package.  This program is written in python and I am not python literate so a patch/fix will need to be done by someone else.

I have looked into the upstream creator/maintainer and there is no advertized means of reporting bugs ... the source is made available and that is it.

You do not need a real name server to work on this ... just a Fedora 11 (or 12) system.  Install the bind and dnssec-conf packages.  Then create a valid /etc/named.conf file (I used /etc/named.named.bak as my base).  I added a "forwarders" statement to the configuration.  I started named to make sure my /etc/named.conf file was good ... it was.  To do my testing, I did not start/run named but simply used the following command:
  /usr/sbin/dnssec-configure -b --norestart --dnssec=off --dlv=off

The problem is that dnssec-configure does not properly parse the "options" statement.  While named (see named-checkconf) allows statements and sub-statements to be on multiple lines, dnssec-configure does not.

Specifica problems:

1.  An option statement is not recognized unless it is immediately followed by a left brace ("{") on the same line.  As far as I can determine, additional left braces in substatements are ignored.

2. The program then looks for dnssec-<whatever> statements on separate physical lines OR the next right brace ("}") which it assumes is the end of the options statement.  This is wrong as it could be a sub-statement such as forwarders with a list of IP addresses and a right brace on a separate line for readability.

3. Given the apparent simplistic nature of parsing used by dnssec-configure, there are likely other ways that this program could screw up your /etc/named.conf.

Current workaround ... "don't do that ... it hurts"

That is, make sure that the options statement is immediately followed by a left brace and that no right braces are on a line by themselves.  For multi line statements, put the "};" at the end of the last item in the list.

BTW, I am a bit bothered that the Fedora package maintainer has not said anything concerning this bug.  I am not expecting him to fix this ... it needs to be fixed upstream.

*** Bug 523973 has been marked as a duplicate of this bug. ***

BTW, given that this problem has no clear resolution, there should be documentation provided in Release Notes or somewhere which documents the problem and explains how the work-around.

Oops ... there is an even erlier report and the fix is suppose to be in dnssec-conf 1.22 (bugzilla comment dated 2009-06-25)

*** This bug has been marked as a duplicate of bug 505754 ***