Facebook

[Bernd Plagge]

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

Hi,

today I was called to a customer because he could not access facebook - but all other domains.

The customer runs a small network with tinydns and an external dnscache.
His claims were justified: tinydns was working fine but
dig a www.facebook.com or
dnsqr a www.facebook.com
just didn't resolve.

I noticed that
dig @ns1.facebook.com a www.facebook.com
results in:

; <<>> DiG 9.5.1-P3 <<>> @ns1.facebook.com a www.facebook.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3225
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.facebook.com. IN A

;; AUTHORITY SECTION:
www.facebook.com. 900 IN NS glb01.hkg1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ash1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.lhr1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.snc1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.dfw1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ams1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.sf2p.tfbnw.net.

;; Query time: 140 msec
;; SERVER: 204.74.66.132#53(204.74.66.132)
;; WHEN: Thu Mar 11 01:06:03 2010
;; MSG SIZE rcvd: 218

which is strange.
It seems that not only the domain 'facebook.com' has name servers but the host 'www.facebook.com' has another set of 7 name servers.

Later at home (where I have a similar setup) I tried it again:

dnsqr a www.facebook.com

timed out.
However, when I ran the command the 2nd, 3rd, 4th etc. time it returned an IP number.

Both servers run Debian Linux.
The difference was that my home server had the djbdns package installed (which seems to be more standard) while the other server had the dbndns package installed. This package contains patches to support IPv6.

Not sure whether this was the problem I installed the djbdns package on the client machine as well.
Yes, and it worked as well.

While I solved the problem (at least from the customers viewpoint) I wonder whether somebody else made the same experience. Facebook must have changed something before the system had been working for months without any problem.

Did anybody make similar experiences?

Regards,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuXx48ACgkQpYU8M8PbPV6g1ACdHGPRs6O5F/J40H5iscI68ilj
4VAAoK5slr71XnpDWEqMjM/sydWOU4t+
=smC9
-----

[Joe Baptista]

The misconfiguration is at facebook.com.

Post by Bernd Plagge
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
today I was called to a customer because he could not access facebook - but
all other domains.
The customer runs a small network with tinydns and an external dnscache.
His claims were justified: tinydns was working fine but
dig a www.facebook.com or
dnsqr a www.facebook.com
just didn't resolve.
I noticed that
; (1 server found)
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3225
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;www.facebook.com. IN A
www.facebook.com. 900 IN NS glb01.hkg1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ash1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.lhr1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.snc1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.dfw1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ams1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.sf2p.tfbnw.net.
;; Query time: 140 msec
;; SERVER: 204.74.66.132#53(204.74.66.132)
;; WHEN: Thu Mar 11 01:06:03 2010
;; MSG SIZE rcvd: 218
which is strange.
It seems that not only the domain 'facebook.com' has name servers but the
host 'www.facebook.com' has another set of 7 name servers.
dnsqr a www.facebook.com
timed out.
However, when I ran the command the 2nd, 3rd, 4th etc. time it returned an IP number.
Both servers run Debian Linux.
The difference was that my home server had the djbdns package installed
(which seems to be more standard) while the other server had the dbndns
package installed. This package contains patches to support IPv6.
Not sure whether this was the problem I installed the djbdns package on the
client machine as well.
Yes, and it worked as well.
While I solved the problem (at least from the customers viewpoint) I wonder
whether somebody else made the same experience. Facebook must have changed
something before the system had been working for months without any problem.
Did anybody make similar experiences?
Regards,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkuXx48ACgkQpYU8M8PbPV6g1ACdHGPRs6O5F/J40H5iscI68ilj
4VAAoK5slr71XnpDWEqMjM/sydWOU4t+
=smC9
-----END PGP SIGNATURE-----

[Matthew Dempsky]

Post by Joe Baptista
The misconfiguration is at facebook.com.

For anyone interested in details, the issue here is that two of
facebook.com's name servers are in the tfbnw.net zone while all of
tfbnw.net's name servers are in the facebook.com zone.

dnscache always tries to resolve all of a zone's name servers before
attempting to resolve any names within that zone, so this zone
dependency loop results in dnscache spending a lot of extra effort
trying to track down the missing glue records.

That said, I was able to resolve www.facebook.com using dnscache, just
not on the first attempt. I can imagine it failing repeatedly on a
busy resolver though.

[Joe Baptista]

Post by Matthew Dempsky

Post by Joe Baptista
The misconfiguration is at facebook.com.

For anyone interested in details, the issue here is that two of
facebook.com's name servers are in the tfbnw.net zone while all of
tfbnw.net's name servers are in the facebook.com zone.

