"Mirja Kuehlewind" <i...@kuehlewind.net> writes:
> 1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a
> real test?
I don't think it's possible to easily test this, sadly, without a target
set containing different deterministic response sizes. We could
probably strike the section and simply state that resolvers MUST support
TCP (which actually is stated elsewhere).
> 2) To follow up with the tsv-art review: To avoid network as well as
> server overload, would it be useful to provide further guidance, when and
> how often these tests should be performed?
<t>These tests should be performed when a resolver determines
its network infrastructure has changed. Certainly a resolver
should perform these tests when first starting, but MAY also
perform these tests when they've detected network changes
(e.g. address changes, or network reattachment, etc).</t>
FYI, I don't think even with a lot of boxes starting at the same time it
would cause significant overload. Specifically, those resolver boxes
are serving many more clients that will be issuing significant more
traffic once the resolver is operational than these tests actually
require.
> 3) In section 6.1. (What To Do): maybe also list logging as an option in
> cases where no user is directly involved but a human might check later.
Good point. I've changed it to:
<t>If Host Validator detects that DNSSEC resolution is not
possible it SHOULD log the event and/or SHOULD warn user. In
the case there is no user no reporting can be performed thus
the device MAY have a policy of action, like continue or
fail. </t>
h
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
