With respect to
"ptr names of NS addresses should match the associated A/AAAA names"
you might want to
a) avoid or modify the term "ptr names", since there is nothing about the PTR
record type which *restricts* it to the reverse-mapping function, and
b) disclaim the recommendation as only a soft one, since it is common for a
single authoritative nameserver to be delegated different zones via a diversity
of names, yet we don't want to encourage anyone to populate a single
reverse-mapping entry with *multiple* PTR RRs, since this doesn't produce
useful results and thus effectively only wastes space in DNS databases and
response packets. Alternatively, if we want to recommend that the mapping of
any given NS name to a particular A/AAAA address must be *unique*, then that
should be spelled out explicitly, irrespective of any recommendations
concerning reverse mappings.
- Kevin
-----Original Message-----
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John Kristoff
Sent: Thursday, March 17, 2016 5:45 PM
To: Jakob Schlyter
Cc: dnsop; Patrik Wallström
Subject: Re: [DNSOP] DNS Delegation Requirements
On Mon, 8 Feb 2016 09:57:15 +0100
Jakob Schlyter <ja...@kirei.se> wrote:
> At this point, we're seeking more public comments - on this mailing
> list (unless the chairs disapproves), on the our issue tracker [4] or
> via email to the authors.
Hello Jakob and Patrik. Some comments as requested.
The introduction lists 8 areas of interest. All, except "7. Name Server" have
their own section in the table of contents. Oversight?
This sentence is awfully confusing:
Many requirements in this document deal with the properties of a
nameserver that is used as part of a delegation, therefore the
wording mentioning the use of a name server as part of this is
omitted.
First there is nameserver, then name server as two words. Which is it? More
importantly, I'm not quite sure what is being said here. Can you perhaps
rewrite, elaborate or provide an example?
You may be interested to know that I recently submitted a draft on DNS over TCP
operational requirements. If that work progresses as I hope, it might help
with section 4.2 of your draft.
The consistency requirements might be too strict, since it applies all zone
data. While reasonable people might fret about inconsistency when things like
"views", "geo-location", client-subnet and so on are in use, it might be best
to limit consistency requirements to the infrastructure records (e.g. SOA, NS).
Additionally, I could imagine an argument being made that all names need not
respond with the same NS RRset. While generally this delegation or authority
list inconsistency is often indication of a problem, it is feasible that it
might be intentional and may even provide some advantage. The so-called "fast
flux" invention by the miscreants taught us that.
Suggesting that name servers be the same AS is often unnecessary. More
important is diversity in the route announcements covering the name server
addresses. Many might not even be able to easily satisfy this requirement.
A few additional topics you may wish to consider:
* delegated name server should be authoritative only (no rd service)
* ptr names of NS addresses should match the associated A/AAAA names
* name server should run NTP or equivalent so time is accurate
* DNS TTLs of the NS and A/AAAA name servers MUST be consistent
John
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
