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

18th
Feb 2019
Vladimír Čunát
@vcunat
Feb 18 07:16
It seems really weird to me to get "lost entropy" for query ID. We now use randomness generator from gnutls, so it should be pretty good. In any case, 0.19 bits of entropy is such a negligible amount. Maybe it's just a "measurement error" or something.
Georg
@teadur
Feb 18 10:54
hello
maybe someone has idea, i have knot-resolver with stub '.' pointing to some other box
now when i query knot, the request gets forwarded correctly and if i look at trace i can even see that NS and A records everything are given to knot
but for some reason knot doesnot include glue records in the response
aswell when i enabled qtrace i can see that knot gets both NS and glue records but doesnot give them to client :(
if i disable the forward of . to other box it works
but i dont really understand why it would make any difference
Georg
@teadur
Feb 18 11:02
so if anyone has idea why the additional section isnt sent to the client im all ears
Vladimír Čunát
@vcunat
Feb 18 11:06
Resolvers aren't supposed to return glue, I believe.
The point of glue is to be able to find authoritative servers. You need it if you iterate (i.e. ask authoritatives directly). If you ask a resolver, what would be the point?
Georg
@teadur
Feb 18 11:09
okey but if i ask A record directly i get no result, onyl NS records in authority section
my stub forwarding "disables" recursion and i get authoritve answer from the stub i configured sent directly to client ?
sent directly = "proxied"
Vladimír Čunát
@vcunat
Feb 18 11:11
I suppose we'll need an example. You say that the target of policy.STUB returns an A record for an A query and knot-resolver eats the A record? (i.e. doesn't pass it through)
I should stress that the target of policy.STUB should be a resolver, not an authoritative server.
Knot-resolver will take only the "interesting" records from the answer IIRC and provide cache, but otherwise it should do basically nothing to the query.
Georg
@teadur
Feb 18 11:22
vcunat: thanks for input, the problem was actualy in in the auth not knot
the auth only gave glue records not actual A records and i for some reason considered them to be same things clearly are not
but thanks for the pointers anyways
Vladimír Čunát
@vcunat
Feb 18 11:45
:-)
Fred
@Fred81_gitlab
Feb 18 20:22
Often I'm having GnuTLS decryption errors when letting Knot Resolver TLS_FORWARD to 1.1.1.1 or 9.9.9.9. Does this ring a bell?
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: SSL 3.3 Application Data packet received. Epoch 2, length: 19
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Expected Packet Application Data(23)
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (5) REC[0x5589285527f0]: Received Packet Application Data(23) with length: 19
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../../../lib/accelerated/x86/aes-gcm-x86-pclmul-avx.c[aesni_gcm_aead_decrypt]:351
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/crypto-api.c[gnutls_aead_cipher_decrypt]:714
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/cipher.c[decrypt_packet_tls13]:873
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/cipher.c[_gnutls_decrypt]:160
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1468
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (1) Discarded message[2] due to invalid decryption
Feb 18 21:05:20 piranha kresd[6366]: [gnutls] (3) ASSERT: ../../lib/record.c[_gnutls_recv_int]:1766
Feb 18 21:05:20 piranha kresd[6366]: [tls_client] gnutls_record_recv failed: GNUTLS_E_DECRYPTION_FAILED (-24)
Vladimír Čunát
@vcunat
Feb 18 21:22
No, I don't think I've ever seen that.
Vladimír Čunát
@vcunat
Feb 18 21:30
I see you reported it at gnutls: gnutls/gnutls#707