Bugzilla – Bug 1235
too long DNAME expansion produces SERVFAIL instead of YXDOMAIN + query loop
Last modified: 2017-03-13 09:29:32 CET
Created attachment 381 [details] pcap from the test demonstrating the problem, see packets #17, #23, #33, #41, #47 Version: unbound-1.5.10-1.fc25.x86_64 Unbound incorrectly returns SERVFAIL instead of YXDOMAIN if DNAME expansion produces too long DNS name. Reproducer: a] authoritative is configured with a very long DNAME: ENTRY_BEGIN MATCH qname qtype opcode ADJUST copy_id REPLY QR NOERROR SECTION QUESTION long. IN DNAME SECTION ANSWER long. 3600 IN DNAME 63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.60o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. ENTRY_END b] the client asks for an owner name which is going to be too long after expansion - the authoritative correctly replies with YXDOMAIN ENTRY_BEGIN MATCH qname opcode ADJUST copy_id copy_query REPLY QR YXDOMAIN SECTION QUESTION too.long. IN A SECTION ANSWER long. 3600 IN DNAME 63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.63o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.60o-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. ENTRY_END c] Unbound returns SERVFAIL instead. While digging into it I found out that this behavior is mentioned in https://www.ietf.org/mail-archive/web/dnsext/current/msg11282.html but I did not find any bug mentioning it. I confirm that even relatively modern versions of Unbound re-query for the DNAME several times (in my case 6x) before bailing out. Attached pcap demostrates it. Feel free to close it as WONTFIX but at least the re-query cycle sounds bad enough to me ... This was discovered when writting DNAME RFC compliance test suite for Knot resolver. Relevant part of the test is the uncommented part in the file attached to this bug. You can run it either under Deckard (https://gitlab.labs.nic.cz/knot/deckard - script unbound_run.sh) or do few tweaks to it (mentioned in bug 1234) and run it using Unbound's test harness.
Created attachment 382 [details] test demostrating the issue, see step 229003
Hi Petr, STEP 229004 says question x.long but it has to be question too.long. The same query as step 229003. In the trace. I changed unbounds test harness to accept the missing keywords, so that trace file works as is. Also fixed the bug, it stops the retry and also returns YXDOMAIN. (The fix to stop the retry also moved the YXDOMAIN to the answer). Best regards, Wouter