Subject: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

From: Shane Kerr <[email-masked]>
Date: Thu, 14 Nov 2019 15:40:25 +0100

Hello,

We just implemented DNAME support on an authoritative server that 
already implements giving an HINFO response to ANY queries, as described 
in RFC 8482.

RFC 8482 is clear about not allowing the HINFO response if there is a 
CNAME record at the name. While no rationale is given in the RFC, it 
seems clear that this is because a CNAME cannot exist with any other 
record, so replying with HINFO might break things, or at least cause 
confusion.

What is not clear is what to do DNAME subtree responses. (For ANY 
queries that match the name of the DNAME record itself, we apply the 
normal RFC 8482 logic, which seems reasonable.)

DNAME provides synthesized CNAME answers, presumably to help resolvers 
that do not support DNAME. On the one hand, if this is important then 
probably performing the normal DNAME logic and returning these 
synthesized records makes sense. On the other hand, it seems unlikely 
that any resolver actually sends ANY queries to authoritative servers. 
However RFC 8482 seems to disagree with this, since the 
resolver/authoritative interaction is specifically called out:

    Alternative proposals for dealing with ANY queries have been
    discussed.  One approach proposes using a new RCODE to signal that an
    authoritative server did not answer ANY queries in the standard way.
    This approach was found to have an undesirable effect on both
    resolvers and authoritative-only servers; resolvers receiving an
    unknown RCODE would resend the same query to all available
    authoritative servers rather than suppress future ANY queries for the
    same QNAME.

We have chosen to perform CNAME synthesis for ANY queries that match a 
DNAME subtree, based on the logic that if CNAME is special when added by 
hand then it is probably also special when synthesized.

I'm interested in what the DNSOP group thinks the correct behavior is, 
and also if it makes sense to update RFC 8482 to clarify the expected 
behavior for DNAME.

Cheers,

--
Shane

---

From: "John Levine" <[email-masked]>
Date: 14 Nov 2019 13:50:25 -0500

>hand then it is probably also special when synthesized.

That seems reasonable, but since the point of 8482 was that ANY
queries to authoritative servers are at best silly, it hardly matters.

R's,
John

PS: I'm also coming to the conclusion that if you think DNAME solves
your problem, and your problem isn't the arcane IPv6 rDNS renumbering
for which it was invented, you don't understand DNAME.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Nov 2019 14:31:42 -0500

> On Nov 14, 2019, at 9:40 AM, Shane Kerr <[email-masked]> wrote:
> 
> We have chosen to perform CNAME synthesis for ANY queries that match a DNAME subtree, based on the logic that if CNAME is special when added by hand then it is probably also special when synthesized.
> 
> I'm interested in what the DNSOP group thinks the correct behavior is, and also if it makes sense to update RFC 8482 to clarify the expected behavior for DNAME.

With a signed zone, you have no choice but to provide the DNAME,
the closest encloser is the DNAME owner which has "DNAME" in its
type bitmask.

Thus the correct response is:

	example.net. IN DNAME example.org.
	example.net. IN RRSIG DNAME ...
	sub.example.net. IN CNAME sub.example.org. ; synthesized

This can be the entire response with NOERROR as the RCODE.
For a recursive resolver can chase the CNAME as appropriate.

-- 
-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 15 Nov 2019 13:26:39 +0000

Shane Kerr <[email-masked]> wrote:

> On the other hand, it seems unlikely that any resolver actually sends
> ANY queries to authoritative servers.

This happens when the resolver's cache doesn't have an entry for the name,
so the resolver sends the ANY query to the authoritative servers. It's
rare because ANY queries are rare, but it's easy to make it happen when
you want it to.

> We have chosen to perform CNAME synthesis for ANY queries that match a DNAME
> subtree, based on the logic that if CNAME is special when added by hand then
> it is probably also special when synthesized.

