Understanding cause of DNS format error (FORMERR)

Gabriele Paggi

unread,

Jun 22, 2012, 5:22:12 AM6/22/12

to bind-...@lists.isc.org

Hello,

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:

Jun 22 11:14:47 res1 named[32210]: DNS format error from
94.245.124.49#53 resolving vlasext.partners.extranet.microsoft.com/A
for client 10.16.32.4#50421: invalid response
Jun 22 11:14:47 res1 named[32210]: error (FORMERR) resolving
'vlasext.partners.extranet.microsoft.com/A/IN': 94.245.124.49#53
Jun 22 11:14:47 res1 named[32210]: DNS format error from
131.107.125.65#53 resolving vlasext.partners.extranet.microsoft.com/A
for client 10.16.32.4#50421: invalid response
Jun 22 11:14:47 res1 named[32210]: error (FORMERR) resolving
'vlasext.partners.extranet.microsoft.com/A/IN': 131.107.125.65#53
Jun 22 11:14:47 res1 named[32210]: DNS format error from
207.46.55.10#53 resolving vlasext.partners.extranet.microsoft.com/A
for client 10.16.32.4#50421: invalid response
Jun 22 11:14:47 res1 named[32210]: error (FORMERR) resolving
'vlasext.partners.extranet.microsoft.com/A/IN': 207.46.55.10#53

If I submit the same query to a Windows DNS, or one of the Google DNS,
I do get a reply:
[gpaggi@res1 ~]# dig A @8.8.8.8 vlasext.partners.extranet.microsoft.com +short
70.42.230.20
[gpaggi@res1 ~]#

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.

Thanks!

Gabriele

[1] http://www.isc.org/community/blog/201007/compatibility-issues-bind-970-and-971

Spain, Dr. Jeffry A.

unread,

Jun 22, 2012, 7:25:09 AM6/22/12

to Gabriele Paggi, bind-...@lists.isc.org

> 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.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.49 vlasext.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.net countryday.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.

> 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.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.

Hope this is at least somewhat helpful. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

Carsten Strotmann (private)

unread,

Jun 23, 2012, 4:17:03 AM6/23/12

to bind-...@lists.isc.org

-----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:
>

Carsten Strotmann (private)

unread,

Jun 23, 2012, 4:54:35 AM6/23/12

to bind-...@lists.isc.org

-----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.com ns

; <<>> 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

unread,

Jun 23, 2012, 11:58:25 PM6/23/12

to bind-...@lists.isc.org

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.com ns

; <<>> DiG 9.6-ESV-R4-P3 <<>> @ns1.msft.net.
partners.extranet.microsoft.com ns
; (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

unread,

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

to bind-...@lists.isc.org

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

unread,

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

to bind-...@lists.isc.org

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.49 vlasext.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.net countryday.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)

unread,

Jun 24, 2012, 3:45:34 AM6/24/12

to Gabriele Paggi, bind-...@lists.isc.org

-----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)

unread,

Jun 24, 2012, 4:07:00 AM6/24/12

to bind-...@lists.isc.org

-----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)

unread,

Jun 24, 2012, 4:56:10 AM6/24/12

to bind-...@lists.isc.org

-----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.com DNS server returns

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

; <<>> DiG 9.9.1-P1 <<>> @94.245.124.49 txt 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

unread,

Jun 25, 2012, 7:54:29 AM6/25/12

to Gabriele Paggi, bind-...@lists.isc.org

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.com cannot exist.

