Re: Host spans Multi-Domains
On 21 November 2013 02:55, Davis, Donald W wrote: > A correction. There is only a single IP address for this server. You can either put an A record in each zone pointing to the IP address of the server "red" or you can put an A record in the primary zone which the server is a member of and a CNAME in the secondary zone pointing to the primary zone. Either way it shouldn't make any difference (unless the McAfee software explicitely looks for an A record and doesn't follow CNAMES). Steve ___ 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: BIND9-ARM (HTML) feature request: better hyperlinking in/of chapter 6
So does this mean there could be a Kindle edition of it? Having impulsively snapped up a new Kindle Paperwhite (2nd Gen) for $19 (WiFi only), when I originally had no plans to do so...since I had only jumped in on using the first gen Kindle Paperwhite 3G a few months ago (before that I had a Kindle 2.) I sent the PDF to my Kindle once don't even want to think about it even if I'm in a bind. Though I had at one time thought about trying to read it cover to cover On 2013-11-21 09:14, /dev/rob0 wrote: On Wed, Nov 20, 2013 at 09:43:40PM +, Evan Hunt wrote: On Wed, Nov 20, 2013 at 03:27:59PM -0600, /dev/rob0 wrote: > Looking at the HTML source for the Table of Contents, it seems > like someone had this idea before but didn't follow through. > There are numerous links to plain-language anchors amidst mostly > the "id25x" anchor names. (These probably had something to do > with the "DocBook XSL Stylesheets V1.71.1" generator.) Note that the HTML isn't the source, it's generated from doc/arm/Bv9ARM-book.xml and from the various ".docbook" files throughout the source tree. Right, I figured. It seems that I might add "id" tag modifiers to various and and tags, and that would at least create the anchors. The daunting part is that I'm not sure what this will do: some-named.conf-setting ... See ... because at this point, it looks like the only anchors are in section headers. Perhaps more code will have to be added to properly deal with these links? Or is there some other xref modifier which would do it? (I suppose I can try it and see what happens.) > I might try to work on this myself, but I thought I should toss > the idea out for comments and suggestions first. Specifically, I > suppose that whatever work that is done should be compatible with > the DocBook source and other BIND9-ARM formats. We'd certainly be glad to have help with it. hehe, oops, I guess I'm committed now :) -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally ___ 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: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
On 21/11/2013 18:38, /dev/rob0 wrote: On Thu, Nov 21, 2013 at 10:33:18AM -0800, jen...@promessage.com wrote: Seems the question pops up with every bind release; this time I waited for at least a couple of weeks since the bind release. Anyone know what's happening with the RPZ2+RRL patches for bind 9.9.4-P1? RRL is included in 9.9.4 already. Deployed and working here. Yes. But RPZ2 != RPZ. ___ 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: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
Thanks for the quick response. "dig +noedns" did it. Thank you. > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: >> Bind 9.9.x is able to perform zone transfers from the Windows DC >> without any issue. Performing a named-checkzone against the zone file >> with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the >> issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig >> 9.9). >> >> Has anyone ran into a similar issue? Any help would be greatly appreciated. > > BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > it works, then that was the problem. > > -- > 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: BIND9-ARM (HTML) feature request: better hyperlinking in/of chapter 6
On Wed, 20 Nov 2013, /dev/rob0 wrote: > Chapter 6 is the comprehensive configuration reference. What I'd like > to see is more (and plain-language, consistent) hyperlinking. The > basic idea is that any named.conf setting could be found at an > anchor: > > Bv9ARM.ch06.html#that-setting Yes that would be great. We do something similar with the unique log messages for BIND10 and Kea; for example: http://bind10.isc.org/docs/bind10-messages.html#AUTH_XFRIN_CHANNEL_CREATED http://bind10.isc.org/docs/bind10-messages.html#XFROUT_IXFR_NO_ZONE The corresponding docbook code was like: ... > This sounds grand and relatively simple, but in practice it will > require some thought and work. For example, we have "Grammar" and > "Definition and Usage" subsections for each "Statement" section. > Which one would we link to? Ideally, both, but we'd have to think > about a good anchor naming scheme. I'd say that the name in each > "Grammar" should hyperlink to each "Definition and Usage" name and > vice versa. I had thought about this several times. I published a print book based on the ARM and considered having the grammar for a specific item statement included next to the corresponding documentation -- so you don't have to look in multiple places. > Also, what do we do in the case where the same setting is usable in > more than one context? Looking at "Zone Options", with numerous "See > the description of ...", this would actually help, because it would > take you directly to the setting rather than to the subsection > heading. Yes. I did a lot of work on this also, but never made it into the released ARM. By the way, I have found that the maintained dblatex (http://dblatex.sourceforge.net/) framework is easier and more reliable to use than the existing db2latex stylesheets. Hopefully someday I can finish the conversion of our Makefiles to use it instead (or as an alternative). Thank you much for your suggestions and potential work. If you have any questions or need assistance with the PDF/HTML builds, please let me know. (I can also share with you my detailed plans also.) ___ 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: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
On Thu, Nov 21, 2013 at 10:33:18AM -0800, jen...@promessage.com wrote: > Seems the question pops up with every bind release; this time I > waited for at least a couple of weeks since the bind release. > > Anyone know what's happening with the RPZ2+RRL patches for bind > 9.9.4-P1? RRL is included in 9.9.4 already. Deployed and working here. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: RHEL 6 CPU load
On 21/11/13 14:57, - wrote: Are others seeing the named process run at 130-180% on RHEL 6? We've No. Our RHEL6 boxes rune fine. ___ 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: RHEL 6 CPU load
What version of BIND did you have on RHEL5? Does your RHEL6 named get any better if you try ‘-U #’ (where # is half or less your cpu count)? _S On Nov 21, 2013, at 7:35 AM, Phil Mayers wrote: > On 21/11/13 14:57, - wrote: > >> Are others seeing the named process run at 130-180% on RHEL 6? We've > > No. Our RHEL6 boxes rune fine. > ___ > 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 ___ 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: RHEL 6 CPU load
> What about the information from top? When comparing RHEL5 and RHEL6 systems, > I would compare the total CPU usage of the server (out of 100% not 2400% or > 1600%). > > Since the hardware is different, comparing a 16 named threads on a 16 core > box at ???MHz against a 24 core box with 24 named threads at ???MHz may not > necessarily be valid. If the CPUs are running at the same frequency (look at > what speed they are actually running at vs the max speed... see > /proc/cpuinfo ) then you can probably account for the 16 vs 24 core > difference pretty easily. If the CPUs run at more than negligibly different > frequencies you will have to factor that into any comparison or make the > frequencies the same to make a 1:1 good comparison. The systems run at the exact same frequency processors (RHEL 6 - X5675 @ 3.07GHz, RHEL 5 - X5667 @ 3.07GHz). One is just a little older and only has 16 CPUs. I've run named on the RHEL 6 system with only 16 procs (named -n 16) to see if it made a difference and the result was the same, named on the RHEL 6 system running 6-7 times the load of a RHEL 5 system. We aren't running DNSSec so I don't think the managed-keys-directory should be an issue. Running a 30 second strace on one of the named threads shows the process is a lot busier and has more errors on the RHEL 6 system: RHEL 6: > strace -c -p 29904 Process 29904 attached - interrupt to quit Process 29904 detached % time seconds usecs/call callserrors syscall -- --- --- - - 99.939.074464 135 67128 20375 futex 0.040.003689 1 2538 2430 recvmsg 0.020.002141 1 2498 write 0.000.000256 2 103 sendmsg 0.000.000138 436 socket 0.000.65 236 connect 0.000.19 072 setsockopt 0.000.00 036 close 0.000.00 036 bind 0.000.00 036 getsockopt 0.000.00 0 108 fcntl -- --- --- - - 100.009.080772 72627 22805 total RHEL 5: > strace -c -p 18498 Process 18498 attached - interrupt to quit Process 18498 detached % time seconds usecs/call callserrors syscall -- --- --- - - 99.971.549134 69 22399 5604 futex 0.020.000243 0 720 698 recvmsg 0.010.000193 0 722 write 0.000.17 036 socket 0.000.00 036 close 0.000.00 036 connect 0.000.00 039 sendmsg 0.000.00 036 bind 0.000.00 072 setsockopt 0.000.00 036 getsockopt 0.000.00 0 108 fcntl -- --- --- - - 100.001.549587 24240 6302 total Are others seeing the named process run at 130-180% on RHEL 6? We've never seen this high of CPU usage for named on any system including a Solaris 10 system running 32 CPUs. They have all run around 11-30% CPU depending on the time of day. -- Daniel ___ 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: RHEL 6 CPU load
On 21/11/13 17:30, Sean Channel wrote: What version of BIND did you have on RHEL5? Does your RHEL6 named get any better if you try ‘-U #’ (where # is half or less your cpu count)? We moved from RHEL5 9.8.3 to RHEL6 9.8.3, and saw no performance change. We then upgraded through various versions to 9.9.3 (still on RHEL6) and also saw no performance change. I'm not sure what you mean by "does my named performance get any better" as it's fine now, but if you're asking whether CPU usage changes with that option, I'm afraid I'm not about to mess with our production DNS servers to answer a random mailing list query ;o) ___ 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
any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
Hi, Seems the question pops up with every bind release; this time I waited for at least a couple of weeks since the bind release. Anyone know what's happening with the RPZ2+RRL patches for bind 9.9.4-P1? I've tried repeatedly to subscribe to the dns firewalls list to ask this, but never get a confirmation email to my subscription. Checking, there doesn't seem to be any activity at all since October in that list's archives. I've tried emailing the authors of the patch to get some kind of info; so far, no response. Are the patches still being developed separately? Has the project died? Any insights/info from the list here? Thanks, JenL ___ 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: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix writes: > Thanks for the quick response. "dig +noedns" did it. Thank you. It still should not have resulted in a "extra input data". It would be useful to see the hex dump of the dns message that triggered the "extra input data" message. Mark > > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > > > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > >> Bind 9.9.x is able to perform zone transfers from the Windows DC > >> without any issue. Performing a named-checkzone against the zone file > >> with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the > >> issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig > >> 9.9). > >> > >> Has anyone ran into a similar issue? Any help would be greatly appreciated. > > > > BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > > it works, then that was the problem. > > > > -- > > 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 -- 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: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
In message <1385060190.20266.50452509.48b1a...@webmail.messagingengine.com>, jen...@promessage.com writes: > On Thu, Nov 21, 2013, at 10:38 AM, /dev/rob0 wrote: > > RRL is included in 9.9.4 already. Deployed and working here. > > as specified @ > > http://ss.vix.su/~vjs/rrlrpz.html > > ... > BIND9 9.9.4 > file rpz2+rl-9.9.4.patch, version 9.9.4-rpz2+rl.13269.14 > Version 9.9.4 includes RRL with ./configure --enable-rrl so this > patch only affects RPZ. > ... > > So, that's simply a naming issue. > > IIUC, rpz2 != rpz. > > I'd applied "rpz2+rl-9.9.4.patch" to 9.9.4; with success. > > So, now, I'm asking about the name- and functionally-equivalent > "rpz2+rl-9.9.4-P1.patch" for the bind 9.9.4-P1 release. Did you try applying rpz2+rl-9.9.4-P1.patch to 9.9.4-P1? Apart from the version file it should apply cleanly and you can ignore the version file or patch it by hand if you want. I would append "-rpz2+rl.13269.14" to "RELEASEVER=1" to give "RELEASEVER=1-rpz2+rl.13269.14" which results in a full version string of "9.9.4-P1-rpz2+rl.13269.14". > JenL > ___ > 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: RHEL 6 CPU load
Phil Mayers wrote the following on 11/21/2013 9:35 AM: On 21/11/13 14:57, - wrote: Are others seeing the named process run at 130-180% on RHEL 6? We've No. Our RHEL6 boxes rune fine. Fine here as well... Here is a decently busy CentOS 6 system w/ latest BIND from RPM, 2x Xeon CPU E5-2640 (the cores typically run at 1200MHz). 1 [|24.7%] 13 [||| 12.1%] Tasks: 411, 107 thr, 446 kthr; 5 running 2 [|| 10.2%] 14 [||1.3%] Load average: 0.71 0.83 0.90 3 [ 6.5%] 15 [||| 4.5%] 4 [||| 4.5%] 16 [ 6.4%] 5 [||| 4.4%] 17 [||1.9%] 6 [| 0.6%] 18 [||3.2%] 7 [||| 3.8%] 19 [||2.5%] 8 [| 0.6%] 20 [| 0.6%] 9 [||1.3%] 21 [ 0.0%] 10 [ 0.0%] 22 [ 0.0%] 11 [||| 10.8%] 23 [| 0.6%] 12 [ 0.0%] 24 [ 0.0%] Mem[|||34455/64375MB] Swp[ 0/9607MB] PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 1862 named 20 0 1960M 203M 2900 S 10.8 0.3 46:47.44 ├─ /usr/sbin/named -u named 1888 named 20 0 1960M 203M 2900 S 0.6 0.3 5:11.81 │ ├─ /usr/sbin/named -u named 1887 named 20 0 1960M 203M 2900 S 0.0 0.3 0:07.57 │ ├─ /usr/sbin/named -u named 1886 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.64 │ ├─ /usr/sbin/named -u named 1885 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.95 │ ├─ /usr/sbin/named -u named 1884 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.78 │ ├─ /usr/sbin/named -u named 1883 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.46 │ ├─ /usr/sbin/named -u named 1882 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.81 │ ├─ /usr/sbin/named -u named 1881 named 20 0 1960M 203M 2900 S 1.3 0.3 1:43.79 │ ├─ /usr/sbin/named -u named 1880 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1879 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.51 │ ├─ /usr/sbin/named -u named 1878 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.71 │ ├─ /usr/sbin/named -u named 1877 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.73 │ ├─ /usr/sbin/named -u named 1876 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.78 │ ├─ /usr/sbin/named -u named 1875 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1874 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1873 named 20 0 1960M 203M 2900 S 1.3 0.3 1:43.57 │ ├─ /usr/sbin/named -u named 1872 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.92 │ ├─ /usr/sbin/named -u named 1871 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.60 │ ├─ /usr/sbin/named -u named 1870 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1869 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.87 │ ├─ /usr/sbin/named -u named 1868 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.43 │ ├─ /usr/sbin/named -u named 1867 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.68 │ ├─ /usr/sbin/named -u named 1866 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.42 │ ├─ /usr/sbin/named -u named 1865 named 20 0 1960M 203M 2900 S 0.0 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1864 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.49 │ ├─ /usr/sbin/named -u named 1863 named 20 0 1960M 203M 2900 S 0.6 0.3 1:43.76 │ └─ /usr/sbin/named -u named And here's a less loaded CentOS 5 server (2x Xeon E5620 which typically runs at 1600MHz per core): 1 [ 0.0%] Tasks: 1962, 64 thr; 2 running 2 [| 4.2%] Load average: 0.48 0.44 0.50 3 [|| 1.2%] 4 [| 0.6%] 5 [ 0.0%] 6 [ 0.0%] 7 [| 0.6%] 8 [|| 1.2%] 9 [ 0.0%] 10 [||| 9.0%] 11 [ 84.4%] 12 [|| 1.2%] 13 [| 0.6%] 14 [||
Re: BIND9-ARM (HTML) feature request: better hyperlinking in/of chapter 6
On Wed, Nov 20, 2013 at 09:43:40PM +, Evan Hunt wrote: > On Wed, Nov 20, 2013 at 03:27:59PM -0600, /dev/rob0 wrote: > > Looking at the HTML source for the Table of Contents, it seems > > like someone had this idea before but didn't follow through. > > There are numerous links to plain-language anchors amidst mostly > > the "id25x" anchor names. (These probably had something to do > > with the "DocBook XSL Stylesheets V1.71.1" generator.) > > Note that the HTML isn't the source, it's generated from > doc/arm/Bv9ARM-book.xml and from the various ".docbook" files > throughout the source tree. Right, I figured. It seems that I might add "id" tag modifiers to various and and tags, and that would at least create the anchors. The daunting part is that I'm not sure what this will do: some-named.conf-setting ... See ... because at this point, it looks like the only anchors are in section headers. Perhaps more code will have to be added to properly deal with these links? Or is there some other xref modifier which would do it? (I suppose I can try it and see what happens.) > > I might try to work on this myself, but I thought I should toss > > the idea out for comments and suggestions first. Specifically, I > > suppose that whatever work that is done should be compatible with > > the DocBook source and other BIND9-ARM formats. > > We'd certainly be glad to have help with it. hehe, oops, I guess I'm committed now :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
Hi, Mark. I've also seen the same problem which occurs with AXFR queries to both Windows server 2003 and 2012: Win2003 --- > ;; Got bad packet: extra input data > 115 bytes > e9 f3 80 80 00 01 00 01 00 00 00 00 04 6c 61 62 .lab > 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc 00 s.hpl.hp.com > 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 70 .._kerberos._tcp > 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f 6d .ba._sites.dc._m > 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 23 sdcs...!.X.# > 00 00 00 64 00 58 0b 73 75 70 70 6f 72 74 2d 62 ...d.X.support-b > 72 31 04 6c 61 62 73 03 68 70 6c 02 05 00 00 00 r1.labs.hpl. > 00 00 00 ... Win2012 --- > ;; Got bad packet: extra input data > 118 bytes > 91 7d 80 80 00 01 00 01 00 00 00 00 05 69 6c 61 .}...ila > 62 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc bs.hpl.hp.com... > 00 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 ..._kerberos._tc > 70 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f p.ba._sites.dc._ > 6d 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 msdcs...!.X. > 25 00 00 00 64 00 58 0c 69 73 75 70 70 6f 72 74 %...d.X.isupport > 2d 70 61 35 05 69 6c 61 62 73 03 05 00 00 00 00 -pa5.ilabs.. > 00 00 00 6f 6d 00...om. -- Andris Mark Andrews wrote: > > In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix > writes: >> Thanks for the quick response. "dig +noedns" did it. Thank you. > > It still should not have resulted in a "extra input data". > > It would be useful to see the hex dump of the dns message > that triggered the "extra input data" message. > > Mark > >>> On Nov 20, 2013, at 22:09, Evan Hunt wrote: >>> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: Bind 9.9.x is able to perform zone transfers from the Windows DC without any issue. Performing a named-checkzone against the zone file with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig 9.9). Has anyone ran into a similar issue? Any help would be greatly appreciated. >>> >>> BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if >>> it works, then that was the problem. >>> >>> -- >>> 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 ___ 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: BIND9-ARM (HTML) feature request: better hyperlinking in/of chapter 6
On Thu, 21 Nov 2013, /dev/rob0 wrote: > The daunting part is that I'm not sure what this will do: > > some-named.conf-setting > > ... > See > > ... because at this point, it looks like the only anchors are in > section headers. Perhaps more code will have to be added to properly > deal with these links? Or is there some other xref modifier which > would do it? > > (I suppose I can try it and see what happens.) Yes, please try it. You can set the id in other elements too. It would be nice to fix all these because often when we regenerate the HTML, the machine-generated IDs change so it cause a huge diff for even minor changes. ___ 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: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
On Thu, Nov 21, 2013, at 10:38 AM, /dev/rob0 wrote: > RRL is included in 9.9.4 already. Deployed and working here. as specified @ http://ss.vix.su/~vjs/rrlrpz.html ... BIND9 9.9.4 file rpz2+rl-9.9.4.patch, version 9.9.4-rpz2+rl.13269.14 Version 9.9.4 includes RRL with ./configure --enable-rrl so this patch only affects RPZ. ... So, that's simply a naming issue. IIUC, rpz2 != rpz. I'd applied "rpz2+rl-9.9.4.patch" to 9.9.4; with success. So, now, I'm asking about the name- and functionally-equivalent "rpz2+rl-9.9.4-P1.patch" for the bind 9.9.4-P1 release. JenL ___ 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: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
In message <528ec4db.6060...@hpl.hp.com>, Andris Kalnozols writes: > Hi, Mark. > > I've also seen the same problem which occurs with AXFR queries > to both Windows server 2003 and 2012: > > Win2003 > --- > > ;; Got bad packet: extra input data > > 115 bytes > > e9 f3 80 80 00 01 00 01 00 00 00 00 04 6c 61 62 .lab > > 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc 00 s.hpl.hp.com > > 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 70 .._kerberos._tcp > > 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f 6d .ba._sites.dc._m > > 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 23 sdcs...!.X.# > > 00 00 00 64 00 58 0b 73 75 70 70 6f 72 74 2d 62 ...d.X.support-b > > 72 31 04 6c 61 62 73 03 68 70 6c 02 05 00 00 00 r1.labs.hpl. > > 00 00 00 ... Which looks like the SRV record is corrupted. There are 4 extra zero octets at the end after the domain name finished. Note the space is correct for a record ending in .hp.com. > Win2012 > --- > > ;; Got bad packet: extra input data > > 118 bytes > > 91 7d 80 80 00 01 00 01 00 00 00 00 05 69 6c 61 .}...ila > > 62 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc bs.hpl.hp.com... > > 00 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 ..._kerberos._tc > > 70 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f p.ba._sites.dc._ > > 6d 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 msdcs...!.X. > > 25 00 00 00 64 00 58 0c 69 73 75 70 70 6f 72 74 %...d.X.isupport > > 2d 70 61 35 05 69 6c 61 62 73 03 05 00 00 00 00 -pa5.ilabs.. > > 00 00 00 6f 6d 00...om. Again the end of the SRV record is corrupted. Similarly the space is correct for a record ending in .hpl.hp.com. One should be able to see the corruption in a packet trace to confirm that it isn't a bug in dig. Mark > -- > Andris > > > Mark Andrews wrote: > > > > In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix wri > tes: > >> Thanks for the quick response. "dig +noedns" did it. Thank you. > > > > It still should not have resulted in a "extra input data". > > > > It would be useful to see the hex dump of the dns message > > that triggered the "extra input data" message. > > > > Mark > > > >>> On Nov 20, 2013, at 22:09, Evan Hunt wrote: > >>> > On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > Bind 9.9.x is able to perform zone transfers from the Windows DC > without any issue. Performing a named-checkzone against the zone file > with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the > issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig > 9.9). > > Has anyone ran into a similar issue? Any help would be greatly appreciat > ed. > >>> > >>> BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > >>> it works, then that was the problem. > >>> > >>> -- > >>> Evan Hunt -- e...@isc.org > >>> Internet Systems Consortium, Inc. > >> ___ > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr > ibe from this list > >> > >> bind-users mailing list > >> bind-users@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > > ___ > 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: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
Mark Andrews wrote: > In message <528ec4db.6060...@hpl.hp.com>, Andris Kalnozols writes: >> Hi, Mark. >> >> I've also seen the same problem which occurs with AXFR queries >> to both Windows server 2003 and 2012: >> >> Win2003 >> --- >>> ;; Got bad packet: extra input data >>> 115 bytes >>> e9 f3 80 80 00 01 00 01 00 00 00 00 > 04 6c 61 62 .lab >>> 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc 00 s.hpl.hp.com >>> 01 > >09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 70 .._kerberos._tcp >>> 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f 6d .ba._sites.dc._m >>> 73 64 63 73 c0 0c > 00 21 > 00 01 > 00 00 02 58 > 00 23 sdcs...!.X.# >>> 00 00 00 64 00 58 > 0b 73 75 70 70 6f 72 74 2d 62 ...d.X.support-b >>> 72 31 04 6c 61 62 73 03 68 70 6c > 02 05 00 > 00 > 00 r1.labs.hpl. >>> 00 00 00 ... > > Which looks like the SRV record is corrupted. There are 4 extra > zero octets at the end after the domain name finished. Note the > space is correct for a record ending in .hp.com. > >> Win2012 >> --- >>> ;; Got bad packet: extra input data >>> 118 bytes >>> 91 7d 80 80 00 01 00 01 00 00 00 00 > 05 69 6c 61 .}...ila >>> 62 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc bs.hpl.hp.com... >>> 00 01 > 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 ..._kerberos._tc >>> 70 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f p.ba._sites.dc._ >>> 6d 73 64 63 73 c0 0c >00 21 > 00 01 > 00 00 02 58 > 00 msdcs...!.X. >>> 25 >00 00 00 64 00 58 > 0c 69 73 75 70 70 6f 72 74 %...d.X.isupport >>> 2d 70 61 35 05 69 6c 61 62 73 > 03 05 00 00 > 00 > 00 -pa5.ilabs.. >>> 00 00 00 6f 6d 00...om. > > Again the end of the SRV record is corrupted. Similarly the space > is correct for a record ending in .hpl.hp.com. > > One should be able to see the corruption in a packet trace to > confirm that it isn't a bug in dig. Your trained eyes could zero-in on any problem much quicker than I could. I have posted the pcap files for both a successful AXFR with +noedns and the problematic query using +edns: ftp://ftp.hpl.hp.com/outgoing/WinAXFR/WinAXFRnoedns.pcap ftp://ftp.hpl.hp.com/outgoing/WinAXFR/WinAXFRedns.pcap Regards, Andris > Mark > >> -- >> Andris >> >> >> Mark Andrews wrote: >>> >>> In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix wri >> tes: Thanks for the quick response. "dig +noedns" did it. Thank you. >>> >>> It still should not have resulted in a "extra input data". >>> >>> It would be useful to see the hex dump of the dns message >>> that triggered the "extra input data" message. >>> >>> Mark >>> > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: >> Bind 9.9.x is able to perform zone transfers from the Windows DC >> without any issue. Performing a named-checkzone against the zone file >> with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the >> issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig >> 9.9). >> >> Has anyone ran into a similar issue? Any help would be greatly appreciat >> ed. > > BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > it works, then that was the problem. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr >> ibe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users >> >> ___ >> 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 ___ 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-us