I double checked. There is no misconfiguration. But your explanation is not
correct or is confused. The facebook.com NS are as follows:

facebook.com. 172800 IN NS dns04.sf2p.tfbnw.net.
facebook.com. 172800 IN NS dns05.sf2p.tfbnw.net.
facebook.com. 172800 IN NS ns1.facebook.com.
facebook.com. 172800 IN NS ns2.facebook.com.

but www.facebook.com is not in the facebook zone. It has it's own set of DNS
servers - i.e.:

www.facebook.com. 491 IN NS glb01.hkg1.tfbnw.net.
www.facebook.com. 491 IN NS glb01.snc1.tfbnw.net.
www.facebook.com. 491 IN NS glb01.dfw1.tfbnw.net.
www.facebook.com. 491 IN NS glb01.sf2p.tfbnw.net.
www.facebook.com. 491 IN NS glb01.lhr1.tfbnw.net.
www.facebook.com. 491 IN NS glb01.ash1.tfbnw.net.
www.facebook.com. 491 IN NS glb01.ams1.tfbnw.net.

Post by Matthew Dempsky
dnscache always tries to resolve all of a zone's name servers before
attempting to resolve any names within that zone, so this zone
dependency loop results in dnscache spending a lot of extra effort
trying to track down the missing glue records.
That said, I was able to resolve www.facebook.com using dnscache, just
not on the first attempt. I can imagine it failing repeatedly on a
busy resolver though.

That could be an issue.

regards
joe

[Matthew Dempsky]

But your explanation is not correct or is confused

My explanation is correct.

facebook.com.        172800    IN    NS    dns04.sf2p.tfbnw.net.
facebook.com.        172800    IN    NS    dns05.sf2p.tfbnw.net.
facebook.com.        172800    IN    NS    ns1.facebook.com.
facebook.com.        172800    IN    NS    ns2.facebook.com.

Right, and the tfbnw.net NS records are as follows:

tfbnw.net. 172800 IN NS ns3.facebook.com.
tfbnw.net. 172800 IN NS ns4.facebook.com.
tfbnw.net. 172800 IN NS ns5.facebook.com.
tfbnw.net. 172800 IN NS ns6.facebook.com.
tfbnw.net. 172800 IN NS ns7.facebook.com.

but www.facebook.com is not in the facebook zone.

The www.facebook.com vs facebook.com distinction is unrelated to the
dependency loop between facebook.com and tfbnw.net.

[Matthew Dempsky]

Post by Matthew Dempsky
My explanation is correct.

It was not clear. Confusing.

Apologies then.

Post by Matthew Dempsky
The www.facebook.com vs facebook.com distinction is unrelated to the
dependency loop between facebook.com and tfbnw.net.

I get what your saying now but there should still be no problem resolving
it.  Its not a configuration error. A name server should not have any
problems resolving either domain.

Whether or not Facebook's configuration is an "error" is arguable but
moot: the important thing is that it's a configuration that dnscache
doesn't handle particularly gracefully.

[Joe Baptista]

Post by Matthew Dempsky

But your explanation is not correct or is confused

My explanation is correct.

It was not clear. Confusing.

Post by Matthew Dempsky

facebook.com. 172800 IN NS dns04.sf2p.tfbnw.net.
facebook.com. 172800 IN NS dns05.sf2p.tfbnw.net.
facebook.com. 172800 IN NS ns1.facebook.com.
facebook.com. 172800 IN NS ns2.facebook.com.

tfbnw.net. 172800 IN NS ns3.facebook.com.
tfbnw.net. 172800 IN NS ns4.facebook.com.
tfbnw.net. 172800 IN NS ns5.facebook.com.
tfbnw.net. 172800 IN NS ns6.facebook.com.
tfbnw.net. 172800 IN NS ns7.facebook.com.

but www.facebook.com is not in the facebook zone.

The www.facebook.com vs facebook.com distinction is unrelated to the
dependency loop between facebook.com and tfbnw.net.

I get what your saying now but there should still be no problem resolving
it. Its not a configuration error. A name server should not have any
problems resolving either domain.

What I find strange is that the www.facebook.com A record is set for 30
seconds. Most of their DNS records are set at very low ttl. As a result they
must get a lot of DNS traffic. Maybe the problem is congestion at their end?

regards
joe baptista

[Bernd Plagge]

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

On Wed, 10 Mar 2010 10:20:40 -0800

Post by Matthew Dempsky

Post by Joe Baptista
The misconfiguration is at facebook.com.

....

