DNS - validate record BEFORE saving

Discussion in 'Feature Requests' started by Jan Jurko, Oct 29, 2020.

  1. Jan Jurko

    Jan Jurko New Member

    Hello all. Current situation:
    ISPconfig -> edit dns record -> insert some not correct records like A and CNAME to the same target -> save -> ispconfig updates the zone file and run the check via named-checkzone. If the check fails, the zone file is renamed to .err and kicked out from the bind without any warning. The correct behaviour should be you enter some bad records, ispconfig will check it and tell you there is an error and will not save it to the zone file.
    Thank you :)
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Why would that be more correct than the current behaviour?
  3. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    You posted in the ISPConfig 2 board, but I guess you are using ISPConfig 3.

    We have several checks in place to make sure there are no broken records inserted, and in my experience, this almost never fails. If it does, we improve the checks. The named-checkzone is a kind of last option if all other checks passed but something is wrong.
  4. Jan Jurko

    Jan Jurko New Member

    The problems are records for example if you have the same "A" and "CNAME" record for the same name, the error is: "dns_master_load: pri.test.cz.err:15: subdomena.test.cz: CNAME and other data". The syntax of A and CNAME is ok but these 2 records together are zone error for bind. This will disable the whole zone and should be checked before saving the zone.
  5. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    It is not possible to create a CNAME and A record with the same name in 3.2. There is a check that prevents duplicate entries for A/CNAME/DNAME and AAAA/CNAME/DNAME
  6. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    In addition to the specific checks so you can't create an A and a CNAME for the same record, this does not happen in current ISPConfig, either; if an error is made in dns records so the zone can't be loaded, the zone file is indeed renamed to .err, and the previous zone file is put back in place, so the zone is not disabled.

    If you see this behavior, maybe you are running ISPConfig 2 after all?

Share This Page