Dns format error from bind

dns format error from bind

In most cases, such error is interconnected with misconfiguration of bind nameserver (named.conf). If the "forward nameservers" are. 03-Jun-2014 13:35:16.328 DNS format error from 192.168.0.1#53 resolving n4g4.akamai.net/AAAA: non-improving referral Bind FORMERR errors in syslog. Dear Friends, I have deployed Bins as caching DNS. Following are the version: bind-9.7.3-8.P3.el6_2.2.i686 bind-libs-9.7.3-8. dns format error from bind

watch the thematic video

How to troubleshoot DNS issues in an Active Directory domain controller

Dns format error from bind - can

4 RRs pointing toward an authority +---------------------+

Understanding cause of DNS format error (FORMERR)

Spain, Dr. Jeffry A.'s profile photo

Spain, Dr. Jeffry A.

unread,
Jun 22, 2012, 3:25:09 PM6/22/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Gabriele Paggi, [email protected]

> I'm a BIND novice and I'm trying to understand what causes my BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried for the A record of vlasext.partners.extranet.microsoft.com:

FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. On this system "dig @localhost vlasext.partners.extranet.microsoft.coma" returns the answer 70.42.230.20 and identifies dns11.one.microsoft.com(94.245.124.49) as one of four authoritative servers. "dig @94.245.124.49vlasext.partners.extranet.microsoft.coma" also returns the answer 70.42.230.20, but no authority or additional records (except EDNS UDP 4000), and with no AA flag set. On the contrary querying one of my own authoritative servers, also running BIND 9.9.1-P1, for a record for which it is authoritative ("dig @ns2.countryday.netcountryday.neta") does return the answer along with authority and additional records for the name servers and does have the AA flag set. Finally querying one of my internal Microsoft DNS servers (Windows Server 2008 R2 SP1) for a record for which it is authoritative gives me a correct answer, no authority or additional records (except EDNS UDP 4000), but does have the AA flag set.


> Is it related to the "AA bit strictness"[1] ? 94.245.124.49 is dns11.one.microsoft.com and does indeed reply without setting the AA bit.
> As far as know the 'strictness' was removed in P2, correct me if I'm wrong.

I don't know enough about the history of BIND functionality to answer this. I'm sure others will comment.

>From what I observed I would conclude that dns11.one.microsoft.comis a Windows DNS server since it behaves like mine except for the AA flag not being set in theirs. The missing AA flag and lack of authority and additional records in their response seems like improper behavior to me, but I don't know whether or not the DNS protocol actually requires this. Apparently BIND 9.9.1-P1 is able to handle this situation.

Hope this is at least somewhat helpful. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

Carsten Strotmann (private)'s profile photo

Carsten Strotmann (private)

unread,
Jun 23, 2012, 12:17:03 PM6/23/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

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

Hello Gabriele,


On 6/22/12 11:22 AM, Gabriele Paggi wrote:
> I'm a BIND novice and I'm trying to understand what causes my
> BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried
> for the A record of vlasext.partners.extranet.microsoft.com:
>

At Men & Mice I've investigated this issue a few weeks ago for one of
our customers. At that point of time, we've seen NS records with
private addresses:

dig ns partners.extranet.microsoft.com.

; <<>> DiG 9.9.1 <<>> ns partners.extranet.microsoft.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53053
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. IN NS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sinxtdnsz01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-05.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
rno-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-04.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-02.partners.extranet.microsoft.com.