That's correct.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: North 5 to 7, occasionally gale 8 at first, except
in Irish Sea. Moderate or rough, becoming slight in northern Irish Sea.
Showers. Good, occasionally moderate.

---

From: Tony Finch <[email-masked]>
Date: Fri, 15 Nov 2019 13:28:54 +0000

> for which it was invented, you don't understand DNAME.

We're using it to reduce the number of IPv4 reverse DNS zones, for which
it works nicely. Basically, classless reverse DNS for short prefixes.

https://www.dns.cam.ac.uk/domains/reverse/

Tony.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Nov 2019 12:36:11 -0500

> On Nov 14, 2019, at 1:50 PM, John Levine <[email-masked]> wrote:
> 

As you may recall,

   http://mailarchive.ietf.org/arch/msg/dnsop/adrEUoWPq1EoxonkvcCJCnEkcFg

the .tw registry employs a DNAME to identify their traditional and simplified
Chinese IDN TLDs (simplified is a DNAME alias for traditional).  For example:

台湾.                   DNAME   台灣.
日曆.台湾.              CNAME   日曆.台灣.
日曆.台灣.              SOA     brit.ns.cloudflare.com. [email-masked]. ...

Or equivalently:

xn--kprw13d.		DNAME	xn--kpry57d.
xn--wgvnt.xn--kprw13d.	CNAME	xn--wgvnt.xn--kpry57d.
xn--wgvnt.xn--kpry57d.	SOA	brit.ns.cloudflare.com. [email-masked]. ...

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 16 Nov 2019 22:41:51 +0800

In article <[email-masked]> you write:
>Chinese IDN TLDs (simplified is a DNAME alias for traditional). ...

I know.  I'm wondering how many of those DNAME'd names actually work.

Remember that it's invalid for an NS or MX to point to a CNAME so I assume
it's equally invalid for them to point to a DNAME.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sat, 16 Nov 2019 07:08:32 -0800

On Thu, Nov 14, 2019 at 6:40 AM Shane Kerr <[email-masked]>
wrote:

> CNAME response is small was the main reason as well as making sure things
keep working.

> I agree not mentioning DNAME in RFC8482 is an omission feel free to file
an errata.

> Our experience at Cloudflare with ANY floods is that most/many resolvers
implement
"exact match" caching i.e. if what is explicitly asked for in this case ANY
then is in cache, then forward.
Thus the only way to shut them down is to give them something to cache in
the "foo.bar. ANY" slot.

> Just file an errata

> Cheers,
>
> --
> Shane
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 16 Nov 2019 23:33:50 -0500

> it's equally invalid for them to point to a DNAME.
 
They couldn't point to a DNAME, but they could point to a target that
would resolve through a DNAME-using resolution.  To my knowledge there
is no explicit prohibition, but if you asked in the right way (such as
without DO set) you'd get a CNAME synthesized, which would mean that
the thing would break sometimes and not other times.  Seems even less
good for that reason.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 16 Nov 2019 23:35:01 -0500

Apologies, all, that was supposed to go off-list.  I have an employer
(ISOC), not speaking for it, &c &c.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 17 Nov 2019 01:20:43 -0500

> On Nov 16, 2019, at 9:41 AM, John Levine <[email-masked]> wrote:
> 

There's no need for NS RRs pointing the non-canonical names, the DNAMEs
are there for continuity (or to support alternative representations) of
actual application services.  That's not a real barrier to DNAME use.

And speaking of application services, the prohibition of MX pointing to
CNAME is not enforced by any MTA I'm aware, and a small, but non-negligible
fraction of domains do have MX RRs that point to CNAMEs.

In my DANE survey, out of of 8503 MX hosts, 130 (1.5%) are CNAME aliases.
None presently via DNAMEs, but Tony Finch has a DNAME redirecting TLSA
lookups:

  _tcp.hummus.csx.cam.ac.uk. IN DNAME _hummus_tcp.exim.org.

and three other domains also have DNAME-redirected _tcp subtrees.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Nov 2019 12:35:48 +1100

