Subject: another out-of-zone cname question-- anti-aliasing of zone servers?

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Apr 2006 17:47:03 +0000

"dig en.wikipedia.org a" retrieves from the wikipedia.org authority server
the following out-of-zone cname chain:

    ;; ANSWER SECTION:
    en.wikipedia.org.       3600    IN      CNAME   rr.wikimedia.org.
    rr.wikimedia.org.       600     IN      CNAME   rr.pmtpa.wikimedia.org.
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.202
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.245
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.246
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.206
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.203
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.236
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.210
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.214
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.235
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.247
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.213
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.205
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.204
    rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.248

because the second and subsequent ownernames are outside the wikipedia.org
zone, they are thrown away by at least one modern paranoid resolver, since
this is the same mechanism that would be used to poison a cache with phish
data (like a www.bankofamerica.com name).

i don't blame wikipedia for trying this, since it's also what virtually all
akamaized services do.  check "www.yahoo.com" or "www.microsoft.com" for
examples.  what this causes is an extra query from the resolver to the zone
authority of each out-of-zone cname target.

    ;; ANSWER SECTION:
    www.yahoo.com.          300     IN      CNAME   www.yahoo.akadns.net.
    www.yahoo.akadns.net.   60      IN      A       66.94.230.41
    www.yahoo.akadns.net.   60      IN      A       66.94.230.39
    www.yahoo.akadns.net.   60      IN      A       66.94.230.49
    www.yahoo.akadns.net.   60      IN      A       66.94.230.42
    www.yahoo.akadns.net.   60      IN      A       66.94.230.36
    www.yahoo.akadns.net.   60      IN      A       66.94.230.47
    www.yahoo.akadns.net.   60      IN      A       66.94.230.46
    www.yahoo.akadns.net.   60      IN      A       66.94.230.44

    ;; ANSWER SECTION:
    www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.
    toggle.www.ms.akadns.net. 300   IN      CNAME   g.www.ms.akadns.net.
    g.www.ms.akadns.net.    300     IN      CNAME   lb1.www.ms.akadns.net.
    lb1.www.ms.akadns.net.  300     IN      A       207.46.20.60
    lb1.www.ms.akadns.net.  300     IN      A       207.46.19.60
    lb1.www.ms.akadns.net.  300     IN      A       207.46.225.60
    lb1.www.ms.akadns.net.  300     IN      A       207.46.199.30
    lb1.www.ms.akadns.net.  300     IN      A       207.46.19.30
    lb1.www.ms.akadns.net.  300     IN      A       207.46.20.30
    lb1.www.ms.akadns.net.  300     IN      A       207.46.198.30
    lb1.www.ms.akadns.net.  300     IN      A       207.46.198.60

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"?

if we should do this, it will save on backbone and overall DNS traffic, but
it will mean we have to think very hard about the ways in which other NS RRs
get into our cache.  (since they will override some current paranoia logic.)

if we should not do this, then wikipedia should put all of its infrastructure
under the main (wikipedia.org) name and not switch to wikimedia.org (note the
"m" rather than the "p") and akamai's customers should allocate .akamai
subdomains of their .com names, still served by akamai but semantically "part
of" the zone that the most common queries in the universe are all asking for.

either way it's probably time for a BCP document on this kind of processing.

i'm especially interested in DJB's perspective on this issue.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Emilio Perea <[email-masked]>
Date: Mon, 3 Apr 2006 13:34:47 -0500

> authority of each out-of-zone cname target.

With all due respect (which in this case is a great deal) why should
wikipedia, yahoo and microsoft not be blamed for this abomination?

---

From: bert hubert <[email-masked]>
Date: Mon, 3 Apr 2006 20:46:33 +0200

> the following out-of-zone cname chain:

They run PowerDNS with the GEO IP backend, btw (which was written by a
Wikipedian, Mark Bergsma).

>     rr.pmtpa.wikimedia.org. 3600    IN      A       207.142.131.245

Here is what it answers here:

;; ANSWER SECTION:
en.wikipedia.org.       3600    IN      CNAME   rr.wikimedia.org.
rr.wikimedia.org.       600     IN      CNAME   rr.knams.wikimedia.org.
rr.knams.wikimedia.org. 300     IN      A       145.97.39.155

