FORMERR resolving AAAA/IN records [solved]

Oliver Henriot Oliver.Henriot at imag.fr
Fri Mar 27 16:03:20 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Barry and list users,

Thanks for the info.

- From what you tell me, there's not much more to do than reduce logging
of this type of error on my side, so the logging info you gave in 2006
solves my problem just fine.
Thank you very much for your help.

Cheers,

Dans sa grande sagesse, b19141 at anl.gov a écrit, le 26.03.2009 15:19 :
> Oliver Henriot <Oliver.Henriot at imag.fr> wrote:
> 
>> Dear list users,
>>
>> I have a bind 9.3 server on a centos 5.2 machine which logs huge (about
>> 12 errors every second) quantities of FORMERR messages while trying to
>> resolve AAAA/IN records which look like this :
>>
>> Mar 25 08:44:24 myserver named[1124]: FORMERR resolving
>> 'auniarael.com/AAAA/IN': 216.69.185.38#53
>>
>> I'm a bit of a bind noob so I scoured the bind 9.3 ARM and the web
>> looking for info which could help me understand what is going wrong. I
>> found nothing of much use to me, appart from a thread on this list from
>> 2006 in which Barry Finkel has a similar question. I followed the
>> logging instructions he gives and solved the overfull /var/log problem
>> but I presume I still have these FORMERR problems occuring.
>>
>> Just for info, if it of any use, in a log file from before modifying
>> logging, I had 1826550 lines of AAAA FORMERR but of these, only 275
>> unique adresses, so it's always the same requests and always the same
>> errors...
>> I don't think it's a recursion problem, I have restricted that to my
>> networks.
>> I only get these logs on this server, not on any of the others.
>>
>> I'd greatly appreciate if someone could point me in the right direction
>> to try and work out what is going wrong and fix it.
> 
> Look at the output of these queries:
> 
> dnsserver% dig auniarael.com @216.69.185.38
> 
> ; <<>> DiG 8.3 <<>> auniarael.com @216.69.185.38 
> ; (1 server found)
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      auniarael.com, type = A, class = IN
> 
> ;; ANSWER SECTION:
> auniarael.com.          1H IN A         68.178.232.143
> 
> ;; AUTHORITY SECTION:
> auniarael.com.          1H IN NS        cpns01.secureserver.net.
> auniarael.com.          1H IN NS        cpns02.secureserver.net.
> 
> ;; Total query time: 62 msec
> ;; FROM: dnsserver.anl.gov to SERVER: 216.69.185.38  216.69.185.38
> ;; WHEN: Thu Mar 26 09:05:56 2009
> ;; MSG SIZE  sent: 31  rcvd: 105
> 
> dnsserver% !! AAAA
> dig auniarael.com @216.69.185.38 AAAA
> 
> ; <<>> DiG 8.3 <<>> auniarael.com @216.69.185.38 AAAA 
> ; (1 server found)
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      auniarael.com, type = AAAA, class = IN
> 
> ;; AUTHORITY SECTION:
> .                       1D IN SOA       cpns01.secureserver.net. dns.jomax.net. (
>                                         20080922        ; serial
>                                         8H              ; refresh
>                                         2H              ; retry
>                                         1W              ; expiry
>                                         1D )            ; minimum
> 
> auniarael.com.          1H IN NS        cpns01.secureserver.net.
> auniarael.com.          1H IN NS        cpns02.secureserver.net.
> 
> ;; Total query time: 62 msec
> ;; FROM: dnsserver.anl.gov to SERVER: 216.69.185.38  216.69.185.38
> ;; WHEN: Thu Mar 26 09:06:02 2009
> ;; MSG SIZE  sent: 31  rcvd: 157
> 
> dnsserver%
> 
> Note that the first query defaults to an "A" record search, and the
> authority section gives the names of the two name servers.  This is
> fine.  The second query is specifically for an "AAAA" record.
> Note the authority section - 
> 
>      ;; AUTHORITY SECTION:
>      .                       1D IN SOA    ...
> 
> The authority is the root.  BIND (correctly) does not believe this
> and returns FORMERR (format error).  This occurs, as Mark Andrews
> pointed out to me a numbe of months ago, because the DNS administrator
> has placed all of the records for various zones into one zone, and thus
> cannot configure an SOA record that is correct.  A search for an "A"
> record that exists will return correct values, but a search for a
> record that does not exist forces DNS to return the faulty SOA record.
> 
> I just ran my FORMERR script against our current /var/adm/messsages,
> and I see a handful of DNS servers producing most of the FORMERR
> messages:
> 
>  cnt DNS Server IP
>  --- --------------
>   37 60.191.254.243
>   37 219.152.120.12
>   24 203.93.208.86
>   24 124.207.117.60
>   12 75.126.8.248
>   12 75.126.57.130
>   12 65.55.238.126
>   12 65.54.240.126
>   12 213.199.161.77
>   12 207.68.160.190
>   12 207.46.66.126
>    6 66.211.162.250
>    6 66.135.220.69
>    6 66.135.220.68
>    4 159.215.217.197
>    4 159.215.16.197
>    4 159.215.117.197
>    3 209.235.30.142
>    3 204.77.28.20
>    1 68.156.138.136
>    1 66.194.84.50
>    1 65.24.6.70
>    1 216.74.148.58
>    1 216.64.220.37
>    1 208.86.225.61
> 
> ----------------------------------------------------------------------
> 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
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

- --
Oliver Henriot B.Sc. Ph.D. | Technicien de Maintenance
Moyens Informatiques et Multimédia | UMS MI2S | http://mi2s.imag.fr/
Domaine universitaire BP53 | 38041 Grenoble cedex 9 | France
tel.: +33 4 76 51 43 48 | fax: +33 4 76 51 47 15


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknM+McACgkQSWuBJnHIHdJUaACdHVzSXzDAR+ZdEDBpZZ+hotnM
KfQAoOvZi5ALq7qSClw4qGS1sD54tsDW
=ukLD
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4046 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090327/4bddfd4d/attachment.bin>


More information about the bind-users mailing list