Subject: [BEHAVE] FW: DNS64 draft feedback

From: Dave Thaler <[email-masked]>
Date: Fri, 4 Jun 2010 02:02:22 +0000

Below are some IETF last call comments on this draft, which were sent to me from Jeff Westhead ([email-masked]<mailto:[email-masked]>)

-Dave

From: Jeff Westhead
Sent: Thursday, June 03, 2010 6:16 PM
To: Dave Thaler
Subject: DNS64 draft feedback

Here is my feedback. A lot of my issues I think stem from the fact that the draft authors envision DNS64 as a component grafted into existing DNS implementations, which would give them all kinds of DNS protocol handling for free. I'm not sure this is a suitable approach to take in this context. I think some acknowledgement should be made of various DNS protocol issues that will have to be taken into account during DNS64 processing. Some implementors may choose to build a DNS64 server from scratch.

I also have some reservations about the piecemeal approach to working configurations. When DNSSEC is used, the DNS64 server is fairly broken. Instead DNS64 must be implemented on clients. This is ok, except that a) it is up to administrators and/or implementors to ensure that only working DNS64 deployment models are used, and b) if DNS64 is implemented on clients then DNS64 configuration becomes more difficult to distribute.

Specific feedback on draft-ietf-behave-dns64-09:
*        There is no mention if the following aspects of the DNS protocol SHOULD or MUST be implemented or otherwise handled by DNS64:
o   Listen on UDP, TCP, or both
o   EDNS support, although this is implied by the use of the DO bit
o   If EDNS is supported, is support for UDP packets of a specific size mandated?
o   Caching of remote query results
o   When synthesizing AAAA records, what if the response becomes too large
o   TC bit handling, either in responses received to remote servers or in responses sent to clients
o   Packet assembly may be complicated if the DNS64 server uses a larger EDNS packet size than some of its clients; or if truncation applies to some clients but not others because of client EDNS packet size variations
o   Note that all of these items above may be handled already if one treats DNS64 as a "logical function" as noted in the first paragraph of Section 5; however there are many elements of the draft, such as anything discussing the DO and CD bits, and requiring the algorithm to generate remote queries, where this definition is violated and the DNS protocol is brought into the realm of DNS64
*        There are a number of DNSSEC scenarios that are broken for certain types of DNS64. The draft does not contain much precise guidance for this. Specifically:
o   Section 3, case 4: the draft only says this will be "problematic" which is at best an understatement.
o   Section 3, case 5: this case is fine but does not allow for any deviation in application or OS behavior; this artificial restriction will be "problematic" for some vendors as not all applications and OSes are guaranteed to conform.
o   Section 3, case 7: the downstream validator will ignore the synthesized data; the draft should in my opinion more clearly state that DNS64 is fundamentally broken for this case .
*        The phrase "ought to work" seems a bit imprecise (section 3, case 6).
*        Section 5.1 does not mention if cached results from previous queries should be consulted. The DNS64 should probably cache results as per standard DNS practice.
*        Section 5.1.1 states "as per normal DNS semantics". This is not quite as trivial as the draft makes it sound. The DNS64 will have to deal with truncation caused by mismatched EDNS packet sizes.
*        Section 5.1.2 oversimplifies error handling. I understand the motivation but were a server to return SERVFAIL for some unknown reason, a normal DNS server would attempt resolution against another server. DNS64 will change that behavior and may impact general DNS robustness. I'm not sure it's a good idea to treat all error codes as an empty response. Also, if DNS64 is being purposefully designed in violation of the spirit of the DNS protocol to work around deployed name server behavior, I think a reference justifying this would be appropriate.
*        In 5.1.3, if a timeout occurs shouldn't the query be sent to another server if one is available?
*        Section 5.1.6, caching is not mentioned here, as above.
*        Section 5.1.6 mentions "transient errors" and seems to contradict the error handling algorithm presented in Section 5.1.2.
*        Section 5.1.7: When synthesizing a AAAA record, why is the TTL "min (TTL of A record, SOA MinimumTTL)" and not just the TTL of the A record? If there is a good reason for this, perhaps the draft should state the rationale.
*        Section 5.3.2: The additional section will contain records, but the client will be unable to use them. I believe that some clients will not re-query for additional section data in this case. Some test/prototyping might be advisable.
*        Section 5.4: This section should discuss truncation and the EDNS OPT record.
*        Section 7.1: Step #3 contains two plural/singular typos.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 15:33:10 -0400