The 'ams' stands for Amsterdam.

> data (like a www.bankofamerica.com name).

The data is also discarded by the powerdns recursor (which I'd like to call
modern & paranoid). Output of --trace query for en.wikipedia.org from a cold
cache, taking 5 packets in total. I've > quoted the lines that reject the
wikimedia.org data:

question for 'en.wikipedia.org|A' from 127.0.0.1
en.wikipedia.org: Looking for CNAME cache hit of 'en.wikipedia.org|CNAME'
en.wikipedia.org: No CNAME cache hit of 'en.wikipedia.org|CNAME' found
en.wikipedia.org: Looking for direct cache hit of 'en.wikipedia.org|A', negative cached: 0
en.wikipedia.org: No cache hit for 'en.wikipedia.org|A', trying to find an appropriate NS record
en.wikipedia.org: Checking if we have NS in cache for 'en.wikipedia.org'
en.wikipedia.org: Checking if we have NS in cache for 'wikipedia.org'
en.wikipedia.org: Checking if we have NS in cache for 'org'
en.wikipedia.org: Checking if we have NS in cache for ''
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'a.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'b.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'c.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'd.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'e.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'f.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'g.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'h.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'i.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'j.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'k.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'l.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'm.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'a.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'b.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'c.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'd.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'e.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'f.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'g.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'h.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'i.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'j.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'k.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'l.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'm.root-servers.net'
en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999
en.wikipedia.org: We have NS in cache for ''
en.wikipedia.org: Cache consultations done, have 13 NS to contact
en.wikipedia.org: Nameservers: j.root-servers.net(0ms), g.root-servers.net(0ms), e.root-servers.net(0ms), h.root-servers.net(0ms), 
en.wikipedia.org:              m.root-servers.net(0ms), i.root-servers.net(0ms), f.root-servers.net(0ms), b.root-servers.net(0ms), 
en.wikipedia.org:              l.root-servers.net(0ms), d.root-servers.net(0ms), c.root-servers.net(0ms), a.root-servers.net(0ms), 
en.wikipedia.org:              k.root-servers.net(6ms)
en.wikipedia.org: Trying to resolve NS j.root-servers.net (1/13)
  j.root-servers.net: Looking for CNAME cache hit of 'j.root-servers.net|CNAME'
  j.root-servers.net: No CNAME cache hit of 'j.root-servers.net|CNAME' found
  j.root-servers.net: Looking for direct cache hit of 'j.root-servers.net|A', negative cached: 0
  j.root-servers.net: Found cache hit for A: 192.58.128.30[ttl=3599999] 
en.wikipedia.org: Resolved '' NS j.root-servers.net to 192.58.128.30, asking 'en.wikipedia.org|A'
en.wikipedia.org: Got 12 answers from j.root-servers.net (192.58.128.30), rcode=0, in 192ms
en.wikipedia.org: accept answer 'org|NS|TLD1.ULTRADNS.NET.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'org|NS|TLD2.ULTRADNS.NET.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'org|NS|TLD3.ULTRADNS.org.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'org|NS|TLD4.ULTRADNS.org.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'org|NS|TLD5.ULTRADNS.INFO.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'org|NS|TLD6.ULTRADNS.CO.UK.' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD1.ULTRADNS.NET|A|204.74.112.1' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD2.ULTRADNS.NET|A|204.74.113.1' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD3.ULTRADNS.org|A|199.7.66.1' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD4.ULTRADNS.org|A|199.7.67.1' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD5.ULTRADNS.INFO|A|192.100.59.11' from '' nameservers? YES!
en.wikipedia.org: accept answer 'TLD6.ULTRADNS.CO.UK|A|198.133.199.11' from '' nameservers? YES!
en.wikipedia.org: determining status after receiving this packet
en.wikipedia.org: got NS record 'org' -> 'TLD1.ULTRADNS.NET.'
en.wikipedia.org: got NS record 'org' -> 'TLD2.ULTRADNS.NET.'
en.wikipedia.org: got NS record 'org' -> 'TLD3.ULTRADNS.org.'
en.wikipedia.org: got NS record 'org' -> 'TLD4.ULTRADNS.org.'
en.wikipedia.org: got NS record 'org' -> 'TLD5.ULTRADNS.INFO.'
en.wikipedia.org: got NS record 'org' -> 'TLD6.ULTRADNS.CO.UK.'
en.wikipedia.org: status=did not resolve, got 6 NS, looping to them
en.wikipedia.org: Nameservers: tld4.ultradns.org(0ms), tld3.ultradns.org(0ms), tld6.ultradns.co.uk(0ms), tld2.ultradns.net(0ms), 
en.wikipedia.org:              tld5.ultradns.info(0ms), tld1.ultradns.net(0ms)
en.wikipedia.org: Trying to resolve NS tld4.ultradns.org (1/6)
  tld4.ultradns.org: Looking for CNAME cache hit of 'tld4.ultradns.org|CNAME'
  tld4.ultradns.org: No CNAME cache hit of 'tld4.ultradns.org|CNAME' found
  tld4.ultradns.org: Looking for direct cache hit of 'tld4.ultradns.org|A', negative cached: 0
  tld4.ultradns.org: Found cache hit for A: 199.7.67.1[ttl=172800] 
