FWIW, this was first broached on the AS112 operators ML. Thread here:
https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000209.html
Hope this contributes to the discussion.
On Thu, 14 Mar 2013, Joe Abley wrote:
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
wfms
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
