On 2013-02-22, at 15:14, "Dickson, Brian" <[email protected]> wrote:
> Instead of delegating to omniscient AS112 servers, what about doing a > DNAME to a specific target "foo" (replace "foo" with what you will) in the > DNS tree? I've thought about this a bit, and I've decided that I quite like it. So, if I can paraphrase to ensure we're talking about the same thing, the current working omniscient plan involves: - custom code - some degree of discomfort, possibly unwarranted, with the NOERROR/no ANSWER approach Your idea, however, involves - hosting a known, empty zone on known nameservers - pseudo-delegating new worthy zones by provisioning a DNAME at a suitable point in another zone - no custom code - no protocol discomfort, so long as we don't gag too badly on the use of DNAME Your idea has advantages, then. Anybody could decide to sink traffic for any name at AS112++ servers by installing a similar DNAME. This would become a standard way to dispense with and junk DNS traffic; perhaps we need to think about writing this up as AS112.ARPA and make it a more general mechanism than just a place to sink default-local-zones traffic. Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't matter much, except that they need not to be named under AS112.ARPA (since that would pollute the empty zone with A and AAAA RRSets). We acquire an IPv4 /24 and an IPv6 /48 from which to number those three servers. AS112++ operators listen on those addresses, announce the corresponding routes and host an AS112.ARPA zone which is empty apart from apex SOA and NS RRSets. (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we could sign it and install a DS RRSet in the ARPA zone. This would have the side benefit that we could track from ICANN's distribution masters who is retrieving the zone, and hence where the AS112++ operators were. So, this is also AS112 with DNSSEC, and it's measurable.) We want traffic for names under D.F.IP6.ARPA (RFC4291) to be handled in an AS112 like way. We install a DNAME in the IP6.ARPA zone: $ORIGIN IP6.ARPA. D.F IN DNAME AS112.ARPA. No changes are needed to the servers which serve AS112.ARPA. We can change our minds about D.F.IP6.ARPA or add new bits of namespace to be treated similarly at any time, with no coordination required by the AS112++ operators. Once we have confidence that the AS112.ARPA zone is being hosted adequately, we could re-provision 10.IN-ADDR.ARPA, 168.192.IN-ADDR.ARPA and 16.172.IN-ADDR.ARPA and friends with DNAME and the old AS112 system can be retired. RFC 6303 could be simplified by specifying that resolvers should host an empty AS112.ARPA zone, which would give similar behaviour to hosting a long list of empty zones (not as great a reduction in traffic for the zones mentioned in 6303, but with the benefit that other zones which are AS112++ified would get caught locally without requiring updates to 6303 or resolver configuration). RFC 6304 could be replaced with updated guidance (new addresses, just hosting AS112.ARPA). We can avoid re-enragement of the IESG by not re-proposing SINK.ARPA as a way to avoid generating junk traffic, understanding that using AS112.ARPA wherever SINK.ARPA might have been used is nearly as good. This seems like a good, pragmatic path forward. I'm intrigued to hear the reactions of others to the general idea or the details of this rambling thought experiment. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
