-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 10-04-14 21:54, Patrik Fältström schreef:
> We already have too many parents that have I do not know how many > stupid rules for what various values must be in the child hosting > situation, and in many cases that make it plain impossible to do > what you want as a child. Really silly rules. While I agree with you some (TLD) parents are sometimes too pedantic, it may serve a need for parents to refuse certain use cases under their parenthood. If the rules are stupid, complain to the parent if you want to be his child. > Parent should not control the child. I don't agree you can put it that generic. Some parents only want specific use under their tree, and you cannot force a parent to grant you a use case you want. While I agree with you some parents want to control their children too much, and hence have silly rules that don't match the use case they want to accommodate, it's not always the case. Don't throw away the child with the bathwater. Let me give you a use case where this may be clear. Suppose I want to set up a network of probes under a parent "probenetwork.example.com". Every probe gets a registration, but for the probenetwork to work, every delegation MUST do DNSSEC with an algoritm the probe architecture can handle and know the whereabouts of every other probe. Every probe handles it's own delegation so queries over the network requires the zones to contain specific records the probes use. So my local policy is to only allow delegations for certain DNSSEC algorithms, and every delegated zone MUST contain a LOC record. In order not to disturb the running probe network, I only accept new delegations after I verify the child zone for that. Another example may be that as a parent, we do not want too short TTL's on the child's NS RRset because our infrastructure is hit with more queries that are useless with our zone's publication frequency. And we don't want too long TTL's as a countermeasure against ghost domains misused by botnets. Now the botnet herders may be against that policy, but it's our choice as a parent not to accommodate that use case in our tree unless someone convinces us there's a legitimate other use case that cannot live with those rules. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTS8HQAAoJEDqHrM883Agn8XYIANEHTXRmoAgK0nFN+UXLcjY3 SU8c9x0C2ZIgVFpPm1jIyyetFhzVgtHh6IzJb0BRINziRYYaXkR0sNxC0feCpboP sv4nPBw3JkY24rZ6xFJ9O+vSA3TLujp9JlgudZLAPVx/g2LuGeO7jwGXssF95I5F Uv9eFOLH6Nul3KVynN6osRaE6fgHyaFppOb/SvkCVRwpccyrGTH+jQzlHhdhL9rv ra+VG5G3pDrRND4LcRAHpev14QYhZejmyXsf4scIy/fh4SSCvUZ5wuwhTbMWPMtG ocVAZFqibdVZWJ1E/xDxSXSqqXU3lGCuDHGvFe8P+fZcUO5lHuPjBRK3NnSimag= =khPI -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
