Subject: [DNSOP] DNS Delegation Requirements

From: Jakob Schlyter <[email-masked]>
Date: Mon, 8 Feb 2016 09:57:15 +0100

As we've seen to good summary on requirements for on a well-behaved DNS delegation of a domain name, Patrik Wallström and myself has written an Internet-Draft [1] describing such requirements. The requirements were developed within the CENTR Test Requirements Task Force (TRTF) and most of the original requirements and text originate from the Zonemaster [2][3] project.

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.

	jakob

[1] https://www.ietf.org/id/draft-wallstrom-dnsop-dns-delegation-requirements-00.txt
[2] https://zonemaster.net/
[3] https://github.com/dotse/zonemaster
[4] https://github.com/CENTRccTLDs/TRTF/issues

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 08 Feb 2016 11:00:33 +0100

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.

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

---

From: Shane Kerr <[email-masked]>
Date: Mon, 8 Feb 2016 12:45:00 +0100

Jakob,

At 2016-02-08 09:57:15 +0100

> [4] https://github.com/CENTRccTLDs/TRTF/issues

Document structure
----

Just to be clear, the idea here is only to have really, absolutely
essential requirements? Because it seems like a mix of "just the
minimum" and "oh, here are some other things too".

I guess I kind of envision three levels:

1. Actual minimum requirements (SHOULD)
2. Strongly recommended requirements (MUST)
3. "-Wall" requirements, for people who want to know the Proper way to
   run DNS (a.k.a "Aussie rules" DNS operations)

In my mind, organizing the document in this order would be helpful. You
could have the same sections in each, such as "Routing" or "Zone
Contents" - the current set is probably fine.

This should make it easier both for authors - since it is clear what
is really, REALLY a requirement at all times. It should also make it
easier for operators and implementors, because you can start at the top
and then as you move on to softer requirements decide if they fit your
situation or not.

Specific requirements
----
Looking at the list, I see a lot of MUST requirements which seem too
strong for me:

6.3.  The name servers MUST have distinct IP addresses

Certainly this is not a MUST. Name server operations can happily
function like this, and I can possibly even think of reasons why this
might be easier if I squint my eyes and step back a bit. ;)

6.8.  SOA MNAME MUST be authoritative for the zone

Oddly the very first sentence uses SHOULD not MUST, which seems
appropriate. :)

7.1.  The DS Digest Type MUST be assigned by IANA
7.2.  The DNSKEY algorithm MUST be assigned by IANA

Both of these eliminate the chance for private (or public)
experimentation. For example, maybe I want to put in a DNSKEY RR that
uses some alternative crypto in addition to IANA ones. 7.2 forbids that.

8.4.  The SOA RNAME MUST not contain the '@' character
8.5.  The SOA RNAME MUST be a legal hostname
8.6.  The SOA MNAME MUST be a legal hostname

Breaking these rules happens all the time (mostly by mistake), and
nothing breaks. MUST seems too strong.

8.7.  The MX record in apex MUST point to a valid hostname

Getting this wrong will break e-mail, but I'm not 100% sure about MUST.

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Feb 2016 23:00:27 +1100

In message <[email-masked]>, Jakob Schlyter writ
es:

7.4 is per DNSSEC algorithm in the DS RRset.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 8 Feb 2016 13:07:42 +0100

On 8 feb. 2016, at 11:00, Ralf Weber <[email-masked]> wrote:

> 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.

