Date: Mon, 03 Oct 2016 20:31:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 213178] resolv "asked for IN A got RRSIG" syslog spamming with DNSSEC bit set Message-ID: <bug-213178-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213178 Bug ID: 213178 Summary: resolv "asked for IN A got RRSIG" syslog spamming with DNSSEC bit set Product: Base System Version: 10.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: alexander@wittig.name Created attachment 175397 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D175397&action= =3Dedit short test case triggering the warning to syslog I noticed when compiling the mail/exim port with DNSSEC enabled (and with t= he default local unbound resolving DNS server) I get many syslog messages to /var/log/messages such as Oct 3 22:07:25 hotzenplotz exim: gethostby*.gethostanswer: asked for "www.wittig.name IN A", got type "RRSIG" This message repeats for every DNSSEC enabled lookup. The lookup itself is successful. I traced the problem back to src/lib/libc/net/getaddrinfo.c, around line 21= 00. When the resolver receives a different record type than it asked for, the warning is logged and the unknown record is ignored. The logging code is in principle inside an #ifdef DEBUG, but it seems the code is compiled with DE= BUG set. By default the libc resolver does not set the DNSSEC flag, as, from what I understand, it does not yet know how to handle the response. However, it is possible to set it from the user program (via the _res structure). This is = what exim does to enable DNSSEC. The attached sample code is a short extract of = the exim code setting these options and performing a lookup that triggers the message logged to syslog. The immediate solution to the problem is of course not to enable the DNSSEC flag in user code as the libc resolver anyway doesn't support it yet. Howev= er, as use of DNSSEC becomes more widely spread and other resolvers start to support it, more code will probably enable it by default. And the warning logged by the resolver is confusing as it warns about perfectly correct, no= rmal DNSSEC behavior. The resolver code already contains a list of accepted responses where the response record type can differ from what was requested. This includes the = old SIG and KEY records as well as DNAME records (see old bug bin/127591 for an almost identical problem arising from DNAME instead of RRSIG). It would be straight forward to also add RRSIGs and DNSKEYs to the list of exempted responses. Alternatively, the file in question could just be compiled without DEBUG se= t, which would remove the logging of such warnings. Note that glibc, who's resolver is based on the same original bind code bas= e, on the other hand simply decided to completely drop these messages and remo= ve them from the code (https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git;a=3Dcommitdiff;h=3Db9b= 026c9c00db1a1b5b4a3caa28162655a04a882). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213178-8>