date:20161116

RE: refused rcode is not working RPZ?

2016-11-16 Thread LEE SUKMOON

> On 17/11/2016 10:20, LEE SUKMOON wrote:
> 
> > I want to response NXDOMAIN.
> > Is it a solution this case?
> 
> You'd usually get SERVFAIL from the recursor because the domain is
> misconfigured with a lame delegation, and either way the client won't
> get an answer.
> 
> Is there a particular reason that the exact RCODE matters ?
> 
> Ray
> 

This domain causes many recursive query.
And client received late SERVFAIL response.

I want to quickly response "*.jifr.net". 
I want to solve this problem using RPZ.

Thanks.
Sukmoon Lee.
___
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

refused rcode is not working RPZ?

2016-11-16 Thread LEE SUKMOON

Hi all.

I am using RPZ zone. 
Below line is rpz zone file. But jifr.net is not working.


jifr.netCNAME .
*.jifr.net  CNAME .

Unusual, this domain is responding with refused rcode. (from authority name 
server)

$ dig @173.245.58.51 jifr.net

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 39590
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;jifr.net.  IN  A

;; Query time: 105 msec


I want to response NXDOMAIN.
Is it a solution this case?

Thanks.
___
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.11, cookes by default

2016-11-16 Thread Mark Andrews


In message <1479332234.30976.34.ca...@ns.five-ten-sg.com>, Carl Byington writes
:
> On Thu, 2016-11-17 at 07:47 +1100, Mark Andrews wrote:
> > I know you think doing this collectively is a service but having
> > individuals discover and complain to the site operators that their
> > DNS is broken is the only way there will be enough presure brought
> > to bear for some of these companies to fix their server
> > configurations.
> 
> > It requires noise for them to act.  Collectively hiding broken
> > servers doesn't generate the noise.
> 
> I agree that having individuals complain is the way to bring enough
> pressure to get things fixed. But recording the results of the discovery
> process can be centralized.
> 
> 
> > https://ednscomp.isc.org/ has lists of servers with broken EDNS
> > support some of which stops / slows DNS resolution in BIND.
> 
> I am only interested (for now) in the names that are fully broken
> without "send-cookie no". It seems more important to get those fixed,
> than to fix those that (only) slow down resolution.
> 
> I propose adding /etc/named.broken.servers to track those that cannot
> handle cookies, but that file won't be included in the default
> /etc/named.conf configuration. It will include for each server the dig
> tests that can verify that the server is still broken, and should
> include contact information so the bind administrator can send a note
> asking that it be fixed.
> 
> For example, something like:
> 
> // adobe servers that don't understand edns options
> //
> // please send a note asking hostmas...@adobe.com to fix those servers.
> //
> // dig wip4.adobe.com ns
> // dig airdownload.wip4.adobe.com @192.150.16.247   +cookie ==> nxdomain
> // dig airdownload.wip4.adobe.com @192.150.16.247 +nocookie ==> noerror
> server 192.150.16.247   { send-cookie no; };
> server 192.150.19.247   { send-cookie no; };
> server 193.104.215.247  { send-cookie no; };
> 
> 
> 
> Note that "dig wip4.adobe.com soa" shows hostmas...@sj1gtm001.adobe.com
> for that zone, but sj1gtm001.adobe.com has no MX record, and the A
> record target does not answer port 25 connections.

Adobe has been told multiple times that their servers are misconfigured.
The even half fixed them once.  Their DNS administrators are just
plain incompentent.  They can fix this in less than 5 minutes by
adding a single period (.) to the end of "sl-download.adobe.com.edgekey.net"
in the fallback zone which is used when the a cookie option is
present.  It should be "sl-download.adobe.com.edgekey.net." which has a
period at the end.

Without a cookie option you get:
airdownload.wip4.adobe.com. 300 IN  CNAME   
ssl-download.adobe.com.edgekey.net.

With a cookie option you get:
airdownload.wip4.adobe.com. 300 IN  CNAME   
ssl-download.adobe.com.edgekey.net.wip4.adobe.com.

They just refuse to act.

Mark
 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAlgs0WkACgkQL6j7milTFsFF5gCfdguqebQ8OAlClMDJMbFQH06h
> LtQAn16TQQaG/zgAL0Sx/mrFCdSvnFwJ
> =O049
> -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
-- 
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.11, cookes by default