;; ADDITIONAL SECTION:
db3-ptnr-dc-01.partners.extranet.microsoft.com. 1406 IN A 10.251.138.15
tk5-ptnr-dc-02.partners.extranet.microsoft.com. 26 IN A 10.251.51.102
by1-ptnr-dc-03.partners.extranet.microsoft.com. 3505 IN A 10.251.94.15
co2-ptnr-dc-02.partners.extranet.microsoft.com. 2941 IN A 10.251.152.89
co2-ptnr-dc-01.partners.extranet.microsoft.com. 2679 IN A 10.251.152.173
sinxtdnsz01.partners.extranet.microsoft.com. 171 IN A 10.251.168.142
kaw-ptnr-dc-02.partners.extranet.microsoft.com. 1101 IN A 10.251.162.20
ph1-ptnr-dc-01.partners.extranet.microsoft.com. 1417 IN A 10.251.26.11
tk5-ptnr-dc-01.partners.extranet.microsoft.com. 2872 IN A 10.251.51.13
tk5-ptnr-dc-05.partners.extranet.microsoft.com. 137 IN A 10.251.52.143
rno-ptnr-dc-01.partners.extranet.microsoft.com. 1375 IN A 10.251.64.113
tk5-ptnr-dc-03.partners.extranet.microsoft.com. 1564 IN A 10.251.52.124
sin-ptnr-dc-03.partners.extranet.microsoft.com. 882 IN A 10.251.168.67
sin-ptnr-dc-02.partners.extranet.microsoft.com. 505 IN A 10.251.169.47
by1-ptnr-dc-04.partners.extranet.microsoft.com. 2270 IN A 10.251.94.16
kaw-ptnr-dc-03.partners.extranet.microsoft.com. 3461 IN A 10.251.162.193
db3-ptnr-dc-02.partners.extranet.microsoft.com. 1690 IN A 10.251.138.59
ph1-ptnr-dc-02.partners.extranet.microsoft.com. 3018 IN A 10.251.26.12

;; Query time: 1314 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 30 18:57:27 2012
;; MSG SIZE rcvd: 867

The issue seem to differ from the point in the network you are sending
the query, and if the resolving DNS server has only IPv4 or is
dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes
broken, but we have not found the root cause of the issue.

This forward zone proved to be an (ugly, but working) workaround:

zone "partners.extranet.microsoft.com" IN {
type forward;
forwarders { 131.107.125.65;
94.245.124.49;
207.46.55.10;
65.55.31.17; };
};

We've also informed Microsoft about the issue.

Best regards

Carsten Strotmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/le38ACgkQsUJ3c+pomYEwDACgit4MdoFl4rfSCcapx1NMr9cB
1bUAn1QNRM2Gw//EsLYnH1jw1g25IvFl
=hB+P
-----END PGP SIGNATURE-----
Carsten Strotmann (private)'s profile photo

Carsten Strotmann (private)

unread,
Jun 23, 2012, 12:54:35 PM6/23/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

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

Hello Gabriele,

On 6/22/12 11:22 AM, Gabriele Paggi wrote:

> I'm a BIND novice and I'm trying to understand what causes my
> BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried
> for the A record of vlasext.partners.extranet.microsoft.com:

about the FORMERR. This might be caused by a Firewall or other
middlebox that truncates the large answer containing the NS record set
for this domain.

I see the same if I try to fetch the delegation NS records from the
parent domain (microsoft.com) for partners.extranet.microsoft.com:

# dig @ns1.msft.net. partners.extranet.microsoft.comns

; <<>> DiG 9.9.1-P1 <<>> ns @ns1.msft.net. partners.extranet.microsoft.com
; (2 servers found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 30679
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. IN NS

;; Query time: 167 msec
;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)
;; WHEN: Sat Jun 23 10:47:33 2012
;; MSG SIZE rcvd: 60

