René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Message.toWire(Message.MAXLENGTH) can generate byte[] \u003e Message.MAXLENGTH","articleBody":"Hello!\r\n\r\nSo I was investigating a failed update to a BIND nameserver that returned FORMERR. Looking with the debugger, I've noticed that the generated wire format was \u003e 65535 [here](https://github.com/dnsjava/dnsjava/blob/master/src/main/java/org/xbill/DNS/SimpleResolver.java#L356).\r\n\r\nAfter more investigation, I think I identified the issue: I am using a resolver with tsig with algorithm `HMAC_SHA384`, and the calculation that is made in [TSIG.recordLength()](https://github.com/dnsjava/dnsjava/blob/master/src/main/java/org/xbill/DNS/TSIG.java#L761) is wrong. More specifically, it considers a MAC size of 16 bytes. While this is true for MD5, it doesn't work for other algorithms such as `HMAC_SHA384`, where the hash is greater in length.\r\n\r\nThis is a small repro (in Kotlin) showing the generated message is higher than the allowed DNS message size of 65535:\r\n\r\n```kotlin\r\nimport org.xbill.DNS.DClass\r\nimport org.xbill.DNS.Message\r\nimport org.xbill.DNS.Name\r\nimport org.xbill.DNS.SimpleResolver\r\nimport org.xbill.DNS.TSIG\r\nimport org.xbill.DNS.TXTRecord\r\nimport org.xbill.DNS.Update\r\nimport org.xbill.DNS.io.IoClientFactory\r\nimport org.xbill.DNS.io.TcpIoClient\r\nimport org.xbill.DNS.io.UdpIoClient\r\nimport java.util.concurrent.CompletableFuture\r\n\r\n\r\nfun main() {\r\n    val update = Update(Name.fromConstantString(\"zone.example.com.\"))\r\n\r\n    repeat(2000) { i -\u003e\r\n        val record = TXTRecord(\r\n            Name.fromConstantString(\"name-$i.zone.example.com.\"),\r\n            DClass.IN,\r\n            900,\r\n            \"a\",\r\n        )\r\n        update.absent(record.name, record.type)\r\n        update.add(record)\r\n    }\r\n\r\n    val resolver = SimpleResolver().apply {\r\n        tsigKey = TSIG(TSIG.HMAC_SHA384, \"zone.example.com.\", \"c2VjcmU=\")\r\n        ioClientFactory = object : IoClientFactory {\r\n            override fun createOrGetTcpClient(): TcpIoClient {\r\n                return TcpIoClient { local, remote, query, data, timeout -\u003e\r\n                    println(\"Sending data of length: ${data.size}\")\r\n                    println(\"Is data \u003e max message size (${Message.MAXLENGTH})? ${data.size \u003e Message.MAXLENGTH}\")\r\n                    CompletableFuture.failedFuture(Exception())\r\n                }\r\n            }\r\n\r\n            override fun createOrGetUdpClient(): UdpIoClient {\r\n                TODO(\"Not yet implemented\")\r\n            }\r\n        }\r\n    }\r\n\r\n    resolver.send(update)\r\n}\r\n``` \r\n\r\nThis outputs:\r\n```\r\nSending data of length: 65544\r\nIs data \u003e max message size (65535)? true\r\n```\r\n\r\nThe FORMERR we got is because the data of 65544 bytes exceeds what can be stored in two bytes so [this computation](https://github.com/dnsjava/dnsjava/blob/master/src/main/java/org/xbill/DNS/NioTcpClient.java#L101,L102) rolls over, so the message gets truncated at a random point and cannot be interpreted by the receiver.\r\n\r\n---\r\n\r\nI believe an easy fix for this would be to either give more slack in the calculation and put the max of all supported algorithms, or put the correct number based on the algorithm used.","author":{"url":"https://github.com/MMauro94","@type":"Person","name":"MMauro94"},"datePublished":"2024-12-05T17:10:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/355/dnsjava/issues/355"}