These are chat archives for CZ-NIC/knot-resolver

7th
Aug 2017
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 04:45
reran same tests on unbound again, unbound only sends half as many queries and scores excellent for each rating
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 05:56
turning on 0x20 and extra hardening, about 50% more queries that kresd, but still everything ranked as excellent
Vladimír Čunát
@vcunat
Aug 07 2017 08:23
IIRC unbound default is a bit more permissive than kresd default.
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 08:54
lost entropy around 0.03 even with multiple listening addresses though
as low as 0.01
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 11:23
freebsd.org always seems to take forever to resolve when it falls out of cache.. havent seen that with other resolvers
Petr Špaček
@pspacek
Aug 07 2017 12:26
Hi @nakame_maiku_twitter . We could debug this if you provide us with a verbose log.
Vladimír Čunát
@vcunat
Aug 07 2017 12:29
It takes ~1s for me with clean cache (tried a few times); with the verbose log we would hopefully see.
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 12:30
Sure, I'll try to get something created tonight
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 12:47
Should I mail this somewhere?
I guess there aren't timestamps, but loading from browser causes it to sit for several seconds "resolving host"
Vladimír Čunát
@vcunat
Aug 07 2017 12:51
@nakame_maiku_twitter: you can mail me vladimir.cunat@nic.cz
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 12:52
drill google.com @10.10.10.10
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 60914
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; google.com.    IN    A

;; ANSWER SECTION:
google.com.    300    IN    A    172.217.24.142

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 191 msec
;; SERVER: 10.10.10.10
;; WHEN: Mon Aug  7 21:51:37 2017
;; MSG SIZE  rcvd: 44
vs
drill www.freebsd.org @10.10.10.10
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 27009
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; www.freebsd.org.    IN    A

;; ANSWER SECTION:
www.freebsd.org.    598    IN    CNAME    wfe0.ysv.freebsd.org.
wfe0.ysv.freebsd.org.    3600    IN    A    8.8.178.110

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 11387 msec
;; SERVER: 10.10.10.10
;; WHEN: Mon Aug  7 21:51:41 2017
;; MSG SIZE  rcvd: 81
sent
Vladimír Čunát
@vcunat
Aug 07 2017 13:25
Hmm, right, kresd is repeatedly failing to receive any reply to dig @63.243.194.1 DNSKEY freebsd.org +cd +dnssec. The answer packets would be 1466 Bytes, so I suspect that might be why the replies are getting dropped on your connection, though they go through on mine. (Possibly fragmented due to lower MTU on some link and then dropped by some box/firewall disliking fragmented packets.) It seems clear that kresd badly handles some of these cases - it does fall back to TCP eventually and obtains the records, but it takes long before getting to that attempt. And the dance gets repeated, as answer to www.freebsd.org is even 2228 Bytes long (!) so it's always fragmented if going over UDP...
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 13:27
hmm that dig on the server itself goes through immediately
dig @63.243.194.1 DNSKEY freebsd.org +cd +dnssec

; <<>> DiG 9.10.4-P4 <<>> @63.243.194.1 DNSKEY freebsd.org +cd +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8154
;; flags: qr aa rd cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;freebsd.org.            IN    DNSKEY

