Moin, > 1) The one mentioned in the draft where only a subset of resolvers > have the ability to resolve for each address family. This is > certainly a problem of its own -- I wonder how well various stub > resolvers deal with this? Having different partial connectivity from > different stub resolvers but configured as the same may confuse some > of the stub resolvers and will cause performance issues. I'm > unconvinced that having a subset of them dual-stacked is good enough > to avoid problems, as many stubs aren't good with handling cases > where their recursive resolvers have partial functionality.
This should be something that can be relatively exhaustively measured with a bunch of implementations. Sounds like an ideal student project to me. I will try to keep that in mind when an opportunity comes by. > 2) The one I'm raising where it is important to make sure the client > receives at least one recursive resolver its stub resolver or stub > library can reach is separate/distinct. This isn't covered in the > current draft, but I agree that it is messy enough that it is likely > hard to cover with just a small update here. (I'm actually not sure > there is a heuristic that always works.) I think this should start out with an informational draft outlining the problem; This will likely get some of the messy-ness out, and might lead to a good recommendation. Let me mark this thread as 'unread', so i remember to setup a skeleton structure for an I-D. With best regards, Tobias -- Univ.Prof. Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
