Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00

From: Florian Weimer <[email-masked]>
Date: Sun, 04 Oct 2009 18:40:14 +0000

* Alfred Hönes:

> Andreas,
> after a first glance at draft-ietf-dnsext-rfc3597-bis-00 :

I've got a request, too: Could you please mention that RRsets of
unknown type (and perhaps class?) must be ignored in all sections?
Thanks.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 05 Oct 2009 08:57:17 +0200

> unknown type (and perhaps class?) must be ignored in all sections?

I disagree, for the answer section.  There you expect the answer type.
Ignore RRsets of unknown type in the answer section when qtype=ANY.
Otherwise, you'd expect only data that you requested there,
or CNAMEs, DNAMEs and that kind of interesting types.

Best regards,
   Wouter

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 5 Oct 2009 10:18:09 +0300

> unknown type (and perhaps class?) must be ignored in all sections?

Could you be more specific as to what situations this would apply in?
Clearly, you can't just always "ignore" RRsets of unknown type,
because that would conflict with the requirement to transparently
transmit them.

Or do you actually mean "Unexpected RRsets received in any section of
a DNS response must be ignored"?  If so, I agree with the requirement,
but I think it is outside the scope of the document because it applies
equally to known and unknown types.  For example, if you were to
receive an RP record in the authority section, you should ignore it
even if RP is a known type.
--
Andreas Gustafsson, [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Mon, 05 Oct 2009 17:33:08 +0000

> because that would conflict with the requirement to transparently

Clearly, I was a bit confused yesterday.

> a DNS response must be ignored"?

That's probably the best way of putting it, thanks.

> If so, I agree with the requirement, but I think it is outside the
> scope of the document because it applies equally to known and
> unknown types.  For example, if you were to receive an RP record in
> the authority section, you should ignore it even if RP is a known
> type.

But can you still claim you know its purpose and semnatics if it
appears in the wrong section, or with the wrong owner name?  But the
reference to the owner name clearly indicates that this is not in
scope.

Perhaps it's possible to extend the scope of 3597 just a little bit?

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 5 Oct 2009 21:33:27 +0300

Florian Weimer wrote:
> appears in the wrong section, or with the wrong owner name?

You can't; that's one of the reasons why you ignore it.

> But the reference to the owner name clearly indicates that this is
> not in scope.
> 

I'd really rather not.  Getting a draft through the IETF process is
hard enough as it is, and every additional topic discussed is one more
potential point of contention and blockage.
-- 
Andreas Gustafsson, [email-masked]

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 5 Oct 2009 11:55:02 -0700

> That's probably the best way of putting it, thanks.

Would you mind clarifying what you mean here by 'ignore'?  In
particular, are resolvers still allowed to cache unexpected
in-bailiwick RRsets as long as it doesn't affect how they otherwise
treat the response (i.e., nxdomain, nodata, referral, answer,
whatever)?  E.g., if a DNAME-ignorant cache receives a response with a
DNAME record and a synthesized CNAME record in response to an A-type
query, is it allowed to cache the DNAME record still?  If an
AAAA-ignorant cache receives a response with AAAA glue records, is it
allowed to cache the AAAA record still?

---

From: Florian Weimer <[email-masked]>
Date: Mon, 05 Oct 2009 19:09:28 +0000

* Matthew Dempsky:

> query, is it allowed to cache the DNAME record still?

It should not be returned to the client in response to a subsequent
query for the DNAME record at its owner name.  It probably should be
stripped from respones for the original question, too, but that may be
subject to debate.

> If an AAAA-ignorant cache receives a response with AAAA glue
> records, is it allowed to cache the AAAA record still?

No, certainly not.  This touches forgery resilience, too.  It's hard
to see how this would be observable anyway---the RRset can't be used
for the resolution process itself, it can't be promoted to an answer
section, and section 8 of RFC 3597 states that no additional section
processing is to be performed for unknown records, so you won't see it
there, either.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Oct 2009 15:19:57 -0400

> or CNAMEs, DNAMEs and that kind of interesting types.

Are you suggesting, then, that a new "interesting" type (were one to
be invented) that required additional processing of this sort would
necessarily have to return a synthesized answer of the relevant type
for "old" clients?  (I think that's what you mean, and I think I
agree, but I want to be specific since this affects the position the
draft takes on this question.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 5 Oct 2009 12:21:27 -0700

On Mon, Oct 5, 2009 at 12:09 PM, Florian Weimer <[email-masked]> wrote:
> * Matthew Dempsky:
>> E.g., if a DNAME-ignorant cache receives a response with a
> query for the DNAME record at its owner name.

What's your reasoning for this?

> No, certainly not.  This touches forgery resilience, too.

Your wording implies there are reasons other than forgery resilience
that the AAAA glue records should be discarded.  Is this the same as
the DNAME case, or are there additional reasons here?

> it can't be promoted to an answer section,

In practice, additional section records are regularly promoted to the
answer section.  E.g., A and AAAA records returned in the additional
section in response to an MX or SRV query.

> and section 8 of RFC 3597 states that no additional section

This seems irrelevant to me: the issue I was suggesting isn't whether
an unknown record causes additional section processing or not, but
whether an unknown record type is added because of additional section
processing.

Maybe you're assuming a cache that goes to extra effort to associate
additional section records with the answer/authority records that were
processed to add them?  If so, even in this case, caches might receive
a query for a SRV2 record which may include address records in the
additional records section; it would be sensible to be prepared to
save these, even if the cache itself is unaware of SRV2 records.

Thanks.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 05 Oct 2009 20:07:29 +0000

> What's your reasoning for this?

Mainly the observation that it would deliver incomplete RRsets for
RRSIG queries today if we didn't have DO.  Future interesting records
could show similar behavior.

> the DNAME case, or are there additional reasons here?

You don't really know to which section the additional data is related,
and if the RRset is complete (as in the RRSIG case).

> section in response to an MX or SRV query.

Let's just say that BIND is buggy in this regard, okay?

> whether an unknown record type is added because of additional section

You need two records to end up with additional section processing, so
it's at best unclear to me if this applies or not.

> processed to add them?

I'm worried about BIND 8 style caches which pass through unchecked
information of unknown provence, causing correctness issues further
downstream.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 5 Oct 2009 13:34:38 -0700

> could show similar behavior.

This is why partial RRSIG RRsets can only be sent to clients that
understand them (i.e., ones that set DO=1).  Future record types need
to be similarly designed to not cause compatibilities issues.  Most
new types being introduced don't require partial RRsets, and I don't
think the majority of new types should be punished because some new
types might have a use case for sending partial sets.

> You don't really know to which section the additional data is related,

Sorry, I don't follow why a cache needs to know this.

> and if the RRset is complete (as in the RRSIG case).

RRSIG is exceptional; see above.

> Let's just say that BIND is buggy in this regard, okay?

I disagree.  I think the spec is buggy for not adequately documenting
how DNS works in practice.  Otherwise, if caches aren't allowed to
include additional section records in the answer section, then
authoritative servers should stop performing additional section
processing on MX and SRV records.

Is there any production MTA/XMPP/whatever software whose stub resolver
looks at records in the additional records section?

---

From: Florian Weimer <[email-masked]>
Date: Tue, 06 Oct 2009 05:53:37 +0000

* Matthew Dempsky:

> understand them (i.e., ones that set DO=1).

It seems to me that the DO bit was specified for SIG and others.  It
was re-used for RRSIG later, so the behavior i described could
actually happen with RRSIG.

> Future record types need to be similarly designed to not cause
> compatibilities issues.

But RRSIG wasn't, and this is exactly my point.  Why should future RR
types behave differently from RRSIG?

> how DNS works in practice.

BIND 9 was written after RFC 2181 was published.  Even today, it is
not entirely safe to configure BIND 9 as a forwarder to anything which
isn't BIND 9 itself (and which might pass additional section data
unfiltered).

To bring this back to 3597bis, my concern is that past incidents show
that unclear responsibilities for additional section processing
between forwarders.  As a result, I think that records of unknown type
should not be blindly copied into reponses because their effect is
unknown.

> Otherwise, if caches aren't allowed to include additional section
> records in the answer section, then authoritative servers should
> stop performing additional section processing on MX and SRV records.

Not performing additional section processing is becoming more and more
common.  It also helps cut down response size for signed zones.

> looks at records in the additional records section?

Exim tried to do this, but turned out to be too difficult to implement
correctly for too little gain, so the code was removed.