(now https://github.com/CENTRccTLDs/TRTF/issues/64)

I agree, we should write something along that line.

> 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 would agree, but on the other hand it's apparent that a lot still make really bad choices, such as putting all of their authoritative name servers on a single LAN or site. There are exceptions for the "belong to same AS", can we perhaps try to state those?

> 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?

This depends on the parent zone policy. IMHO, any requirement for a domain to accept email is moot, but there are still TLDs that require this I understand.

> On the SOA settings I do have a question. Would the following SOA be legitimate according to this draft?
> If not why not, as my spot checking didn't find anything that made it invalid.

Yes, but it looks funky.  Can we do better by accepting reserved names (such as localhost., example.com)?

	jakob

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 8 Feb 2016 12:57:32 +0000

Jakob, Patrik
thanks for writing this up, a great start.

On first read this document seems to be duplicating what is in
https://tools.ietf.org/html/rfc1912
It is hard to see what is new and what is the same.

There are number of assumptions in the current draft, that only apply when
the DNS contents  are distributed as zone in "files or axfr"  which not all
operators use.
There are few other examples of "rules" that show this document is written
from a TLD's perspective which is different from what Domain operators may
want to practice.

So before we start working on exactly what is in the current draft, can we
have a discussion about what should be in the document.

For example the document omits all discussion on TTL's is that
good/bad/separate ?
Do we want to talk about how many addresses are associated with a name
server name. (common practice is 1 A and/or 1 AAAA but will more work?)
Are the "current" naming rules still something we want to promote, i.e. can
we get rid of the Hostname rules from https://tools.ietf.org/html/rfc953

IMHO this should be a BCP candidate that obsoletes all prior guidance, no
matter what RFC the guidance came from.

Olafur

On Mon, Feb 8, 2016 at 8:57 AM, Jakob Schlyter <[email-masked]> wrote:

> As we've seen to good summary on requirements for on a well-behaved DNS
> delegation of a domain name, Patrik Wallström and myself has written an
> Internet-Draft [1] describing such requirements. The requirements were
> developed within the CENTR Test Requirements Task Force (TRTF) and m ost of
> the original requirements and text originate from the Zonemaster [2][3]
> project.
>
> 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.
>
>
>         jakob
>
>
> [1]
> https://www.ietf.org/id/draft-wallstrom-dnsop-dns-delegation-requirements-00.txt
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Patrik Wallström <[email-masked]>
Date: Mon, 8 Feb 2016 14:22:24 +0100

Olafur,

> On 08 Feb 2016, at 13:57, Ólafur Guðmundsson <[email-masked]> wrote:
> 
> Jakob, Patrik
> On first read this document seems to be duplicating what is in https://tools.ietf.org/html/rfc1912

Yes, some parts of it are duplicated. However, I believe it is clear that these two documents are very different in what they are. One could also argue that this draft is supposed to be a BCP, which 1912 is not.

> There are number of assumptions in the current draft, that only apply when the DNS contents  are distributed as zone in "files or axfr"  which not all operators use.

Yes. It would be useful to describe that AXFR is just one way to distribute a zone.

> There are few other examples of "rules" that show this document is written from a TLD's perspective which is different from what Domain operators may want to practice.

It is indeed written from a TLD perspective, but also what IANA requires for delegations at the root. But our hope is to make this a generic enough document that suits any part of the DNS tree.

> So before we start working on exactly what is in the current draft, can we have a discussion about what should be in the document.

We started with the assumption that most of the things we wanted to include was already documented in other RFCs, and thus already accepted by this community in some way. If the aim is to have a BCP we may go beyond this, but I think this would make it very hard for the working group to agree on the content. Yes, we need to have this discussion.

> For example the document omits all discussion on TTL's is that good/bad/separate ?

As the document comes from the work on Zonecheck, DNSCheck and Zonemaster, this is one of the things that none of these tools ever looked at. But if we can agree on that it is important to include, and on a recommendation, we will be happy to add it.

> Do we want to talk about how many addresses are associated with a name server name. (common practice is 1 A and/or 1 AAAA but will more work?)
> Are the "current" naming rules still something we want to promote, i.e. can we get rid of the Hostname rules from https://tools.ietf.org/html/rfc953

If we want to update RFC953, I think that would better fit in another document rather than this one.

> IMHO this should be a BCP candidate that obsoletes all prior guidance, no matter what RFC the guidance came from.

Thank you.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 8 Feb 2016 13:40:34 +0000

>> 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 would agree, but on the other hand it's apparent that a lot still
> make really bad choices, such as putting all of their authoritative
> name servers on a single LAN or site. There are exceptions for the
> "belong to same AS", can we perhaps try to state those?

The IANA new gTLD testing requires that the servers not all be in the
same "origin AS".

IMHO, this requirement is wrong.  What matters more is that they don't
all have the same AS path.

That's a separate issue from being physically co-located on the same
LAN, but you can't readily tell that from routing views.

At the moment it's possible to have a perfectly well designed Anycast
cloud with multiple sites and yet fail the IANA checks because the sites
all use the same stub ASN.

Ray

---

From: Warren Kumari <[email-masked]>
Date: Mon, 08 Feb 2016 14:21:12 +0000

> 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."

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Mon, 8 Feb 2016 23:37:57 +0000

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.

                                                                                                                        - Kevin

From: DNSOP [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:
Moin!

I think that the SHOULD NOT is actually correct here -- from RFC1771: The use of the term Autonomous System

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:

So long
-Ralf

_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Mon, 08 Feb 2016 23:51:07 +0000

On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA) <[email-masked]>
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:[email-masked]] *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
>
>
>
>
>

---

From: Jacques Latour <[email-masked]>
Date: Tue, 9 Feb 2016 16:59:38 +0000

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:[email-masked]] 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) <[email-masked]<mailto:[email-masked]>> wrote:
My 2 cents…