2016-11-16 Thread Carl Byington

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-11-17 at 07:47 +1100, Mark Andrews wrote:
> I know you think doing this collectively is a service but having
> individuals discover and complain to the site operators that their
> DNS is broken is the only way there will be enough presure brought
> to bear for some of these companies to fix their server
> configurations.

> It requires noise for them to act.  Collectively hiding broken
> servers doesn't generate the noise.

I agree that having individuals complain is the way to bring enough
pressure to get things fixed. But recording the results of the discovery
process can be centralized.

> https://ednscomp.isc.org/ has lists of servers with broken EDNS
> support some of which stops / slows DNS resolution in BIND.

I am only interested (for now) in the names that are fully broken
without "send-cookie no". It seems more important to get those fixed,
than to fix those that (only) slow down resolution.

I propose adding /etc/named.broken.servers to track those that cannot
handle cookies, but that file won't be included in the default
/etc/named.conf configuration. It will include for each server the dig
tests that can verify that the server is still broken, and should
include contact information so the bind administrator can send a note
asking that it be fixed.

For example, something like:

// adobe servers that don't understand edns options
//
// please send a note asking hostmas...@adobe.com to fix those servers.
//
// dig wip4.adobe.com ns
// dig airdownload.wip4.adobe.com @192.150.16.247   +cookie ==> nxdomain
// dig airdownload.wip4.adobe.com @192.150.16.247 +nocookie ==> noerror
server 192.150.16.247   { send-cookie no; };
server 192.150.19.247   { send-cookie no; };
server 193.104.215.247  { send-cookie no; };

Note that "dig wip4.adobe.com soa" shows hostmas...@sj1gtm001.adobe.com
for that zone, but sj1gtm001.adobe.com has no MX record, and the A
record target does not answer port 25 connections.

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

iEYEAREKAAYFAlgs0WkACgkQL6j7milTFsFF5gCfdguqebQ8OAlClMDJMbFQH06h
LtQAn16TQQaG/zgAL0Sx/mrFCdSvnFwJ
=O049
-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: rndc addzone type forward

2016-11-16 Thread Evan Hunt

> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:

Unfortunately that's not currently possible. The configuration syntax is
misleading here. You configure forwarding in a view by putting a "zone"
statement in named.conf, but it doesn't actually build a zone *object*,
the way type "master" or "slave" does; it tells the server to set up a
different data structure entirely.  The addzone command is focused on zone
objects and doesn't know what to do with this.

(I thought I remembered documenting this limitation, but I don't see it in
the ARM; my apologies for that oversight.)

We've had a feature request in our queue for some time to make it possible
to configure forwarding via rndc. Hopefully in 9.12.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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.11, cookes by default

2016-11-16 Thread Mark Andrews


I know you think doing this collectively is a service but having
individuals discover and complain to the site operators that their
DNS is broken is the only way there will be enough presure brought
to bear for some of these companies to fix their server configurations.

It requires noise for them to act.  Collectively hiding broken
servers doesn't generate the noise.

https://ednscomp.isc.org/ has lists of servers with broken EDNS
support some of which stops / slows DNS resolution in BIND.

Everyone subscribe to the gtld-tech mailing list and complain that
ICANN doesn't require registries and registrars under its control
to check that servers being delegated to are RFC compliant.  Tell
them that lack of EDNS compliance is breaking DNS resolution.

gtld-tech is tasked with providing operational stability.

My lone voice is not enough.  It requires collective action to
people of the backsides to do stuff.

Similarly ask your countries TLD administrators to audit delegated
server for DNS and EDNS compliance and to remove delegations if the
servers are not fixed in a reasonable period of time.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
has a list of tests which cover this and other issues which affect
DNS interoperability.

Mark

