[dns-operations] Any DNAME usage experience?
Meir Kraushar
meir at isoc.org.il
Mon Mar 30 10:35:40 UTC 2020
Greetings all
Thank you for responding, that's very kind.
As some of the consideration are less relevant, with your permission I will
refine my question:
We are looking into implementing IDN zones (finally..)
The IDN will be a mirror of an existing SLD (we are one of the few
registries still using SLDs. No registrations under the ccTLD. yet..)
So if I take for example the "co.il" domain:
- It holds few hundred K delegations
- It holds only delegations. No MX, etc..
- It is dnssec signed, so will be the IDN
- Obviously resolver compliance is very important (Knot support is
questionable?)
it's new sibling would be: xn--mebbq.xn--4dbrk0ce
The immediate question is of course to consider the "out of the box" DNAME
solution .
I saw few notes from other registries dealing with this (cn & JP for
example), but couldn't find definitive conclusions, mainly due to the fact
that these were quite old.
>From what I read in the responses it looks like DNAME is still not ready
for the task.
Or am I wrong?
Thanks again!
On Mon, 30 Mar 2020 at 07:12, Brian Somers <bsomers at opendns.com> wrote:
> A few interesting things about DNAMES:
>
> * For unsigned zones, resolvers don’t have to do anything, but the DNAME
> itself can break
> - The synthesized CNAME makes the resolver “just work”
> - RFC 3597 section 7 says that resolvers MUST uncompress DNAMEs. If
> they don’t, they may serve corrupt RRs
> So a nameserver that serves compressed DNAMEs must be “fixed” by the
> resolver.
> * For signed zones three things can break
> - RFC 4034 section 6.2 explicitly says that DNAMEs must be lowercased
> before their signatures are validated
> - Synthesized CNAMEs are not signed, so resolvers have to use the DNAME
> to validate the CNAME.
> The DNAME must be signed and it must dictate the target of the CNAME
>
> Our (OpenDNS/Umbrella) resolver ignored DNAMEs up until recently. The
> current release running in production gets just about all of the above
> wrong :(. FWIW, the next release (just waiting to go out!) fixes all of the
> above!
>
> —
> Brian
>
> > On Mar 29, 2020, at 4:23 AM, Meir Kraushar via dns-operations <
> dns-operations at dns-oarc.net> wrote:
> >
> >
> > From: Meir Kraushar <meir at isoc.org.il>
> > Subject: Any DNAME usage experience?
> > Date: March 29, 2020 at 4:23:29 AM PDT
> > To: dns-operations at lists.dns-oarc.net
> >
> >
> > Hi
> >
> > I looking for insights, usage experience regarding DNAME record
> implementation.
> > If any compatibility issues, client side problems, resolvers etc?..
> > Highly apperciate If anyone could share their knowledge.
> >
> > Take care and stay safe.
> > Thank you!
> >
> >
> >
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200330/f02d4f70/attachment.html>
More information about the dns-operations
mailing list