Re: Verify raw data within slaves on 9.9.x
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?
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★
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
> 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?
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?
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?
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"
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
> 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
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?
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
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