W

                                                                                                                        - Kevin

From: DNSOP [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Warren Kumari

W

So long
-Ralf

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Tue, 9 Feb 2016 22:33:13 +0000

That’s a very good catch. Restrictions on *hostnames* are different than restrictions on *domain*names*. The language below, from RFC 2181, Section 11 (incorrectly cited as RFC 2182, Section 11, in the draft; but RFC 2182 has no Section 11), should be controlling, and the other references (to RFCs 1035, 1123) should be discarded, since they refer specifically to *hostname* (not *domain*name*) restrictions, and/or are ambiguous as to whether they apply to hostnames or domain names. The reference to RFC 3696 should be discarded also, since it is only an Informational RFC, and defers to the others (1035, 1123 and 2181) as “authoritative” (and in any case, makes an explicit exception for “names that are normally not seen by users”).

--- RFC 2181, SECTION 11 ---
Occasionally it is assumed that the Domain Name System serves only
   the purpose of mapping Internet host names to data, and mapping
   Internet addresses to host names.  This is not correct, the DNS is a
   general (if somewhat limited) hierarchical database, and can store
   almost any kind of data, for almost any purpose.

   The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators).  The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".  Those restrictions
   aside, any binary string whatever can be used as the label of any
   resource record.  Similarly, any binary string can serve as the value
   of any record that includes a domain name as some or all of its value

   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
--- END QUOTE ---

(Nota bene the reference to “any binary string” being legal “as the value” of an NS record – how can that be compatible with subjecting delegations to “hostname” rules?).

Now, if a particular *registry* wants to put additional restrictions on the names it will delegate, then that’s another matter, but IMO outside the scope of this draft.

In practice, it is quite common to delegate subzones whose only contained “leaf” RRs are of type SRV and thus *must*, according to the naming conventions of SRV, contain underscores in their FQDNs. As long as those zones contain no “hostname” records, this is perfectly legal and acceptable, according to current standards, and I see no compelling reason to disparage or mark as “defective”, the delegation of such domains. Although much rarer, some zones might only contain MX records, and/or some other record type(s) which is/are not considered to represent a “hostname”, _per_se_.

                                                                                                                                                                - Kevin

From: DNSOP [mailto:[email-masked]] On Behalf Of Jacques Latour
Sent: Tuesday, February 09, 2016 12:00 PM
To: Warren Kumari; Darcy Kevin (FCA); dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements

Hi,

Jack

W

                                                                                                                        - Kevin

W

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Feb 2016 10:21:02 +1100

In message <[email-masked]>, Jacques Latour writes:
> 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".
>
> Zonemaster fails on delegations like _sips._tcp.cam.ac.uk
>

There are rules for TLDs which are tighter than the general DNS
requirements.

I can remember when COM was looking at what names to allow in
delegations and I said something along the lines of you can allow
anything but if you allow something other than LDH then the person
requesting the delegation needs to know that they can't use it for
hostnames.

After that the COM delegation rules got tightened down to just LDH
and some delegations got removed.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Feb 2016 10:34:39 +1100

In message <[email-masked]>, "Darcy Kevin (FCA)" writes:
> Thats a very good catch. Restrictions on *hostnames* are different than
> restrictions on *domain*names*. The language below, from RFC 2181,
> Section 11 (incorrectly cited as RFC 2182, Section 11, in the draft; but
> RFC 2182 has no Section 11), should be controlling, and the other
> references (to RFCs 1035, 1123) should be discarded, since they refer
> specifically to *hostname* (not *domain*name*) restrictions, and/or are
> ambiguous as to whether they apply to hostnames or domain names. The
> reference to RFC 3696 should be discarded also, since it is only an
> Informational RFC, and defers to the others (1035, 1123 and 2181) as
> authoritative (and in any case, makes an explicit exception for names
> that are normally not seen by users).
>
> (Nota bene the reference to any binary string being legal as the value of
> an NS record  how can that be compatible with subjecting delegations to
> hostname rules?).
>
> Now, if a particular *registry* wants to put additional restrictions on
> the names it will delegate, then thats another matter, but IMO outside
> the scope of this draft.
>
> In practice, it is quite common to delegate subzones whose only contained
> leaf RRs are of type SRV and thus *must*, according to the naming
> conventions of SRV, contain underscores in their FQDNs. As long as those
> zones contain no hostname records, this is perfectly legal and
> acceptable, according to current standards, and I see no compelling
> reason to disparage or mark as defective, the delegation of such domains.
> Although much rarer, some zones might only contain MX records, and/or
> some other record type(s) which is/are not considered to represent a
> hostname, _per_se_.

