In message <[email protected]>, Matthias-Christian Ott writes:
> On 02/09/15 03:22, Mark Andrews wrote:
> > In message <[email protected]>, Matthias-Christian Ott writes:
> >> Has this problem been addressed somewhere or is there an ongoing effort
> >> that would address it?
> >
> > https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/
> >
> > Provided a mechanism to do this which allowed fine grain access control
> > base on tsig / sig(0) name.
> >
> > It could also use SIG(0) instead of TSIG though the draft doesn't state
> > that.
>
> A variant of the mechanism proposed in the draft is certainly a simple
> solution.
>
> However, I don't think it will work in the current market. Most
> registrars and nearly all of their customers have no interest in this
> (ask a randomly selected registrar about DNSSEC and IPv6). So there is
> no competitive advantage or incentive to implement it.
This is partially a chicken and egg issue. There is no protocol
specified so no one is willing to invest the time to get a protocol.
As there is no protocol no one complains about it not being there.
Apple have registered _dns-upate._udp SRV as a mechanism to redirect
updates to a alternate server. MacOS uses this to do its dynamic
updates (See System Preference -> Sharing -> Edit). This could just
be pointed at a UPDATE only server that examines the ZONE and UPDATE
sections for the correct registrar then forwards the update message
provided it has a TSIG or SIG(0) signature.
This UPDATE only server would take less than a day to write.
open listening sockets
parse message
check for signature - return NOTIMP if not found.
check ZONE section for sanity
look at first name in UPDATE section to determine registrar
forward update using a per registrar txid space for TSIG
so you can de-mux replies.
forward update using same txid for SIG(0) ensuring that
you don't have multiple txid outstanding on the same socket
so you can de-mux replies.
relay reply fixing restoring txid for TSIG.
Named does all this for UPDATE when running as a slave with
update-forwarding enabled, with the exception of looking up the
registrar, so this is *nothing* new. You are looking at 16 year
old code paths here.
> I looked at many registrars over the last weeks and found that their
> proprietary APIs provided by most registrars are often incomplete and
> low quality (some PHP script that translate SOAP or REST API calls to
> EPP or a proprietary protocol of a registry) because they are developed
> for resellers of the registrars who apparently don't care and have very
> low requirements (often also only available to resellers).
>
> It's hard to find DNS service providers that even offer TSIG for zone
> transfers, most providers sadly authenticate zone transfers through IPv4
> addresses.
>
> Very recently I scraped the websites of ICANN and major European
> registrars and tested whether the websites of several hundred registrars
> are available over IPv6 and whether the corresponding zone is signed
> with DNSSEC. Fewer than a dozen registrars worldwide fulfil this
> criteria and fewer than a handful of registrars have an API that allows
> you to change your NS RRs and DNSSEC keys.
>
> So to sum it up: Registrars are very far behind and haven't even
> implemented DNSSEC and IPv6. There are to too many registrars and most
> of them have customers who simply do not care as long as their website
> is somehow reachable over IPv4 and any additional service just means
> wasted time for them. Asking them for an even less frequently used
> feature is hopeless and pointless (its cheaper to become a registrar
> yourself than to pay the registrar to implement this feature). I think
> if there can be a solution it should not involve registrars. On the
> other hand most registries also do not directly deal with registrants,
> so I'm not sure who should implement the solution to this problem.
>
> To prevent a longer discussion: I know that most statements and
> observations that I made about are claims and except for the statistics
> about DNSSEC and IPv6 deployment I have no evidence to back them up
> other than the fact that I spent a considerable amount of time studying
> the market.
>
> - Matthias-Christian
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
