== DNS/実装/KnotDNSresolver/query-minimization == https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-06 https://tools.ietf.org/html/draft-wkumari-dnsop-hammer-01 [[/zone-cut-memory]] [[/badCDN]] ---- https://gist.github.com/vavrusa/c3e24deb1dbbd4538034 {{{ ## How it deals with bad CDNs The query is `who.ami.here.com. A` 1. It's going to ask at `.` to `com. NS` and get a referral 2. it's going to ask `com.` nameserver about `here.com. NS` and get a referral ... see the pattern, it just appends labels, but bear with me 3. We're asking `here.com` nameserver about `ami.here.com. NS` , but he's a prick and tells us 'NXDOMAIN'. In real world, we **would** know that there is nothing at or below it, but with some CDNs it's **a lie**. }}} いまでもこんなことをするところがあるのですかねえ。　googleではなさそうです。 https://tools.ietf.org/html/rfc2308 {{{ So we turn off the minimization and requery the full name `who.ami.here.com A`, now it's going to either refer us to final nameserver or give us `NXDOMAIN` again. If (a), we leaked some information to the parent nameserver, if (b) it was reliable and we wasted an extra query. In real world it doesn't happen that often since `NS com.` is authoritative for `<1-2 labels>.com` etc., but it happens with CDNs where you suddenly jump 2 or more labels. }}} {{{ ## How does it deal with a truckload of labels (IPv6 PTR records) Fortunately, since root nameservers give us an authoritative answer to `arpa.`, we turn off minimization afterwards. Yes, this leaks information to `arpa.`. Most of the names with many labels don't actually have search path this long (it often jumps several labels per referral), or end up covered by a wildcard. In any way, you need to follow the referral chain anyway even if you don't minimize. }}} [[/www.toyota.jp]] amazon の返事がおかしい。 -- ToshinoriMaeno <>