How to Stop the "unexpected RCODE (SERVFAIL)" Messages?

Mark Andrews Mark_Andrews at isc.org
Sun Feb 5 23:36:22 UTC 2006


> On Sun, 5 Feb 2006 18:02:51 +0100
> Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> > On Mon, Feb 06, 2006 at 12:13:30AM +0800,
> >  imacat <imacat at mail.imacat.idv.tw> wrote 
> >  a message of 63 lines which said:
> > > Some how I heard of it years ago, I did not disable it, because I
> > > was told to be supposed to be solving the problem instead of
> > > supressing the error messages.
> > This is a good advice if the error is *local*. If it is remote, you
> > cannot do a lot: sure you can write people but my experience with
> > email to DNS administrators is that you'll get a bounce or simply a
> > complete silence (TLD administrators are not different in that
> > respect). The DNS administrators who reply to email are typically not
> > the ones who have configuration problems :-}
>     Now that I know this is all about the "lame servers" problem, in
> 1997.  I have a little search on this issue.  Is it supposed to be
> something like a valid SOA record?

	A lame server is a server that has had a zone delegated to
	it but is not serving the zone.  It can also be a server
	that is serving the zone but the zone has a error which
	hasn't been fixed by the operator of the nameserver.
 
>     Well, all the SOA records of the domains hosted on my servers are
> valid.  I think it's a important to be a good citizen.  But if BIND want
> to enforce that, could you please do some other thing, for example,
> notifying the TLD administrators automatically (without using mail,
> please), instead of making DoS attack to the harddisk of th good
> citizens?  With one of my previous servers that has a /var/log partition
> only 500MB, it'll be filled up in a very, very short time.  And not to
> mention the lifespan of the harddisk itself.

	It is logged so you have a idea why your (your clients) lookups
	are failing.  If you don't want to know why your lookups are
	failing you are perfectly free to turn the logging off.

	As for filling up the log partition, log rotation usually deals
	with that.

>     If I were to attack some DNS server, knowing that it does not
> disable the lame-server messages, all I have to do is to register a
> domain, configure an improper SOA record, and trigger it to do DNS query. 
> Bla!  Either the hard disk will be filled up, or die completely.
> 
>     This is somehow security-related, isn't it?
> 
>     By the way, I have already made a patch that bypass all the
> "unexpected RCODE (SERVFAIL)" messages, that applies to BIND 9.3.2.  It
> runs well without disabling the "lame-server" messages.  I attached it
> below.  Please tell me if there is any problem.
> 
> diff -r -u bind-9.3.2.orig/lib/dns/resolver.c bind-9.3.2/lib/dns/resolver.c
> --- bind-9.3.2.orig/lib/dns/resolver.c	2005-10-14 09:38:48.000000000 +
> 0800
> +++ bind-9.3.2/lib/dns/resolver.c	2006-02-06 00:33:34.000000000 +0800
> @@ -1663,6 +1663,10 @@
>  	if (reason == DNS_R_LAME)	/* already logged */
>  		return;
>  
> +	if (reason == DNS_R_UNEXPECTEDRCODE
> +	    && fctx->rmessage->rcode == dns_rcode_servfail)
> +		return;		/* no "unexpected RCODE (SERVFAIL)" */
> +
>  	if (reason == DNS_R_UNEXPECTEDRCODE) {
>  		isc_buffer_init(&b, code, sizeof(code) - 1);
>  		dns_rcode_totext(fctx->rmessage->rcode, &b);
> 
> --
> Best regards,
> imacat ^_*' <imacat at mail.imacat.idv.tw>
> PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
> 
> <<Woman's Voice>> News: http://www.wov.idv.tw/
> Tavern IMACAT's: http://www.imacat.idv.tw/
> TLUG List Manager: http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list