facebook.com delegation

Chris Buxton cbuxton at menandmice.com
Tue Nov 27 22:36:27 UTC 2007


You are correct, matching delegation and authority NS records is how  
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:   cbuxton at 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.wark at 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.
>
>
>
> ----- Original Message -----
> From: Chris Buxton [cbuxton at menandmice.com]
> Sent: 11/27/2007 01:29 PM PST
> To: Jeff Wark <jwark at tbaytel.net>
> Cc: <bind-users at isc.org>
> Subject: Re: facebook.com delegation
>
>
>
> It appears that the load balancers that are authoritative for these  
> 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:   cbuxton at 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 12:44 PM, Jeff Wark wrote:
>
>> We are currently having some difficulty resolving facebook.com.   
>> Restarts of our nameservers solve the problem for a short time,
>> 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
>>
>>
>
>
> -----------------------------------------
> 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.



More information about the bind-users mailing list