In message <1479321516.30976.7.ca...@ns.five-ten-sg.com>, Carl Byington write
s:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Now that bind is sending cookies by default, there are some broken
> servers out there that we need to configure with send-cookie no;.
> 
> Unless I am missing something, 9.11.0-P1 will (by default) fail to
> resolve names like airdownload.wip4.adobe.com.
> 
> In the interest of publicly naming and shaming their operators, I will
> add an "include /etc/named.broken.servers" file in my packaging. The
> content so far is below. Send me a note if you run into any others.
> 
> 
> // adobe servers that don't understand edns options
> // dig wip4.adobe.com ns
> // dig airdownload.wip4.adobe.com @192.150.16.247   +cookie ==> nxdomain
> // dig airdownload.wip4.adobe.com @192.150.16.247 +nocookie ==> noerror
> server 192.150.16.247   { send-cookie no; };
> server 192.150.19.247   { send-cookie no; };
> server 193.104.215.247  { send-cookie no; };
> 
> 
> 
> // eia.gov servers that don't understand edns options
> // dig eia.gov ns
> // dig phantom.eia.gov. @205.254.135.9   +cookie => formerr
> // dig phantom.eia.gov. @205.254.135.9 +nocookie => noerror
> server 205.254.135.9{ send-cookie no; };
> server 199.36.140.199   { send-cookie no; };
> 
> 
> 
> // lctcs.edu servers that don't understand edns options
> // dig lctcs.edu ns
> // dig www.lctcs.edu @76.165.120.16   +cookie => formerr
> // dig www.lctcs.edu @76.165.120.16 +nocookie => noerror
> server 76.165.120.16{ send-cookie no; };
> server 76.165.210.249   { send-cookie no; };
> 
> 
> 
> // london-nano.com servers that don't understand edns options
> // dig london-nano.com ns
> // dig www.london-nano.com @213.162.97.177   +cookie
> // dig www.london-nano.com @213.162.97.177 +nocookie
> server 213.162.97.177   { send-cookie no; };
> server 213.162.97.178   { send-cookie no; };
> 
> 
> 
> // etdbw.com servers that don't understand edns options
> (www.mycoverageinfo.com)
> // dig www.mycoverageinfo.gtm.etdbw.com. +trace
> // dig www.mycoverageinfo.gtm.etdbw.com. @167.79.186.7   +cookie =>
> noerror, 0 answers
> // dig www.mycoverageinfo.gtm.etdbw.com. @167.79.186.7 +nocookie =>
> noerror, 1 answer
> server 167.79.45.7  { send-cookie no; };
> server 167.79.182.7 { send-cookie no; };
> server 167.79.186.7 { send-cookie no; };
> server 167.79.192.7 { send-cookie no; };
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAlgsp6AACgkQL6j7milTFsF5VACfXxKp+HLNNX7fczr4xF4qT4LP
> UCIAn3h4WPC2QZ21+gYnSuECG3t2nwEQ
> =22tF
> -END PGP SIGNATURE-
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri
> be 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

bind 9.11, cookes by default

2016-11-16 Thread Carl Byington

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Now that bind is sending cookies by default, there are some broken
servers out there that we need to configure with send-cookie no;.

Unless I am missing something, 9.11.0-P1 will (by default) fail to
resolve names like airdownload.wip4.adobe.com.

In the interest of publicly naming and shaming their operators, I will
add an "include /etc/named.broken.servers" file in my packaging. The
content so far is below. Send me a note if you run into any others.


// adobe servers that don't understand edns options
// dig wip4.adobe.com ns
// dig airdownload.wip4.adobe.com @192.150.16.247   +cookie ==> nxdomain
// dig airdownload.wip4.adobe.com @192.150.16.247 +nocookie ==> noerror
server 192.150.16.247   { send-cookie no; };
server 192.150.19.247   { send-cookie no; };
server 193.104.215.247  { send-cookie no; };



// eia.gov servers that don't understand edns options
// dig eia.gov ns
// dig phantom.eia.gov. @205.254.135.9   +cookie => formerr
// dig phantom.eia.gov. @205.254.135.9 +nocookie => noerror
server 205.254.135.9{ send-cookie no; };
server 199.36.140.199   { send-cookie no; };



// lctcs.edu servers that don't understand edns options
// dig lctcs.edu ns
// dig www.lctcs.edu @76.165.120.16   +cookie => formerr
// dig www.lctcs.edu @76.165.120.16 +nocookie => noerror
server 76.165.120.16{ send-cookie no; };
server 76.165.210.249   { send-cookie no; };



// london-nano.com servers that don't understand edns options
// dig london-nano.com ns
// dig www.london-nano.com @213.162.97.177   +cookie
// dig www.london-nano.com @213.162.97.177 +nocookie
server 213.162.97.177   { send-cookie no; };
server 213.162.97.178   { send-cookie no; };



