[dns-operations] Zone cut on _tcp.example.ca

[Edward Lewis]

On 2/9/16, 19:24, "dns-operations on behalf of Robert Edmonds"
<dns-operations-bounces at dns-oarc.net on behalf of edmonds at mycre.ws> wrote:

>I've run into secondary DNS service providers that have a special rule
>against zone names that look like this: "www.example.com".  Apparently
>it causes too much of a support burden when customers meant to configure
>"example.com" instead.

For the most part, any string of octets up to the length limit can be in a
zone and own an NS record set.  Except maybe for "*" with DNSSEC in place,
as noted below in this message.  The caveat is that certain situations may
lead to confusion by software relying on the DNS and humans looking at a
business card.

What is acceptable for registration is a subset of what is possible in the
protocol.  Registration has many goals including one of not enabling
confusion for anti-social reasons.  That goal is not shared by the DNS
protocol (and is why there's a thread on non-LDH names owning NS sets).

(From RFC 4592)

4.2.1.  Discarded Notions

   Prior to DNSSEC, a wildcard domain name owning a NS RRSet appeared to
   be workable, and there are some instances in which it is found in
   deployments using implementations that support this.  Continuing to
   allow this in the specification is not tenable with DNSSEC.  The
   reason is that the synthesis of the NS RRSet is being done in a zone
   that has delegated away the responsibility for the name.  This
   "unauthorized" synthesis is not a problem for the base DNS protocol,
   but DNSSEC in affirming the authorization model for DNS exposes the
   problem.

   Outright banning of wildcards of type NS is also untenable as the DNS
   protocol does not define how to handle "illegal" data.
   Implementations may choose not to load a zone, but there is no
   protocol definition.  The lack of the definition is complicated by
   having to cover dynamic update [RFC2136] and zone transfers, as well
   as loading at the master server.  The case of a client (resolver,
   caching server) getting a wildcard of type NS in a reply would also
   have to be considered.

   Given the daunting challenge of a complete definition of how to ban
   such records, dealing with existing implementations that permit the
   records today is a further complication.  There are uses of wildcard
   domain name owning NS RRSets.

   One compromise proposed would have redefined wildcards of type NS to
   not be used in synthesis, this compromise fell apart because it would
   have required significant edits to the DNSSEC signing and validation
   work.  (Again, DNSSEC catches unauthorized data.)

   With no clear consensus forming on the solution to this dilemma, and
   the realization that wildcards of type NS are a rarity in operations,
   the best course of action is to leave this open-ended until "it
   matters".





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160210/d1acff58/attachment.bin>