en.wikipedia.org: Resolved 'org' NS tld4.ultradns.org to 199.7.67.1, asking 'en.wikipedia.org|A'
en.wikipedia.org: Got 6 answers from tld4.ultradns.org (199.7.67.1), rcode=0, in 23ms
en.wikipedia.org: accept answer 'wikipedia.org|NS|ns2.wikimedia.org.' from 'org' nameservers? YES!
en.wikipedia.org: accept answer 'wikipedia.org|NS|ns1.wikimedia.org.' from 'org' nameservers? YES!
en.wikipedia.org: accept answer 'wikipedia.org|NS|ns0.wikimedia.org.' from 'org' nameservers? YES!
en.wikipedia.org: accept answer 'ns2.wikimedia.org|A|145.97.39.158' from 'org' nameservers? YES!
en.wikipedia.org: accept answer 'ns1.wikimedia.org|A|207.142.131.208' from 'org' nameservers? YES!
en.wikipedia.org: accept answer 'ns0.wikimedia.org|A|207.142.131.207' from 'org' nameservers? YES!
en.wikipedia.org: determining status after receiving this packet
en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns2.wikimedia.org.'
en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns1.wikimedia.org.'
en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns0.wikimedia.org.'
en.wikipedia.org: status=did not resolve, got 3 NS, looping to them
en.wikipedia.org: Nameservers: ns2.wikimedia.org(0ms), ns0.wikimedia.org(0ms), ns1.wikimedia.org(0ms)
en.wikipedia.org: Trying to resolve NS ns2.wikimedia.org (1/3)
  ns2.wikimedia.org: Looking for CNAME cache hit of 'ns2.wikimedia.org|CNAME'
  ns2.wikimedia.org: No CNAME cache hit of 'ns2.wikimedia.org|CNAME' found
  ns2.wikimedia.org: Looking for direct cache hit of 'ns2.wikimedia.org|A', negative cached: 0
  ns2.wikimedia.org: Found cache hit for A: 145.97.39.158[ttl=86400] 
en.wikipedia.org: Resolved 'wikipedia.org' NS ns2.wikimedia.org to 145.97.39.158, asking 'en.wikipedia.org|A'
en.wikipedia.org: Got 3 answers from ns2.wikimedia.org (145.97.39.158), rcode=0, in 10ms
en.wikipedia.org: accept answer 'en.wikipedia.org|CNAME|rr.wikimedia.org.' from 'wikipedia.org' nameservers? YES!

> en.wikipedia.org: accept answer 'rr.wikimedia.org|CNAME|rr.knams.wikimedia.org.' from 'wikipedia.org' nameservers? NO!
> en.wikipedia.org: accept answer 'rr.knams.wikimedia.org|A|145.97.39.155' from 'wikipedia.org' nameservers? NO!