// etdbw.com servers that don't understand edns options
(www.mycoverageinfo.com)
// dig www.mycoverageinfo.gtm.etdbw.com. +trace
// dig www.mycoverageinfo.gtm.etdbw.com. @167.79.186.7   +cookie =>
noerror, 0 answers
// dig www.mycoverageinfo.gtm.etdbw.com. @167.79.186.7 +nocookie =>
noerror, 1 answer
server 167.79.45.7  { send-cookie no; };
server 167.79.182.7 { send-cookie no; };
server 167.79.186.7 { send-cookie no; };
server 167.79.192.7 { send-cookie no; };

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

iEYEAREKAAYFAlgsp6AACgkQL6j7milTFsF5VACfXxKp+HLNNX7fczr4xF4qT4LP
UCIAn3h4WPC2QZ21+gYnSuECG3t2nwEQ
=22tF
-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: rndc addzone type forward

2016-11-16 Thread Tony Finch

Emil Natan  wrote:
>
> I also compiled BIND 9.11.0rc3, but nothing changed, no more verbosity,
> only the name of the .nzf file created changed from hash to plain text.

Try 9.11.0-P1 which has a few changes since rc3.

> Another finding is that the failure .nzf file is created, but it's empty
> and the next run of rndc addzone fails with "already exists".

Is the zone present in memory but not on disk, perhaps? Try something like:

$ curl -Ssf http://server:8053/json/v1/zones | grep name

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
South Biscay, South Fitzroy: Northeasterly 4 or 5 at times in Fitzroy,
otherwise variable 3 or 4, becoming westerly 5 or 6 in north. Slight or
moderate, becoming rough later in north. Rain or showers. Moderate or good.
___
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: rndc addzone type forward

2016-11-16 Thread Emil Natan

 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:50 PM
UTC Time: November 16, 2016 3:50 PM
From: e...@foowatch.com
To: bind-users@lists.isc.org 

 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:12 PM
UTC Time: November 16, 2016 3:12 PM
From: d...@dotat.at
To: Emil Natan 
bind-users@lists.isc.org 

Emil Natan  wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
--
f.anthony.n.finch  http://dotat.at/ - I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.

Thank you for your response.
I'm not using and not specifying view, which is optional anyway. I also 
compiled BIND 9.11.0rc3, but nothing changed, no more verbosity, only the name 
of the .nzf file created changed from hash to plain text.
Another finding is that the failure .nzf file is created, but it's empty and 
the next run of rndc addzone fails with "already exists".

root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: not found
root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
/chroot/named/var/named/_default.nzf
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: already exists
configure_zone failed: already exists
ls -l /chroot/named/var/named/_default.nzf -rw-r--r-- 1 named named 0 Nov 16 
17:39 /chroot/named/var/named/_default.nzf

Emil

Update: despite the errors, the forwarding takes effect, checked with tcpdump.
But now I can't remove the forwarding zone:
After:
root@debugtzc:/usr/local/stow# rndc addzone google.com '{ type forward; forward 
only; forwarders { 8.8.4.4; }; };
'rndc: 'addzone' failed: not found

Here forwarding works:
18:04:36.703150 IP debugtzc.isoc.org.il.55531 > 8.8.4.4.domain: 20892+% [1au] 
A? google.com. (51)

But then:
root@debugtzc:/usr/local/stow# rndc delzone google.com
rndc: 'delzone' failed: not found
no matching zone 'google.com' in any view

And the queries for google.com are still forwarded to 8.8.4.4.

Emil___
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: rndc addzone type forward

2016-11-16 Thread Emil Natan

 Original Message 
Subject: Re: rndc addzone type forward
Local Time: November 16, 2016 5:12 PM
UTC Time: November 16, 2016 3:12 PM
From: d...@dotat.at
To: Emil Natan 
bind-users@lists.isc.org 

Emil Natan  wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
--
f.anthony.n.finch  http://dotat.at/ - I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.

Thank you for your response.
I'm not using and not specifying view, which is optional anyway. I also 
compiled BIND 9.11.0rc3, but nothing changed, no more verbosity, only the name 
of the .nzf file created changed from hash to plain text.
Another finding is that the failure .nzf file is created, but it's empty and 
the next run of rndc addzone fails with "already exists".

