DNS zones ending in err suddenly??

Discussion in 'ISPConfig 3 Priority Support' started by ledoktre, Apr 29, 2014.

  1. ledoktre

    ledoktre Member


    I've been working towards setting up the panel to manage domain dns as we transfer websites into it. All have worked fine so far, and we employ a hidden / masked primary server, and only publish the secondary.

    So I have a domain that I modified today, and now it shows up with a .err on the end. I had no idea, it just stopped working when I discovered that.

    Thinking it might help, I told the panel to resync dns zones. Now I've got like 4 of them ending in err.

    Ive looked around in the logs and Im not even sure where to look to find what its issue was --

    So question 1: How do I tell what issue its having with the zone definition? It looks fine to me.

    Question 2: Is there any mechanism in place to alert either msyelf or customers when they may create a bugger and it effectively destroys their domain dns existence (by renaming to err)?

    Trying to resolve -- but need some answers.


  2. ledoktre

    ledoktre Member

    How I figured it out :

    cd /etc/bind/
    ls -l #check for pri.[].err
    named-checkzone domain.com pri.domain.com.err

    The why:

    In the previous version of ISPConfig3 ( I was using, it seemed like I could add an MX record by inputting the server it was connecting to, the priority, and that was it (it seemed to default to the main domain itself if not specificied).

    This time around, running, that's not valid-- so when I modified one zone today, it ran checks and said uh oh! err! On the server itself anyway...

    Not good?:

    So I just figured out you can input NS records and MX records without filling in the hostname box (and thats all I have tried?). I added a test MX record to a domain without filling in a hostname. It added it, no err. When I test with the above tool, it reports fine. When use dig, it reports fine.

    So what caused it to freak out? Not sure. I am going to resync right now, see if it flags it as an err file. Done. This time it did not set any to err (last time was 5 or 6 of them).

    So if its important to the checking mechanism that the hostname be present, perhaps there should be some error checking on the add/modify screen in ISPConfig? Or have the system fill in the domain automatically. My concern for this is if customers create a record without the hostname filled in (which a lot of other managed dns will accept this), and the domain just tanks (changes to err) they have no visual interaction to know what just happened.

    I am a little nervous now honestly, when is one going to change itself to err again?
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    You dont have to fill in the hostname. The hostname can either stay empty or it has to be the full hostname, ending with a dot.

    Customers normally use the dns wizard, this ensures that they get a complete zone with all nescessary records that you as admin defined in the zone template.

    It is logged with loglevel warn. so you can look this up in the system logs when you have set the loglevel for that server to warning instead of error.

    Zones never change itself to .err. The .err files get created when you update a zone file and bind rejects to load it. The process is quite simple and straight forward:

    1) ISPConfig writes the zone file, e.g. pri.example.com
    2) ispconfig lets bind check the zone with the named-cehckzone command.
    3) If named-checkzone returns taht the zone file contains syntax errors and will not get loaded by bind, then the file is renamed to .err so that the admin can investigate the problem.

    If the file would not have been renamed, then bind would simply have ignored it and not loaded its content. older ispconfig versions did not checked the syntax with named-checkzone, so the zone just did not work then.
    Last edited: Apr 29, 2014
  4. GrafPorno

    GrafPorno New Member

    We`re experiencing the same problem with our Multiserver-Setup. If we change or just open an existing zonefile, we`re receiving the error/warning-mails and Bind changes the zonefiles to *.err.

    This is how the zonefile looks like:
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    try to change your zone to use the zone name for the ns records like the ispconfig dns wizard does it. so instead of:

    3600 NS ns01.domain2.de.
    3600 NS ns02.domain2.com.
    3600 NS ns03.domain2.de.


    domain.de. 3600 NS ns01.domain2.de.
    domain.de. 3600 NS ns02.domain2.com.
    domain.de. 3600 NS ns03.domain2.de.
  6. GrafPorno

    GrafPorno New Member

    this works. problem is, from now on we cannot just take a look at the zonefiles - we then have to change all the entrys.
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    does this work:

    NS ns01.domain2.de.
    NS ns02.domain2.com.
    NS ns03.domain2.de.

    and does this work:

    @ 3600 NS ns01.domain2.de.
    @ 3600 NS ns02.domain2.com.
    @ 3600 NS ns03.domain2.de.
  8. ledoktre

    ledoktre Member

    Hey fellas,

    Been a bit busy these past few days. Just checking in. Im glad to see its not just me seeing that behavior - it helps me feel better that its not just me.

    When I wrote something about my fear of the domains just randomly deciding to change themselves to err, thats just what I meant. I used the wizard to create all zones so far. Some of them I'd add in MX records. One of them I removed the default NS records and added some temporary NS records (long story, has to do with migrating from managed to secondary DNS on my provider).

    Every one of them worked fine.

    When the issue came up, was when I had things sorted out, and needed to switch the NS records back. I removed the temporary ones, added my good ones in (with no host filled in, just nameserver) and saved it. Thats when the first one went to err.

    It took me a while to figure out what happened (and during that time I opened this ticket), and in fixing it, I tried also resyncing the dns zones (in the ISPConfig menu). Suddenly maybe half of my domains went to err, previously were working fine.

    When I ran the zone check on each of them, they were complaining about the MX records. I added the host name in on each one, saved them, problem went away. On the original one, the only way I could make the error go away was to add the hostname to the NS records.

    So that was when I mentioned my fear - if customers create custom records themselves without filling in the hostname (which I am guessing many will -- I did), it appeared to me like it might work, it might work until later when they change some other unrelated record, or it might just err immediately.

    That was why I suggested that if the hostname was required, it should have error checking built in.

    I am glad to hear that the hostname is not required, but then it draws me to the question, why did I have these failures then?


  9. till

    till Super Moderator Staff Member ISPConfig Developer

Share This Page