;; ANSWER SECTION:
freebsd.org.        3600    IN    DNSKEY    256 3 8 AwEAAb5tK5aTiMJNjUbu0DJUcYiYnWbb7dpq6u8E/rKXuqeVKNipZwdU zLp68B0BsMSFciykv0wax+hd41iEtRWLc2giMfsmg4druDW2y8zp+QKf DLY5/d4f3OE3/h2TSmMEi2v6yhvErgHW2EPwNHbRybRMzCWg83KvuDub 3O1NEtZ2erpJ/12QxK8caNCHoiLsLqzM/NxGfWYrMEsold1ln3h3qw5W UncX8GBKoeesrtU7KtQwgwrmJkJTMojDEZD3zVLH8AeYovQEKGloNipx uJWj2MhuFqTIdMRNFmwh+2Ktd01d+zSHhuwUHPLduruTDzrtgsF08QKP PIiFkJtZL+E=
freebsd.org.        3600    IN    DNSKEY    257 3 8 AwEAAct/17gKsM8CPmoGTd7s6XoSdgJrKj64h1FqolwfI7yl8PRpCSk8 Ewh+DX5KBE5ifACVDjKUmkMHbGUvbwU5WEOXiXEDrCmTVS1v3hW9scPP ap/20z0ApULFk6aTYVUdKkxWSR2XZ7Z8zCIkteu0/6ICVgUVHU4Yz7w2 SoUGbIr3HWHd4bxvO8kIXXgGySVhY3idNJ3W7/5LASx+6Fsyeps3Y3Er HExTM1QZfk18vpbNaM0Pd83RIc3/4XO9IZoFv4I14oXoYhZGKB0GoONP NXcMKdSm9V8lTAFk3qqn5azl6Vbz7x2ghq5gkb0GSsEyAdZiQLstXQiJ zK5ljJmBEz0=
freebsd.org.        3600    IN    DNSKEY    257 3 8 AwEAAdjRLOwObGZM6GMo8Y5bUedwXwLCvPwqBAEXjEPPc5eUzwzPnQ4X Z7Rt9htUfA1vnhVPoqZjIwGc5mNwfnPZlbdGGzGXgCL3cEOPQeJrW32P Eb7Bi4VW5YwDhJdE84e80WX2YpLGFsBk/tIrPl+Pf7kkbBJZ4k2lV4bl ls31xCbsgBdnGTRw89BwfInyd4ThRFzBX3iRBau7fNTOpcCHJIsF+41V JThvvMnAwdtjEMhD+0PDYCQ6qINKD+nhWCzeUNAy+aoT1q6iZp0XkPRX OB4qsKLgivQamE5hD4/MXc58lK5x3W3sMSL17fQHpyZSm8PC+v4h/mRV hheVK09uVak=
freebsd.org.        3600    IN    RRSIG    DNSKEY 8 2 3600 20170817180153 20170803234759 25814 freebsd.org. IlMhj1YKHbjg8vrPmZhA+g3mi7GnHjxRrvvjIgmmLTEDQDEsdHR5OnqF vYEAOSTIWOzpJplJ0jYhQEgmbp5sAj05JoTll/F/8Gvuhg14PtAZMY+L 8aXbKSTCqakTKllcDV4bad2fCf6TVCRf2L2GX1GmGb0Zf8WopwsjvtbM bxeShTH4n0xUSfRIpOaULXMtqfY4CTUtS51si+eoAWzKzjULHTkrrBtF Mb/kUfKPUp2hoPrKeod3Uv8LlHSXpKPYJX/YvndRdZ6lzWKNFI1WPFc4 m+ODvjsyal/Qsj1JVHoaQwqEJgCcwp/7YHpWv3Cut4Bg4fqvQ77lul9o ijSrHg==
freebsd.org.        3600    IN    RRSIG    DNSKEY 8 2 3600 20170817180153 20170803234759 37681 freebsd.org. Y+HhmoutGkyRt3E5yTOJ1PqVDB1PgGmD0a078XmwPsyOrn1miXqFuaLj aCrl/YV5lf+t5OqDHEoE4jYCZqP+gDZ4xVsnYQnB/MCBuiReKVzMz5WP bmsFLf6OQrIKIVtMLaQQfrpdUttYnsbqsCFHHbDUi24CjbzLeVfJV5LA Vo55cKHmU0gI0WD5VNaMrI4ejd2Dr96srjUOAOo5s4pIP82/Zz7ggQ3r DdnE6E4uIC6HQ3QR+JuS9ehBkUfJbBD99P8yKVwY8oMxGeUeVH/Gh0Sd 7AqZAIW1SUdmvAZ1Sata/QpehVCTKIg54FaJOV7eeErWgl8h5GTEN4Ui DcVoEw==

;; Query time: 66 msec
;; SERVER: 63.243.194.1#53(63.243.194.1)
;; WHEN: Mon Aug 07 22:27:41 JST 2017
;; MSG SIZE  rcvd: 1466
Vladimír Čunát
@vcunat
Aug 07 2017 13:45
That puzzles me. The log seems clear - kresd asks over UDP a few times, but all times out without getting an answer, and then it succeeds over TCP. The same also happens e.g. with dig @72.52.71.1 wfe0.ysv.freebsd.org +cd +dnssec.
Mike Emigh
@nakame_maiku_twitter
Aug 07 2017 13:52
is it possible that when kqueue is read, the full response isnt caught in a single read?
ill also try to get a tcpdump later
Vladimír Čunát
@vcunat
Aug 07 2017 17:15
I don't think that should be possible with UDP. We read it via libuv which uses recvmsg call inside - and there seems to be no possibility of a datagram being split in that API. (It could be truncated if the buffer was too small, but I see us always passing at least 64kB.)
Capturing the packets would reveal if they're lost on the way or something else happens. (I personally use wireshark.)