en.wikipedia.org: determining status after receiving this packet
en.wikipedia.org: status=got a CNAME referral, starting over with rr.wikimedia.org
rr.wikimedia.org: Looking for CNAME cache hit of 'rr.wikimedia.org|CNAME'
rr.wikimedia.org: No CNAME cache hit of 'rr.wikimedia.org|CNAME' found
rr.wikimedia.org: Looking for direct cache hit of 'rr.wikimedia.org|A', negative cached: 0
rr.wikimedia.org: No cache hit for 'rr.wikimedia.org|A', trying to find an appropriate NS record
rr.wikimedia.org: Checking if we have NS in cache for 'rr.wikimedia.org'
rr.wikimedia.org: Checking if we have NS in cache for 'wikimedia.org'
rr.wikimedia.org: Checking if we have NS in cache for 'org'
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld1.ultradns.net'
rr.wikimedia.org: within bailiwick: 0, not in cache
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld2.ultradns.net'
rr.wikimedia.org: within bailiwick: 0, not in cache
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld3.ultradns.org'
rr.wikimedia.org: within bailiwick: 1, in cache, ttl=172800
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld4.ultradns.org'
rr.wikimedia.org: within bailiwick: 1, in cache, ttl=172800
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld5.ultradns.info'
rr.wikimedia.org: within bailiwick: 0, not in cache
rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld6.ultradns.co.uk'
rr.wikimedia.org: within bailiwick: 0, not in cache
rr.wikimedia.org: We have NS in cache for 'org'
rr.wikimedia.org: Cache consultations done, have 6 NS to contact
rr.wikimedia.org: Nameservers: tld3.ultradns.org(0ms), tld5.ultradns.info(0ms), tld6.ultradns.co.uk(0ms), tld2.ultradns.net(0ms), 
rr.wikimedia.org:              tld1.ultradns.net(0ms), tld4.ultradns.org(11ms)
rr.wikimedia.org: Trying to resolve NS tld3.ultradns.org (1/6)
  tld3.ultradns.org: Looking for CNAME cache hit of 'tld3.ultradns.org|CNAME'
  tld3.ultradns.org: No CNAME cache hit of 'tld3.ultradns.org|CNAME' found
  tld3.ultradns.org: Looking for direct cache hit of 'tld3.ultradns.org|A', negative cached: 0
  tld3.ultradns.org: Found cache hit for A: 199.7.66.1[ttl=172800] 
rr.wikimedia.org: Resolved 'org' NS tld3.ultradns.org to 199.7.66.1, asking 'rr.wikimedia.org|A'
rr.wikimedia.org: Got 6 answers from tld3.ultradns.org (199.7.66.1), rcode=0, in 92ms
rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns2.wikimedia.org.' from 'org' nameservers? YES!
rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns1.wikimedia.org.' from 'org' nameservers? YES!
rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns0.wikimedia.org.' from 'org' nameservers? YES!
rr.wikimedia.org: accept answer 'ns2.wikimedia.org|A|145.97.39.158' from 'org' nameservers? YES!
rr.wikimedia.org: accept answer 'ns1.wikimedia.org|A|207.142.131.208' from 'org' nameservers? YES!
rr.wikimedia.org: accept answer 'ns0.wikimedia.org|A|207.142.131.207' from 'org' nameservers? YES!
rr.wikimedia.org: determining status after receiving this packet
rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns2.wikimedia.org.'
rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns1.wikimedia.org.'
rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns0.wikimedia.org.'
rr.wikimedia.org: status=did not resolve, got 3 NS, looping to them
rr.wikimedia.org: Nameservers: ns0.wikimedia.org(0ms), ns1.wikimedia.org(0ms), ns2.wikimedia.org(5ms)
rr.wikimedia.org: Trying to resolve NS ns0.wikimedia.org (1/3)
  ns0.wikimedia.org: Looking for CNAME cache hit of 'ns0.wikimedia.org|CNAME'
  ns0.wikimedia.org: No CNAME cache hit of 'ns0.wikimedia.org|CNAME' found
  ns0.wikimedia.org: Looking for direct cache hit of 'ns0.wikimedia.org|A', negative cached: 0
  ns0.wikimedia.org: Found cache hit for A: 207.142.131.207[ttl=86400] 
