dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
Andris Kalnozols
andris at hpl.hp.com
Fri Nov 22 05:58:53 UTC 2013
Mark Andrews wrote:
> In message <528EC4DB.6060204 at 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-BBBB-0BD3944428F8 at 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 <each at 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 -- each at 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 at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list