Mail domains have exactly the same syntax requirements as hostnames.

If you see a MX record w/o a LDH owner then it is not being used
for a mail domain or it is there in error the same way as A / AAAA
without a LDH owner is not being used as a hostname or it is there
in error.

Mark

>             - Kevin
>
> From: DNSOP mailto:[email-masked] On Behalf Of Jacques Latour
> Subject: Re: DNSOP DNS Delegation Requirements
>
>
> Hi,
>
>
>
> From: DNSOP mailto:[email-masked] On Behalf Of Warren Kumari
> Subject: Re: DNSOP DNS Delegation Requirements
>
>
> On Mon, Feb 8, 2016 at 3:38 PM Darcy Kevin (FCA)
> <[email-masked]<mailto:[email-masked]>> wrote:
> My 2 cents
>
> I dont think any DNS RFC should be tied to any specific element of
> 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.
>
> From: DNSOP mailto:[email-masked]<mailto:[email-masked]>
> On Behalf Of Warren Kumari
> Cc: dnsop; Patrik Wallstrm
> Subject: Re: DNSOP DNS Delegation Requirements
>
>
> On Mon, Feb 8, 2016 at 2:00 AM Ralf Weber
> <[email-masked]<mailto:[email-masked]>> wrote:
> Moin!
>
> > list (unless the chairs disapproves), on the our issue tracker 4 or
> 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 time0. 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 :-)
>
> 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

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Tue, 9 Feb 2016 23:39:20 +0000

True, the MX case falls within the intersection of DNS and SMTP standards, and thus must conform to the naming restrictions of both. That was a bad example and I shouldn't have cited it.

											- Kevin

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: Tuesday, February 09, 2016 6:35 PM
To: Darcy Kevin (FCA)
Cc: dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements

In message <[email-masked]>, "Darcy Kevin (FCA)" writes:
> Thats a very good catch. Restrictions on *hostnames* are different 
> than restrictions on *domain*names*. The language below, from RFC 
> 2181, Section 11 (incorrectly cited as RFC 2182, Section 11, in the 
> draft; but RFC 2182 has no Section 11), should be controlling, and the 
> other references (to RFCs 1035, 1123) should be discarded, since they 
> refer specifically to *hostname* (not *domain*name*) restrictions, 
> and/or are ambiguous as to whether they apply to hostnames or domain 
> names. The reference to RFC 3696 should be discarded also, since it is 
> only an Informational RFC, and defers to the others (1035, 1123 and 
> 2181) as authoritative (and in any case, makes an explicit exception 
> for names that are normally not seen by users).
>
> (Nota bene the reference to any binary string being legal as the value 
> of an NS record  how can that be compatible with subjecting 
> delegations to hostname rules?).
>
> Now, if a particular *registry* wants to put additional restrictions 
> on the names it will delegate, then thats another matter, but IMO 
> outside the scope of this draft.
>
> In practice, it is quite common to delegate subzones whose only 
> contained leaf RRs are of type SRV and thus *must*, according to the 
> naming conventions of SRV, contain underscores in their FQDNs. As long 
> as those zones contain no hostname records, this is perfectly legal 
> and acceptable, according to current standards, and I see no 
> compelling reason to disparage or mark as defective, the delegation of such domains.

If you see a MX record w/o a LDH owner then it is not being used for a mail domain or it is there in error the same way as A / AAAA without a LDH owner is not being used as a hostname or it is there in error.

Mark

> 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".
>
>
>
> 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.
>
> From: DNSOP 
> mailto:[email-masked]<mailto:[email-masked]>
> 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 
> 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 time0. 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 :-)
>
> 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

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Feb 2016 10:14:58 +1000

its maybe me, I'm having a bad (no?) hair day, I need more caffiene.. but
this feels like a "oh can't we just stop" moment.

MUST in protocols terms is good: its proscriptive, definitive language
around on-the-wire.

MUST in operations terms is getting way off IETF charter, even with an ops
focus.

waddaya gonna do if I don't do the MUST? you gonna blacklist me? you gonna
forbid applications to flow?

I feel like capitalized normatives in operational recommendations is a big
mistake.

Sure, by all means lets recommend "please: don't put your authoritative NS
eggs in one AS basket" but MUST?  MUST we? must WE?

-G

On Wed, Feb 10, 2016 at 9:39 AM, Darcy Kevin (FCA) <[email-masked]

