[dns-operations] attention yahoo, microsoft, wikipedia, akamai, and akamai customers

[Pawel Rogocz]

On Tue, Apr 04, 2006 at 01:12:10AM +0000, Paul Vixie wrote:
> today i posted the following on namedroppers at .

Paul,

Akamai knew about this problem for at least 18 months:

http://marc.theaimsgroup.com/?l=djbdns&m=109558785029131&w=2

Let's hope your comments will encourage them to change this nonsense.

Pawel

> 
> re:
> 

Content-Description: forwarded message
> From: Paul Vixie <paul at vix.com>
> Subject: Re: another out-of-zone cname question-- anti-aliasing of zone
> 	servers?
> Date: Mon, 03 Apr 2006 21:29:21 +0000
> Message-ID: <e0s4gi$1utm$1 at sf1.isc.org>
> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1
> 
> > > so here's my question.  should a modern paranoid resolver anti-alias these
> > > out-of-zone cname targets, with logic along the lines of "even though the
> > > zone of the target isn't within the zone of my question, i know that the
> > > zone of the target is served by the same nameservers as the zone of my
> > > question, so it is allowed to give me this out-of-zone data"?
> > 
> > I think it's interesting to consider a resolver asking itself if it would
> > employ the same source for the information it is otherwise likely to ignore
> > from the response.  Assuming the resolver wants the complete answer, it
> > will be asking that question (who can I query for this name) soon enough,
> > so why not ask it before tossing away data instead of after.
> 
> here's why i think it doesn't matter.  in my wikipedia example, there's no
> reason for me to already have a cached copy of the wikimedia.org NS RRset,
> and so i'd have to go and fetch something.  if i run off and fetch that NS
> RRset it would help me trust out-of-zone CNAME chains from wikipedia to
> wikimedia in the future, sure.  on the other hand if i run off and fetch the
> name beyond the break (the first name in wikimedia after leaving wikipedia)
> then it would help me generate the full CNAME chain from cache.  either way
> i have to go fetch something, and either way i can answer from cache
> thereafter.  there's a possible improvement if many other queries will lead
> me across the same zone boundary, but that doesn't feel like a "big deal".
> 
> so ultimately the BCP on this would just say, don't bother emitting CNAME
> chains that cross zone boundaries.  if an authority zone has a nonterminal
> CNAME in it, then the authority servers for that zone should just emit it
> and let the recursive agents of the world follow it.
> 
> sadly, this is the opposite of the advice i gave yahoo a week ago, and so i
> apologize for suggesting stub zones.  akamai, if you're listening, you ought
> to ask each of your clients for a subzone of their main domain, so that you
> can work your DNS tricks in-ballywick and cut down on the wide area DNS load.
> 
> and wikipedia, if you're listening, you should stop jumping from wikipedia.org
> to wikimedia.org, nobody's following those pointers before making an
> additional query.  to suppress that additional query, stay within a single
> zone.  jump from wikipedia.org into network.wikipedia.org or something.
> 
> i am not volunteering to write this up as a BCP, but that's what it would say.
> 
> > A properly paranoid server would certainly have to be conservative in this
> > regard, but it could save a bit of time and network I/O.  So it is an
> > optimization which might not always pan out.  If you try to further optimize
> > this check by maintaining information about the relationships between these
> > domains through a common server IP address, you definitely need to be
> > careful not to create information that behaves differently than the NS/A RRs
> > and TTLs that contribute to it.
> 
> i'm just as happy that there's no practical reason to pursue this approach,
> since it feels intuitively like a deep swamp waiting to swallow us all.
> 
> --
> to unsubscribe send a message to namedroppers-request at ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations


--