These are some fantastic comments.  Thanks.  Some elaboration inline.
Should I contact Jeff Westhead directly, or do you want to play
intermediary?

On Fri, Jun 04, 2010 at 02:02:22AM +0000, Dave Thaler wrote:
> 
> Here is my feedback. A lot of my issues I think stem from the fact
> that the draft authors envision DNS64 as a component grafted into
> existing DNS implementations, which would give them all kinds of DNS
> protocol handling for free. I'm not sure this is a suitable approach
> to take in this context. 

Something came up during some testing that caused me to have a similar
reaction.  The -10 draft (which is not out yet because the final
touches went on about three seconds before I saw the IETF LC
announcement) includes the following text:

   The final response from the DNS64 is subject to all the standard DNS
   rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].

It goes at the end of section 5.4.  The -09 text also says (and the
-10 text retains) at the top of section 5:

   DNS64 is a logical function that synthesizes AAAA records from A
   records.  The DNS64 function may be implemented in a stub resolver,
   in a recursive resolver, or in an authoritative name server.

Does the combination of those now make it clear that everything you
need to know when implementing "plain" DNS you also need to know for
DNS64?  I am really not keen to try to respecify general DNS handling
in this document.

> I also have some reservations about the piecemeal approach to
> working configurations. When DNSSEC is used, the DNS64 server is
> fairly broken. Instead DNS64 must be implemented on clients. This is
> ok, except that a) it is up to administrators and/or implementors to
> ensure that only working DNS64 deployment models are used, and b) if
> DNS64 is implemented on clients then DNS64 configuration becomes
> more difficult to distribute.

This is true, but it's completely insurmountable.  The answer to "gee,
DNS64 doesn't get along well with DNS64-oblivious DNS clients" is
"don't use DNS64, then."  By design, DNSSEC detects intermediate
mucking with DNS answers.  By design, DNS64 mucks with answers.  These
are never going to play nice. 

> o   Caching of remote query results

I don't really understand why the document ought to specify these:
those are questions for what you are doing when implementing a stub or
recursive resolver, or an authoritative server, I think.

> o   Packet assembly may be complicated if the DNS64 server uses a larger EDNS packet size than some of its clients; or if truncation applies to some clients but not others because of client EDNS pa…

Does the additional sentence to be in -10 help?

> o   Note that all of these items above may be handled already if one treats DNS64 as a "logical function" as noted in the first paragraph of Section 5; however there are many elements of the draft,…

That isn't the intention.  The intention instead is to make the
logical function fit within the bounds of what a regular DNS server or
client is going to expect.  But if there's a way to make this clearer,
text would be appreciated.

> o   Section 3, case 4: the draft only says this will be "problematic" which is at best an understatement.

Would "broken" instead be better?  It is in fact not going to work, period.

> o   Section 3, case 5: this case is fine but does not allow for any deviation in application or OS behavior; this artificial restriction will be "problematic" for some vendors as not all applicatio…

I don't understand the objection here.  What's the artificial
restriction?  There is no guarantee to a client of what they get
(DNSSEC-wise) from an intermediate resolver if CD=0 or DO=0.  If you
don't set those both, you cannot rely on your validation to be complete.

> o   Section 3, case 7: the downstream validator will ignore the synthesized data; the draft should in my opinion more clearly state that DNS64 is fundamentally broken for this case .

So if we added, "So DNS64 will not work with an unmodified validating
node of this sort," would that address the objection?

> *        The phrase "ought to work" seems a bit imprecise (section 3, case 6).

s/ought to/will/?

> *        Section 5.1 does not mention if cached results from previous queries should be consulted. The DNS64 should probably cache results as per standard DNS practice.

It does not say that because some kinds of implementations just don't
cache.  So this would depend entirely on whether you're building a cache.

> *        Section 5.1.1 states "as per normal DNS semantics". This is not quite as trivial as the draft makes it sound. The DNS64 will have to deal with truncation caused by mismatched EDNS packet s…

It's not trivial, of course, but it is as per normal DNS semantics.
Is there something more that should be said here?