If some other members of this mailing list also see the same FORMERR
(I'm seeing it over IPv4+IPv6), that is is very likely a firewall or
middlebox on the Microsoft side.


Best regards

Carsten Strotmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/lhEsACgkQsUJ3c+pomYE8RwCgldVhiIiwuavJGy0VEQAbek5M
d7sAoKg1ny9dN6UMhuXyF1a6diylGyzz
=+PcU
-----END PGP SIGNATURE-----
Gabriele Paggi's profile photo

Gabriele Paggi

unread,
Jun 24, 2012, 7:58:25 AM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

Hello Carsten,

Thanks for your reply!

> about the FORMERR. This might be caused by a Firewall or other
> middlebox that truncates the large answer containing the NS record set
> for this domain.
>
> I see the same if I try to fetch the delegation NS records from the
> parent domain (microsoft.com) for partners.extranet.microsoft.com:

That doesn't explain why I get a correct reply to my query if I use a
Windows DNS or one of the Google DNS (what software do they run?) or my
home ISP DNS (UPC, Netherlands).

stanislao:~ gpaggi$ dig A @62.179.104.196
vlasext.partners.extranet.microsoft.com+short
70.42.230.20
stanislao:~ gpaggi$ dig A @8.8.8.8
vlasext.partners.extranet.microsoft.com+short
70.42.230.20

I'm trying to understand if this behavior is specific to the BIND
release that I'm running (should be the latest available on CentOS 5)
and what's triggering it.
Increasing debug logging to 90 doesn't tell me what's wrong with the
reply BIND gets from the Microsoft DNS.


> # dig @ns1.msft.net. partners.extranet.microsoft.com ns

[...]


> If some other members of this mailing list also see the same FORMERR
> (I'm seeing it over IPv4+IPv6), that is is very likely a firewall or
> middlebox on the Microsoft side.

I do get indeed a reply from my home connection:

stanislao:~ gpaggi$ dig @ns1.msft.net. partners.extranet.microsoft.comns

; <<>> DiG 9.6-ESV-R4-P3 <<>> @ns1.msft.net.
partners.extranet.microsoft.comns
; (1 server found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37303
;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;partners.extranet.microsoft.com. IN NS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.

;; ADDITIONAL SECTION:
dns13.one.microsoft.com. 3600 IN A 65.55.31.17
dns11.one.microsoft.com. 3600 IN A 94.245.124.49
dns12.one.microsoft.com. 3600 IN A 207.46.55.10
dns10.one.microsoft.com. 3600 IN A 131.107.125.65

;; Query time: 201 msec
;; SERVER: 65.55.37.62#53(65.55.37.62)
;; WHEN: Sun Jun 24 05:51:37 2012
;; MSG SIZE rcvd: 197


Gabriele

PS. Carsten, apologizes for the double message.

Gabriele Paggi's profile photo

Gabriele Paggi

unread,
Jun 24, 2012, 8:10:21 AM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

Hello Carsten,

> At Men& Mice I've investigated this issue a few weeks ago for one of

> our customers. At that point of time, we've seen NS records with
> private addresses:

That's interesting but it still doesn't explain why BIND reports a
format error in the reply it receives.
The reply is nonsense but it's legit and BIND should just return it. Am
I wrong?
Beside that, I've been constantly getting a FORMERR reply for a week now.


> The issue seem to differ from the point in the network you are sending
> the query, and if the resolving DNS server has only IPv4 or is
> dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes
> broken, but we have not found the root cause of the issue.

I'm running with only IPv4. May I ask you which version of BIND are you
running?
Jeffry is not able to reproduce the issue using BIND 9.9.1-P1 and I
might consider an upgrade.



> We've also informed Microsoft about the issue.

I know what the answer is but I'll ask anyway: did you ever get a reply
/ acknowledgement from them?

Thanks!

Gabriele
Gabriele Paggi's profile photo

Gabriele Paggi

unread,
Jun 24, 2012, 8:14:58 AM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

You do not have permission to delete messages in this group

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

Hello Jeffry,


> FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. On this system "dig @localhost vlasext.partners.extranet.microsoft.com a" returns the answer 70.42.230.20 and identifies dns11.one.microsoft.com (94.245.124.49) as one of four authoritative servers. "dig @94.245.124.49vlasext.partners.extranet.microsoft.com a" also returns the answer 70.42.230.20, but no authority or additional records (except EDNS UDP 4000), and with no AA flag set. On the contrary querying one of my own authoritative servers, also running BIND 9.9.1-P1, for a record for which it is authoritative ("dig @ns2.countryday.netcountryday.net a") does return the answer along with authority and additional records for the name servers and does have the AA flag set. Finally querying one of my internal Microsoft DNS servers (Windows Server 2008 R2 SP1) for a record for which it is authoritative gives me a correct answer, no authority or additional records (except EDNS UDP 4000), but does have the AA flag set.

Thanks. At least I know an upgrade would fix the issue although I still
don't know what and where the problem is (Microsoft DNS reply? BIND?).

> From what I observed I would conclude that dns11.one.microsoft.com is a Windows DNS server since it behaves like mine except for the AA flag not being set in theirs. The missing AA flag and lack of authority and additional records in their response seems like improper behavior to me, but I don't know whether or not the DNS protocol actually requires this. Apparently BIND 9.9.1-P1 is able to handle this situation.

I kind of assumed Microsoft would have been running a Windows DNS for
their domains ;-)

Gabriele



Carsten Strotmann (private)'s profile photo

Carsten Strotmann (private)

unread,
Jun 24, 2012, 11:45:34 AM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Gabriele Paggi, [email protected]

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

Hello Gabriele,

On 6/24/12 5:57 AM, Gabriele Paggi wrote:
> Hello Carsten,
>
> Thanks for your reply!
>> about the FORMERR. This might be caused by a Firewall or other
>> middlebox that truncates the large answer containing the NS
>> record set for this domain.
>>
>> I see the same if I try to fetch the delegation NS records from
>> the parent domain (microsoft.com) for
>> partners.extranet.microsoft.com:
> That doesn't explain why I get a correct reply to my query if I use
> a Windows DNS or one of the Google DNS (what software do they run?)
> or my home ISP DNS (UPC, Netherlands).

what we see is that we get different responses for the NS record set
for "partners.extranet.microsoft.com":

1) a list of 4 NS records (dns10/11/12/13.one.microsoft.com) with
public route-able IPv4 addresses, answer size is around 200 byte

2) a list of 18 NS records
(xxxx-ptnr-dc-02.partners.extranet.microsoft.com.) with private RFC
1918 addresses and an answer size of above 800 byte. These are
internal domain controllers.

