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-bbbb-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 <e...@isc.org> 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
