On Jun 28 2013, Joe Abley wrote:
Hi all,
As promised, here's a draft which describes the alternate approach
(alternate to the omniscient, custom-code route that our other document
proposes) of using DNAME to extend AS112 service.
This approach does seem quite attractive.
A point that maybe needs mention in section 6, in the context of caching.
For a DNAME-unaware resolver, this depends on the TTL of the synthesised
CNAME. RFC 2672 (Aug 1999) specified that this should be zero, and this
wasn't officially changed until RFC 6672 (June 2012) re-specified it as
a copy of the TTL of the DNAME. It perhaps ought to be emphasised that
the authoritative nameservers for zones containing DNAMEs referencing
EMPTY.AS112.ARPA should be using the later specification.
Does one have to worry about DNAME-broken resolvers? That is, ones that
choke on the presence of the DNAME in the answer and never get as far as
looking at the synthesised CNAME, effectively treating it as a SERVFAIL.
We certainly had some problems of that sort back in early 2011 when
we started using DNAMEs for reverse lookups of IPv4 addresses in
128.232.128.0/17. It's the reason why for 128.232.233.0/24 we use
256 CNAMEs rather than one DNAME.
<sales pitch>
This one has the side-effect of supporting DNSSEC-validatable redirection to
AS112 nodes!
</sales pitch>
If the DNAME is signed, what effect is that going to have on overriding
local definitions of the redirected names (as in BIND's "automatic empty
zones")?
Of course if the scheme goes ahead, EMPTY.AS112.ARPA itself becomes an
obvious candidate for such a local definition as well.
--
Chris Thompson University of Cambridge Computing Service,
Email: [email protected] New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
