Edward Lewis <[email protected]> writes:
> But I am dubious on the flag for “immediate.” In my experience, I’ve
> never seen queue-jumping to every pay off unless the underlying system
> is over subscribed as it is. If this system is oversubscribed, there
> are bigger problems. Normally I’d let this lie, but it reminds me of
> the key strength field in the KEY RR - a spectacular dud of a concept.
> (KEY RR was the DNSSEC key holder before DNSKEY RR.)
The whole reason for that was to appease some of the people that wanted
to provide a system where the transfer was automatic (reducing
copy/paste errors), but wouldn't be done until a user pushed a button.
IE, setting immediate=0 allows the operator to signal "copy the data but
wait till I'm around to push the button", where "button" is out of
scope. Personally, I agree, I think having it always be immediate would
be simpler and better. But there was clear consensus in the WG to
support both options.
> PS - What if the parental agent tries to retrieve the AAAA records and
> gets no response - persistently? I don’t mean “No Answer” I mean
> nothing back? I’m picking on this (as opposed to A) as a somewhat
> more realistic operational happenstance.
We cover DNSSEC errors, but not general errors, you're right. Changed:
OLD:
If DNSSEC fails to validate all of the data returned for
these queries as "secure", then this CSYNC record MUST NOT be
processed.
NEW:
If a failure occurs of any kind while trying to obtain any
of the required data, or if DNSSEC fails to validate all of
the data returned for these queries as "secure", then this
CSYNC record MUST NOT be processed.
> Who would initiate the debugging of this, the parental agent who
> detects the failure but is mum, or the child whose patience
> is being tested?
Whomever was most annoyed at it not working? Who debugs problems with
nameservers today? Both!
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
