Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri <[e-mail]>]

> On Aug 24, 2018, at 10:11 AM, Joe Abley <[e-mail]> wrote:
> 
> Hi Tom,
> 
>> On Aug 24, 2018, at 09:52, Tom Pusateri <[e-mail]> wrote:
>> 
>>> If a zone is signed, are the TIMEOUT records signed?
>> 
>> No. The draft says they are skipped.
> 
> New RRTypes are supposed to be handled by old software that pre-dates them because they can be treated as opaque types. That's not the case if new RRTypes are encumbered with requirements for special handling at query or signing time (as described in your section 2).
> 
> This seems like a significant architectural change that in effect updates 1034 and 1035 as well as 3597. This would be a much more straightforward and uncontroversial proposal if it was simply a specification for use of a new RRType that made no changes at all to the rest of the protocol.
> 
> I have not read your draft in detail but I think you probably would also need to spend more time considering the cases of old, non-TIMEOUT authority servers that wind up serving zones that contain TIMEOUT RRSets (e.g. third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR with ANSWER sections containing TIMEOUT RRSets, etc.

Yes, the draft says the primary has to agree to send them to the secondary and the secondary has to agree to accept them (administratively). This prevents old authority servers from having to deal with them.

The position of not having them signed is a consequence of not having them returned in a query. If you can’t see them in a query, you can’t do NSEC/NSEC3/NSEC5 next record semantics so we skip them.

By simply making them returned in a query, we can avoid most of your objections. Mark Andrews suggested they not be returned in a query in a hallway discussion and I’m happy to change if that’s the preferred approach.

Thanks for the feedback!

Tom