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