rr.wikimedia.org: Resolved 'wikimedia.org' NS ns0.wikimedia.org to 207.142.131.207, asking 'rr.wikimedia.org|A'
rr.wikimedia.org: Got 2 answers from ns0.wikimedia.org (207.142.131.207), rcode=0, in 126ms
rr.wikimedia.org: accept answer 'rr.wikimedia.org|CNAME|rr.knams.wikimedia.org.' from 'wikimedia.org' nameservers? YES!
rr.wikimedia.org: accept answer 'rr.knams.wikimedia.org|A|145.97.39.155' from 'wikimedia.org' nameservers? YES!
rr.wikimedia.org: determining status after receiving this packet
rr.wikimedia.org: status=got a CNAME referral, starting over with rr.knams.wikimedia.org
rr.knams.wikimedia.org: Looking for CNAME cache hit of 'rr.knams.wikimedia.org|CNAME'
rr.knams.wikimedia.org: No CNAME cache hit of 'rr.knams.wikimedia.org|CNAME' found
rr.knams.wikimedia.org: Looking for direct cache hit of 'rr.knams.wikimedia.org|A', negative cached: 0
rr.knams.wikimedia.org: Found cache hit for A: 145.97.39.155[ttl=300] 
en.wikipedia.org: Starting additional processing
en.wikipedia.org: Done with additional processing
answer to question 'en.wikipedia.org|A': 3 answers, 0 additional, took 5 packets, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0

> question, so it is allowed to give me this out-of-zone data"?

I've pondered this and decided to waste a few packets on not complicating my
nameserver. Yes, the recursor *might* now that the IP address it sent the
question to has previously also been known to be authoritative for the
wikimedia.org domain, but try figuring that out in a timely manner.

It requires lots and lots of memory. Also note that the people who 'suffer'
from this negligence are in part the same people that cause it. 

By the way, I hope you aren't telling me Bind *does* accept the answers the
'modern & paranoid' recursor rejects? How can that be secure?

> of" the zone that the most common queries in the universe are all asking for.

Sure. However, most DNS traffic I emit is caused by lame or broken servers.

> i'm especially interested in DJB's perspective on this issue.

I think I modelled the pdns_recursor pretty closely on his (brilliant)
paranoia. 

DJBDNS is pretty hard to beat as a recursor, and I should know, I've been
working on it for a month now.

	Bert.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Apr 2006 19:01:11 +0000

> 'modern & paranoid' recursor rejects? How can that be secure?

not at all.  bind is perfectly modern and paranoid in this respect.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Apr 2006 19:01:56 +0000

> wikipedia, yahoo and microsoft not be blamed for this abomination?

perhaps because i recommended stub zones as a solution to what yahoo and
microsoft were emitting up 'til last week, i feel that they deserve the
benefit of the doubt on the matter.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 03 Apr 2006 15:08:39 -0400

>wikipedia, yahoo and microsoft not be blamed for this abomination?

Because the server in question is trying to be helpful and save
round trips.

<chair-hat=off>
IMHO fundamental problem here is
#1. that the RFC1034/5 does not exploit say
that a server MUST NOT execute the CNAME algorithm when the CNAME chain
crosses zone boundary.

#2 The CNAME processing is split between the authorative server and
the recursive resolver. If all the work was supposed to be done by the
recursive resolver we would not have the possibility of a cache poisoning
in this case.

In this case my reading of the scriptures is different from what I think
is a safe behavior and recursors should fetch all data from authorative
sources, including the second and subsequent CNAME's if there is a
possibility the CNAME is from a different zone than the preceding CNAME.

         Olafur

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 03 Apr 2006 17:08:05 -0400

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

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.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Apr 2006 21:29:21 +0000

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Apr 2006 09:36:41 +1000

The fix is to fully deploy DNSSEC then each RRset in the answer
	can be independently be validated.  You do then get the savings.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Apr 2006 01:04:46 +0000

> 	can be independently be validated.  You do then get the savings.

well, if boiling the ocean is an option, then let's fully deploy BCP38 which
would be a lot less complicated than fully deploying DNSSEC-bis.  but since
boiling the ocean is out of scope for this moment in time, we probably do need
a BCP telling what to do with out-of-zone CNAMEs, both on transmission and on
reception.

---

From: bert hubert <[email-masked]>
Date: Tue, 4 Apr 2006 07:53:02 +0200

> 	can be independently be validated.  You do then get the savings.

