DNS/実装/KnotDNSresolver/query-minimization

1. DNS/実装/KnotDNSresolver/query-minimization

## 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 2015-10-11 02:51:33

MoinQ: DNS/実装/KnotDNSresolver/query-minimization

1. DNS/実装/KnotDNSresolver/query-minimization