In bind ver 9.16 in rocky linux . I get the below messages in logs. Could anyone suggest what could be the issue.
FORMERR resolving 'sin3-ib.sin1.geoadnxs.com/AAAA/IN': 64.208.141.10#53
Thanks in advance
In bind ver 9.16 in rocky linux . I get the below messages in logs. Could anyone suggest what could be the issue.
FORMERR resolving 'sin3-ib.sin1.geoadnxs.com/AAAA/IN': 64.208.141.10#53
Thanks in advance
Hello, @padma. Is the only server you are seeing this for 64.208.141.10
?
Modern BIND servers often send queries using EDNS (Extension mechanisms for DNS) to allow for larger messages and extra features. Some older or misconfigured DNS servers do not understand these EDNS extensions and will reply with FORMERR when they see them.
If I had to guess, most likely the remote server isn’t fully compatible with EDNS0, so when BIND sends an EDNS-enabled AAAA query (IPv6), the server responds with a format error.
If you’re trying to clean up your logs, you can surpress the errors by disabling EDNS for that specific server so that BIND sends “plain” DNS queries that the server understands. If you want to do this, you add the following to your BIND configuration:
server 64.208.141.10 {
edns no;
};
In many cases, the resolution falls back (e.g., via A records for IPv4), and you might not have to do anything if you do not see the name resolution affected. This configuration change is for when you want to clean up your logs or ensure proper handling.
Others can chime in if I’m missing the mark on this (since this is based on research I did) or if there is more to add.
Hi, @nebraskacoder
Thanks for quick reply. I see the below messages .
Mar 20 18:18:42 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.197.128#53
Mar 20 18:18:42 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.195.61#53
Mar 20 18:18:42 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.193.130#53
Mar 20 18:18:42 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.198.24#53
Mar 20 18:18:55 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.195.61#53
Mar 20 18:18:55 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.197.128#53
Mar 20 18:18:55 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.193.130#53
Mar 20 18:18:55 intdns named[54354]: FORMERR resolving ‘trace.mediago.io/HTTPS/IN’: 205.251.198.24#53
Is it possible to resolve or do we need to suppress these messages.
If you’re getting FORMERR regardless of the domain, is there something intercepting your DNS traffic? Do you have caching servers? How is your internal DNS actually setup?
Hi @Nazunalika,
Thanks for reply. No we do not have caching server. Please find the conf file below. Zone file has been configured but removed below.
options {
listen-on port 53 { 127.0.0.1; 192.168.xx.xx; };
// listen-on-v6 port 53 { ::1; };
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
memstatistics-file “/var/named/data/named_mem_stats.txt”;
secroots-file “/var/named/data/named.secroots”;
recursing-file “/var/named/data/named.recursing”;
allow-query { any; };
tcp-clients 10000;
recursive-clients 10000;
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recurs ion.
- If you are building a RECURSIVE (caching) DNS server, you need to ena ble
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so w ill
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
dnssec-validation no;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
};
logging {
channel default_debug {
file “data/named.run”;
severity dynamic;
};
};
server ::/0 {
edns no;
};
server 0.0.0.0/0 {
edns no;
};
//zone file has been mentioned
#include “/etc/named.rfc1912.zones”;
#include “/etc/named.root.key”;
Log generated daily are in 3 to 4 MB.
Hi @nebraskacoder,
Name resolution is happening. There is no issue.