server selection rewrite
- Dec 31, 2020
-
-
Vladimír Čunát authored -
Vladimír Čunát authored
Small things I've noticed while reading it all. - line breaks: I believe <90 is OK, as usually the attempts to reduce lengths impair readability - avoid unnecessary casts; usually the type was visible on the same line anyway - avoid `|` on booleans - one block gets de-indented (often badly shown in diffs) - no need for UNRECOVERABLE_ERRORS in a header (and a weird one, too) - recoverability from failed assertions (in case they're turned off)
-
Vladimír Čunát authored
- fix switched \alpha and \beta from the RFC (no big deal, I think) - use the same order as in the RFC (perhaps that caused the switch?) - avoid floating-point arithmetics (it's simple with these formulas) - simplify the the backoff formula (MINs instead of branches)
-
Vladimír Čunát authored
-
Vladimír Čunát authored
It's all because the timestamp that we're using isn't (guaranteed to be) meaningful across reboots or different machines, whereas our cache even persists by default.
-
Vladimír Čunát authored
- standardize cache key choice and ensure impossibility of collisions - comment on interaction with GC; it would be better to give RTT priority over most of other records - be more robust wrt. value in cache
-
-
- Dec 20, 2020
-
-
Štěpán Balážik authored
-
Štěpán Balážik authored
-
- Dec 18, 2020
-
-
Vladimír Čunát authored
When resolving just NS names and addresses which won't go to answers, our cache can satisfy them with just parent-side records. Now we also make iterator consistent with that, and it will cut short if a delegation satisfies what the kr_query wants. There's a general risk that we will never get the child-side records, and in practice the parent-side ones are sometimes "less accurate". This change may increase this risk (to NS addresses in particular), but we'd better consider addressing the risk later and systematically. A suggestion is to refresh the records asynchronously: https://tools.ietf.org/html/draft-ietf-dnsop-ns-revalidation --- State before this commit lead to a weird behaviour where some IPv4-only tests in Deckard (namely `iter_pcdiff.rpl`) were failing with IPv6 turned off. This was due to the resolvers' internal preference towards AAAA records for NS names. With IPv6 networking on, NS name resolution was first done for AAAA record and the glue (containing A record for the NS name in question) from parent zone was put into cache. As the AAAA resolution failed (there is no AAAA for this NS name), A was queried next and was satisfied from cache. With IPv6 off, there is no query for the AAAA record, so no A record from glue gets put in to the cache. A record is resolved first, and resolution ignores the glue in parent zone and continue to the child zone which might be broken (intentionally in the case of that `iter_pcdiff.rpl` test).
-
