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
"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’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 wi
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 pos
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/
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
-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-
Versio
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.or
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 lik
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 tha
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
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
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
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
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
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 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
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
>>
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 af
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 i
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,
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
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 hav
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 rea
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
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:4
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 yo
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.
>
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 rewrit
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 disa
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 , z
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@lis
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)
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 val
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
-
> 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 f
36 matches
Mail list logo
