Hi Paul,
On 15 Jun 2015, at 14:49, Paul Hoffman wrote:
This message, and some of the earlier in this discussion, says in
essence "RFC Foo says the definition of X is Y, but that's wrong". At
the beginning of this process, we decided that we should use
definitions from the RFCs where possible instead of making up our own.
That was a good way to get this document out in a reasonable amount of
time.
The authors of the WG document have also floated the idea that there
should be a -bis RFC to come later to deal with the important terms
for which we cannot get consensus. At this point, I think we should
also assume that the -bis document will formally update a bunch of
RFCs and say "RFC Foo says the definition of X is Y, but this document
updates RFC Foo to say that the definition of X is Z".
Quoted entirely to confirm that I have read them. :-)
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.
"Name Error" as a synonym for NXDOMAIN seems like it is worth
including, somewhere.
Are you sure that "name error" always refers to NXDOMAIN? If not, this
is not a can of worms we should open.
I was sure until you asked that question. I can do some more research
and justify my opinion or change my mind, but it might be quicker just
to wait for Mark Andrews to wake up. :-)
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.
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.
In zone cut, I'm not sure what "barely an ostensive definition" is
intended to convey. Are you saying that this is not a definition that
is made by way of demonstration, or that it is, or that it should be,
or something else?
The former.
OK. I guess the main reason for the question was rhetorical; if it's not
obvious what it means, perhaps "ostensive" could be replaced with a
merely $1 word in the interests of clarity.
7. Registration Model
This whole section talks about "registration of names in a zone",
which I think encourages a kind of conflation between database and
DNS operations that keeps cropping up and always causes headaches.
The RRR (or RR or RRRR, with a reseller layer, even) structure exists
to maintain uniqueness in a database. Information present in that
database is used to publish one or more zones in the DNS, but the
interactions between the Rs are better characterised in database
terms than DNS terms.
Without specific proposed text, we can't fix this in this round.
I will see what I can do to propose something, then.
"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".
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
