Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Mark Andrews <[e-mail]>]

> On 8 Nov 2018, at 2:30 pm, Brian Dickson <[e-mail]> wrote:
> 
> 
> 
> On Thu, Nov 8, 2018 at 10:06 AM Dan York <[e-mail]> wrote:
> Brian,
> 
> DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still massively distributed and decentralized (even though we do have ongoing centralization/consolidation), getting a new RRTYPE deployed means:
> 
> - upgrading all the authoritative servers to support the new RRTYPE
> - upgrading all the *provisioning software* at the thousands of DNS registries, DNS registrars, DNS hosting operators to support the new RRTYPE
> - upgrading the *millions* of recursive resolvers to know what to do they receive the new RRTYPE in a query response
> 
> 
> Actually, for this specific case, the only places that require support (at least initially) are:
> 	• Authority servers (because, duh), unless they already support it, via hard-coded types and RDATA generically (maybe not overly relevant, but covering all cases)
> 	• Authority provisioning systems for DNS hosting services (at least one hosting service has to do so before the type is "live") (also possibly supported by the hard-coded mechanism?)
> 	• Clients (because someone has to request the new type)
> For new RRtypes, registries, registrars, and their provisioning services do NOT need to support them; the new types are in the zones only.
> New RRtypes which do not require any "additional" processing, do NOT strictly speaking require resolver support, since resolvers handle unknown RRtypes. (Mark A can quote you the RFC, and I think has recently.)

It's RFC 1034 and RFC 1035.  AKA STD 13.

The only components that have *ever* needed upgrading for a new type from the very beginning for a where the authoritative servers for the zone as they needed to be able to load the record. Recursive servers and stub resolvers where all supposed to treat unknown record types and blobs of data.  DNS records are named TVLs, name compression was only every valid on well known types and the only possible well known types are those listed in STD13.  Anything that dropped or blocked unknown types was not STD 13 compliant.

RFC 3597 reduced the list of components that needed to be updated to NONE though it was still desirable to update the primary server and provisioning systems.

RFC 1034

   3. General lookup function

      This function retrieves arbitrary information from the DNS,
      and has no counterpart in previous systems.  The caller
      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
      matching RRs.  This function will often use the DNS format
      for all RR data instead of the local host's, and returns all
      RR content (e.g., TTL) instead of a processed form with local
      quoting conventions.

When the resolver performs the indicated function, it usually has one of
the following results to pass back to the client:

   - One or more RRs giving the requested data.

     In this case the resolver returns the answer in the
     appropriate format.

   - A name error (NE).

     This happens when the referenced name does not exist.  For
     example, a user may have mistyped a host name.

   - A data not found error.

     This happens when the referenced name exists, but data of the
     appropriate type does not.  For example, a host address
     function applied to a mailbox name would return this error
     since the name exists, but no address RR is present.

It is important to note that the functions for translating between host
names and addresses may combine the "name error" and "data not found"
error conditions into a single type of error return, but the general
function should not.  One reason for this is that applications may ask
first for one type of information about a name followed by a second
request to the same name for some other type of information; if the two
errors are combined, then useless queries may slow the application.

> On the plus side, I can confirm at least one hosting/authority service will do this as soon as a stable spec is available (i.e. HTTP and a code point early allocation).
> 
> That should take what, a couple of weeks or so?
> 
> It'd be nice to ask the browser folks to start using something that is already deployed (however small the initial user base is, with the expectation of viral uptake.)
> 
> 
> DY> Which does means we do need to get started NOW [...]
> 
> Thanks for bringing this all together,
> Dan
> 
> You're welcome, and thanks for participating in the discussion.
> 
> Brian 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]