You honestly believe that? You'd have far larger packets to carry the RRSIGs
and additional packets to walk the authentication chain. 

	Bert

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Apr 2006 09:18:12 +0200

On Mon, Apr 03, 2006 at 01:34:47PM -0500,
 Emilio Perea <[email-masked]> wrote 

> wikipedia, yahoo and microsoft not be blamed for this abomination?

Because it is BIND's default behavior when it is authoritative for the
two zones? (And rightly so, IMHO, even if it is quite useless since
the resolver may not know that we are authoritative.)

Check the A record of www.afnic.fr on ns{1,2,3}.nic.fr (ns1 and ns3
are BIND, ns2 is nsd) and appreciate the difference (all three
nameservers are authoritative both for nic.fr and afnic.fr). If you
blame Microsoft, you have to blame us as well :-)

---

From: Ketil Froyn <[email-masked]>
Date: Tue, 04 Apr 2006 11:27:25 +0200

> and let the recursive agents of the world follow it.

Interestingly, tinydns doesn't "recurse" CNAME chains at all. Here's an 
example:

dig @a.ns.froyn.name cname.ketil.froyn.name
dig @a.ns.froyn.name tst.ketil.froyn.name

This simplifies the authoritative server, it doesn't transmit more than 
necessary (for instance, the CNAME target might be cached already), and 
as a result it acts like you recommend for CNAMEs across zone boundaries.

Ketil Froyn
[email-masked]
http://ketil.froyn.name/

---

From: Florian Weimer <[email-masked]>
Date: Tue, 04 Apr 2006 14:09:00 +0200

> question, so it is allowed to give me this out-of-zone data"?

There could be a zone cut somewhere, so you can't really know that the
name servers are the same even if you've cached a matching NS RR for a
parent zone.  If you require exact knowledge of the delegation, I
don't think the additional caching logic will buy you much in terms of
performance.

I don't know if agressive caching (potentially stomping over zone
boundaries) is a problem in this case, but it feels wrong (but still
being ill, a lot feels wrong 8-/).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Apr 2006 16:22:50 +0200

On Mon, Apr 03, 2006 at 07:01:11PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 11 lines which said:

> > I hope you aren't telling me Bind *does* accept the answers the

Examining the queries received by our BIND nameserver ns3.nic.fr
(which is authoritative for both nic.fr and afnic.fr and therefore
send out-of-zone replies when queried for www.afnic.fr), I notice that
one third of queries for www.afnic.fr are *not* followed by a query
for rigolo.nic.fr, the canonical name.

We can conclude that one third of the resolvers in the wild are not
paranoid enough? Or that BIND (and may be others) nameservers which
try to be helpful by following out-of-zone CNAME work for only one
third of their clients?

---

From: bert hubert <[email-masked]>
Date: Tue, 4 Apr 2006 16:42:43 +0200

> for rigolo.nic.fr, the canonical name.

They might still have it in the cache - records have a way of not expiring
in sync.

$ dig rigolo.nic.fr @127.0.0.1 -p 5300

;; QUESTION SECTION:
;rigolo.nic.fr.                 IN      A

;; ANSWER SECTION:
rigolo.nic.fr.          172800  IN      A       192.134.4.20

$ dig www.afnic.fr @127.0.0.1 -p 5300

;; QUESTION SECTION:
;www.afnic.fr.                  IN      A

;; ANSWER SECTION:
www.afnic.fr.           172800  IN      CNAME   rigolo.nic.fr.
rigolo.nic.fr.          172792  IN      A       192.134.4.20

---

From: David Blacka <[email-masked]>
Date: Tue, 4 Apr 2006 10:43:26 -0400

> that a server MUST NOT execute the CNAME algorithm when the CNAME  

I think that 1034 *implicitly* says the opposite, actually.

> recursive resolver we would not have the possibility of a cache  

Agreed.

> possibility the CNAME is from a different zone than the preceding  

I am thinking that, in this case, 1034 is now essentially out-of- 
date.  Since it has become apparent over the years that modern (and  
properly paranoid) resolvers must ignore CNAME targets that appear to  
be out of zone, then it makes no sense for authoritative servers to  
continue to follow CNAMEs out of zone when constructing responses.   
Although, OTOH, those authoritative servers that do so are (for the  
most part) just wasting time and bandwidth.