Post by Matthew Dempsky
That said, I was able to resolve www.facebook.com using dnscache, just
not on the first attempt. I can imagine it failing repeatedly on a
busy resolver though.

Yes, that's what I found as well.

Thanks for your explanations!

But the IPv6 enabled version didn't succeed in resolving it.
I was just wondering whether anybody else experienced this problem and what the reason is.

Regards,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuYMkkACgkQpYU8M8PbPV5A2ACff+Y+kjSq824mwCl+l2fR+MLx
5KAAoLhHKr7aJb70zKKsOHOuePAgcAJ

[Matthew Dempsky]

Post by Bernd Plagge
But the IPv6 enabled version didn't succeed in resolving it.

That's odd. I don't think Facebook has any IPv6 name servers, and
last I checked, fefe's IPv6 patches to dnscache didn't change it to
actually query for or even use AAAA records when attempting to contact
an authoritative server.

Exactly which patches are you using?

[Bernd Plagge]

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

On Wed, 10 Mar 2010 16:45:23 -0800

Post by Matthew Dempsky

Post by Bernd Plagge
But the IPv6 enabled version didn't succeed in resolving it.

That's odd. I don't think Facebook has any IPv6 name servers, and
last I checked, fefe's IPv6 patches to dnscache didn't change it to
actually query for or even use AAAA records when attempting to contact
an authoritative server.
Exactly which patches are you using?

Debian package dnsdbs, maintainer is Gerrit Pape.
At http://packages.debian.org/lenny/dbndns you find detailed information together with the original 1.05 djbdns tarball and the diff.

Regards,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuYSVMACgkQpYU8M8PbPV6g4gCeMk5B7Pl+pRZA4SmYOkUbGC8Y
oosAoKjYhxj4WNbIxUSeYCAsvaXaaLHq
=gEJR
-----END PGP S

[Dean Anderson]

This is the gluelessness problem.

facebook.com is nearly glueless and tfbnw.net is glueless

If ns1.facebook.com and ns2.facebook.com are both down, both
facebook.com and tfbnw.net are unresolvable because there is no working
glue that can get to either one.

http://cr.yp.to/djbdns/notes.html

--Dean

Post by Bernd Plagge
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
today I was called to a customer because he could not access facebook - but all other domains.
The customer runs a small network with tinydns and an external dnscache.
His claims were justified: tinydns was working fine but
dig a www.facebook.com or
dnsqr a www.facebook.com
just didn't resolve.
I noticed that
; (1 server found)
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3225
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;www.facebook.com. IN A
www.facebook.com. 900 IN NS glb01.hkg1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ash1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.lhr1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.snc1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.dfw1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.ams1.tfbnw.net.
www.facebook.com. 900 IN NS glb01.sf2p.tfbnw.net.
;; Query time: 140 msec
;; SERVER: 204.74.66.132#53(204.74.66.132)
;; WHEN: Thu Mar 11 01:06:03 2010
;; MSG SIZE rcvd: 218
which is strange.
It seems that not only the domain 'facebook.com' has name servers but the host 'www.facebook.com' has another set of 7 name servers.
dnsqr a www.facebook.com
timed out.
However, when I ran the command the 2nd, 3rd, 4th etc. time it returned an IP number.
Both servers run Debian Linux.
The difference was that my home server had the djbdns package installed (which seems to be more standard) while the other server had the dbndns package installed. This package contains patches to support IPv6.
Not sure whether this was the problem I installed the djbdns package on the client machine as well.
Yes, and it worked as well.
While I solved the problem (at least from the customers viewpoint) I wonder whether somebody else made the same experience. Facebook must have changed something before the system had been working for months without any problem.
Did anybody make similar experiences?
Regards,
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkuXx48ACgkQpYU8M8PbPV6g1ACdHGPRs6O5F/J40H5iscI68ilj
4VAAoK5slr71XnpDWEqMjM/sydWOU4t+
=smC9
-----END PGP SIGNATURE-----

[Michael Loftis]

Post by Dean Anderson
This is the gluelessness problem.
facebook.com is nearly glueless and tfbnw.net is glueless
If ns1.facebook.com and ns2.facebook.com are both down, both
facebook.com and tfbnw.net are unresolvable because there is no working
glue that can get to either one.
http://cr.yp.to/djbdns/notes.html

False, and unlike yourself, I'll even document it, and point out that
anyone can reproduce this documentation with their favorite DNS Query tool,
I personally use dig.

There are glue records present for all of the facebook.com NSes within the
net. and com. zones.

There are glue records also present for all of the tfbnw.net NSes within
the com. zone.