> On 17 Nov 2019, at 17:20, Viktor Dukhovni <[email-masked]> wrote:
> 

Just because broken configuration don’t always cause problems doesn’t mean
that they don’t sometimes.  MTA’s need to know what names they are known
by to properly remove MX records from consideration when performing store and
forward. Email forwarding loops still occur.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Nov 2019 12:37:53 -0500

> On Nov 17, 2019, at 8:35 PM, Mark Andrews <[email-masked]> wrote:
> 

Postfix ignores the names, and does loop elimination by IP
address.  It also detects loops when it sees its own name in
the 220 banner or EHLO reply.  Relying on just canonical names
for loop elimination is not enough.  The same IP address can
can have multiple names even without CNAMEs.

Other MTAs may look at the names and not the addresses, but
I would hope that they also employ additional loop detection
mechanisms, and there's ultimately the hop (Received header)
count.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Nov 2019 13:00:54 -0500

a correct implemention of smtp could pick up the a and aaaa from additional data without making any additional queries. it could also ignore cname records in the a/aaaa response and declare that the a/aaaa owner was wrong.

we can't break working behaviour no matter what the statistics show. a draft that said clients can expect this would also have to say servers should not expect clients to expect this.

vixie

⁣Get BlueMail for Android ​

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Nov 2019 15:56:04 -0500

> On Nov 18, 2019, at 1:00 PM, Paul Vixie <[email-masked]> wrote:
> 
> A correct implementation of SMTP could pick up the A and AAAA from
> additional data without making any additional queries.

Some resolvers return "minimal" answers and don't include additional
records.  MTA's can't rely on getting addresses in additional records,
even if the name is canonical.  If the authoritative server send the
additionals along, then the (local by BCP) resolver the MTA is using
will already have the data cached, and the followup query is fast.

> It could also ignore CNAME records in the A/AAAA response and declare
> that the A/AAAA owner was wrong.

Yes, an implementation that does not support CNAMEs could do that.
My point was that in practice MTAs do support CNAMEs, and they are
deployed for real domains, and work well enough for the operators
to continue to use them.

> We can't break working behaviour no matter what the statistics show.

The MX -> CNAME domains already exist, and receive email.  The
mainstream MTAs don't object, and so at this point the thing that's
somewhat of sync with practical reality is the RFC.  We can try to
insist that the RFC is right and world is wrong, but I've moved on.

> A draft that said clients can expect this would also have to say
> servers should not expect clients to expect this.

There could be such a draft, but for now at least the major MTAs just
accept CNAMEs informally and get the mail delivered.

Yes, it helps to not get too creative.  Just today I helped an
operator squash an ESMTP STARTTLS advertisement failure, which
broke inbound email delivery from one large DANE-enabled sender.
The problem was a odd-looking (but mostly benign) EHLO response
anomaly:

	250-"HELO OK."
	250-...
	250-STARTTLS
	...

instead of:

	250-fqdn.example
	250-...
	250-STARTTLS
	...

This was find for most senders, but not all.  One particular
large sender's ESMTP parser seems to choke on the double-quoted
"HELO OK.", and never sees the STARTTLS, and with DANE TLSA
published, declines to send in the clear.

At the end of the day, operating outside the RFC carries some risk,
and one should not be cavalier in deploying creative deviations from
the spec.  However, post-MX CNAME indirection is seen to useful by
some to stick to the spec, and since MTAs tolerate this, it is used
in the wild.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Nov 2019 16:53:45 -0800

Viktor Dukhovni wrote on 2019-11-18 12:56:> ...
> some to stick to the spec, and since MTAs tolerate this, it is used

a lot of things happen in the wild. that's why we call it "the wild".

every protocol recommendation should be thought of as rebuilding the 
airplane during flight -- to be done with utmost caution. "just do 
whatever mostly works" is in no way cautious.

-- 
P Vixie