This is a discussion on Re: XQID (Re: Forgery Resistance phase #2 ) - DNS ; > I'm actually not too sure of whether a 'mix and match to your hearts > content' approach is what we should be trying to achieve here. Although > that might make debugging problems so insanely difficult that switching > ...
> I'm actually not too sure of whether a 'mix and match to your hearts
> content' approach is what we should be trying to achieve here. Although
> that might make debugging problems so insanely difficult that switching
> to DNSSEC will be a relief
tkey+tsig, or dnssec+sig(0), or vpn, should be considered equivilent. that
has been my basic gripe with bert's draft on forgery resilience -- it mandates
a specific method rather than offering a specific method and then mandating
that some method equivilent or superior to that method in strength be used.
> I do have two questions, that probably go for all the add-entropy proposals;
> 1. Do all recursive servers even have access to enough entropy? This
> might not be a problem at all, or extra entropy could be arranged for
> busy ones, but it might be worth thinking about in advance. For that
> matter, what about dos attacks where the entropy pool itself is attacked,
> is that possible? What would happen then?
in my statement i called for "high quality randomness". if you don't have
enough randomness, or if its quality is too low, then you can't speak dns.
(and, i expect that banks will test your RDNS strength before letting you
log in, assuming that this approach isn't already patented up the wazoo.)
> 2. Is it feasible to require (as a deployment consideration or
> otherwise) that in setups where there might be multiple implementations
> pretending to be one server, all implementations should have the exact
> same feature set? Would we even want that?
i think we can strongly recommend, but not mandate, that all members of a
local or distributed dns cluster (whether authority or recursive or stub)
implement the same protections and options, but that in practice, stuff
will be wrong, there will be churn, there will be partial rollouts for
testing and QA, and thus it will always be nec'y for initiators to cope
with inconsistent responders.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.