Hi,
Sent something relating to this on DNS-OARC this morning, but it seems to be legit to have delegation for a “_tcp.example.ca”, which fails the syntax requirements defined in section “8.1. Illegal characters MUST NOT be in the domain name". A delegation can happen to a valid domain name, not necessarily a valid hostname. Zonemaster fails on delegations like “_sips._tcp.cam.ac.uk” # dig _sips._tcp.cam.ac.uk ns +short rnb-uls2-jabber.phone.cam.ac.uk. cnh-uls2-jabber.phone.cam.ac.uk. wolf-uls2-jabber.phone.cam.ac.uk. Jack From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Warren Kumari Sent: February-08-16 6:51 PM To: Darcy Kevin (FCA); dnsop Subject: Re: [DNSOP] DNS Delegation Requirements On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA) <kevin.da...@fcagroup.com<mailto: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<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<mailto: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<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
