plain lxc:

lxc-start -n dns -d

I am pretty sure it is not restarting.
e.g. an open shell session would be destroyed on a restart (lxc-attach)

The filesystem is not versionable to have access to the previous old zone file.

-rsd

On 07/02/2017 19:43, Warren Kumari wrote:
This really sounds like the zone file is *in* the container itself, and that the container is restarting. You said that this is running under LXC -- is this actually a Docker container? How are you starting the container?

W


On Tue, Feb 7, 2017 at 11:35 AM, Raul Dias <r...@dias.com.br <mailto:r...@dias.com.br>> wrote:

    I know.

    So far, the only files changed are the ones I changed myself, like
    bind config files and vimrc.

    No hidden toolkit found too.

    I still think that it is easier to be a misconfiguration done by
    myself.

    Still looking for better indications that this could be the case.


    On 07/02/2017 12:42, Alberto Colosi wrote:

    IP ports not open does not mean is not hacked.

    a vulnerability can be used to make a change or an access


    try to change and audit file access and permission firewall log
    analisys can give a plus to find a solution (check all IP traffic
    out from TCP/UDP 53)


    If you have RNDC , change KEY or disable it




    ------------------------------------------------------------------------
    *From:* Raul Dias <r...@dias.com.br> <mailto:r...@dias.com.br>
    *Sent:* Tuesday, February 7, 2017 3:34 PM
    *To:* Alberto Colosi; bind-users@lists.isc.org
    <mailto:bind-users@lists.isc.org>
    *Subject:* Re: bind 9 goes rogue and revert zone information

    Sorry,
    Static files.
    It is the master server.
    No dynamic updates.
    Host under lxc with only bind ports open.


    On Tue, Feb 7, 2017, 12:27 Alberto Colosi <al...@hotmail.com
    <mailto:al...@hotmail.com>> wrote:

        hi is unclear named structure if is a slave a master if
        dynamic updates are enabled and if the unix box has been hacked

        as last , zones are static files on fs ?



        ------------------------------------------------------------------------
        *From:* bind-users <bind-users-boun...@lists.isc.org
        <mailto:bind-users-boun...@lists.isc.org>> on behalf of Raul
        Dias <r...@dias.com.br <mailto:r...@dias.com.br>>
        *Sent:* Tuesday, February 7, 2017 3:03 PM
        *To:*
        <mailto:bind-users@lists.isc.org>bind-users@lists.isc.org
        <mailto:bind-users@lists.isc.org>
        *Subject:* bind 9 goes rogue and revert zone information
        Hello,

        I have a very strange behavior that I am failing to understand.

        2 to 5 times a week, a named server revert back to a previous
        version os
        a master zone.
        This happens during the night, usually around 20h EST.

        This zone has a serial of 3017020401
        <tel:%28301%29%20702-0401> (yes, I typo the 3 somewhere in the
        past).
        When it reverts its zone information, it goes back to
        3016060101 <tel:%28301%29%20606-0101>.

        I have updated, restarted the host, clean all cache and
        journal files,
        grep all files in the host for 3016060101
        <tel:%28301%29%20606-0101> (just shows up in the logs).

        So, I have no clue why, or how it is happening. Where does it
        get the
        old information.

        I thought first about the serial, but it would have happened
        in the past
        too, right?  As it should be a 32bit unsigned integer, it
        shouldn't be a
        problem, IMHO.

        Yet, when "dig domain -t SOA @server", it is there again.

        The host is a debian Jessie and bind is 9.9.5,
        1:9.9.5.dfsg-9+deb8u8
        more specifically.


        Thanks for any direction.
        -rsd
        _______________________________________________
        Please visit
        https://lists.isc.org/mailman/listinfo/bind-users
        <https://lists.isc.org/mailman/listinfo/bind-users> to
        unsubscribe from this list
        bind-users Info Page - Internet Systems Consortium
        <https://lists.isc.org/mailman/listinfo/bind-users>
        lists.isc.org <http://lists.isc.org>
        To see the collection of prior postings to the list, visit
        the bind-users Archives. Using bind-users: To post a message
        to all the list members, send ...



        bind-users mailing list
        bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
        https://lists.isc.org/mailman/listinfo/bind-users
        <https://lists.isc.org/mailman/listinfo/bind-users>
        bind-users Info Page - Internet Systems Consortium
        <https://lists.isc.org/mailman/listinfo/bind-users>
        lists.isc.org <http://lists.isc.org>
        To see the collection of prior postings to the list, visit
        the bind-users Archives. Using bind-users: To post a message
        to all the list members, send ...



-- Att. Raul Dias


    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users
    <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
    from this list

    bind-users mailing list
    bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
    https://lists.isc.org/mailman/listinfo/bind-users
    <https://lists.isc.org/mailman/listinfo/bind-users>




--
I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

--
Att. Raul Dias

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to