MaddieM4 / pymads

A fork of the pymds authoritative DNS server, designed for asynchronous lookup without domain restrictions.
GNU Lesser General Public License v3.0
4 stars 2 forks source link

Packet problems with MX records ($50) #36

Open clehner opened 11 years ago

clehner commented 11 years ago

I am running djdns-hype-flat and have DNS recursion to 8.8.8.8. pymads sometimes return malformed packets when MX records are involved.

$ dig google.com MX @localhost                          
;; Got bad packet: bad label type
186 bytes
ec 0f 84 00 00 01 00 05 00 00 00 00 06 67 6f 6f          .............goo
67 6c 65 03 63 6f 6d 00 00 0f 00 01 06 67 6f 6f          gle.com......goo
67 6c 65 03 63 6f 6d 00 00 0f 00 01 00 00 02 58          gle.com........X
00 11 00 32 04 61 6c 74 34 05 61 73 70 6d 78 01          ...2.alt4.aspmx.
6c c0 0c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00          l...google.com..
0f 00 01 00 00 02 58 00 09 00 14 04 61 6c 74 31          ......X.....alt1
c0 2f 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 0f          ./.google.com...
00 01 00 00 02 58 00 09 00 1e 04 61 6c 74 32 c0          .....X.....alt2.
2f 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 0f 00          /.google.com....
01 00 00 02 58 00 04 00 0a c0 2f 06 67 6f 6f 67          ....X...../.goog
6c 65 03 63 6f 6d 00 00 0f 00 01 00 00 02 58 00          le.com........X.
09 00 28 04 61 6c 74 33 c0 2f                            ..(.alt3./

other times I get:

$ dig google.com MX @localhost
;; Got bad packet: bad compression pointer
186 bytes
a7 21 84 00 00 01 00 05 00 00 00 00 06 67 6f 6f          .!...........goo
67 6c 65 03 63 6f 6d 00 00 0f 00 01 06 67 6f 6f          gle.com......goo
67 6c 65 03 63 6f 6d 00 00 0f 00 01 00 00 00 d9          gle.com.........
00 11 00 32 04 61 6c 74 34 05 61 73 70 6d 78 01          ...2.alt4.aspmx.
6c c0 0c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00          l...google.com..
0f 00 01 00 00 00 d9 00 09 00 14 04 61 6c 74 31          ............alt1
c0 2f 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 0f          ./.google.com...
00 01 00 00 00 d9 00 09 00 1e 04 61 6c 74 32 c0          ...........alt2.
2f 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 0f 00          /.google.com....
01 00 00 00 d9 00 04 00 0a c0 2f 06 67 6f 6f 67          ........../.goog
6c 65 03 63 6f 6d 00 00 0f 00 01 00 00 00 d9 00          le.com..........
09 00 28 04 61 6c 74 33 c0 2f                            ..(.alt3./

and other times it works.

I haven't seen this happen with requests for A, AAAA, CNAME, TXT, or SRV records.

MaddieM4 commented 11 years ago

Yup. There's no MX handling information, so it just goes with the naive default (TXT-style), rather than properly parsing it. The handler for it looks fairly unique. So this will require creating a new handler function, and hooking it into the record types switcher. I think that's all pretty much self-contained in record.py.

Will add a bounty on this shortly.

MaddieM4 commented 11 years ago

Bounty is $50.

http://www.freedomsponsors.org/core/issue/302/packet-problems-with-mx-records


(Copied from acceptance criteria)

Add relevant pack and unpack functions to Record class, and the necessary elif clause to Record.packtype. Use the existing code as a guide to how that works - it isn't properly documented, and this is a somewhat complex record format to implement, so I hope the bounty is sufficient.