FYI: a bug report from a user. i have not been able to reproduce the
issues.
----- Forwarded message from Hannah Schroeter <hannah@schlund.de> -----
FYI: a bug report from a user. i have not been able to reproduce the
issues.
----- Forwarded message from Hannah Schroeter <hannah@schlund.de> -----
FYI: a bug report from a user. i have not been able to reproduce the
issues.
Typical case of Garbage in Garbage out. Labels have a max of 63
bytes. The application should check that before before further
processing. Examples:
bartok.nlnetlabs.nl:~ > unbound-host aa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[1265101891] libunbound[91074:0] fatal error: util/data/dname.c:267: dname_query_hash: assertion lablen <= LDNS_MAX_LABELLEN failed
bartok.nlnetlabs.nl:~ > drill !$
drill aa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
error: Label length overflow
;; No packet received
bartok.nlnetlabs.nl:~ > dig !$
dig aa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
dig: convert UTF-8 textname to IDN encoding: label length reduced to 0 or exceeded 63 bytes
Apparently libunbound does catch this on some occasions but raising
an assertion smells like an overkill. That opens the door for DOS
attacks when the application doesn't check on LDNS_MAX_LABELLEN.
Raising and returning an error (EGREG) and silently truncating on
LDNS_MAX_LABELLEN for those applications which don't bother to check
return values might be a better option.
jaap
----- Forwarded message from Hannah Schroeter <hannah@schlund.de> -----
Hi Robert,
1. Fixed already in the current ldns and unbound packages.
2. This is a bug in ldns, fixed in libldns.
3. But this does work? There is an error from libunbound, not a DNS
error, and this prints out as 'syntax error'.
Best regards,
Wouter