[as112-ops] [DNSOP] Adoption of <draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work item? (fwd)
Joe Abley
jabley at hopcount.ca
Thu Jan 9 17:43:22 UTC 2014
On 2014-01-07, at 22:23, Aleksi Suhonen <as112-ops at trex.fi> wrote:
> Has anyone been working on this in the mean time? An earlier email referred to the following code, but it doesn't do what was advertised:
>
> http://code.google.com/p/evldns/source/browse/trunk/as112d.c
I don't think Ray has done anything else with that, but when I looked at the code it seemed like it should do what Warren's last omniscient draft said it should do. I'm sure he'd be interested in hearing if there are bugs.
> Joe Abley wrote:
>> 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
>
> I understand that DNAMEs cause auto-generated CNAMEs which could be abused to seriously clog up the caches of recursing DNS servers if used with IPv6 reverse zones. Is this true?
That's interesting. I guess the extent of the potential damage depends on the installed base of resolvers that support DNAME.
My immediate thought is that anybody who really cares about this problem is likely already running code recent enough to allow the DNAME itself to be cached, and the synthesised CNAMEs to be discarded (e.g. for reasons of performance in the case of code bases that pre-date DNAME, or because more recent alternatives came with DNAME support in their initial release).
Do you have operational war stories that suggest this is significant? It's difficult to imagine an experiment that could test the theory without causing collateral damage in the event that this really is a problem.
>> 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).
>
> BTW, blackhole-{3,4} only have AAAA records. I am of the opinion that we should request IANA to reserve IPv4 addresses for those names as well. Regardless of which model we go for or what zones are delegated there.
That's the approach we took (the thinking has matured somewhat in the last eleven months). The most recent description of the proposal is here:
http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname
That draft is in a bit of a holding pattern, waiting for the newly-partially-reconstituted dnsop chairs to give direction as to whether we want to roll revised RFC6304-style text into this document, or publish a separate replacement for 6304 (my preference is the latter).
> I also think it would be beneficial to have the proper local mirror name and the proper local mirror management email contacts in the SOA for AS112.ARPA. (Except if the zone is signed and AXFR'ed from ICANN.)
I like that idea, too. We could preserve some more general RDATA for people who choose not to put their own details in there (for whatever reason).
Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/as112-ops/attachments/20140109/7ac01984/attachment.pgp>
More information about the as112-ops
mailing list