Bug 1235 – too long DNAME expansion produces SERVFAIL instead of YXDOMAIN + query loop

Bug 1235 - too long DNAME expansion produces SERVFAIL instead of YXDOMAIN + query loop


Summary:	too long DNAME expansion produces SERVFAIL instead of YXDOMAIN + query loop

Status:	RESOLVED FIXED

Product:	unbound
Classification:	Unclassified
Component:	server
Version:	1.5.10
Hardware:	x86_64 Linux

Importance:	P5 enhancement
Assigned To:	unbound team

URL:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2017-03-10 22:06 CET by Petr Špaček
Modified:	2019-04-08 08:33 CEST (History)
CC List:	3 users (show)

See Also:

Attachments
pcap from the test demonstrating the problem, see packets #17, #23, #33, #41, #47 (7.27 KB, application/octet-stream) 2017-03-10 22:06 CET, Petr Špaček	Details
test demostrating the issue, see step 229003 (29.49 KB, application/octet-stream) 2017-03-10 22:07 CET, Petr Špaček	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Petr Špaček 2017-03-10 22:06:54 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.

Comment 1 Petr Špaček 2017-03-10 22:07:43 CET

Created attachment 382 [details]
test demostrating the issue, see step 229003

Comment 2 Wouter Wijngaards 2017-03-13 09:29:32 CET

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

Comment 3 Ashwin kumar 2019-04-08 08:33:23 CEST

Thanks for this type of support, i was searching for complete answer for control panel http://controlpanelwindows10.com then here it is. start following and learn.