Re: Verify raw data within slaves on 9.9.x

2012-06-12 Thread Mark Elkins
On Mon, 2012-06-11 at 15:51 -0700, Walter Smith wrote:
> Folks,
> 
> 
> What tools/commands I can run to get plain ascii/text data out of
> modern raw/binary on BIND 9.9.x slaves?
> I just want to verify that changes are correct down to the slaves. So
> - I can check-in these changes into svn etc.

If you always want 'ascii' - then configure it so in 'named.conf'

zone "example.com" {
type slave;
file "sec/db.example.com";
masterfile-format text;
masters {
192.168.1.1;
};
};

However - I guess its a little less efficient than the new default 'raw'
mode, especially for large zones. Consider a change of approach and if
its just an automated check - try 'dig'? I'm finding with in-line
signing that zones are often spread about in journal files - which makes
options like 'dig' a better way to go. Otherwise - you may have to first
run 'rndc sync -clean the.zone'.

-- 
  .  . ___. .__  Posix Systems - (South) Africa
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496



smime.p7s
Description: S/MIME cryptographic 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: How to handle zones that need to be the same in all views?

2012-06-12 Thread Phil Mayers

On 06/12/2012 01:03 AM, Max Bowsher wrote:

That won't help me for slave zones:

* the zones get needlessly re-transferred once for each view


If you actually want a copy of each zone in each view, you can't avoid this.



* the files on disk will be repeatedly overwritten as bind tries to save
the zone data separately for each zone, to the same filename


This does rule out includes; they only work for static zones.



* bind will only act on a notify for the view that receives it, leaving
all the other views serving stale data for the zone


Again, this is hard to avoid unless you burn a lot of IPs.


Have you considered a single view containing all the common zones, then 
a view per "different" zone that forwards to 127.0.0.1? Provided you 
arrange your "match-clients" correctly this should work.


You may wish to investigate the attach-cache option, so that all the 
forwarding views can share cache results.


Bear in mind that the forwarding views will not see changes in the 
common view immediately, but will have to wait for TTL expiry. There's 
not much you can do about this.


Basically, there's no trick to do what you want; bind isn't designed to 
share non-static zone data between zones.

___
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


◆with great service , we grow , we achieve!◆jesus★

2012-06-12 Thread Juan O

Dear!
  what's going on? 
  I'd like to share a good online shopping experience with you. 
   www.li-xiao4。info    is a top online store.
  It sells brand new phones, TV ,camera and so on. the quality is very good. I 
can't believe my eyes when I receive the apple phone, 
it is really original, the product has high quality and good after-sales 
service. 
Hope you will not miss this valuable chance!
  We solicit a continuance of your confidence and support!
  cutrez
 
 
 
   2012/6/12 16:34:55
 
  ___
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: Verify raw data within slaves on 9.9.x

2012-06-12 Thread Spain, Dr. Jeffry A.
> However - I guess its a little less efficient than the new default 'raw' 
> mode, especially for large zones. Consider a change of approach and if its 
> just an automated check - try 'dig'? I'm finding with in-line signing that 
> zones are often spread about in journal files - which makes options like 
> 'dig' a better way to go. Otherwise - you may have to first run 'rndc sync 
> -clean the.zone'.

I understand that "named-checkzone -j" will incorporate the contents of the 
journal file, if any. Jeff.
___
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: How to handle zones that need to be the same in all views?

2012-06-12 Thread Barry Margolin
In article ,
 Phil Mayers  wrote:

> Have you considered a single view containing all the common zones, then 
> a view per "different" zone that forwards to 127.0.0.1? Provided you 
> arrange your "match-clients" correctly this should work.

Forwarding only works for recursive queries.  I think he's dealing with 
an auth server.

-- 
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: How to handle zones that need to be the same in all views?

2012-06-12 Thread Phil Mayers

On 12/06/12 15:31, Barry Margolin wrote:

In article,
  Phil Mayers  wrote:


Have you considered a single view containing all the common zones, then
a view per "different" zone that forwards to 127.0.0.1? Provided you
arrange your "match-clients" correctly this should work.


Forwarding only works for recursive queries.  I think he's dealing with
an auth server.



That's not apparent to me, but if so, then he's just going to have to 
tolerate multiple copies of the zones, and deal with the NOTIFY issue 
somehow (burn a lot of IPs?).

___
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: How to handle zones that need to be the same in all views?

2012-06-12 Thread Dan Pritts
Unless I misunderstand 
what you're asking it's simple to do.  

Something like this:

view "internal"
{

   match-clients { 192.168.1.0/24; };

    include "stdzones/stdzones.conf";

    include "conf/internal-zones.conf";

    include "conf/authoritativezones.conf";
    include "conf/slavezones.conf";
};


view "external"
{

    match-clients        { any; };
    match-destinations    { any; };

    include "stdzones/stdzones.conf";

    include "conf/authoritativezones.conf";
    include "conf/slavezones.conf";
};




   	   
   	Max Bowsher  
  June 11, 2012 
