Got bad packet: bad label type
Linux Addict
it means and how to resolve it.
;; Got bad packet: bad label type
160 bytes
2b 3c 81 80 00 01 00 04 00 00 00 00 09 5f 6b 65
72 62 65 72 6f 73 04 5f 75 64 70 05 49 54 57 45
42 05 57 45 42 4d 44 03 4e 45 54 00 00 21 00 01
c0 0c 00 21 00 01 00 00 00 77 00 10 00 00 00 64
00 58 07 64 6e 79 64 63 30 32 c0 3f c0 0c 00 21
00 01 00 00 00 77 00 10 00 00 00 64 00 58 07 64
6e 79 64 63 30 31 c0 3f c0 0c 00 21 00 01 00 00
00 77 00 10 00 00 00 64 00 58 07 64 6e 6a 64 63
30 32 c0 3f c0 0c 00 21 00 01 00 00 00 77 00 10
00 00 00 64 00 58 07 64 6e 6a 64 63 30 31 c0 3f
Thanks
LA
Peter Dambier
Did you install the right kerberos authenticator
and the gnu tls library for your linux version?
kind regards
Peter
--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
Linux Addict
> Looks like crypted chaos records.
>
> Did you install the right kerberos authenticator
> and the gnu tls library for your linux version?
>
>
> kind regards
> Peter
Thank you for your response.
Its RHEL4U6. I have all the default RPMs installed.
gnutls-1.0.20-3.2.2
krb5-libs-1.3.4-27
krbafs-1.2.2-6
pam_krb5-2.1.8-1
krb5-devel-1.3.4-27
krb5-workstation-1.3.4-27
krbafs-devel-1.2.2-6
Anyway, why does it matter if the client just makes domain request. My
assumption was that server was sending extra packets which the client didn't
understand, but I may be wrong.
Cheers, La
Linux Addict
BTW, Where do I download iason? I will give it a shot with...
~LA
Peter Dambier
sorry, I was pulling your leg.
It would be nice to know, what request you made.
Did you query an A record or an MX record.
A very good help is the dig tool.
You might have a look with ngrep if dig gets
the same answer and how it interprets that
answer.
You can find the latest IASON at
Look for downloads or
wget http://iason.site.voila.fr/Iason/iason.0.0.7.tgz
Sorry the documentation is still horrible.
Cheers
Peter
> +49(6252)750-308 (VoIP: sipgate.de <http://sipgate.de>)
> mail: pe...@peter-dambier.de <mailto:pe...@peter-dambier.de>
Mark Andrews
In message <707abafb0810211024m2d1...@mail.gmail.com>, "Linu
x Addict" writes:
> I get this error when I try resolve some specific records. Anyone know what
> it means and how to resolve it.
You got a malformed packet.
> ;; Got bad packet: bad label type
> 160 bytes
> 2b 3c 81 80 00 01 00 04 00 00 00 00 09 5f 6b 65
id=11068
questions=1
answers=4
authorityu=0
additional=0
_kerberos.
> 72 62 65 72 6f 73 04 5f 75 64 70 05 49 54 57 45
_tcp. ITWEB.
> 42 05 57 45 42 4d 44 03 4e 45 54 00 00 21 00 01
WEBMD. CET. SRV IN
> c0 0c 00 21 00 01 00 00 00 77 00 10 00 00 00 64 <------------------\
compression point to offset 0x0c (_tcp.ITWEB.WEBMD.CET.) |
SRV IN 119 16 0 100 |
> 00 58 07 64 6e 79 64 63 30 32 c0 3f c0 0c 00 21 |
88 dnydc02. compression pointer to offset 3f ----/
(which is 0x64, which is not a valid label).
> 00 01 00 00 00 77 00 10 00 00 00 64 00 58 07 64
> 6e 79 64 63 30 31 c0 3f c0 0c 00 21 00 01 00 00
> 00 77 00 10 00 00 00 64 00 58 07 64 6e 6a 64 63
> 30 32 c0 3f c0 0c 00 21 00 01 00 00 00 77 00 10
> 00 00 00 64 00 58 07 64 6e 6a 64 63 30 31 c0 3f
>
> Thanks
> LA
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Mark Andrews
In message <48FE4112...@peter-dambier.de>, Peter Dambier writes:
> Hello Linux Addict,
>
> sorry, I was pulling your leg.
If you have nothing constructive to say please say nothing.
> It would be nice to know, what request you made.
> Did you query an A record or an MX record.
He queried for a SRV record. Which was in the question
section of the dumped response.
> A very good help is the dig tool.
He used dig. It dumped the raw packet as it couldn't
decode it.
> You might have a look with ngrep if dig gets
> the same answer and how it interprets that
> answer.
>
> You can find the latest IASON at
>
> http://iason.site.voila.fr/
>
> Look for downloads or
>
> wget http://iason.site.voila.fr/Iason/iason.0.0.7.tgz
>
> Sorry the documentation is still horrible.
>
>
> Cheers
> Peter
Linux Addict
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
>
This is awesome!! How did you decode it? Now How do I fix it?
Thanks, LA
Mark Andrews
In message <707abafb0810211732o3a2...@mail.gmail.com>, "Linu
The contents of a DNS packet are described in RFCs 1034 and
RFC 1035. It's a simple matter to just read the data.
> Now How do I fix it?
You fix the server (usually that means upgrade) that sent
you the response and/or any middle box (nat/firewall) that
mucked with the packets contents.
All the compression pointers in the SRV records are bad
which rules out random packet corruption. So you are looking
at the software that wrote / re-wrote the DNS payload.
Mark
>
> Thanks, LA
Kevin Darcy
>
>
Well, the Message Format and Resource Record format are described in RFC
1035, and ASCII is, well, ASCII.
How do you fix it?
Are you seeing this from a BIND nameserver?
If so, then there is presumably something in the middle corrupting the
packet (not that I think BIND is perfect, but if it had a problem with
basic packet construction I think we would have heard about it by now).
Find out what that middlebox is and complain to the administrator/vendor.
If it's from some non-BIND nameserver, then go complain to the implementor.
- Kevin
Linux Addict
I will figure it out from here. Thank you very much everyone!
Joseph Karpenko (jkarpenk)
layer pretty quickly and you can write the result to a pcap file.
>>> p=DNS(import_hexcap())
0000 2b 3c 81 80 00 01 00 04 00 00 00 00 09 5f 6b 65
0010 72 62 65 72 6f 73 04 5f 75 64 70 05 49 54 57 45
0020 42 05 57 45 42 4d 44 03 4e 45 54 00 00 21 00 01
0030 c0 0c 00 21 00 01 00 00 00 77 00 10 00 00 00 64
0040 00 58 07 64 6e 79 64 63 30 32 c0 3f c0 0c 00 21
0050 00 01 00 00 00 77 00 10 00 00 00 64 00 58 07 64
0060 6e 79 64 63 30 31 c0 3f c0 0c 00 21 00 01 00 00
0070 00 77 00 10 00 00 00 64 00 58 07 64 6e 6a 64 63
0080 30 32 c0 3f c0 0c 00 21 00 01 00 00 00 77 00 10
0090 00 00 00 64 00 58 07 64 6e 6a 64 63 30 31 c0 3f
>>>
>>> p
<DNS id 068 qr=1L opcode=QUERY aa=0L tc=0L rd=1L ra=1L z=0L rcode=ok
qdcount=1 ancount=4 nscount=0 arcount=0 qd=<DNSQR
qname='_kerberos._udp.ITWEB.WEBMD.NET.' qtype=SRV qclass=IN |> an=<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnydc02\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnydc01\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnjdc02\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnjdc01\xc0?' |>>>> ns=0 ar=0 |>
>>>
>>>
>>> p.show(),hexdump(p)
###[ DNS ]###
id= 11068
qr= 1L
opcode= QUERY
aa= 0L
tc= 0L
rd= 1L
ra= 1L
z= 0L
rcode= ok
qdcount= 1
ancount= 4
nscount= 0
arcount= 0
\qd\
|###[ DNS Question Record ]###
| qname= '_kerberos._udp.ITWEB.WEBMD.NET.'
| qtype= SRV
| qclass= IN
\an\
|###[ DNS Resource Record ]###
| rrname= '_kerberos._udp.ITWEB.WEBMD.NET.'
| type= SRV
| rclass= IN
| ttl= 119L
| rdlen= 16
| rdata= '\x00\x00\x00d\x00X\x07dnydc02\xc0?'
|###[ DNS Resource Record ]###
| rrname= '_kerberos._udp.ITWEB.WEBMD.NET.'
| type= SRV
| rclass= IN
| ttl= 119L
| rdlen= 16
| rdata= '\x00\x00\x00d\x00X\x07dnydc01\xc0?'
|###[ DNS Resource Record ]###
| rrname= '_kerberos._udp.ITWEB.WEBMD.NET.'
| type= SRV
| rclass= IN
| ttl= 119L
| rdlen= 16
| rdata= '\x00\x00\x00d\x00X\x07dnjdc02\xc0?'
|###[ DNS Resource Record ]###
| rrname= '_kerberos._udp.ITWEB.WEBMD.NET.'
| type= SRV
| rclass= IN
| ttl= 119L
| rdlen= 16
| rdata= '\x00\x00\x00d\x00X\x07dnjdc01\xc0?'
ns= 0
ar= 0
0000 2B 3C 81 80 00 01 00 04 00 00 00 00 09 5F 6B 65
+<..........._ke
0010 72 62 65 72 6F 73 04 5F 75 64 70 05 49 54 57 45
rberos._udp.ITWE
0020 42 05 57 45 42 4D 44 03 4E 45 54 00 00 21 00 01
B.WEBMD.NET..!..
0030 09 5F 6B 65 72 62 65 72 6F 73 04 5F 75 64 70 05
._kerberos._udp.
0040 49 54 57 45 42 05 57 45 42 4D 44 03 4E 45 54 00
ITWEB.WEBMD.NET.
0050 00 21 00 01 00 00 00 77 00 10 00 00 00 64 00 58
.!.....w.....d.X
0060 07 64 6E 79 64 63 30 32 C0 3F 09 5F 6B 65 72 62
.dnydc02.?._kerb
0070 65 72 6F 73 04 5F 75 64 70 05 49 54 57 45 42 05
eros._udp.ITWEB.
0080 57 45 42 4D 44 03 4E 45 54 00 00 21 00 01 00 00
WEBMD.NET..!....
0090 00 77 00 10 00 00 00 64 00 58 07 64 6E 79 64 63
.w.....d.X.dnydc
00a0 30 31 C0 3F 09 5F 6B 65 72 62 65 72 6F 73 04 5F
01.?._kerberos._
00b0 75 64 70 05 49 54 57 45 42 05 57 45 42 4D 44 03
udp.ITWEB.WEBMD.
00c0 4E 45 54 00 00 21 00 01 00 00 00 77 00 10 00 00
NET..!.....w....
00d0 00 64 00 58 07 64 6E 6A 64 63 30 32 C0 3F 09 5F
.d.X.dnjdc02.?._
00e0 6B 65 72 62 65 72 6F 73 04 5F 75 64 70 05 49 54
kerberos._udp.IT
00f0 57 45 42 05 57 45 42 4D 44 03 4E 45 54 00 00 21
WEB.WEBMD.NET..!
0100 00 01 00 00 00 77 00 10 00 00 00 64 00 58 07 64
.....w.....d.X.d
0110 6E 6A 64 63 30 31 C0 3F njdc01.?
(None, None)
>>>
>>> ## we only have the DNS layer, need to add Ethernet,
>>> ## IP, and UDP and then write the pcap:
>>>
>>> p=Ether()/IP()/UDP()/p
>>> p
<Ether type=IPv4 |<IP frag=0 proto=UDP |<UDP sport=domain |<DNS
id 068 qr=1L opcode=QUERY aa=0L tc=0L rd=1L ra=1L z=0L rcode=ok
qdcount=1 ancount=4 nscount=0 arcount=0 qd=<DNSQR
qname='_kerberos._udp.ITWEB.WEBMD.NET.' qtype=SRV qclass=IN |> an=<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnydc02\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnydc01\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnjdc02\xc0?' |<DNSRR
rrname='_kerberos._udp.ITWEB.WEBMD.NET.' type=SRV rclass=IN ttl 9L
rdata='\x00\x00\x00d\x00X\x07dnjdc01\xc0?' |>>>> ns=0 ar=0 |>>>>
>>>
>>> wrpcap("/tmp/dns-bad-label-type.pcap", p)
>>>
cheers,
---
karpenko
> From: bind-use...@isc.org
> [mailto:bind-use...@isc.org] On Behalf Of Mark Andrews
> Sent: Tuesday, October 21, 2008 7:47 PM
> To: Linux Addict
> Cc: bind-...@isc.org
> Subject: Re: Got bad packet: bad label type
>
>
> In message
> <707abafb0810211732o3a2...@mail.gmail.com>, "Linu
> x Addict" writes:
> > On Tue, Oct 21, 2008 at 6:24 PM, Mark Andrews
> <Mark_A...@isc.org> wrote:
> >
> > >
> > > In message
> <707abafb0810211024m2d1...@mail.gmail.com>,
> > > "Linu
> > > x Addict" writes:
> > > > I get this error when I try resolve some specific
> records. Anyone know
> > > what
> > > > it means and how to resolve it.
> > >
> > > You got a malformed packet.
> > >
> > > > ;; Got bad packet: bad label type
> > > > 160 bytes
> > > > 2b 3c 81 80 00 01 00 04 00 00 00 00 09 5f 6b 65
> > > id 068
> The contents of a DNS packet are described in RFCs 1034 and
> RFC 1035. It's a simple matter to just read the data.
>
> > Now How do I fix it?
>
> You fix the server (usually that means upgrade) that sent
> you the response and/or any middle box (nat/firewall) that
> mucked with the packets contents.
>
> All the compression pointers in the SRV records are bad
> which rules out random packet corruption. So you are looking
> at the software that wrote / re-wrote the DNS payload.
>
> Mark
> >
> > Thanks, LA