On 3/9/19 9:35 PM, Mark Andrews wrote:
On 10 Mar 2019, at 11:27 am, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 3/9/19 7:21 PM, Mark Andrews wrote:
First of all, firewall vendors are changing their views on DNS. Lots of default blockage have gone and UPDATE is no more dangerous than QUERY.
Checkpoint have removed their default QUERY blocks. Similarly Juniper have also remover their default blocks. If there are blocks on UPDATE they can similarly be removed. Nameservers that support UPDATE don’t need external protection.
UPDATE has had fine grain authentication for 15+ years since the invention of TCP, TSIG and SIG(0). See update-policy in BIND for a example. TCP is still hard to spoof and is useful for some updates especially in the reverse tree.
Yes, but there are zillions of SOHO routers deployed that still implement such blocks in firmware, are unlikely to be updated, and will be replaced only slowly.
It's been awhile, but last time I looked, I couldn't find a single DNS registry that implemented UPDATE. For better or worse, many organizations (some large ones) use godaddy or similar services for their public-facing DNS.
Keith
Mostly because they are hooked on EPP.
Perhaps, but I somehow doubt that's the only reason. It seems to have
become widely accepted that the way ordinary mortal zone maintainers
update their RRs is via the registrar's web UI. And why would the
registrars bother supporting UPDATE if clients can't use it due to
blocking? After all, customer dependence on the registrar's UI (or
proprietary API) is yet another thing that deters customers from
changing registrars.
Note there really isn’t a reason UPDATE can’t
be used to drive EPP updates.
Perhaps another piece of the puzzle (i.e. part of the solution). Though
I don't think that will address the issues with router firmware.
While below says TSIG this works equally as well with
SIG(0).
https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/
If zone maintainers can't directly send updates to their servers, what
does it matter?
To be clear, I don't think that this part of the problem is (mostly) a
protocol issue except perhaps that the most expedient way to address the
blocking problem might be to allocate another port or let update be
port-agile. But I strongly suspect that there are several practical
barriers like this to widespread use of DNSSEC, which impacts DANE and a
lot of other things that we need very badly.
More generally, if we took a step back and asked ourselves "In what ways
are people not using DNS, or not using DNS the way we think they
should?" (and "why?"), we might uncover several things like this that
deserve at least some attention. The fixes might be simple tweaks -
that would be great - but we might be much better off for asking those
questions.
Keith