5:09 PM
  I've inherited some 
responsibility for existing DNS system that makesextensive use of 
BIND's view feature (there are 10 views; external,internal-site1, 
internal-site2, ...etc...).I'm experiencing a problem in that 
there's really only one zone thatdiffers between views, and now I'm 
facing the difficulty of wanting tohave these multi-viewed 
nameservers act as slaves for some additionalzones; with the slaved 
data being identically visible to all views.In a perfect world, 
BIND would let me tell it that some zones wereglobal to all views, 
but this feature doesn't seem to exist.Does anyone have any 
suggestions for how to structure a setup like this?About the 
only possibility I can come up with is to run two differentsets of 
nameservers, one for the zones that need to be different acrossviews,
 and one for the zones that need to be global.Max.___Please
 visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this listbind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users


-- Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224

___
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.6 crashing with "random.c:106: REQUIRE(jitter < max) failed"

2012-06-12 Thread David A. Evans
This past weekend I upgraded 22 multiprocessor Enterprise Redhat Linux 
servers (ver 5.4, and 5.5) from BIND 9.6-ESV-R5-P1 to 9.6-ESV-R7-P1. Six 
of the servers began to BIND exit after having run for 8 to 12 minutes.

All 22 server configured with: ./configure --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --enable-threads

The 6 servers that were failing were running different version of Redhat 
(5.4, and 5.5) These are the same versions that the other 16 servers are 
running an they have no problems.

The 6 servers that failed were those that are used to resolve DNS names 
FROM the internet, they point at internet roots, the 16 servers that did 
NOT fail are internal caching resolvers that point at internal root 
servers. 

The following was discovered in the log file.

Jun 10 00:39:14 NS1 named[9631]: general: critical: random.c:106: 
REQUIRE(jitter < max) failed
Jun 10 00:39:14 NS1 named[9631]: general: critical: exiting (due to 
assertion failure)

The only difference I can see in random.c are lines 2 and 18 but both are 
commented out so should have no impact. Does anyone have any idea what 
could have changed in the way 9.6-ESV-R7-P1 uses random.c or what values 
it passes to random.c? Seems like 9.6-ESV-R7-P1 is passing random.c some 
jitter value that it does not like so it exits. Any chance this could be 
related to the name servers is the internet root hints file? I noticed 
that I was using an old version of the root name servers list.

The 6 failing servers we downgraded back to BIND 9.6-ESV-R5-P1 and are 
running fine now. 

David A. Evans
Enterprise IP/DNS Management
Network Infrastructure Tools and Services
evans_davi...@cat.com___
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: Verify raw data within slaves on 9.9.x

2012-06-12 Thread Evan Hunt
> However - I guess its a little less efficient than the new default 'raw'
> mode, especially for large zones.

More than a little.  Raw zonefiles load in about half the time it
takes to parse the equivalent text.  The delay only becomes really
noticeable when you have big zones, or a lot of small ones, but
it's always there.

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


Wild card for IPV6 reverse configuration

2012-06-12 Thread hugo hugoo

Dear all,
 
I have tried to configure a zone containing a range of IPV6 PTR records.
My target was to see how it is possible to configure such a zone to
 always return the same answer for all the IPV6 IP’s in the range.
And if possible to return specifi names for specific IP’s.
 
Example of a IPV6 range:
 
1234:5678:90ab:00cd::/56
 
 
Creation of the zone  è  “0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa.”
 
In the zone, I have put the following PTR record:
 
*.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN   PTR 123.lebrol.be.
 
It seems (according to some of my tests) that for all IP’s in the range, the 
reverse is “123.lebrol.be.”
 
Question  è  is this a correct way to configure reverse IPV6 if we accept the 
same name for all the IP’s in the range?
 
 
Zone modification:
 
I have tried to add in the zone file the possibility to answer a 
specific name to a specific IP in the range and keep answering the 
general name to all the other IP’s in the range.
 
*.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN   PTR 123.lebrol.be.
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa.   
 3600IN  PTR nombre.de.cerise.be.è specific IP
 
 
It works when the specific IP is used:
 
lennydnstest01:~# dig @localhost -x 1234:5678:90ab:0021:0fed:cba9:8765:4321
 
;; QUESTION SECTION:
;1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. IN 
PTR
;; ANSWER SECTION:
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 
IN PTR nombre.de.cerise.be.
 
 
But if another IP in the range is used having the following nibbles mapping the 
specific PTR  (here 1.2 ),  it do not work  and nothing is found!
 
 
lennydnstest01:~# dig @localhost -x 1234:5678:90ab:0021::
 
;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. IN 
PTR
;; AUTHORITY SECTION:
0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN SOA ns1.uat.skynet.be. 
dnsmaster.skynet.be. 5 10800 3600 360 3600
 
 
Can someone give an explanation on the use of the wildcard *.Any other way to 
obtain the desired result?
 
 
Thanks in advance for your feedback,
 
