Hi dnsop, it seems that OpenDNS is the first to implement RFC 6975: https://lists.dns-oarc.net/pipermail/dns-operations/2020-June/020219.html
This reminded me of its existence so I looked at definition for validating recursors: 4.2.1. Validating Recursive Resolvers A validating recursive resolver sets the DAU, DHU, and/or N3U option(s) when performing recursion based on its list of algorithms and any DAU, DHU, and/or N3U option lists in the stub client query. When the recursive server receives a query with one or more of the options set, the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. For example, if the recursive resolver's algorithm list for the DAU option is (3, 5, 7) and the stub's algorithm list is (7, 8), the final DAU algorithm list would be (3, 5, 7, 8). If the client included the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU, and/or N3U option(s) in the query, the validating recursive resolver MAY include the option(s) with its own list in full. If one or more of the options are missing, the validating recursive resolver MAY include the missing options with its own list in full. What is your opinion on: a) Sending RFC 6975 EDNS options with queries which target zone cuts which are not signed (DS provably not present in parent)? That sounds like waste of bytes, but maybe it is not worth optimizing. Opinions? b) It is not clear if/how authors took into account deduplication of queries: the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. Multiple queries from stubs can translate to a single upstream query. Typically this happens for very frequently asked names on cache miss event. E.g. many stubs ask "www.google.com AAAA" but recursor can optimize traffic upstream and send only single query to auth. Of course stub queries will likely not arrive simultaneously so the first query to auth (possibly with union of algo sets) is already in flight when second stub query (possibly with diffent set) arrives. Now what? (Section 7. Traffic Analysis Considerations shifts the problem to oneone else, but I think deduplication trick + interaction with DNS cache should be pointed out because it significantly complicates analysis.) c) Is union of sets even a good idea? Why not copy ENDS options from stub and append _another_ "instance" of options so the auth can see there are multiple parties with different set of options? d) Is there a risk of inflating queries too much/new attack vector? What about stub sending EDNS option with all alg fields present (700+ bytes)? Should there be a limit on number of algs? (I cannot see any in the RFC.) e) What should happen if multiple options are present? Answer with FORMERR? (But see questions c,d above.) Thank you for opinions! P.S. Sorry for opening this topic again, but this seems like another example of RFC which would benefit from more implementation experience prior publication. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