> *        Section 5.1.2 oversimplifies error handling. I understand the motivation but were a server to return SERVFAIL for some unknown reason, a normal DNS server would attempt resolution against…

I was nor real happy with this change in the first place, as some
participants may recall, but there seemed to be a lot of voices in
favour of this approach.  SERVFAIL in particular was a target, because
that seems to be a common (bogus, IMO) cases where one gets SERVFAIL
for v6 records instead of something reasonable.  I'm not sure how to
put references in for unpublished test results.  Chairs?

> *        In 5.1.3, if a timeout occurs shouldn't the query be sent to another server if one is available?

This was again an attempt to cope with deployed systems that just
don't respond to AAAA queries.  ISTR that one of the large content
network systems does this, but I don't have my finger on it at the
moment.  So yes, this makes the system more subject to failure.

I'd be interested to hear whether those who argued strongly for this
error handling in the past are influenced by these objections.

> *        Section 5.1.6, caching is not mentioned here, as above.

Again, I am not sure we ought to be opening that topic in this draft.

> *        Section 5.1.6 mentions "transient errors" and seems to contradict the error handling algorithm presented in Section 5.1.2.

Good catch.  This will have to be resolved along with the discussion
of errors above.

> *        Section 5.1.7: When synthesizing a AAAA record, why is the TTL "min (TTL of A record, SOA MinimumTTL)" and not just the TTL of the A record? If there is a good reason for this, perhaps the…

This is for the same reason one uses this approach in negative
caching.  We want the shortest TTL possible, so that a cache that gets
the synthetic AAAA does not keep it longer than the zone operator
expects (so that if the zone operator adds a real AAAA record, it
starts to get used as soon as possible).  I can add some rationale for it.

> *        Section 5.3.2: The additional section will contain records, but the client will be unable to use them. I believe that some clients will not re-query for additional section data in this cas…

If they don't, they're completely broken already today.  We had this
argument when this section was changed, and Mark Andrews pointed out
that a client that didn't re-query because of existing additional data
is already broken, because there's no promise the additional section
is ever complete.

> *        Section 5.4: This section should discuss truncation and the EDNS OPT record.

This is where we added the sentence mentioned near the beginning of
this message.  Thanks.

> *        Section 7.1: Step #3 contains two plural/singular typos.

Hrm. I guess the problem is that it talks about "single records" as
opposed to RRSets.  Thanks.

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Jun 2010 17:41:17 -0400

> DNS64?  I am really not keen to try to respecify general DNS handling

As an implementor, I found it to be more than enough already. It is very
important that DNS64 be considered a separate and optional logical
function, not a rigidly-defined pyramid of protocols. DNS64 could
conceivably be implemented on top of, underneath, or alongside other
RFCs that we didn't think of or that are yet to be written. So please
leave the text as it is.

> put references in for unpublished test results.  Chairs?

It's common in these cases to put references to WG mailing list
archives. Why not reference this?

http://www.ietf.org/mail-archive/web/behave/current/msg07686.html

> error handling in the past are influenced by these objections.

I think that the OP is misinterpreting the text. Here it is:

5.1.3. Dealing with timeouts

   If the query receives no answer before the timeout, it is treated as
   RCODE=2 (Server failure).

It doesn't say "no answer *from a single server*". Of course you're
supposed to do what a recursive DNS implementation usually does! ;)

> Again, I am not sure we ought to be opening that topic in this draft.

+1

> Good catch.  This will have to be resolved along with the discussion

Just scrap the sentence. It's functionality that should be part of the
normal DNS stuff, not DNS64.

> starts to get used as soon as possible).  I can add some rationale for it.

Just for the OP's information, here's where this was discussed:

http://www.ietf.org/mail-archive/web/behave/current/msg05948.html

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 17:50:42 -0400

> supposed to do what a recursive DNS implementation usually does! ;)

That's reasonable.  It does seem to me that we could clean this up
slightly, though, because even though I wrote the sentence, I still
interpreted it as "the timeout for the server".  What about this:

    If the query receives no answer before the timeout (which might be
    the timeout from every authoritative server, depending on whether
    DNS64 is implemented as part of a recursive name server), it is
    treated as RCODE=2 (Server failure).

?  I'll need to check the language for consistency (I've already had
my knuckles rapped once for being careless about "recursive name
server", "recursive mode", "recursor", &c.), but you get the idea.

A

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