facebook.com delegation
Jeff Wark
but it crops up again.
It seems that 'www.facebook.com' and 'login.facebook.com' are delegated zones and the delegation is not set up correctly. The
name servers for 'www.facebook.com' and 'login.facebook.com' do not return NS records. Perhaps I am checking something
incorrectly, its been a long day.
Can anyone confirm or deny these delegation problems? If confirmed, what kind of problems could be expected?
Thank for taking a look.
Jeff Wark
TBayTel Internet
Chris Buxton
two zones do not return NS records when answering the queries. In
fact, if asked for such NS records, they give a negative answer.
Delegation of these zones, however, looks perfectly normal.
While this is a little weird, and may break the rules a bit, there's
no problem that it's likely to cause unless a resolving name server
tries to verify the delegation records. I can see why a software
designer creating a load balancer might not think there would be any
problem here.
Testing with my vanilla install of BIND 9.4.1-P1, there is no problem.
If I ask once for www.facebook.com, the records are retrieved, and I
see:
;; QUESTION SECTION:
;www.facebook.com. IN A
;; ANSWER SECTION:
www.facebook.com. 30 IN A 69.63.176.11
;; AUTHORITY SECTION:
www.facebook.com. 900 IN NS glb01.sctm.tfbnw.net.
www.facebook.com. 900 IN NS glb01.sf2p.tfbnw.net.
;; ADDITIONAL SECTION:
glb01.sctm.tfbnw.net. 7200 IN A 204.15.20.101
glb01.sf2p.tfbnw.net. 7200 IN A 69.63.176.101
Further requests are answered with the same records, from cache. named
has not asked the load balancers for the zone's authoritative NS
records, instead relying on the cached delegation records. In fact, if
I ask it to look up the zone's NS records, it returns SERVFAIL, and
does not cache the bogus nxrrset response from the authoritative
servers.
What name server software are you using for recursion? Are you
forwarding or recursing? If forwarding, what is the ultimate recursion
server?
Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone: +354 412 1500
Email: cbu...@menandmice.com
www.menandmice.com
Men & Mice
We bring control and flexibility to network management
This e-mail and its attachments may contain confidential and
privileged information only intended for the person or entity to which
it is addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution or copy of this e-mail is strictly prohibited. If you
have received this e-mail in error, please notify us immediately by
reply e-mail and immediately delete this message and all its attachment.
Chris Buxton
it's supposed to work.
It sounds like your BIND 8 server is trying to confirm the zone's NS
records sometime after retrieving the A record from the load balancers
in response to the initial request, by asking the load balancers for a
list of NS records. This fails. If you weren't able to follow that,
here's the sequence of events that I mean:
- Get query for www.facebook.com.
- Ask facebook.com servers for www.facebook.com IN A, get referral.
- Ask load balancers the same question. Get answer, but no authority
NS records.
- Return answer to clients, cache A record.
- Time passes, cached A record expires.
- Get query for www.facebook.com.
- Query load balancers for www.facebook.com IN NS, get negative
answer. This is more "credible" than the delegation RRSet, so it
replaces the cached delegation records, at least until the negative
answer expires (60 seconds).
- Repeat the last two steps as needed, until the original delegation
records expire (15 minutes). Then back to square one.
Again, I can see why somebody thought this wouldn't be a problem. They
may have tested with BIND 9, not realizing that different name servers
behave differently and not knowing that it's a violation of RFC.
The best solution would be to upgrade your BIND version to BIND 9. The
next best would be to forward the queries to an unaffected resolving
name server, as you're doing.
Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone: +354 412 1500
Email: cbu...@menandmice.com
www.menandmice.com
Men & Mice
We bring control and flexibility to network management
This e-mail and its attachments may contain confidential and
privileged information only intended for the person or entity to which
it is addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution or copy of this e-mail is strictly prohibited. If you
have received this e-mail in error, please notify us immediately by
reply e-mail and immediately delete this message and all its attachment.
On Nov 27, 2007, at 2:02 PM, jeff...@tbaytel.com wrote:
> (Message sent from blackberry...please forgive typos)
>
> I was under the impression that the parent zone supplied ns records
> and then the delegated name servers also had those entries. The NS
> records exist in both the parent and the child zone.
>
> We are running BIND 8.4.6 (debian sarge package). It has worked
> fine for a long time and this is the only (noticeable) domain that
> is giving us trouble. We can resolve the host and then answer
> queries until the TTL expires. Then we experience timeouts.
>
> We were resolving directly and then we tried forwarding queries
> directly to the facebook name servers. Now we are forwarding it to
> another server that is just looking up www.facebook.com addresses.
>
> Dnsstuff.com seems to report intermittent timeouts when contacting
> the two 204. nameservers for facebook.
>
> One of the things that makes this problem so noticeable is the 30
> second ttl. It expires very quickly causing the problem.
>
> Thank you for your input. I really appreciate it.
> Any other ideas are welcomed.
>
> Have a good evening/night.
> -----------------------------------------
> The information transmitted by electronic communication is intended
> only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. The sender does
> not waive any related rights or obligations. Any review,
> retransmission, dissemination or other use of, or taking of any
> action in reliance upon this information, by persons or entities
> other than the intended recipient, is prohibited. If you received
> this in error, please contact the sender and delete the material
> from any computer.