[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