Re: Enforce EDNS

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

Re: Enforce EDNS

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

Re: Enforce EDNS

> 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

Re: bind 9 goes rogue and revert zone information

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:

Re: bind 9 goes rogue and revert zone information

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

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

Re: bind 9 goes rogue and revert zone information

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.

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

Re: Enforce EDNS

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

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

Re: Enforce EDNS

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

Re: Enforce EDNS

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

Re: Enforce EDNS

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

Re: Enforce EDNS

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

Re: bind 9 goes rogue and revert zone information

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

RE: Bind Queries log file format

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

Re: bind 9 goes rogue and revert zone information

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:

Re: Bind Queries log file format

"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

Re: bind 9 goes rogue and revert zone information

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:

Re: Bind Queries log file format

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

Re: Bind Queries log file format

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

Re: Bind Queries log file format

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,

Re: Enforce EDNS

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

Re: Enforce EDNS

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

Re: Enforce EDNS

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