> True, the MX case falls within the intersection of DNS and SMTP standards,
> and thus must conform to the naming restrictions of both. That was a bad
> example and I shouldn't have cited it.
>
>
>               - Kevin
>
> If you see a MX record w/o a LDH owner then it is not being used for a
> mail domain or it is there in error the same way as A / AAAA without a LDH
> owner is not being used as a hostname or it is there in error.
>
> Mark
>
> >             - Kevin
> >

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Feb 2016 10:36:33 +0000

> Mail domains have exactly the same syntax requirements as hostnames.

Except that trailing dots are not allowed on mail domains!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight, Humber: Northwest 5 to 7, occasionally gale 8 at first in
Humber. Moderate or rough. Rain or showers. Moderate or good.

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 21 Feb 2016 17:37:39 -0500

(no hats)

George,

I've been thinking about this post, and this general topic, for quite some time, and I think I have a coherent answer, but the WG needs to weigh in. Generally speaking, I think it deserves more attention than it's gotten from us, which is why I'm writing now.

I think I'm actually OK with normative language in an operational document, *if* that document is intended to be a BCP.  A BCP RFC gets more scrutiny than an Informational one under IETF process; it's supposed to be an IETF consensus document just as a standards track document is; and at least to my mind, it's thus defensible to use more prescriptive language. 

RFC 2026 Section 5, which talks about BCPs, seems consistent with this approach.

In the case of a BCP, there's also a sensible answer to your question about consequences of violating a MUST: The violation of a MUST in a protocol document means that the implementation isn't compliant with the protocol specification, and may not interoperate with other implementations that do comply. I think a similar argument can be made for what it means to be compliant with an operational BCP.

With that said, RFC 2119 is also pretty cautionary about being careful in the use of MUSTs and SHOULDs: it suggests staying away from those terms unless there are identifiable consequences to violating them, i.e. they're not just expressing an aesthetic preference.

This draft was posted with an intended status of Informational. I'm interested in what the authors and the WG would think of it as a BCP.

The no-response draft has a similar issue IMO, in that it's quite prescriptive about what a certain set of players (TLD operators) should do about identified problems, and silent on advice to anyone else (registrars who have customer relationships with domain owners, DNS hosting operators, DNS implementers,….)

I think the other way to frame the use of strongly prescriptive language in this document would be to leave the intended status at Informational, and introduce it as an example of what some operators consider good practice in setting up their delegations, without claiming general applicability.

Comments?

thanks,
Suzanne

On Feb 9, 2016, at 7:14 PM, George Michaelson <[email-masked]> wrote:

> its maybe me, I'm having a bad (no?) hair day, I need more caffiene.. but this feels like a "oh can't we just stop" moment.
> 
> MUST in protocols terms is good: its proscriptive, definitive language around on-the-wire.
> 
> MUST in operations terms is getting way off IETF charter, even with an ops focus.
> 
> waddaya gonna do if I don't do the MUST? you gonna blacklist me? you gonna forbid applications to flow?
> 
> I feel like capitalized normatives in operational recommendations is a big mistake. 
> 
> Sure, by all means lets recommend "please: don't put your authoritative NS eggs in one AS basket" but MUST?  MUST we? must WE?
> 
> -G
> 
> On Wed, Feb 10, 2016 at 9:39 AM, Darcy Kevin (FCA) <[email-masked]> wrote:

---

From: George Michaelson <[email-masked]>
Date: Tue, 23 Feb 2016 12:22:24 +1300

On Mon, Feb 22, 2016 at 11:37 AM, Suzanne Woolf <[email-masked]>
wrote:

> (no hats)
>
> I think the other way to frame the use of strongly prescriptive language
> in this document would be to leave the intended status at Informational,
> and introduce it as an example of what some operators consider good
> practice in setting up their delegations, without claiming general
> applicability.
>
> Comments?
>

I definitely prefer this, because its more clear that the document intent
is informative not normative, and I suspect the editorial process higher up
the food chain will take cognizance of this reviewing use of language.

What people do now, they may not do tomorrow. We don't constrain them
unnecessarily.

> Suzanne

cheers

-George

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Feb 2016 10:40:49 +1100

In message <[email-masked]>, Suzanne Woolf writ
es:
> The no-response draft has a similar issue IMO, in that it's quite
> prescriptive about what a certain set of players (TLD operators) should
> do about identified problems, and silent on advice to anyone else
> (registrars who have customer relationships with domain owners, DNS
> hosting operators, DNS implementers,...
> .)

We could just add this:

+      <t>
+	Nothing in this section precludes others testing servers
+	for protocol compliance.  DNS operators should test their
+	servers to ensure that their vendors have shipped protocol
+	compliant products.  Nameserver vendors can use these tests
+	as a part of this release processes.  Registrants can use
+	these tests to check their DNS operators servers.
+      </t>