FORMERR Messages in BIND 9.3.2

[Barry Finkel]

I wrote on July 5:

>I recently upgraded BIND from 9.2.4 to 9.3.2.  I am now seeing in the
>syslog of two of my DNS servers messages like this:
>
>     Jun 29 13:26:35 titania.ctd.anl.gov named[18180]:
>       [ID 866145 daemon.info] FORMERR resolving
>       'nicholas.8dstar.com/AAAA/IN': 64.250.235.139#53
>
>I did not see anything in the 9.3.2 CHANGES file about this message.
>Is this something new that 9.3.2 catches but that 9.2.4 did not?
>Or is it something that was caught in 9.2.4 but not logged.
>
>I am seeing a large number of these (342,644 since Friday at 03:10),
>and I am trying to see how to eliminate logging of the message and to
>discover what is causing the message.
>
>I ran a snoop trace on one of my servers, and I traced one FORMERR.
>I see in response to the query:
>
>     What are the NS records for liarignorance.info.?
>
>that the response packet contains
>
>     1 question
>     0 answers
>     4 authority (NS) records
>     5 additional records (the addresses of the four nameservers plus
>                           some garbage).
>
>I assume that it is this garbage in the fifth additional record that
>is causing the FORMERR message from BIND.  I checked the version of
>the server that created this response packet - 
>
>     "UltraDNS Version 2.9.6.1 Build 5094"
>
>Is it correct to have the answer appear in the authority section instead
>of the answer secion?  Would this cause a FORMERR?  I did a standard 
>
>     dig anl.gov ns
>
>using one of my BIND slaves, and I get four answer sections and no
>authority sections:
>
>     flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

As there have been no replies, I decided to run some tests.  I can run
the following query

     britaine%   dig nastyhos.com mx @dns2.anl.gov

     ; <<>> DiG 8.3 <<>> nastyhos.com mx @dns2.anl.gov 
     ; (3 servers found)
     ;; res options: init recurs defnam dnsrch
     ;; got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
     ;; QUERY SECTION:
     ;;      nastyhos.com, type = MX, class = IN

     ;; Total query time: 106 msec
     ;; FROM: britaine.ctd.anl.gov to SERVER: dns2.anl.gov  146.137.64.7
     ;; WHEN: Mon Jul 10 09:57:35 2006
     ;; MSG SIZE  sent: 30  rcvd: 30

     britaine%

and produce the message

     Jul 10 09:57:41 oberon.ctd.anl.gov named[24253]:
       [ID 866145 daemon.info] FORMERR resolving 'nastyhos.com/MX/IN':
       64.20.33.3#53

I run the same command on one of our external DNS servers:

     britaine% dig nastyhos.com mx @t1dns2.anl.gov

     ; <<>> DiG 8.3 <<>> nastyhos.com mx @t1dns2.anl.gov 
     ; (1 server found)
     ;; res options: init recurs defnam dnsrch
     ;; got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
     ;; QUERY SECTION:
     ;;      nastyhos.com, type = MX, class = IN

     ;; Total query time: 138 msec
     ;; FROM: britaine.ctd.anl.gov to SERVER: t1dns2.anl.gov  130.202.101.37
     ;; WHEN: Mon Jul 10 09:59:21 2006
     ;; MSG SIZE  sent: 30  rcvd: 30

     britaine%

and I do not see any FORMERR message.  Note that both queries return
SERVFAIL.  All of my DNS servers are running BIND 9.3.2, SunOS
Generic_118558-23 sun4u sparc SUNW,Sun-Fire-V240.  I built BIND 9.3.2
on each of the five servers using the same parameters.  The executables
have different lengths, but an "ldd" command run against all five
executables shows the same output.

As a further test, I took the executable on dns2 and replaced it with
the executable on t1dns2, thinking that there may be problems with the
executable on the internal dns1 and dns2, but I still get a FORMERR
message on dns2.

I have looked at the code, and I am not sure what causes a FORMERR.
I have looked at some SNOOP traces, and in some cases I cannot see
anything wrong with the packets.  I have to assume from the numerous
messages that when a FORMERR is detected, nothing in the packet it
cached, as subsequent queries again produce a FORMERR message instead of
retrieving information from the cache.

Can anyone explain what I am seeing?  Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory          Phone:    +1 (630) 252-7277
9700 South Cass Avenue               Facsimile:+1 (630) 252-4601
Building 222, Room D209              Internet: BSFinkel at anl.gov
Argonne, IL   60439-4828             IBMMAIL:  I1004994