Hello Unbound devs (Wouter & team),
I'm reading [1] and see the following:
After a long time of being unwilling to sink our time into it, we're
going to implement our own DNS stub resolver. It sucks that we have to
write this code and get it to work on all platforms and lose OS
caching,
Wouldn't this be a good opportunity to suggest libunbound? Just a
thought... 
Regards,
-JP
[1] https://plus.google.com/103382935642834907366/posts/FKot8mghkok
For the record, the Chromium guy replied:
I chatted with others about what they thought about this, and we've
decided that due to the level of tinkering we want to do in DNS, we
don't want to use third party libraries here.
Topic closed. Pity.
-JP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now, that's a scary phrase. . .
Bill.
> > decided that due to the level of tinkering we want to do in DNS, we
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Now, that's a scary phrase. . .
Indeed. Catch a glimpse by launching Chrome and going to
chrome://net-internals to get a preview of the tinkering...
-JP
Nothing in the DNS section there looks that scary to me. (linux)
If you take tcpdump, you'll see it does this at startup and those 'random'-hostnames will remain to be queried (probably to
check if a dns resolver is still responding ?):
31418+ AAAA? www.google.com. (32)
31418 1/1/0 CNAME www.l.google.com. (102)
37251+ A? www.google.com. (32)
37251 7/0/0 CNAME www.l.google.com., A 173.194.65.99, A 173.194.65.104, A 173.194.65.105, A 173.194.65.147, A 173.194.65.103, A 173.194.65.106 (148)
32165+ AAAA? www.google.com. (32)
32165 1/1/0 CNAME www.l.google.com. (102)
48491+ A? www.google.com. (32)
48491 7/0/0 CNAME www.l.google.com., A 173.194.65.99, A 173.194.65.104, A 173.194.65.105, A 173.194.65.147, A 173.194.65.103, A 173.194.65.106 (148)
16721+ AAAA? ocsp.thawte.com. (33)
16721 1/0/0 CNAME ocsp.verisign.net. (64)
8453+ A? ocsp.thawte.com. (33)
8453 2/0/0 CNAME ocsp.verisign.net., A 199.7.50.72 (80)
3544+ AAAA? ocsp.thawte.com. (33)
3544 1/0/0 CNAME ocsp.verisign.net. (64)
44288+ A? ocsp.thawte.com. (33)
44288 2/0/0 CNAME ocsp.verisign.net., A 199.7.50.72 (80)
11659+ AAAA? hddbusubir.local. (34)
23847+ AAAA? egyfizszvs.local. (34)
30060+ AAAA? ibtrlsfjai.local. (34)
11659 NXDomain* 0/0/0 (34)
23847 NXDomain* 0/0/0 (34)
30060 NXDomain* 0/0/0 (34)
7555+ AAAA? egyfizszvs. (28)
47511+ AAAA? hddbusubir. (28)
2986+ AAAA? ibtrlsfjai. (28)
2986 NXDomain 0/1/0 (103)
35652+ A? ibtrlsfjai.local. (34)
35652 NXDomain* 0/0/0 (34)
38741+ A? ibtrlsfjai. (28)
38741 NXDomain 0/1/0 (103)
47511 NXDomain 0/1/0 (103)
22881+ A? hddbusubir.local. (34)
22881 NXDomain* 0/0/0 (34)
25885+ A? hddbusubir. (28)
7555 NXDomain 0/1/0 (103)
2367+ A? egyfizszvs.local. (34)
2367 NXDomain* 0/0/0 (34)
65531+ A? egyfizszvs. (28)
25885 NXDomain 0/1/0 (103)
65531 NXDomain 0/1/0 (103)
8985+ AAAA? ssl.gstatic.com. (33)
8985 0/1/0 (90)
58195+ AAAA? ssl.gstatic.com.local. (39)
58195 NXDomain* 0/0/0 (39)
53127+ A? ssl.gstatic.com. (33)
53127 1/0/0 A 173.194.65.120 (49)
48118+ AAAA? crl.geotrust.com. (34)
48118 1/1/0 CNAME crl.verisign.net. (133)
31523+ A? crl.geotrust.com. (34)
31523 2/0/0 CNAME crl.verisign.net., A 199.7.59.190 (80)
23360+ AAAA? www.gstatic.com. (33)
23360 0/1/0 (90)
1956+ AAAA? www.gstatic.com.local. (39)
1956 NXDomain* 0/0/0 (39)
18311+ A? www.gstatic.com. (33)
18311 1/0/0 A 173.194.65.120 (49)
So that is what it does already, this was with only an about:blank page.
The tinkering they want to do is mostly the timing I presume.
Leen Besselink wrote:
If you take tcpdump, you'll see it does this at startup and those
'random'-hostnames will remain to be queried (probably to check if a
dns resolver is still responding ?):
it's to detect NXDOMAIN rewriting.