A few simple DNS queries using, for example dig, pointed towards any of the
net./com. servers in gtld-servers.net, such as say f.gtld-servers.net, will
educate you very quickly.

The gtld-servers.net nameservers will ONLY return delegation information at
present IE if you ask for an A record you'll only ever get the delegation
information, including glue, for that record.

$ dig ns facebook.com @f.gtld-servers.net

; <<>> DiG 9.5.1-P3 <<>> ns facebook.com @f.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25349
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;facebook.com. IN NS

;; AUTHORITY SECTION:
facebook.com. 172800 IN NS dns04.sf2p.tfbnw.net.
facebook.com. 172800 IN NS dns05.sf2p.tfbnw.net.
facebook.com. 172800 IN NS ns1.facebook.com.
facebook.com. 172800 IN NS ns2.facebook.com.

;; ADDITIONAL SECTION:
dns04.sf2p.tfbnw.net. 172800 IN A 69.63.176.8
dns05.sf2p.tfbnw.net. 172800 IN A 69.63.176.9
ns1.facebook.com. 172800 IN A 204.74.66.132
ns2.facebook.com. 172800 IN A 204.74.67.132

;; Query time: 45 msec
;; SERVER: 192.35.51.30#53(192.35.51.30)
;; WHEN: Wed Mar 10 19:00:35 2010
;; MSG SIZE rcvd: 184

$ dig ns tfbnw.net @f.gtld-servers.net

; <<>> DiG 9.5.1-P3 <<>> ns tfbnw.net @f.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8906
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tfbnw.net. IN NS

;; AUTHORITY SECTION:
tfbnw.net. 172800 IN NS ns3.facebook.com.
tfbnw.net. 172800 IN NS ns4.facebook.com.
tfbnw.net. 172800 IN NS ns5.facebook.com.
tfbnw.net. 172800 IN NS ns6.facebook.com.
tfbnw.net. 172800 IN NS ns7.facebook.com.

;; ADDITIONAL SECTION:
ns3.facebook.com. 172800 IN A 69.63.178.21
ns4.facebook.com. 172800 IN A 69.63.186.49
ns5.facebook.com. 172800 IN A 69.63.176.200
ns6.facebook.com. 172800 IN A 208.93.136.11
ns7.facebook.com. 172800 IN A 208.93.136.12

;; Query time: 47 msec
;; SERVER: 192.35.51.30#53(192.35.51.30)
;; WHEN: Wed Mar 10 19:00:47 2010
;; MSG SIZE rcvd: 209

$

[Matthew Dempsky]

Post by Michael Loftis
There are glue records present for all of the facebook.com NSes within the
net. and com. zones.
There are glue records also present for all of the tfbnw.net NSes within the
com. zone.

dnscache doesn't go to the extra effort of recognizing that the same
authoritative name servers control both the .com and .net zones. (To
my knowledge, no recursive DNS server does, but I could be wrong.) As
such, the *.tfbnw.net A records returned for facebook.com's NS records
and the *.facebook.com A records returned for tfbnw.net's NS records
are discarded as out-of-bailiwick poison.

[Dean Anderson]

I don't know if they are discarded as poison by DNScache, right off
hand, and I'm not going to check tonight.

Glueless domains are a bad idea. Don't do it. Pick a name in the
domain, add it as a NS for that domain and give it an A record. One IP
address can have an unlimited number of A records pointing to it.

Indeed, the .com and .net servers put in the glue. But the IETF says
not to:

Dan writes in http://cr.yp.to/djbdns/notes.html:

For referrals to out-of-bailiwick DNS servers, however, RFC 1034 says
that glue is unnecessary. RFC 1537 says the same thing. RFC 1912 says
the same thing. The comp.protocols.tcp-ip.domains FAQ says that ``you
do not need a glue record, and, in fact, adding one is a very bad
idea.'' (This is an obsolete reference to accidental poisoning; see
above.) Some DNS server implementations ignore out-of-bailiwick glue by
default. So the glueless domains espn.tv and disney.corp are following
the rules---yet neither of them is reachable.

Like Dempsky points out (that was a good call), the .com and .net
probably aren't recognized by the cache to be the same, so their
out-of-baliwick glue is discarded.

NS records and MX records should have addresses instead of names. But we
can't fix that now. (could have been fixed in IPv6, though)

DNS is not the work of the best and the brightess, that's for sure.
Not only has it been bad, but it isn't getting any better. Its worse.
One chair of the DNSEXT working group is qualified only as a Database
admin and is educated as a philospher (truth is relative; what is
reality anyway?...good stuff for con-artists, but not very useful for
engineering), no background as an engineer--has virtually no technical
background whatsoever. The real tragedy is that DNS protocol could have
been re-done for IPV6, but...well, you can probably guess why it wasn't.
Sigh.