Hugo, ___
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: How to handle zones that need to be the same in all views?

2012-06-12 Thread Mark Andrews

This really isn't that hard.  Just use tsig and transfer the zone
between views on the slave machine.  Just ensure that you transfer
from the view that is getting the notify messages from the master.

You will want BIND 9.9.x or later.

Mark

key view1 {

};



key view16 {

};

acl viewkeys {
key view1;
key view2;
...
key view16;
};

view view1 {
match-clients { key view1; !viewkeys; ; };
zone xxx {
type slave;
masters { ; };
file "slave/view1/xxx";
also-notify {
 127.0.0.1 key view2;
 127.0.0.1 key view3;
 
 127.0.0.1 key view16;
};
};
}

view view2 {
match-clients { key view2; !viewkeys; ; };
zone xxx {
type slave;
masters { 127.0.0.1 key view1; };
file "slave/view2/xxx";
};
};

...

view view16 {
match-clients { key view16; !viewkeys; ; };
zone xxx {
type slave;
masters { 127.0.0.1 key view1; };
file "slave/view16/xxx";
};
};

-- 
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: Wild card for IPV6 reverse configuration

2012-06-12 Thread Mark Andrews

In message , hugo hugoo writes:
> Dear all=2C
> =20
> I have tried to configure a zone containing a range of IPV6 PTR records.
> My target was to see how it is possible to configure such a zone to
>  always return the same answer for all the IPV6 IP=92s in the range.
> And if possible to return specifi names for specific IP=92s.
> =20
> Example of a IPV6 range:
> =20
> 1234:5678:90ab:00cd::/56
> =20
> =20
> Creation of the zone  =E8  =930.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa.=94
> =20
> In the zone=2C I have put the following PTR record:
> =20
> *.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN   PTR 123.lebrol.be=
> .
> =20
> It seems (according to some of my tests) that for all IP=92s in the range=
> =2C the reverse is =93123.lebrol.be.=94
> =20
> Question  =E8  is this a correct way to configure reverse IPV6 if we accept=
>  the same name for all the IP=92s in the range?
> =20
> =20
> Zone modification:
> =20
> I have tried to add in the zone file the possibility to answer a=20
> specific name to a specific IP in the range and keep answering the=20
> general name to all the other IP=92s in the range.
> =20
> *.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN   PTR 123.lebrol.be=
> .

You need to add a few more records.  Wildcards don't work the way you think
they do.  The existance of a label, even with no data, disables wildcard
processing.

*.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 123.lebrol.be.
*.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.
*.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.
*.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.
*.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.
*.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.
*.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. PTR 
123.lebrol.be.

> 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa.  =
>   3600IN  PTR nombre.de.cerise.be.=E8 s=
> pecific IP
> =20
> =20
> It works when the specific IP is used:
> =20
> lennydnstest01:~# dig @localhost -x 1234:5678:90ab:0021:0fed:cba9:8765:4321
> =20
> =3B=3B QUESTION SECTION:
> =3B1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa=
> . IN PTR
> =3B=3B ANSWER SECTION:
> 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3=
> 600 IN PTR nombre.de.cerise.be.
> =20
> =20
> But if another IP in the range is used having the following nibbles mapping=
>  the specific PTR  (here 1.2 )=2C  it do not work  and nothing is found!
> =20
> =20
> lennydnstest01:~# dig @localhost -x 1234:5678:90ab:0021::
> =20
> =3B=3B QUESTION SECTION:
> =3B0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.2.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa=
> . IN PTR
> =3B=3B AUTHORITY SECTION:
> 0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 IN SOA ns1.uat.skynet.be. dnsmas=
> ter.skynet.be. 5 10800 3600 360 3600
> =20
> =20
> Can someone give an explanation on the use of the wildcard *.Any other way =
> to obtain the desired result?
> =20
> =20
> Thanks in advance for your feedback=2C
> =20
> Hugo=2C =
> 
> --_8940b2fd-a732-48b4-8129-33249f29de87_
> Content-Type: text/html; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> 
> 
>  =3D"font-size:11pt">Dear all=2C
>  =3B
> I have tried to configure a zone containing a range of IPV6 PTR record=
> s.
> My target was to see how it is possible to configure such a zone to
>  always return the same answer for all the IPV6 IP=92s in the range.
> And if possible to return specifi names for specific IP=92s.
>  =3B
> Example of a IPV6 range:
>  =3B
> 1234:5678:90ab:00cd::/56
>  =3B
>  =3B
> Creation of the zone =3B =
> =E8 =3B =930.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa.=94 >
>  =3B
> In the zone=2C I have put the following PTR record:
>  =3B
> *.0.0.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. 3600 =3B =3B =3B&n=
> bsp=3B IN =3B =3B PTR =3B =3B =3B =3B 123.lebrol.be=
> .
>  =3B
> It seems (acco