On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA) <kevin.da...@fcagroup.com> wrote:
> My 2 cents… > > > > I don’t think any DNS RFC should be tied to any specific element of > Internet routing technology. Keep it relatively generic and avoid mention > of “ASes” and the like, since this RFC may outlive the use of ASes for > Internet routing. ”Path diversity”, “link diversity”, “network-level > redundancy”, those are all fine. > That works too -- RFC 2182, 3.1. ? :-) W > > > > - Kevin > > > > *From:* DNSOP [mailto:dnsop-boun...@ietf.org] *On Behalf Of *Warren Kumari > *Sent:* Monday, February 08, 2016 9:21 AM > *To:* Ralf Weber; Jakob Schlyter > *Cc:* dnsop; Patrik Wallström > *Subject:* Re: [DNSOP] DNS Delegation Requirements > > > > > > On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber <d...@fl1ger.de> wrote: > > Moin! > > On 8 Feb 2016, at 9:57, Jakob Schlyter 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. > Thanks a lot for this work. I certainly would like dnsop to work on > this. > > I would soften some of language and have a question. > > 5.1. There are use cases where the serial number rarely if ever is the > same on all servers and it's only really used inside communication for a > given domain and not during resolution. So the only people who know if a > divergent serial number is a problem are the domain owners. So we > shouldn't tell the public that this is a problem. I would say that a > different SOA serial number could be seen as an indicator of an > inconsistent setup, but that further analysis is required to really > conclude that. > > 6.2 The name servers SHOULD NOT belong to the same AS > I would drop that requirement altogether or make it a MAY. We really > should not tell people how to build networks from the DNS world. > > > > > > I think that the SHOULD NOT is actually correct here -- from RFC1771: The > use of the term Autonomous System > > here stresses the fact that, even when multiple IGPs and metrics are > > used, the administration of an AS appears to other ASs to have a > > single coherent interior routing plan and presents a consistent > > picture of what destinations are reachable through it. > > > > An AS is a "network", run by one organization. This means that there is a > monkey sitting somewhere making all of the routing decisions, and sometimes > monkeys screw up. Having a nameserver in an AS that is run by a different > monkey means that you need multiple monkeys messing up at the same time[0]. > Also, a significant amount of routing and traffic engineering decisions are > made at the AS level ("Meh, I'll local-pref AS 42 down to move this traffic > $there") - this means that sometimes folk screw up and accidentally block > access to some set of ASes - SIDR may or may not make this more likely :-) > > > > This is *not* telling people how to build their network - it is simply > *suggesting* that they consider putting some net of nameservers in a > network run by someone else. If you understand the implications of putting > all of your nameservers in one AS, good for you. If not, chances are it's > safer to put at least some elsewhere... > > > > W > > [0]: This (obviously) isn't really true, both ASs could share the same > upstream, router, etc. RFC 2182, 3.1. says it best: > > "They should also be connected to > > the net via quite diverse paths. This means that the failure of any > > one link, or of routing within some segment of the network (such as a > > service provider) will not make all of the servers unreachable." > > > > > > > > > > > > > 8.7 We should point out here that neither an MX nor an A record are > required at the zone apex or do you want either of them mandatory? > > On the SOA settings I do have a question. Would the following SOA be > legitimate according to this draft? > localhost. root.localhost. 1115106304 16384 2048 1048576 2560 > If not why not, as my spot checking didn't find anything that made it > invalid. > > So long > -Ralf > > _______________________________________________ > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
