Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

[Paul Hoffman <[e-mail]>]

On Jun 15, 2015, at 12:15 PM, Joe Abley <[e-mail]> wrote:
>>> I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.
>> 
>> These seem limited to the EPP RFCs only, so probably not worth bringing up here.
> 
> Well, there's a whole section on registration that also makes sole reference to those RFCs, no? If we're at least tipping the hat towards the intersection between RRR and DNS, they seem useful (and easy) to include.

Judgement call, and you haven't provided text, so let's leave them out unless others have seen them in the wild and care.

>>> 4. Resource Records
>>> 
>>> The negative cache TTL is alluded to under SOA field names, but not under TTL. The former also claims a definition of MINIMUM of "the TTL to be used for negative responses", when in fact the TTL to be used for negative responses is the MINIMUM value or the TTL of the SOA RR returned with the negative response, whichever is the smaller. This fact may be familiar to Secure64 and Afilias people :-)
>> 
>> If you want to update RFC 2308, you need to do so separately from this document. (Note to Mark and Joe: if you want to argue about this, please change the name of the thread, since we are not going to make that change in this document.)
> 
> RFC 2308 section 3 says exactly:
> 
>   Name servers authoritative for a zone MUST include the SOA record of
>   the zone in the authority section of the response when reporting an
>   NXDOMAIN or indicating that no data of the requested type exists.
>   This is required so that the response may be cached.  The TTL of this
>   record is set from the minimum of the MINIMUM field of the SOA record
>   and the TTL of the SOA itself, and indicates how long a resolver may
>   cache the negative answer.
> 
> So I don't think I'm asking for a change to 2308, rather that this document not contradict 2308.

The last paragraph of Section 4 of RFC 2308 says:
   The remaining of the current meanings, of being the TTL to be used
   for negative responses, is the new defined meaning of the SOA minimum
   field.
We used that for the direct quotation in the draft. Again, if you want to update that RFC to clarify it, please do so on a different thread.

>>> There is no mention of "authority-only servers", which I find to be in common usage.
>> 
>> That term appears in exactly one RFC, of which you are co-author.
> 
> But Paul, I am the voice of the people! The people must be heard!
> 
>>> I wonder what the real difference is between "stealth server" and "hidden master". If they are synonyms (I think they are) it might be as well to say so; as it stands they both have the appearance of having different definitions.
>> 
>> The two definitions from the RFCs do not make them seem like synonyms to me. In one, it is a slave, and in the other it is a master.
> 
> We ought to note somewhere that servers can easily both slaves and masters for the same zone, simultaneously. I often refer to such servers as "distribution masters", but only really as a convenience when describing a particular platform where the zone distribution graph is simple.
> 
> In any case, in both cases in this doc they are authoritative servers for a set of zones, and do not appear in those zones' NS RRSets (either at the zone apex or in the parent). It seems troublesome to me that it's trivial to find a production server that could fit either or both of those definitions.
> 
> But perhaps this is all fine, as you say, and something to be addressed in -bis.

I cannot imagine how we can simply say "servers can easily both slaves and masters for the same zone, simultaneously" without a lot more explanation and some over-riding of earlier RFCs. But this is certainly one of the topics of confusion that should be addressed.

>>> "NSEC3": whether not NSEC3 is "quite different" from NSEC depends on your context. Functionally, in the narrow sense of "allows verifiable denial of existence", they are identical. I think it would be clearer to focus on their functional similarities, and point out the additional features of NSEC3 (opt-out and making zone enumeration harder), observing that any particular signed zone must use exactly one of these, not both (so, they are alternatives, and one of them is required).
>> 
>> Disagree. Even in the "allows verifiable denial of existence", they are quite different in that the processing needed is very different. The "fundamental similarities" are only in what is achieve, not in the way of achieving it.
> 
> Perhaps we could agree on some text that confirms that they are functionally similar, whilst having quite different approaches to achieving that functionality? That seems like it would be better than declaring them to be "quite different".

The current text says:
NSEC3:
: The NSEC3 resource record is quite different than the NSEC resource record.
Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however,
NSEC3 records mitigates against zone enumeration and support Opt-Out.
NSEC3 resource records are defined in {{RFC5155}}.

I think the second sentence says what you want, and the first sentence is factually correct in the that the records themselves really are different.

--Paul Hoffman