Hi,
I've been brewing an idea for formalizing methods to perform
modifications to catalog zones (CATZ) for a bunch of purposes:
* Protect the zones important to the consumer by filtering out certain
member zones according to some rules;
* Protect the consumer by filtering out property values or whole
properties that are deemed harmful;
* Convert and merge consumed Catalog Zones into a newly produced
Catalog Zone for downstream servers. For example, the hidden primary of
an anycast DNS service provider can consume customers' Catalog Zones,
combine them into one zone and remove or replace all the primaries
listed in the zone by its own address for the benefit of the anycast
service nodes;
* Assign priorities to different Catalog Zones for conflict
resolution, in the absense of CoO properties.
This idea was hatched after the DNS Hackathon in Stockholm last March,
and we've been chatting about it on chat.dns-oarc.net to gauge if others
feel it would be helpful and also to figure out a good way to do it. Now
I feel it's time to introduce the idea to a wider audience.
Looking at prior art, RFC2136 (DNS UPDATEs) already specifies a method
to modify zones, and also addresses edge cases like preventing the zone
from ending up in an invalid state, such as having a CNAME combined with
other RRs for the same name.
RFC2136 specifies a protocol for making changes remotely, while what
we're thinking here is processing received CATZ(s) locally before
consuming. This means we're interested mostly in the concepts RFC2136
introduced, and not much else.
Another big difference is that RFC2136 is aimed at changing a singular
or only a small number of RRs at a time, while this proposal aims at
processing a whole CATZ. Or even multiple CATZ.
RFC2136 is quite static in nature, so its ideas would need to be
extended with at least the following:
* Setting and using variables in labels and RR values
* Label wildcarding in matches, or possibly even regexps
* Ability to match and modify the name and the value of an RR
independently
These additions could be enough for the simpler use cases with one input
CATZ and one output CATZ, I think. However, for the more complex use
cases of combining multiple input CATZ into one output CATZ, I think
we'll also need:
* Conditional execution
* Iterators
* Subroutines
Finally, here's a thought experiment of how all of the above would
actually be used at an anycast DNS secondary provider:
The anycast provider's control node would fetch CATZs from customers,
and sanitize them before use:
* Remove all listed primaries with invalid (e.g. RFC1918) addresses
* Remove all listed zones with invalid or unacceptable names
* Remove all dangling properties, e.g. those related to removed zones
* Add or modify allow-query properties to allow internal debugging
* Add or modify allow-transfer properties to allow transfers to
anycast service nodes
Then the CATZs would be used to fetch all their zones to the anycast
control node. If a zone is listed in more than one CATZ, figure out the
best candidate according to the "coo" property and the order in which
the CATZs are configured.
The second stage would combine all the customer CATZs into one CATZ that
"gets sent" to the anycast service nodes:
* Filter out or fix name collisions in the CATZs
* Replace all listed primaries with the address of the control node
* Remove all allow-query and allow-transfer properties
* Add some static RRs
I'm not an anycast DNS provider, although I use the services of several.
I hope some real anycast provider can weigh in on what else would need
to be done.
As Peter van Dijk commented in the aforementioned chat, this is not
something that necessitates an RFC. DNS software vendors could just come
up with their own solutions that could even be competitive. But I feel
that there are hidden problems lurking under the surface that are
complex enough that we should at least come up with guidelines for such
implementations. Transferability from software to software, aka
interoperability of solutions, could also be nice.
What do you think should be the next steps? Problem statement I-D?
Best Regards,
--
+358 44 9756548 / http://www.trex.fi/
Aleksi Suhonen / TREX Regional Exchanges Oy
You say "potato", I say "closest-exit."
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