The answer size of 800 bytes can create the FORMERR issue.

I'm using BIND 9.9.1(-P1) and Unbound 1.4.17 here. Today I'm getting
answer type 1) from my home and also from a machine in the datacenter,
yesterday I'm seen answer type 2) and the FORMERR.

The FORMERR I'm seeing is also quite odd, as it has the "AD" flag set,
which should normally not appear in an error type of response, but
might be caused by a mangled DNS packet:


;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 30679
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

I have no explanation of this issue at the moment.

To my knowledge Google is using a homegrown DNS resolver, not BIND.


Best regards

Carsten Strotmann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/mxZ4ACgkQsUJ3c+pomYHc6QCfeONcluurcPOX4dMqMWDm4pnf
SlgAnAxlJ1UQRSdE+WgN28RYVBmo/N03
=DT/n
-----END PGP SIGNATURE-----
Carsten Strotmann (private)'s profile photo

Carsten Strotmann (private)

unread,
Jun 24, 2012, 12:07:00 PM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

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

Hello Jeffry,


On 6/22/12 1:25 PM, Spain, Dr. Jeffry A. wrote:
> From what I observed I would conclude that dns11.one.microsoft.com
> is a Windows DNS server since it behaves like mine except for the
> AA flag not being set in theirs.

It might even be a new Windows 2012 DNS server, and it might be an
issue with this new version. This is just speculation, but if it is an
issue with Windows 2012 DNS, it might be good to be able to isolate
that issue soon (so that it can be fixed before Windows 2012 is released).


> The missing AA flag and lack of authority and additional records in
> their response seems like improper behavior to me, but I don't know
> whether or not the DNS protocol actually requires this. Apparently
> BIND 9.9.1-P1 is able to handle this situation.

my BIND 9.9.1-P1 showed FORMERR yesterday, but shows the same good
answers that you report today.

What is see today when I send a direct query to
dns10.one.microsoft.com. (or dns11/12/13) is that both AA
(Authoritative Answer) and AD (Authenticated Data) flags are set, but
the zone does not seem to be DNSSEC signed (no RRSIGs, no DNSKEY):

bash-3.2# dig partners.extranet.microsoft.com. IN NS
@dns11.one.microsoft.com. +dnssec

; <<>> DiG 9.9.1-P1 <<>> partners.extranet.microsoft.com. IN NS
@dns11.one.microsoft.com. +dnssec

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40230
;; flags: qr aa ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:
;partners.extranet.microsoft.com. IN NS

;; ANSWER SECTION:

partners.extranet.microsoft.com. 10 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 10 IN NS dns12.one.microsoft.com.
dns11.one.microsoft.com. 10 IN A 94.245.124.49
dns10.one.microsoft.com. 10 IN A 131.107.125.65
dns13.one.microsoft.com. 10 IN A 65.55.31.17
dns12.one.microsoft.com. 10 IN A 207.46.55.10