So, at the moment, I am thinking that the new rules should be:

1. Authoritative servers SHOULD not follow CNAME chains across zone  
boundaries, and MAY choose to not follow CNAME chains at all (which,  
I gather, is tinydns' behavior).

2. Recursive resolvers MUST ignore CNAME targets that appear to be  
outside the zone of the response.

Although, I am curious about how resolvers actually go about  
implementing #2.  I suppose that it would be quite easy to always  
ignore CNAME targets in responses (that is, always issue a query- 
restart for the target of the first CNAME).  However, if you wanted  
to allow in zone CNAME chains to be returned, the resolver would need  
a rule that described which CNAMEs to accept and which to ignore (or  
discard).  The best rule that I could come up with was:

    Let Z be the name of the last referral followed.
    Then ignore CNAMEs whose ownernames are not at or below Z, and  
ignore any following CNAMEs.

This doesn't exactly equate to ignore all "out of zone" CNAMEs since  
a CNAME could be in a child zone, but I think it is good enough --  
based on the principle that if your parent is trying to poison you,  
you are doomed anyway.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Ketil Froyn <[email-masked]>
Date: Tue, 04 Apr 2006 16:44:29 +0200

Stephane Bortzmeyer wrote:

> paranoid enough?

Wouldn't surprise me, actually. Has anyone done research on software 
versions that are running in the wild and compared that to software 
versions that are known to be susceptible to poisoning?

Stephane, it would be interesting if you could check your logs and see 
if the name servers that _didn't_ follow up with a query for 
rigolo.nic.fr had queried that name already within the TTL, before the 
query for www.afnic.fr appeared (ie. it was cached already).

Ketil Froyn
[email-masked]
http://ketil.froyn.name/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Apr 2006 17:08:53 +0200

On Tue, Apr 04, 2006 at 04:42:43PM +0200,
 bert hubert <[email-masked]> wrote 
 a message of 29 lines which said:

> They might still have it in the cache - records have a way of not
> expiring in sync.

Since the two records have the same TTL, I believe it is unlikely. (In
your example, you explicitely queried rigolo.nic.fr first, something
that the typical Web browser does not do.)

---

From: bert hubert <[email-masked]>
Date: Tue, 4 Apr 2006 17:17:58 +0200

> that the typical Web browser does not do.)

sure - but perhaps other hosts CNAME to rigolo.nic.fr?

---

From: Chris Thompson <[email-masked]>
Date: Tue, 4 Apr 2006 16:24:54 +0100 (BST)

> that the typical Web browser does not do.)

"Caching nameserver being used by the typical Web browser", surely?

There's also the possibility that the subsequent requests for 
rigolo.nic.fr went to a different authoritative nameserver - that 
is, assuming you weren't correlating the logs for all seven of them?

-- 
Chris Thompson
Email: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Apr 2006 17:27:34 +0200

On Tue, Apr 04, 2006 at 05:17:58PM +0200,
 bert hubert <[email-masked]> wrote 
 a message of 13 lines which said:

> perhaps other hosts CNAME to rigolo.nic.fr?

No, I checked. (Only very unused names like www.nic.yt that no one
knows.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Apr 2006 17:30:05 +0200

On Tue, Apr 04, 2006 at 04:24:54PM +0100,
 Chris Thompson <[email-masked]> wrote 
 a message of 22 lines which said:

> rigolo.nic.fr went to a different authoritative nameserver

That's why I tried on ns3, which has a very distinctive Internet
connection (unlike ns1 and ns2 which are in the same room) so I
believe there is little chance that a resolver switched. (And, anyway,
switching nameservers could as well produce the opposite effect.)

> assuming you weren't correlating the logs for all seven of them?

No, I wasn't.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Apr 2006 09:07:05 -0700

This is pretty much/exactly what my previous message is urging.

At 10:43 -0400 4/4/06, David Blacka wrote:

>ignore CNAME targets in responses (that is, always issue a 
>query-restart for the target of the first CNAME).  However, if you 
>wanted to allow in zone CNAME chains to be returned, the resolver 
>would need a rule that described which CNAMEs to accept and which to 
>ignore (or discard).  The best rule that I could come up with was:

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Apr 2006 09:03:30 -0700

>and let the recursive agents of the world follow it.

Why not make it easier by saying that a resolver ought to ignore 
anything that is "not obviously" in the same zone as the qname?  Let 
servers continue to run the old way (as we don't have a means to do 
field upgrades of old versions), just recommend that new resolvers be 
more conservative.  (But we don't want to pressure stub resolvers 
into having to iterate CNAMEs.)

There's gonna be tradeoffs between sound protocol engineering and 
operational load.  I.e., if I had to do it, I would not let any 
server "chase" a CNAME, just return the CNAME to the querier and let 
the querier restart the operation.  This is cleaner from a protocol 
engineering point of view but leads to worst case traffic load. 
OTOH, if we keep slapping on rules to lower the operational traffic 
load, we are 1) complicating the servers and 2) changing the servers. 
The latter means implementation/deployment churn which may be worse 
than just buying bigger pipes.  (Which is what the ISP operators keep 
telling us, funny, huh?)

