On Mon, Apr 14, 2014 at 7:09 AM, Antoin Verschuren <antoin.verschu...@sidn.nl> wrote: > -----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.
Just checking -- do you want any action *on this doc*? I *think* that we are generic/non-prescriptive enough that you can implement whatever policy you want... If you'd like something additional (probably in Section 6.2) saying something like "Acting on CDS/CDNSKEY records may be subject to local policy" or something, please help by providing text... I *think* that we are generic enough that this is covered, but... W > > - -- > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