;; Query time: 37 msec
;; SERVER: 94.245.124.49#53(94.245.124.49)
;; WHEN: Sun Jun 24 10:00:54 2012
;; MSG SIZE rcvd: 228


Having AD-Flag set on an non-DNSSEC zone might be a protocol
violation, and that might be the cause of FORMERR.


Best regards

Carsten Strotmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/myqQACgkQsUJ3c+pomYGzyQCdF6q+TeWUmA4TWYgiOn6pA0ha
HHgAn2Amo54kuiNEIJ4hU1kXOwjnY7Pb
=7x6l
-----END PGP SIGNATURE-----
Carsten Strotmann (private)'s profile photo

Carsten Strotmann (private)

unread,
Jun 24, 2012, 12:56:10 PM6/24/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to [email protected]

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

Hello,


On 6/24/12 10:07 AM, Carsten Strotmann (private) wrote:

> It might even be a new Windows 2012 DNS server, and it might be an
> issue with this new version. This is just speculation, but if it is
> an issue with Windows 2012 DNS, it might be good to be able to
> isolate that issue soon (so that it can be fixed before Windows
> 2012 is released).

I did some tests with the release candidate version of Windows 2012,
and I could not reproduce the error. Windows 2012 internal version
number is 6.2 (6.2.8400) and it does not implement the "version.bind"
request (returns a NOTIMPL error).

However the dns11.one.microsoft.comDNS server returns

bash-3.2# dig @94.245.124.49txt ch version.bind
;; Warning: query response not set
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.9.1-P1 <<>> @94.245.124.49txt ch version.bind
; (1 server found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11512
;; flags: aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 1476526080 IN TXT "Microsoft DNS
6.1.7601 (1DB14556)"

;; Query time: 36 msec
;; SERVER: 94.245.124.49#53(94.245.124.49)
;; WHEN: Sun Jun 24 10:26:11 2012
;; MSG SIZE rcvd: 76

which is

Version Product Milestone Service branch
6.1.7600.16xxx Windows Server 2008 R2 RTM GDR

I'm now setting up a Windows 2008R2 DNS Server with the latest patches
in the test lab to see if I can recreate the issue.


Best regards

Carsten Strotmann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/m1ioACgkQsUJ3c+pomYEXWQCfYge8Sjqa4YIhztZLZt5Z9PRp
WuYAnjxfbhVJPRm9y31CKPiO/7wCp/fv
=oS8C
-----END PGP SIGNATURE-----
Tony Finch's profile photo

Tony Finch

unread,
Jun 25, 2012, 3:54:29 PM6/25/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

Report message as abuse

Sign in to report message as abuse

Show original message

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Gabriele Paggi, [email protected]

It looks to me like this is an EDNS bug. I am querying the authoritative
server directly, with no firewalls in the way. The FORMERR is coming from
the authoritative server not from BIND. I get the same result over IPv4
and IPv6.

They also have a bug in their NXDOMAIN logic: extranet.microsoft.com
does not exist therefore partners.extranet.microsoft.comcannot exist.


; <<>> DiG 9.9.1-P1 <<>> +noedns @ns1.msft.net. partners.extranet.microsoft.comns
; (2 servers found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9931

;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;partners.extranet.microsoft.com. IN NS

;; ANSWER SECTION:

partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.

;; ADDITIONAL SECTION:

dns12.one.microsoft.com. 3600 IN A 207.46.55.10
dns10.one.microsoft.com. 3600 IN A 131.107.125.65
dns13.one.microsoft.com. 3600 IN A 65.55.31.17
dns11.one.microsoft.com. 3600 IN A 94.245.124.49

;; Query time: 159 msec

;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)

;; WHEN: Mon Jun 25 12:38:51 2012
;; MSG SIZE rcvd: 197


; <<>> DiG 9.9.1-P1 <<>> +edns=0 @ns1.msft.net. partners.extranet.microsoft.comns
; (2 servers found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20875
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;partners.extranet.microsoft.com. IN NS

;; Query time: 142 msec

;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)

;; WHEN: Mon Jun 25 12:38:57 2012
;; MSG SIZE rcvd: 60


; <<>> DiG 9.9.1-P1 <<>> +noedns @ns1.msft.netextranet.microsoft.comns
; (2 servers found)

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 141
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; WARNING: recursion requested but not available

;; QUESTION SECTION:

;extranet.microsoft.com. IN NS

;; AUTHORITY SECTION:
microsoft.com. 3600 IN SOA ns1.msft.net.
msnhst.microsoft.com. 2012062205300 600 2419200 3600

;; Query time: 142 msec

;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1)