root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: not found
root@debugtzc:/usr/local/stow# find /chroot/named -name "*.nzf"
/chroot/named/var/named/_default.nzf
root@debugtzc:/usr/local/stow# rndc addzone google '{ type forward; forward 
only; forwarders { 8.8.8.8; }; };'
rndc: 'addzone' failed: already exists
configure_zone failed: already exists
ls -l /chroot/named/var/named/_default.nzf -rw-r--r-- 1 named named 0 Nov 16 
17:39 /chroot/named/var/named/_default.nzf

Emil___
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: rndc addzone type forward

2016-11-16 Thread Tony Finch

Emil Natan  wrote:
>
> I'm trying to add zone of type "forward" with rndc addzone, but it fails with:
>
> rndc addzone zone.org '{type forward; forward only; forwarders { 
> 192.168.20.115; }; };'
> rndc: 'addzone' failed: not found

I think this happens if you are using a version before 9.11 (which has a
more verbose error) and you get the view name wrong. The view name can be
wrong if you have multiple views and you don't specify which one.

e.g. on a 9.10 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
$

And on a 9.11 server with views:

$ rndc addzone google '{ type forward; forward only; forwarders { 8.8.8.8; }; 
};'
rndc: 'addzone' failed: not found
no matching view found for '_default'
$

You can get a similar error if you specify an incorrect view:

$ rndc addzone google in error '{ type forward; forward only; forwarders { 
8.8.8.8; }; };'
rndc: 'addzone' failed: not found
no matching view found for 'error'
$

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Shannon: West 6 to gale 8, perhaps severe gale 9 later. Rough or very rough,
becoming mainly high. Thundery showers. Good, occasionally poor.
___
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

rndc addzone type forward

2016-11-16 Thread Emil Natan

Hello,

I'm trying to add zone of type "forward" with rndc addzone, but it fails with:


rndc addzone zone.org '{type forward; forward only; forwarders { 
192.168.20.115; }; };'
rndc: 'addzone' failed: not found

I have allow-new-zones set to yes in named.conf. Loading zones of type master 
works fine. All I see in the logs is:
Nov 16 16:12:33 debugtzs named[1018]: general: info: received control channel 
command 'addzone'

Am I missing something?

Emil___
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 statistics?

2016-11-16 Thread Bob Harold

On Wed, Nov 16, 2016 at 8:45 AM, Voigt, Thomas 
wrote:

> Hi all,
>
> I need to create some statistics for our BIND resolvers here. One of the
> measures is the number of unique ip addresses per day which are querying
> our resolvers.
>
> I've already checked "rndc stats" output as well as BIND's XML statistics
> channels. But I didn't found any value that satisfies this question.
>
> Another way could be to apply some "grep | sort --unique" logic to the
> named_querylog file(s). But those files are around >2Gig per day and
> resolver here. That's to much work...
>
> Is there another way to get this measure?
>
> --
> Regards
>
> Thomas
>
>
I suspect that "DSC" collects the data you want, but you might need to
configure a graph to show it.
https://www.dns-oarc.net/tools/dsc

-- 
Bob Harold
___
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 statistics?

2016-11-16 Thread Voigt, Thomas

Hi all,

I need to create some statistics for our BIND resolvers here. One of the 
measures is the number of unique ip addresses per day which are querying our 
resolvers.

I've already checked "rndc stats" output as well as BIND's XML statistics 
channels. But I didn't found any value that satisfies this question.

Another way could be to apply some "grep | sort --unique" logic to the 
named_querylog file(s). But those files are around >2Gig per day and resolver 
here. That's to much work...

Is there another way to get this measure?

--
Regards

Thomas

___
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: refused rcode is not working RPZ?

refused rcode is not working RPZ?

Re: bind 9.11, cookes by default

Re: bind 9.11, cookes by default

Re: rndc addzone type forward

Re: bind 9.11, cookes by default

bind 9.11, cookes by default

Re: rndc addzone type forward

Re: rndc addzone type forward

Re: rndc addzone type forward

Re: rndc addzone type forward

rndc addzone type forward

Re: BIND statistics?

BIND statistics?

14 matches

Site Navigation

Mail list logo

Footer information