'nite, folks.

--Dean

Post by Matthew Dempsky

Post by Michael Loftis
There are glue records present for all of the facebook.com NSes within the
net. and com. zones.
There are glue records also present for all of the tfbnw.net NSes within the
com. zone.

dnscache doesn't go to the extra effort of recognizing that the same
authoritative name servers control both the .com and .net zones. (To
my knowledge, no recursive DNS server does, but I could be wrong.) As
such, the *.tfbnw.net A records returned for facebook.com's NS records
and the *.facebook.com A records returned for tfbnw.net's NS records
are discarded as out-of-bailiwick poison.

[Dan Peterson]

Post by Bernd Plagge
today I was called to a customer because he could not access facebook - but all other domains.

Looks like this is fixed, all facebook.com's nameservers are now
facebook.com names. Rejoice!

-Dan

[Chris Pugh]

Post by Dan Peterson

Post by Bernd Plagge
today I was called to a customer because he could not access facebook - but all other domains.

Looks like this is fixed, all facebook.com's nameservers are now
facebook.com names. Rejoice!
-Dan

Depends what you consider to be broken... ;o)

dnsqr ns www.facebook.com

2 www.facebook.com:
330 bytes, 1+7+0+7 records, response, noerror
query: 2 www.facebook.com
answer: www.facebook.com 500 NS glb01.lhr1.tfbnw.net
answer: www.facebook.com 500 NS glb01.dfw1.tfbnw.net
answer: www.facebook.com 500 NS glb01.hkg1.tfbnw.net
answer: www.facebook.com 500 NS glb01.ash1.tfbnw.net
answer: www.facebook.com 500 NS glb01.sf2p.tfbnw.net
answer: www.facebook.com 500 NS glb01.snc1.tfbnw.net
answer: www.facebook.com 500 NS glb01.ams1.tfbnw.net
additional: glb01.ams1.tfbnw.net 2577 A 69.63.191.219
additional: glb01.ash1.tfbnw.net 2895 A 69.63.185.11
additional: glb01.dfw1.tfbnw.net 2895 A 69.63.185.78
additional: glb01.hkg1.tfbnw.net 1118 A 69.63.185.86
additional: glb01.lhr1.tfbnw.net 1122 A 69.63.191.91
additional: glb01.sf2p.tfbnw.net 2487 A 69.63.176.101
additional: glb01.snc1.tfbnw.net 2895 A 69.63.179.22

Chris.

[Matthew Dempsky]

Post by Chris Pugh
Depends what you consider to be broken... ;o)

Their current setup is still somewhat suboptimal, but it at least no
longer has cyclic zone dependencies: because tfbnw.net only depends on
facebook.com, it's 'okay' for www.facebook.com to depend on tfbnw.net.

[Joe Baptista]

i think this was covered. www.facebook.com is its own zone.

regards
joe baptista

Post by Bernd Plagge

Post by Dan Peterson

Post by Bernd Plagge
today I was called to a customer because he could not access facebook -

but all other domains.

Post by Dan Peterson
Looks like this is fixed, all facebook.com's nameservers are now
facebook.com names. Rejoice!
-Dan

Depends what you consider to be broken... ;o)
dnsqr ns www.facebook.com
330 bytes, 1+7+0+7 records, response, noerror
query: 2 www.facebook.com
answer: www.facebook.com 500 NS glb01.lhr1.tfbnw.net
answer: www.facebook.com 500 NS glb01.dfw1.tfbnw.net
answer: www.facebook.com 500 NS glb01.hkg1.tfbnw.net
answer: www.facebook.com 500 NS glb01.ash1.tfbnw.net
answer: www.facebook.com 500 NS glb01.sf2p.tfbnw.net
answer: www.facebook.com 500 NS glb01.snc1.tfbnw.net
answer: www.facebook.com 500 NS glb01.ams1.tfbnw.net
additional: glb01.ams1.tfbnw.net 2577 A 69.63.191.219
additional: glb01.ash1.tfbnw.net 2895 A 69.63.185.11
additional: glb01.dfw1.tfbnw.net 2895 A 69.63.185.78
additional: glb01.hkg1.tfbnw.net 1118 A 69.63.185.86
additional: glb01.lhr1.tfbnw.net 1122 A 69.63.191.91
additional: glb01.sf2p.tfbnw.net 2487 A 69.63.176.101
additional: glb01.snc1.tfbnw.net 2895 A 69.63.179.22
Chris.