;; WHEN: Mon Jun 25 12:44:44 2012
;; MSG SIZE rcvd: 95


Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
Sole, Lundy, Fastnet: Southeast at first in Lundy and Fastnet, otherwise
southwest, 4 or 5. Slight or moderate, occasionally rough in west Sole.
Occasional rain or drizzle, fog patches. Moderate, occasionally very poor.
Tony Finch's profile photo

Tony Finch

unread,
Jun 25, 2012, 3:57:43 PM6/25/12

Reply to author

Sign in to reply to author

Forward

Sign in to forward

Delete

Link

TC QDCOUNT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ RCODE

Point: Dns format error from bind

CRITICAL ERROR DEA1 49
Dns format error from bind
Dns format error from bind
ERROR 017 UNDEFINED SYMBOL MAX PAWNO

Bind FORMERR errors in syslog

Your DNS traffic may be transparently intercepted, and routed to a caching DNS server and you request answers that cannot be completely answered with brief answers and the caching DNS server gives truncated, rather than minimal answers ("minimal-responses yes;"). For example, www.nvidia.com.edgekey.net is resolved via CNAMES and a long list of nameservers, and it complete answer does not fit in a 500~ish byte response. Here are the steps:

  1. Your BIND makes a non-recursive request to a root server, and expects only authoritative answers (in this case referrals to NS servers responsible for the zone).
  2. The caching DNS server which answers the intercepted request responds with a non-authoritative but incomplete answer, eg, the exact A record being sought, but with a truncated mercedes start error section which does not include the authoritative server for that record. Example (note there is no NS referal for akamaiedge.net):
  1. Your BIND errors with moneyball the non-authoritative answer arriving from a supposedly authoritative server (the answer itself includes the NS referrals, so BIND knows the responding server is not authoritative for the A record), dns format error from bind, and discards the entire response with FORMERR:

The OP question includes an equivalent description of the problem (non-improving NS record == unrelated record in authority section):

  1. Your BIND then attempts the same non-recursive query to the next root server, and the cycle repeats until there are no more root servers to try, and BIND responds with SERVFAIL to the original recursive query.

Arguably the problem is one or several bugs in BIND itself:

  • It checks the consistency of the AUTHORITY section in answers to non-recursive questions, eg, when forwarding a query to an upstream cache, dns format error from bind. It should not reject inconsistent answers, as they may be caused by valid truncation of long AUTHORITY sections
  • When caching, it truncates answers naively. It should truncate more smartly and give AUTHORITY sections that are more useful when truncated, or give minimal answers (no AUTHORITY section) if the truncated AUTHORITY section would not be useful.
  • It should default to "minimal-responses yes;" in caching mode.
  • It should LOG/report if its authoritative queries are answered by non authoritative server (ie, RD flag unset in sent query, but set in received response), ie, detect and report intercepted DNS traffic.

I should note that queries that can be answered completely in a small packet do not trigger these bugs, and therefore, most DNS queries are resolved correctly.

Possible solutions:

  • ask your ISP to add "minimal-responses yes;" to their cache configuration.
  • get the ISP to not intercept your DNS, maybe by switching ISPs
  • run a different BIND version without the bugs (I don't know if such a version exists) or a different software.
  • route BIND's upstream queries through a VPN, and around the DNS dns format error from bind +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Whenever an octet represents a numeric quantity, the leftmost bit in the diagram is the high order or most significant bit. That is, the bit labeled zero is the most significant bit. For example, the following diagram represents the value 170 (decimal).
    0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ 3 RA dns format error from bind 1 RRs pointing toward an authority +---------------------+

0 Comments

Leave a Comment