On 26 Jun 2018, at 10:09, Vladimír Čunát wrote:
Greetings!
I really like the draft, and I'm sorry to be so late.
This is not late, especially if you really like the draft. :-)
I see one minor
issue just below and then a few nitpicks that I don't feel strongly
about.
I'm marking these in the GitHub repo.
NXDOMAIN:
"Name Error - Meaningful only for responses from an
authoritative
name server, this code signifies that the domain name referenced in
the query does not exist." (Quoted from [RFC1035], Section 4.1.1.)
[RFC2308] established NXDOMAIN as a synonym for Name Error.
I dislike keeping this formulation; it might confuse people. It
seems
to imply that NXDOMAIN from a resolver isn't "meaningful", and
that's clearly not true, at least not nowadays. (I develop a
resolver.)
The quoted definition makes sense without the "Meaningful only for
responses from an authoritative name server" phrase, so we can remove it
and still have it be useful.
"Resolver" definition: I don't think the word really implies it runs
on
the same machine as the program asking it. In particular, the
purpose
of stub resolvers is to ask a recursive *resolver* that is typically
on
another machine. Perhaps I misunderstand that RFC1034 part. I
found
one comment on this particular point but no reactions:
https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w
We did indeed miss this. In staring at that longer, I agree that the
quote from 1034 is not true for the current understanding of a resolver.
We can remove it.
"Authoritative-only server" definition: "ignores requests for
recursion"
might mislead into thinking the DNS request is not replied to, whereas
the
server is supposed to return either REFUSED or a referral.
Maybe I'd say something like "ignores the RD bit being set to 1".
Well, the authoritative server doesn't ignore the RD bit, either: it
just doesn't do the recursion that was asked for. Thus you want the
terminology document to (a) update an RFC that (b) is a BCP that (c) was
co-written by my boss. Trifecta!
Instead of changing the wording of the BCP, we can instead add "In this
case 'ignores requests for recursion' means 'responds to requests for
recursion with responses indicating that recursion was not performed'".
Does this work for you?
"Slave server", "Master server": I'm surprised to read that current
common usage has shifted to "secondary" and "primary" instead, but
that
is better judged by people working with authoritative servers (and not
me).
Open resolver: A full-service resolver that accepts and processes
queries from any (or nearly any) stub resolver. [...]
Perhaps not from any "stub resolver" but from any "client". *Who*
asks
really isn't the point.
Very good point! In fact, many open resolvers allow forwarding from
other recursive resolvers.
"Authoritative data" definition: there might be a mention of special
cases added later or perhaps switch quotation to one from
rfc4033#section-2
Yes; will add pointer there.
"Bailiwick" definition: I have (also) seen use like "in-bailiwick
records" in the sense being in a subdomain. I can't really judge how
common that usage is, but it has already been discussed wrt. this
draft:
https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io
My understanding of that thread is that the meaning was planned to be
extended
in the draft, but the current text seems still restricted to name
servers.
We opened a discussion for bailiwick and incorporated what we could from
that discussion.
"NSEC3" definition, this is clearly a typo (missing "3"):
NSEC resource records require associated NSEC3PARAM resource records.
Good catch!
I'm not really sure if a best-practice RFC is really allowed to
"update"
a standards-track RFC (2308), but I assume the authors and chairs know
the process much better than me. (From my point of view it's OK.)
It is indeed OK. BCPs are considered "standards track" themselves.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