; <<>> DiG 9.9.1-P1 <<>> +noedns @ns1.msft.net. partners.extranet.microsoft.com ns
; (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.com ns
; (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.net extranet.microsoft.com ns
; (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. 2012062205 300 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 <d...@dotat.at> 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

unread,

Jun 25, 2012, 7:57:43 AM6/25/12

to Carsten Strotmann (private), bind-...@lists.isc.org

Carsten Strotmann (private) <c...@strotmann.de> wrote:
>
> 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:

I think it is echoing the AD bit in the query.

; <<>> DiG 9.9.1-P1 <<>> +noad +qr @ns1.msft.net. partners.extranet.microsoft.com ns

; (2 servers found)
;; global options: +cmd

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

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 3331
;; flags: qr rd; 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:57:06 2012
;; MSG SIZE rcvd: 60

; <<>> DiG 9.9.1-P1 <<>> +qr @ns1.msft.net. partners.extranet.microsoft.com ns

; (2 servers found)
;; global options: +cmd

;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21060
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 21060

;; 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:56:22 2012
;; MSG SIZE rcvd: 60

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/

Dogger: Northwest 5 or 6 becoming variable 3 or 4. Moderate, becoming slight
in west. Showers. Moderate or good.

Sam Wilson

unread,

Jun 25, 2012, 11:21:07 AM6/25/12

to comp-protoc...@isc.org

In article <mailman.1121.1340625...@lists.isc.org>,
Tony Finch <d...@dotat.at> wrote:

> It looks to me like this is an EDNS bug. ...

There's some kind of delegation bug as well. If I query
dns1[0-3].one.microsoft.com for SOA and NS for
partners.extranet.microsoft.com you get sensible answers though the
origin host is different for each server queried and those origins are
privately addressed.

If I query dns1[0-3].one.microsoft.com for
vlasext.partners.extranet.microsoft.com/IN/A I get answers with no AA
bit set and a decreasing TTL as if the data were cached. It does not
appear that vlasext.partners.extranet.microsoft.com is delegated itself
so it's not cached answers from a child zone. The authority for
zero-answer responses such as
vlasext.partners.extranet.microsoft.com/IN/AAAA is the SOA for
partners.extranet.microsoft.com

It's all rather horrible.

Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Gabriele Paggi

unread,

Jun 26, 2012, 8:55:44 AM6/26/12

to comp-protoc...@isc.org

Hello Sam,

> There's some kind of delegation bug as well. If I query
> dns1[0-3].one.microsoft.com for SOA and NS for
> partners.extranet.microsoft.com you get sensible answers though the
> origin host is different for each server queried and those origins are
> privately addressed.

Which kind of misconfiguration could lead to SOA records for hosts on
the internet to be privately addressed?
Misconfigured split horizon server?

[...]

> The authority for zero-answer responses such as
> vlasext.partners.extranet.microsoft.com/IN/AAAA is the SOA for
> partners.extranet.microsoft.com

What do you mean with "authority for zero-answer responses"?
What is the normal authority response I should get when querying for
non-existent records?
I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
I most of the time get as authority section the SOA for the second
level domain (readthedocs.org).

Thanks!

> It's all rather horrible.

I concur!

Gabriele

Sam Wilson

unread,

Jun 26, 2012, 9:47:52 AM6/26/12

to comp-protoc...@isc.org

In article <mailman.1143.1340715...@lists.isc.org>,

Gabriele Paggi <gabrie...@gmail.com> wrote:

> Hello Sam,
>
> > There's some kind of delegation bug as well. If I query
> > dns1[0-3].one.microsoft.com for SOA and NS for
> > partners.extranet.microsoft.com you get sensible answers though the
> > origin host is different for each server queried and those origins are
> > privately addressed.
>
> Which kind of misconfiguration could lead to SOA records for hosts on
> the internet to be privately addressed?
> Misconfigured split horizon server?

It's not difficult for private addresses to escape. It need not actually
be a problem. It's not necessarily a problem here but it does make it
difficult to work out what's going on.

> [...]
> > The authority for zero-answer responses such as
> > vlasext.partners.extranet.microsoft.com/IN/AAAA is the SOA for
> > partners.extranet.microsoft.com
>
> What do you mean with "authority for zero-answer responses"?
> What is the normal authority response I should get when querying for
> non-existent records?

For a NXDOMAIN response, or NOERROR with an empty answer section, the
server should provide the SOA record in the authority section. That SOA
is the apex of the zone which doesn't contain the answer record you
asked for, if you see what I mean. The server is proving that it has
authority to tell you that the information doesn't exist.

The fact that looking for nonexistent data for
vlasext.partners.extranet.microsoft.com returns the
partners.extranet.microsoft.com SOA record shows that the vlasext
subdomain has not been delegated. The servers should therefore be able
to offer an authoritative answer for data that does exist for
vlasext.etc... but they don't.

> I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
> I most of the time get as authority section the SOA for the second
> level domain (readthedocs.org).
>
> Thanks!

dig <domain> +trace will also (normally) show you how the tree is
delegated, though it doesn't print out the SOA records. Try
www.automation.ucs.ed.ac.uk.

> > It's all rather horrible.
>
> I concur!

Barry Margolin

unread,

Jun 26, 2012, 10:09:44 AM6/26/12

to comp-protoc...@isc.org

In article <mailman.1144.1340718...@lists.isc.org>,

Sam Wilson <Sam.W...@ed.ac.uk> wrote:

> For a NXDOMAIN response, or NOERROR with an empty answer section, the
> server should provide the SOA record in the authority section. That SOA
> is the apex of the zone which doesn't contain the answer record you
> asked for, if you see what I mean. The server is proving that it has
> authority to tell you that the information doesn't exist.

More important, the SOA record contains the TTL that should be used for
the negative cache entry.

>
> The fact that looking for nonexistent data for
> vlasext.partners.extranet.microsoft.com returns the
> partners.extranet.microsoft.com SOA record shows that the vlasext
> subdomain has not been delegated. The servers should therefore be able
> to offer an authoritative answer for data that does exist for
> vlasext.etc... but they don't.

This type of inconsistency often suggests a DNS-based load balancer is
involved.

--
Barry Margolin
Arlington, MA

Sam Wilson

unread,

Jun 27, 2012, 5:23:03 AM6/27/12

to comp-protoc...@isc.org

In article <mailman.1145.1340719...@lists.isc.org>,

Barry Margolin <bar...@alum.mit.edu> wrote:

> In article <mailman.1144.1340718...@lists.isc.org>,
> Sam Wilson <Sam.W...@ed.ac.uk> wrote:
>
> > For a NXDOMAIN response, or NOERROR with an empty answer section, the
> > server should provide the SOA record in the authority section. That SOA
> > is the apex of the zone which doesn't contain the answer record you
> > asked for, if you see what I mean. The server is proving that it has
> > authority to tell you that the information doesn't exist.
>
> More important, the SOA record contains the TTL that should be used for
> the negative cache entry.

More important for the operation of the DNS, but I'd think less
important from the point of view of manual debugging, like we're doing
here.

> > The fact that looking for nonexistent data for
> > vlasext.partners.extranet.microsoft.com returns the
> > partners.extranet.microsoft.com SOA record shows that the vlasext
> > subdomain has not been delegated. The servers should therefore be able
> > to offer an authoritative answer for data that does exist for
> > vlasext.etc... but they don't.
>
> This type of inconsistency often suggests a DNS-based load balancer is
> involved.

I wondered that but it's not consistent with earlier results in the
thread which suggested Windows DNS server for at least one of them. An
old version of fpdns (someone might like to try a newer one) concurs:

$ for i in 0 1 2 3 ; do fpdns dns1$i.one.microsoft.com ; done
fingerprint (dns10.one.microsoft.com, 131.107.125.65): Microsoft \
Windows 2003
fingerprint (dns11.one.microsoft.com, 94.245.124.49): Microsoft \
Windows 2003
fingerprint (dns12.one.microsoft.com, 207.46.55.10): Microsoft \
Windows 2003
fingerprint (dns13.one.microsoft.com, 65.55.31.17): Microsoft \
Windows 2003
$ fpdns -v
fpdns.pl version 0.9.1