>can work your DNS tricks in-ballywick and cut down on the wide area DNS load.

This isn't a "told-you-so" in any sense, but flipping between 
recommendations is a sign that the problem really is in a trade-off 
state.  Some problems are destined not to be decided "correctly" so 
we have to live with compromises.

We're bound to stay in this state until someone comes up with a load 
balancing solution that is not DNS but is as scaleable as the DNS. 
E.g., something ought to be designed that converts a web site name 
(as opposed to a domain name) into a domain name based on load 
considerations.  This conversion has to happen between the web 
browser and the stub resolver it uses, not afterwards, if we are to 
break out of this state.

The DNS isn't dying from this, it's being used outside its design parameters.

>since it feels intuitively like a deep swamp waiting to swallow us all.

I prefer to think of it as job security. ;)

---

From: bert hubert <[email-masked]>
Date: Tue, 4 Apr 2006 18:19:36 +0200

> switching nameservers could as well produce the opposite effect.)

I seem to recall older versions of Bind had more complex 'trust rules' which
might allow it to 'benefit' from the records other nameservers ignore.
Perhaps some people here remember.

1:3 seems plausible for bind 8, although I don't know how bind 8 treats
these answers.

1:3 might also be plausible for any Microsoft product.

	Bert.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Apr 2006 11:19:35 +0200

On Tue, Apr 04, 2006 at 09:03:30AM -0700,
 Edward Lewis <[email-masked]> wrote 
 a message of 61 lines which said:

> operational load.

"load" is too vague. I am not really worried about the number of bytes
that fly through the network, but I'm more concerned with the extra
round-trip time if the resolver has to wait for a reply, then do
another one.

And, before you ask, no, I do not have an algorithm for the resolver
to find out if the extra out-of-zone answer is safe or not (in the
case of our www.afnic.fr, the out-of-zone answer *is* safe because the
same nameserver is authoritative for both domains; so, it is
out-of-zone but not out-of-responsability. The trick is to formalize
it.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Apr 2006 11:43:13 -0000

Out-of-zone chaining sometimes breaks service (because the chains become
so long that resolvers give up), often causes extra delays for DNS
resolvers, and often causes delays visible to users.

Out-of-zone chaining can always be eliminated by proper configuration on
the server side. The server provides the IP addresses instead of forcing
the client to go chasing the IP addresses around the Internet.

> "even though the

That can be made secure, and would eliminate _some_ of the damage caused
by out-of-zone chaining, but having the server do the right thing would
produce much larger benefits for less effort.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

---

From: Paul Vixie <[email-masked]>
Date: Thu, 06 Apr 2006 17:08:13 +0000

> Perhaps some people here remember.

i remember nothing like that.

> 1:3 seems plausible for bind 8, although I don't know how bind 8 treats

bind8 will throw away out-of-zone cnames, and behave iteratively at the point
of the zone crossing.

> 1:3 might also be plausible for any Microsoft product.

clarifying this thread's role on namedroppers, here's my understanding.

any followups specific to bind belong on [email-masked].

any followups concerning operational issues like "why do some folks only
query for the initial name and fail to iterate at the point of the zone
crossing?" belong on [email-masked], where stephane has
already begun discussing his original point.