Re: Enforce EDNS

[Daniel Stirnimann]

> Named doesn't have a switch to force EDNS though I suppose we could
> add one to 9.12.  e.g. server ... { edns force; };

I would find this useful.

> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will fail.  That manual work arounds will now have to
> be done. e.g. "server ... { send-cookie no; };"

I can only speak for the DNS resolvers I'm operating but I would be
willing to accept that. At some point in time, those broken name servers
need to be fixed. If more users start sending complaints to the name
server operator that might help.

Daniel
___
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

Re: Enforce EDNS

[G.W. Haywood]

Hi there,

On Tue, 7 Feb 2017, Mark Andrews wrote:


I really don't want to add new automatic work arounds for broken
servers but it requires people being willing to accepting that
lookups will fail.  That manual work arounds will now have to be
done. e.g. "server ... { send-cookie no; };"


+2

--

73,
Ged.
___
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

Re: Enforce EDNS

[Matus UHLAR - fantomas]

In message , Daniel Stirnimann 
writes:

Hello all,

Our resolver failed to contact an upstream name server as a result of
network connectivity issues. named retries eventually worked but as it
reverted back to not using EDNS and the answer should have been signed,
the query response failed to validate. Subsequent queries towards this
upstream name server were not utilizing EDNS as well because named
remembers a name servers capabilities for some time (See also
https://deepthought.isc.org/article/AA-00510/0)

My question is, can I enforce EDNS usage for a name server? I was
thinking of the 'edns' clause in the server settings [1]. However, this
is already enabled by default and only applies to an "attempt".


On 07.02.17 11:59, Mark Andrews wrote:

I've also been thinking about no longer falling back to plain DNS
on no answer.  False positives on not supporting EDNS impact on
DNSSEC resolution.  Most firewalls now pass EDNS and most of the
old Microsoft servers that don't answer a second EDNS request are
gone.  Any remaining servers would then need to be handled via
server ... { edns no; };

Unfortunately we then need to decide what to do with servers that
don't answer EDNS + DNS COOKIE queries.  Currently we fall back to
plain DNS which works except when there is a signed zone involved
and the server is validating.


fall back for how long? maybe for the same random time as RTT measurements
are done - remember for a while, but retry with edns on after.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
___
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

bind 9 goes rogue and revert zone information

[Raul Dias]

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 (yes, I typo the 3 somewhere in the 
past).

When it reverts its zone information, it goes back to 3016060101.

I have updated, restarted the host, clean all cache and journal files, 
grep all files in the host for 3016060101 (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 to unsubscribe 
from this list

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

Re: bind 9 goes rogue and revert zone information

[Alberto Colosi]

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  on behalf of Raul Dias 

Sent: Tuesday, February 7, 2017 3:03 PM
To: 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 (yes, I typo the 3 somewhere in the
past).
When it reverts its zone information, it goes back to 3016060101.

I have updated, restarted the host, clean all cache and journal files,
grep all files in the host for 3016060101 (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 to unsubscribe 
from this list
bind-users Info Page - Internet Systems 
Consortium
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
https://lists.isc.org/mailman/listinfo/bind-users
bind-users Info Page - Internet Systems 
Consortium
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 ...


___
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

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

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  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  on behalf of Raul
> Dias 
> *Sent:* Tuesday, February 7, 2017 3:03 PM
> *To:* 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 (yes, I typo the 3 somewhere in the
> past).
> When it reverts its zone information, it goes back to 3016060101.
>
> I have updated, restarted the host, clean all cache and journal files,
> grep all files in the host for 3016060101 (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 to
> unsubscribe from this list
> bind-users Info Page - Internet Systems Consortium
> 
> 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
> https://lists.isc.org/mailman/listinfo/bind-users
> bind-users Info Page - Internet Systems Consortium
> 
> 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
> ...
>
>
___
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

Re: bind 9 goes rogue and revert zone information

[Alberto Colosi]

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 
Sent: Tuesday, February 7, 2017 3:34 PM
To: Alberto Colosi; 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 
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 
mailto:bind-users-boun...@lists.isc.org>> on 
behalf of Raul Dias mailto:r...@dias.com.br>>
Sent: Tuesday, February 7, 2017 3:03 PM
To: 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 (yes, I typo the 3 somewhere in the
past).
When it reverts its zone information, it goes back to 3016060101.

I have updated, restarted the host, clean all cache and journal files,
grep all files in the host for 3016060101 (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 to unsubscribe 
from this list
bind-users Info Page - Internet Systems 
Consortium
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
https://lists.isc.org/mailman/listinfo/bind-users
bind-users Info Page - Internet Systems 
Consortium
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 ...


___
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

Re: bind 9 goes rogue and revert zone information

[Warren Kumari]

On Tue, Feb 7, 2017 at 9:34 AM, Raul Dias  wrote:

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

​If it is the master, and there are no automatic updates, I strongly
suspect:
1: ​there is a cron job (or similar) which rewrites the old zone file --
some busticated automation or, more likely
2: you said that this is a "host under lxc" -- this sounds VERY much like
it is in a container, and the container is restarting every N (sometime
around 20h Eastern!) -- the zonefile in the container, and not in an
external volume / persistent disk...

W




>
> On Tue, Feb 7, 2017, 12:27 Alberto Colosi  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  on behalf of Raul
>> Dias 
>> *Sent:* Tuesday, February 7, 2017 3:03 PM
>> *To:* 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 <(301)%20702-0401> (yes, I typo the
>> 3 somewhere in the
>> past).
>> When it reverts its zone information, it goes back to 3016060101
>> <(301)%20606-0101>.
>>
>> I have updated, restarted the host, clean all cache and journal files,
>> grep all files in the host for 3016060101 <(301)%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 to
>> unsubscribe from this list
>> bind-users Info Page - Internet Systems Consortium
>> 
>> 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
>> https://lists.isc.org/mailman/listinfo/bind-users
>> bind-users Info Page - Internet Systems Consortium
>> 
>> 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
>> ...
>>
>>
> ___
> 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
>



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

Re: bind 9 goes rogue and revert zone information

[Mukund Sivaraman]

Hi Raul

On Tue, Feb 07, 2017 at 12:03:40PM -0200, Raul Dias wrote:
> 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 (yes, I typo the 3 somewhere in the
> past).
> When it reverts its zone information, it goes back to 3016060101.
> 
> I have updated, restarted the host, clean all cache and journal files, grep
> all files in the host for 3016060101 (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.

When you say "When it reverts its zone information", how are you
observing it? Are you reading the master file from disk to check what's
in it, or are you doing a dig for the SOA record to check the serial?
By this, I'm asking if your master file is in sync with the journal if
you're reading it directly (rndc sync).

After the zone has a serial of 3017020401, is it updated in any way?  Do
you run any rndc commands against the nameserver during this time?

Is the serial value 3016060101 of any significance? You say it "reverts
back to a previous version". Was 3016060101 a previously observed
serial? What happens to the contents of the zone? Are the contents the
same, or do they appear to have older data?

When you clean journal files, have they been sync'd into the master
file?

You mention again "get the old information".. does it mean that you
noticed that the zone contains old data? How are you checking the
contents? Directly by reading the master file or via query?

Can you send the output of named-checkconf -px for your named config?
If you want details to be private, you can create a bug ticket by
mailing it to .

Mukund


signature.asc
Description: PGP signature
___
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

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

Hi Mukund,

On 07/02/2017 12:42, Mukund Sivaraman wrote:

Hi Raul
When you say "When it reverts its zone information", how are you
observing it? Are you reading the master file from disk to check what's
in it, or are you doing a dig for the SOA record to check the serial?
By this, I'm asking if your master file is in sync with the journal if
you're reading it directly (rndc sync).

with dig.
the zone files are kept in the 30170401 format.
the slaves dns servers do not update to the 3016060101 as it is older 
than the later.


I was not aware of rndc sync.  Which is fine right now.  But I will see 
what happens next time it drifts.


This is newbie question.  Why there is a journal file for a static 
master zone?


After the zone has a serial of 3017020401, is it updated in any way?  Do
you run any rndc commands against the nameserver during this time?

Nope.


Is the serial value 3016060101 of any significance? You say it "reverts
back to a previous version". Was 3016060101 a previously observed
serial? What happens to the contents of the zone? Are the contents the
same, or do they appear to have older data?

3016* was the last zone update until this year.
So, the content stayed the same for at least 6 months.
The major changes were a few A and CNAME records, which gets reverted to 
the previous values (301606*) when the problem occurs. Older ns data 
gets propagated to the Internet.

When you clean journal files, have they been sync'd into the master
file?
I don't think so.  As I said earlier, I am not aware about the 
usefulness of it in this scenario.

What I did was to stop the server, Removed them and start the daemon back.
Everything were fine after this for a few days.


You mention again "get the old information".. does it mean that you
noticed that the zone contains old data? How are you checking the
contents? Directly by reading the master file or via query?

Query.  The files are always right (3017* data).


Can you send the output of named-checkconf -px for your named config?
If you want details to be private, you can create a bug ticket by
mailing it to .

Mukund

Thanks.  Sent over to bind9-bugs.

-rsd
___
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

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

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 
*Sent:* Tuesday, February 7, 2017 3:34 PM
*To:* Alberto Colosi; 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 > 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 mailto:bind-users-boun...@lists.isc.org>> on behalf of Raul Dias
mailto:r...@dias.com.br>>
*Sent:* Tuesday, February 7, 2017 3:03 PM
*To:* 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 (yes, I typo the 3 somewhere
in the
past).
When it reverts its zone information, it goes back to 3016060101.

I have updated, restarted the host, clean all cache and journal
files,
grep all files in the host for 3016060101 (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 to
unsubscribe from this list
bind-users Info Page - Internet Systems Consortium

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 
https://lists.isc.org/mailman/listinfo/bind-users
bind-users Info Page - Internet Systems Consortium

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 to unsubscribe 
from this list

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

Re: Enforce EDNS

[Chuck Anderson]

On Tue, Feb 07, 2017 at 11:59:39AM +1100, Mark Andrews wrote:
> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will fail.  That manual work arounds will now have to
> be done. e.g. "server ... { send-cookie no; };"
> 
> Servers not answering would EDNS or EDNS + DNS COOKIE would require
> operator intervention.

Break them.  That's the only way it will eventually get fixed.
___
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

Re: Enforce EDNS

[Matthew Pounsett]

On 6 February 2017 at 19:59, Mark Andrews  wrote:

>
> Unfortunately we then need to decide what to do with servers that
> don't answer EDNS + DNS COOKIE queries.  Currently we fall back to
> plain DNS which works except when there is a signed zone involved
> and the server is validating.
>
> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will fail.  That manual work arounds will now have to
> be done. e.g. "server ... { send-cookie no; };"


I fully support breaking resolution for such servers.  I'd rather have a
hard failure on my end that I can investigate, and work around if
necessary, than have my server wasting cycles trying to guess what sort of
broken state there is on the far end.   It would also give me the heads up
I need to contact the admin on the far end and report their servers' broken
behaviour.
___
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

Re: Enforce EDNS

[Reindl Harald]

Am 07.02.2017 um 18:13 schrieb Chuck Anderson:

On Tue, Feb 07, 2017 at 11:59:39AM +1100, Mark Andrews wrote:

I really don't want to add new automatic work arounds for broken
servers but it requires people being willing to accepting that
lookups will fail.  That manual work arounds will now have to
be done. e.g. "server ... { send-cookie no; };"

Servers not answering would EDNS or EDNS + DNS COOKIE would require
operator intervention.


Break them.  That's the only way it will eventually get fixed


if things would be that easy

the admins of the broken servers ar the very last which are affected, 
admins with a recent named have to bite the bullet of user terror and 
users typically don#t give a damn when it worked yesterday


the admins of the broken server don't give a damn about as long they can 
point their fingers and say "look, the rest of the world has no lookup 
errors"


if it would be that easy the problem of spam would not exist for many 
years while in reality you waste most of our time to write exceptions 
here and there, disable rules or score them lower because you are not in 
the position to educate every admin of sending servers out there

___
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

Re: Enforce EDNS

[wbrown]

From: Matthew Pounsett 

> I fully support breaking resolution for such servers.  I'd rather 
> have a hard failure on my end that I can investigate, and work 
> around if necessary, than have my server wasting cycles trying to 
> guess what sort of broken state there is on the far end.   It would 
> also give me the heads up I need to contact the admin on the far end
> and report their servers' broken behaviour. 

And the remote admin would say "Well, it must be your problem because no 
one else is complaining."

I get the same line of BS when I refuse to honor a whitelisted domain in 
my spam filter if they fail SPF checks.  Not many filters do that, but I 
think it is a great idea.  People dread hearing from the IRS, but they 
can't afford to block the emails.


Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.

___
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

Re: bind 9 goes rogue and revert zone information

[Barry Margolin]

In article ,
 Raul Dias  wrote:

> 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 (yes, I typo the 3 somewhere in the 
> past).
> When it reverts its zone information, it goes back to 3016060101.

It sounds to me like there's a cron job restoring the zone from a backup.

-- 
Barry Margolin
Arlington, MA
___
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

Re: Enforce EDNS

[Mark Andrews]

In message <3836f038-c480-9970-fd53-a5c87ad36...@thelounge.net>, Reindl Harald 
wr
ites:
> 
> 
> Am 07.02.2017 um 18:13 schrieb Chuck Anderson:
> > On Tue, Feb 07, 2017 at 11:59:39AM +1100, Mark Andrews wrote:
> >> I really don't want to add new automatic work arounds for broken
> >> servers but it requires people being willing to accepting that
> >> lookups will fail.  That manual work arounds will now have to
> >> be done. e.g. "server ... { send-cookie no; };"
> >>
> >> Servers not answering would EDNS or EDNS + DNS COOKIE would require
> >> operator intervention.
> >
> > Break them.  That's the only way it will eventually get fixed
> 
> if things would be that easy
> 
> the admins of the broken servers ar the very last which are affected, 
> admins with a recent named have to bite the bullet of user terror and 
> users typically don#t give a damn when it worked yesterday
> 
> the admins of the broken server don't give a damn about as long they can 
> point their fingers and say "look, the rest of the world has no lookup 
> errors"
> 
> if it would be that easy the problem of spam would not exist for many 
> years while in reality you waste most of our time to write exceptions 
> here and there, disable rules or score them lower because you are not in 
> the position to educate every admin of sending servers out there

You go over the admins head.  You go to the board of directors.
You go the the minister responsible (yes, I have had to do that
along with a copy to the shadow minister and the company that the
DNS was outsourced to for government domains).  Good old snail mail.

Mark

> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> f
> rom this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: Enforce EDNS

[Reindl Harald]

Am 07.02.2017 um 22:11 schrieb Mark Andrews:

In message <3836f038-c480-9970-fd53-a5c87ad36...@thelounge.net>, Reindl Harald 
wr
ites:

Break them.  That's the only way it will eventually get fixed


if things would be that easy

the admins of the broken servers ar the very last which are affected,
admins with a recent named have to bite the bullet of user terror and
users typically don#t give a damn when it worked yesterday

the admins of the broken server don't give a damn about as long they can
point their fingers and say "look, the rest of the world has no lookup
errors"

if it would be that easy the problem of spam would not exist for many
years while in reality you waste most of our time to write exceptions
here and there, disable rules or score them lower because you are not in
the position to educate every admin of sending servers out there


You go over the admins head.  You go to the board of directors.
You go the the minister responsible (yes, I have had to do that
along with a copy to the shadow minister and the company that the
DNS was outsourced to for government domains).  Good old snail mail


if *you* do that from your position it may work but still takes time in 
a world where it somestimes takes days and weeks to find somebody who 
can instruct a admin to change a simple CNAME record from machine A to 
machine B even with the directors OK and CC'ed in the message


i doubt it works the same way for a ordinary admin in a small company 
where you to make it work because *you* broke it with the named update 
and so your advise will be "roll back that stuff to the state of 
yesterday where it worked and no you have not the free time to call each 
and every company and educate them"


problem here is that as long it's not a critical mass anybody who 
deployed the update breaking things have to bleed for it and so you have 
to find enough people with the power to go over admins head *before* the 
breaking updates


and no, when in your company people can't work because DNS is broken you 
don't call foreign admins and directors - you have to fix that *now* and 
after you have fixed it you have no longer arumgents why call somebody 
with no direct relations

___
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

Re: Enforce EDNS

[Alan Clegg]

On 2/7/17 3:11 PM, Mark Andrews wrote:

>>> Break them.  That's the only way it will eventually get fixed
>>
>> if things would be that easy
>>
>> the admins of the broken servers ar the very last which are affected, 
>> admins with a recent named have to bite the bullet of user terror and 
>> users typically don#t give a damn when it worked yesterday
>>
>> the admins of the broken server don't give a damn about as long they can 
>> point their fingers and say "look, the rest of the world has no lookup 
>> errors"
>>
>> if it would be that easy the problem of spam would not exist for many 
>> years while in reality you waste most of our time to write exceptions 
>> here and there, disable rules or score them lower because you are not in 
>> the position to educate every admin of sending servers out there
> 
> You go over the admins head.  You go to the board of directors.
> You go the the minister responsible (yes, I have had to do that
> along with a copy to the shadow minister and the company that the
> DNS was outsourced to for government domains).  Good old snail mail.

I wish I lived and worked in an ivory tower.

Reindl is right.

If you are in (some) academia, or running this server at your house, you
can get away with "he didn't follow the rules, so I'm not talking to
him".  You just plain can't get away with that in the commercial world.

Remember those Korean IPTV servers that were authoritative but didn't
respond with the AA bit?  The thing that kicked back and caused a very
speedy reversal in the enforcement of that rule is called business pressure.

Yes, we know the rules, yes, we'd love if the rules were strictly
enforced (assuming we don't take the hit when someone else screws up),
but the business world doesn't allow us to enforce the rules, we have to
work as best we can in the world that we are provided.

The idea that "BIND leads the way, allowing no rule breaking, business
needs be damned" will only lead to either a fork of "friendlierBIND",
vendors that include BIND under the covers turning off the strict
enforcement by forking their own BIND versions (do you think this isn't
being done already?), or migration off of BIND completely (do you think
that this isn't being considered already?).

Maybe a "strict-compliance yes;" option?  Those that are willing to take
the hit set it to yes, everyone that needs to ensure business continuity
set it to no?  (and for gods sake, make it default to no)

As with the "let's randomly add a string into the middle of the log
message for everyone", this "let's just break it because the RFCs say
so" isn't going to go over well with lots of people.





signature.asc
Description: OpenPGP digital signature
___
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

Re: bind 9 goes rogue and revert zone information

[Warren Kumari]

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  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  
> *Sent:* Tuesday, February 7, 2017 3:34 PM
> *To:* Alberto Colosi; 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  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  on behalf of Raul
>> Dias < r...@dias.com.br>
>> *Sent:* Tuesday, February 7, 2017 3:03 PM
>> *To:* 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 <(301)%20702-0401> (yes, I typo the
>> 3 somewhere in the
>> past).
>> When it reverts its zone information, it goes back to 3016060101
>> <(301)%20606-0101>.
>>
>> I have updated, restarted the host, clean all cache and journal files,
>> grep all files in the host for 3016060101 <(301)%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 to
>> unsubscribe from this list
>> bind-users Info Page - Internet Systems Consortium
>> 
>> 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
>> https://lists.isc.org/mailman/listinfo/bind-users
>> bind-users Info Page - Internet Systems Consortium
>> 
>> 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 to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> 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
___
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

Re: bind 9 goes rogue and revert zone information

[Alan Clegg]

On 2/7/17 8:42 AM, 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

Occam's razor... if you were a hacker and broke into someone's DNS
server, would the thing that you focus on be resetting the data every 24
hours?

This isn't a hack, this is a screwed up backup/restore or virtualization
configuration.

Don't waste time chasing ghosts.



signature.asc
Description: OpenPGP digital signature
___
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

Re: bind 9 goes rogue and revert zone information

[Reindl Harald]

Am 07.02.2017 um 23:31 schrieb Alberto Colosi:

lucky you say

zombie host and hijacked resourced poisoned DNS are not an hack

In years as Security Desk Seat I had at leat one attack from zombie
hosts from a US University. Admins even not known was hacked.

Target of hackers is not only credit cards or other so valuable things.
Even only a zombie host is a valuable item for them.


yeah, but why should they be so dumb and set your dns zone to the values 
24 hours before so that you notice the issue and much better question: 
from where do they have the exactly data of your own zone 24 hours before?


try "chattr +i" on your zonefile so that it can't be touched and with 
some luck the stuff trying to replace it will error out in cronmails or 
syslog




*From:* bind-users  on behalf of Alan
Clegg 
*Sent:* Tuesday, February 7, 2017 10:48 PM
*To:* bind-users@lists.isc.org
*Subject:* Re: bind 9 goes rogue and revert zone information

On 2/7/17 8:42 AM, 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


Occam's razor... if you were a hacker and broke into someone's DNS
server, would the thing that you focus on be resetting the data every 24
hours?

This isn't a hack, this is a screwed up backup/restore or virtualization
configuration.

Don't waste time chasing ghosts

___
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

Re: bind 9 goes rogue and revert zone information

[Alberto Colosi]

lucky you say


zombie host and hijacked resourced poisoned DNS are not an hack


In years as Security Desk Seat I had at leat one attack from zombie hosts from 
a US University. Admins even not known was hacked.


Target of hackers is not only credit cards or other so valuable things. Even 
only a zombie host is a valuable item for them.




From: bind-users  on behalf of Alan Clegg 

Sent: Tuesday, February 7, 2017 10:48 PM
To: bind-users@lists.isc.org
Subject: Re: bind 9 goes rogue and revert zone information

On 2/7/17 8:42 AM, 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

Occam's razor... if you were a hacker and broke into someone's DNS
server, would the thing that you focus on be resetting the data every 24
hours?

This isn't a hack, this is a screwed up backup/restore or virtualization
configuration.

Don't waste time chasing ghosts.

___
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

Re: Enforce EDNS

[Mark Andrews]

In message <4b0243b1-1c89-023b-f3f3-7279216d5...@thelounge.net>, Reindl Harald 
writes:
> 
> 
> Am 07.02.2017 um 22:11 schrieb Mark Andrews:
> > In message <3836f038-c480-9970-fd53-a5c87ad36...@thelounge.net>, Reindl Har
> ald wr
> > ites:
> >>> Break them.  That's the only way it will eventually get fixed
> >>
> >> if things would be that easy
> >>
> >> the admins of the broken servers ar the very last which are affected,
> >> admins with a recent named have to bite the bullet of user terror and
> >> users typically don#t give a damn when it worked yesterday
> >>
> >> the admins of the broken server don't give a damn about as long they can
> >> point their fingers and say "look, the rest of the world has no lookup
> >> errors"
> >>
> >> if it would be that easy the problem of spam would not exist for many
> >> years while in reality you waste most of our time to write exceptions
> >> here and there, disable rules or score them lower because you are not in
> >> the position to educate every admin of sending servers out there
> >
> > You go over the admins head.  You go to the board of directors.
> > You go the the minister responsible (yes, I have had to do that
> > along with a copy to the shadow minister and the company that the
> > DNS was outsourced to for government domains).  Good old snail mail
> 
> if *you* do that from your position it may work but still takes time in 
> a world where it somestimes takes days and weeks to find somebody who 
> can instruct a admin to change a simple CNAME record from machine A to 
> machine B even with the directors OK and CC'ed in the message

And you can fix the issue by hand while this is going on.

server 74.113.204.34 { send-cookie false; };
server 74.113.206.34 { send-cookie false; };
server 117.56.91.203 { send-cookie false; };
server 117.56.91.204 { send-cookie false; };
server 117.56.91.234 { send-cookie false; };
server 199.252/16 { send-cookie false; };

(or request-sit no; for 9.10.x)

There aren't lots of servers that drop EDNS or drop EDNS + DNS COOKIE.

The big numbers are those that drop EDNS(1) which no one is using at
this stage.  See http://ednscomp.isc.org/

> i doubt it works the same way for a ordinary admin in a small company 
> where you to make it work because *you* broke it with the named update 
> and so your advise will be "roll back that stuff to the state of 
> yesterday where it worked and no you have not the free time to call each 
> and every company and educate them"
>
> problem here is that as long it's not a critical mass anybody who 
> deployed the update breaking things have to bleed for it and so you have 
> to find enough people with the power to go over admins head *before* the 
> breaking updates
> 
> and no, when in your company people can't work because DNS is broken you 
> don't call foreign admins and directors - you have to fix that *now* and 
> after you have fixed it you have no longer arumgents why call somebody 
> with no direct relations
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: bind 9 goes rogue and revert zone information

[Alan Clegg]

On 2/7/17 4:31 PM, Alberto Colosi wrote:
> lucky you say
> 
> zombie host and hijacked resourced poisoned DNS are not an hack 
> 
> In years as Security Desk Seat I had at leat one attack from zombie
> hosts from a US University. Admins even not known was hacked.
> 
> Target of hackers is not only credit cards or other so valuable things.
> Even only a zombie host is a valuable item for them.

I didn't say that there weren't people around messing with DNS.

What I said was this e-mail does not have anything to do with such an event.

Don't chase ghosts.



signature.asc
Description: OpenPGP digital signature
___
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

Re: bind 9 goes rogue and revert zone information

[Alberto Colosi]

The truth is to solve it not to ask what an hacker (maybe a child runned a tool 
found on internet as virus toolkits).

To quote me is not a solution to the issue.

Good your last line only on your last mail.

- Reply message -
From: "Reindl Harald" 
To: "bind-users@lists.isc.org" 
Subject: bind 9 goes rogue and revert zone information
Date: Tue, Feb 7, 2017 23:38



Am 07.02.2017 um 23:31 schrieb Alberto Colosi:
> lucky you say
>
> zombie host and hijacked resourced poisoned DNS are not an hack
>
> In years as Security Desk Seat I had at leat one attack from zombie
> hosts from a US University. Admins even not known was hacked.
>
> Target of hackers is not only credit cards or other so valuable things.
> Even only a zombie host is a valuable item for them.

yeah, but why should they be so dumb and set your dns zone to the values
24 hours before so that you notice the issue and much better question:
from where do they have the exactly data of your own zone 24 hours before?

try "chattr +i" on your zonefile so that it can't be touched and with
some luck the stuff trying to replace it will error out in cronmails or
syslog

> 
> *From:* bind-users  on behalf of Alan
> Clegg 
> *Sent:* Tuesday, February 7, 2017 10:48 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Re: bind 9 goes rogue and revert zone information
>
> On 2/7/17 8:42 AM, 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
>
> Occam's razor... if you were a hacker and broke into someone's DNS
> server, would the thing that you focus on be resetting the data every 24
> hours?
>
> This isn't a hack, this is a screwed up backup/restore or virtualization
> configuration.
>
> Don't waste time chasing ghosts
___
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
___
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

Re: bind 9 goes rogue and revert zone information

[Reindl Harald]

Am 07.02.2017 um 23:52 schrieb Alberto Colosi:

The truth is to solve it not to ask what an hacker (maybe a child runned a tool 
found on internet as virus toolkits).


the truth is to *find out* what happens and since it's more likely that 
some forgotten piece of cronscript lives somewhere than a hacker did it 
a triggered cronmail would call that script if it spits out something on 
stderr


that "chattr +i" for now stops anything including root to touch that 
file until "chattr -i" was issued is just a side-effect



To quote me is not a solution to the issue.
Good your last line only on your last mail


not sure to whom you are talking because the quoting of your last mail 
was completly weird



yeah, but why should they be so dumb and set your dns zone to the values
24 hours before so that you notice the issue and much better question:
from where do they have the exactly data of your own zone 24 hours before?

try "chattr +i" on your zonefile so that it can't be touched and with
some luck the stuff trying to replace it will error out in cronmails or
syslog

___
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

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

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 > 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  
*Sent:* Tuesday, February 7, 2017 3:34 PM
*To:* Alberto Colosi; 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 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 mailto:bind-users-boun...@lists.isc.org>> on behalf of Raul
Dias mailto:r...@dias.com.br>>
*Sent:* Tuesday, February 7, 2017 3:03 PM
*To:*
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
 (yes, I typo the 3 somewhere in the
past).
When it reverts its zone information, it goes back to
3016060101 .

I have updated, restarted the host, clean all cache and
journal files,
grep all files in the host for 3016060101
 (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
 to
unsubscribe from this list
bind-users Info Page - Internet Systems Consortium

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 
https://lists.isc.org/mailman/listinfo/bind-users

bind-users Info Page - Internet Systems Consortium

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
 to unsubscribe
from this list

 

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

On 07/02/2017 20:37, Reindl Harald wrote:


try "chattr +i" on your zonefile so that it can't be touched and with 
some luck the stuff trying to replace it will error out in cronmails 
or syslog 


Good idea.
Done!
___
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

Re: bind 9 goes rogue and revert zone information

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2017-02-07 at 22:15 -0200, Raul Dias wrote:
> I am pretty sure it is not restarting.

What does 'rndc status' show for boot time and last configured time
after the zone has reverted to previous contents?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAliaaUsACgkQL6j7milTFsHp5wCfawH6RhiaRkWClG208jndd5pA
lJUAoISMHrQ0C3opcJlGK3BGAGV6A+Zt
=Ur7i
-END PGP SIGNATURE-


___
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

RE: Bind Queries log file format

[Paul Roberts]

I have to say I agree with the approach of putting this extra info into a 
separate file. I appreciate this could cause additional problems (disk 
utilisation, extra I/O's, log rolling etc.) but I would prefer to keep the 
query log format as stable as possible. I am still mopping up the last big 
change when ISC added the FQDN reference at the start of each message and I'm 
getting a little tired of dealing with customers and their broken regex's when 
log formats change because they've upgraded BIND.

There are also wider implications - there are products out there that hard code 
the regex and it can't be modified, so that then requires dealing with vendors, 
submitting bug reports/enhancement requests, providing evidence, business 
impact statements, also I have to perform root cause analysis for customers why 
their SIEM is no longer capturing the logs, which can have serious regulatory 
implications and consequences (banks etc.), then there's testing every upgrade 
in the lab before we run in production etc., I have enough work on my plate as 
it is! :-)

Basically there's a whole world of pain out there that can be avoided if you 
just keep the log format the same. :-)

Thanks,

Paul

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
MURTARI, JOHN
Sent: 06 February 2017 17:05
To: bind-users@lists.isc.org
Subject: RE: Bind Queries log file format

[snip]

> The additional logging info is specifically for the unusual bugs, 
> which happen very rarely - asking customers to enable the additional 
> logs after a rare event (which might not happen again for months /
> years) means that ISC cannot hunt down and squash the corner case 
> bugs...

I can understand the above.  ISC needs the data to help debug a 
once-in-a-blue-moon crash.  But many busy sites do not have query logging 
turned on at all (or only run sampling periods) and would not benefit anyway.

It would seem this debug info should be moved to a separate log used 
only for that purpose and always 'on'. But that brings up other issues

I've been a sys admin for many years.  If a utility crashes enough to 
bother me I'll turn on more detailed logging.

John


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

Re: bind 9 goes rogue and revert zone information

[Raul Dias]

I don't think I have these info:

# rndc status
version: 9.9.5-9+deb8u8-Debian (DNS server) 
CPUs found: 24
worker threads: 24
UDP listeners per interface: 24
number of zones: 111
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

Note that I did restart named daemon.  That's how i get the zone 
information up again.



-rsd


On 07/02/2017 22:42, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2017-02-07 at 22:15 -0200, Raul Dias wrote:

I am pretty sure it is not restarting.

What does 'rndc status' show for boot time and last configured time
after the zone has reverted to previous contents?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAliaaUsACgkQL6j7milTFsHp5wCfawH6RhiaRkWClG208jndd5pA
lJUAoISMHrQ0C3opcJlGK3BGAGV6A+Zt
=Ur7i
-END PGP SIGNATURE-


___
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


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

Re: Bind Queries log file format

[Mark Andrews]

In message , Paul Roberts writes:
> I have to say I agree with the approach of putting this extra info into a sep
> arate file. I appreciate this could cause additional problems (disk utilisati
> on, extra I/O's, log rolling etc.) but I would prefer to keep the query log f
> ormat as stable as possible. I am still mopping up the last big change when I
> SC added the FQDN reference at the start of each message and I'm getting a li
> ttle tired of dealing with customers and their broken regex's when log format
> s change because they've upgraded BIND.
> 
> There are also wider implications - there are products out there that hard co
> de the regex and it can't be modified, so that then requires dealing with ven
> dors, submitting bug reports/enhancement requests, providing evidence, busine
> ss impact statements, also I have to perform root cause analysis for customer
> s why their SIEM is no longer capturing the logs, which can have serious regu
> latory implications and consequences (banks etc.), then there's testing every
>  upgrade in the lab before we run in production etc., I have enough work on m
> y plate as it is! :-)
> 
> Basically there's a whole world of pain out there that can be avoided if you 
> just keep the log format the same. :-)
> 
> Thanks,
> 
> Paul

Change happens.  The DNS protocol has expanded enormously from the
original specification.  To expect the summary log line to not
change with that change is just not realistic.  We do try to keep
the format change to a .0 release.  This one we missed.

We currently log:

client, qname, qclass, qtype, RD (+/-), was the request signed (S),
the EDNS with version, was it over TCP (T), was DO=1 set (D), was
CD=1 set (C), were DNS COOKIES in use and was it a valide server
cookie or just a client cookie (V, K).  We log the interface it was
received on and if the ECS option.

Not everyone wants all of these details but someone wants everyone
of these.

9.1.0: client, qname, qclass, qtype
9.2.0: client, qname, qclass, qtype
9.3.0: client, qname, qclass, qtype, RD, signed, EDNS
9.4.0: client, qname, qclass, qtype, RD, signed, EDNS
9.5.0: client, qname, qclass, qtype, RD, signed, EDNS, DO, CD
9.6.0: client, qname, qclass, qtype, RD, signed, EDNS, DO, CD
9.7.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
address
9.8.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
address
9.9.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
address
9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
address
9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, 
cookies, local address
9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, 
cookies, local address, ecs

That's basically 5 changes in 17 years.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: Bind Queries log file format

[Larry Stone]

I’ve been around long enough to remember when upward compatability was 
something that was expected. A program built to work with the current version 
of data (e.g. data records, log records, whatever) or even a shared library was 
expected to be able to continue to work with all future versions without the 
need for changes or rebuilding/recompiling. For data, that meant new fields 
went on the end of the record so that anything expecting the old format still 
found everything where it always was and the new stuff was at the end of the 
record where the old programs never even looked. But sadly, this appears to be 
a lost art these days.

Where I work, we have a data set that has 20 years of data in it. Over the 
years, the record length was extended but once a field was placed at a given 
point in the record, it never, ever moved so that programs written years ago 
that had no need for the new fields still ran just fine. And with hundreds if 
not thousands of programs around the company that read this data set, insuring 
that format changes did not break things was a very high priority. 
Occasionally, fields went away in which case that spot in the record was just 
left blank for all new records.

For the BIND log records described below, what I describe appears to be what 
was done through 9.10.0. But then at 9.11.0, we have a field in the middle of 
the record being changed (EDNS changed to EDNS+version). What, IMHO, should 
have been done here was to put the version on the end (either going with a 
split filed - EDNS in one place and the version in another or by duplicating 
EDNS by having it without version where it was and then again with version on 
the end of the record) so that old programs parsing the log file still worked. 
So instead of:
> 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
> address
> 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, 
> CD, cookies, local address
> 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, 
> CD, cookies, local address, ecs


it should have been
> 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
> address
> 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, cookies, 
> local address, EDNSversion
> 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, cookies, 
> local address, EDNSversion, ecs

-- 
Larry Stone
lston...@stonejongleux.com





> On Feb 7, 2017, at 9:06 PM, Mark Andrews  wrote:
> 
> 
> In message 
>  rod.outlook.com>, Paul Roberts writes:
>> I have to say I agree with the approach of putting this extra info into a sep
>> arate file. I appreciate this could cause additional problems (disk utilisati
>> on, extra I/O's, log rolling etc.) but I would prefer to keep the query log f
>> ormat as stable as possible. I am still mopping up the last big change when I
>> SC added the FQDN reference at the start of each message and I'm getting a li
>> ttle tired of dealing with customers and their broken regex's when log format
>> s change because they've upgraded BIND.
>> 
>> There are also wider implications - there are products out there that hard co
>> de the regex and it can't be modified, so that then requires dealing with ven
>> dors, submitting bug reports/enhancement requests, providing evidence, busine
>> ss impact statements, also I have to perform root cause analysis for customer
>> s why their SIEM is no longer capturing the logs, which can have serious regu
>> latory implications and consequences (banks etc.), then there's testing every
>> upgrade in the lab before we run in production etc., I have enough work on m
>> y plate as it is! :-)
>> 
>> Basically there's a whole world of pain out there that can be avoided if you 
>> just keep the log format the same. :-)
>> 
>> Thanks,
>> 
>> Paul
> 
> Change happens.  The DNS protocol has expanded enormously from the
> original specification.  To expect the summary log line to not
> change with that change is just not realistic.  We do try to keep
> the format change to a .0 release.  This one we missed.
> 
> We currently log:
> 
> client, qname, qclass, qtype, RD (+/-), was the request signed (S),
> the EDNS with version, was it over TCP (T), was DO=1 set (D), was
> CD=1 set (C), were DNS COOKIES in use and was it a valide server
> cookie or just a client cookie (V, K).  We log the interface it was
> received on and if the ECS option.
> 
> Not everyone wants all of these details but someone wants everyone
> of these.
> 
> 9.1.0: client, qname, qclass, qtype
> 9.2.0: client, qname, qclass, qtype
> 9.3.0: client, qname, qclass, qtype, RD, signed, EDNS
> 9.4.0: client, qname, qclass, qtype, RD, signed, EDNS
> 9.5.0: client, qname, qclass, qtype, RD, signed, EDNS, DO, CD
> 9.6.0: client, qname, qclass, qtype, RD, signed, EDNS, DO, CD
> 9.7.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local 
> address
> 9.8.0: client, qname, qclass, qtype, RD, si

Re: Bind Queries log file format

[Paul Kosinski]

"I’ve been around long enough to remember when upward compatibility was
something that was expected."

Having been around since before even Unix, I must say I agree totally.

As I understand it, Linus does not take kindly to Linux Kernel changes
that break forward/upward compatibility (of the ABI). I don't think BIND
should do any less.

If a new format is needed for more extensive logging, then add a new
log option (just as new Kernel interfaces are added from time to time).


On Tue, 7 Feb 2017 22:25:36 -0600
Larry Stone  wrote:

> I’ve been around long enough to remember when upward compatability
> was something that was expected. A program built to work with the
> current version of data (e.g. data records, log records, whatever) or
> even a shared library was expected to be able to continue to work
> with all future versions without the need for changes or
> rebuilding/recompiling. For data, that meant new fields went on the
> end of the record so that anything expecting the old format still
> found everything where it always was and the new stuff was at the end
> of the record where the old programs never even looked. But sadly,
> this appears to be a lost art these days.
> 
> Where I work, we have a data set that has 20 years of data in it.
> Over the years, the record length was extended but once a field was
> placed at a given point in the record, it never, ever moved so that
> programs written years ago that had no need for the new fields still
> ran just fine. And with hundreds if not thousands of programs around
> the company that read this data set, insuring that format changes did
> not break things was a very high priority. Occasionally, fields went
> away in which case that spot in the record was just left blank for
> all new records.
> 
> For the BIND log records described below, what I describe appears to
> be what was done through 9.10.0. But then at 9.11.0, we have a field
> in the middle of the record being changed (EDNS changed to
> EDNS+version). What, IMHO, should have been done here was to put the
> version on the end (either going with a split filed - EDNS in one
> place and the version in another or by duplicating EDNS by having it
> without version where it was and then again with version on the end
> of the record) so that old programs parsing the log file still
> worked. So instead of:
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO,
> > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed,
> > EDNS + version, TCP, DO, CD, cookies, local address 9.12.0: client,
> > qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD,
> > cookies, local address, ecs
> 
> 
> it should have been
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO,
> > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed,
> > EDNS, TCP, DO, CD, cookies, local address, EDNSversion 9.12.0:
> > client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> > cookies, local address, EDNSversion, ecs
> 
___
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

Re: Bind Queries log file format

[Mark Andrews]

In message <2c577494-613a-419c-82c4-402ba581c...@stonejongleux.com>, Larry 
Stone writes:
> Ive been around long enough to remember when upward compatability was
> something that was expected. A program built to work with the current
> version of data (e.g. data records, log records, whatever) or even a
> shared library was expected to be able to continue to work with all
> future versions without the need for changes or rebuilding/recompiling.
> For data, that meant new fields went on the end of the record so that
> anything expecting the old format still found everything where it always
> was and the new stuff was at the end of the record where the old programs
> never even looked. But sadly, this appears to be a lost art these days.

BIND 9.12.0 will work with valid zone files from BIND 4.8.  Named
has got better with detecting errors in those zone files so a modern
version will reject some zone files that were incorrectly accepted
by BIND 4.8.

> Where I work, we have a data set that has 20 years of data in it. Over
> the years, the record length was extended but once a field was placed at
> a given point in the record, it never, ever moved so that programs
> written years ago that had no need for the new fields still ran just
> fine. And with hundreds if not thousands of programs around the company
> that read this data set, insuring that format changes did not break
> things was a very high priority. Occasionally, fields went away in which
> case that spot in the record was just left blank for all new records.
>
> For the BIND log records described below, what I describe appears to be
> what was done through 9.10.0. But then at 9.11.0, we have a field in the
> middle of the record being changed (EDNS changed to EDNS+version).

No, we have a field that has more information in it.  Same field E -> E(version)

08-Feb-2017 15:15:44.532 client @0x7fc1c803c600 127.0.0.1#57982/key external 
(rock.dv.isc.org): view external: query: rock.dv.isc.org IN A -SE(0)DV 
(127.0.0.1)

Or with ECS

08-Feb-2017 15:56:27.109 client @0x7fc1c503e800 127.0.0.1#63454 (.): view 
external: query: . IN SOA -E(0)DV (127.0.0.1) [ECS 127.0.0.0/8/0]

Or from a stub resolver.

08-Feb-2017 16:02:22.971 client @0x7fc1c490dc00 127.0.0.1#61028 
(sprocket.isc.org): view secure: query: sprocket.isc.org IN A + (127.0.0.1)

Mark

> What,
> IMHO, should have been done here was to put the version on the end
> (either going with a split filed - EDNS in one place and the version in
> another or by duplicating EDNS by having it without version where it was
> and then again with version on the end of the record) so that old
> programs parsing the log file still worked. So instead of:
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> local address
> > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP,
> DO, CD, cookies, local address
> > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP,
> DO, CD, cookies, local address, ecs
>
>
> it should have been
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> local address
> > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> cookies, local address, EDNSversion
> > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> cookies, local address, EDNSversion, ecs
>
> --
> Larry Stone
> lston...@stonejongleux.com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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