________________________________
From: Wes Hardaker <[email protected]>

> The current documents do not require HTTP.  It is *one* method available
> for obtaining data, but not mandatory to implement.  Technically, no
> method is mandatory.
>
> The expectation is that resolvers should get it in whatever way they prefer.

draft-hardaker-dnsop-root-zone-publication-points says:


   The list of IANA root zone data publication points, available at TBD-
   URL, may be used to discover where the IANA root zone data can be
   fetched from.

Presumably that is an HTTP URL.

I believe this HTTP dependency could be resolved by encoding this list into DNS 
RDATA in some fashion.  This would remove the dependency on HTTP.

Editorially, I believe it would be valuable to have a clearly defined, minimal 
"profile" of Local Root that does not depend on HTTP (or other extraneous 
protocols).  We should offer a clear sub-specification that compact resolvers 
can point to: "we implement this part".

As a matter of architectural simplicity, I also have concerns about this 
draft's apparent duplication of functionality related to DNS zone delegation 
and zone transfers.  To the extent possible, I would like to see the root zone 
using the same protocols and technologies as any other zone.  If we feel that 
AXFR/IXFR queries to the indicated nameservers are not sufficient for root zone 
transfers, perhaps we should define additional zone transfer mechanisms that 
could apply to any zone:
 * A standard for secondary nameservers to download zone contents over HTTP 
would have utility far beyond the root zone.  (This has been deployed 
extensively even without a standard, in closed environments.)
 * A new DELEG parameter could indicate which access modes (querying, AXFR, or 
IXFR) are publicly available on this endpoint.  This would combine naturally 
with DELEG transport selection to advertise support for AXFR-over-TLS (etc.) 
without needing a new registry of URI schemes like "axfr:", opening new 
questions about how TLS is authenticated, etc.

--Ben
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to