Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-06.txt

From: [email-masked]
Date: Mon, 15 Feb 2010 08:45:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-ietf-behave-dns64-06.txt
	Pages           : 30
	Date            : 2010-02-15

DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with an IPv6/IPv4 translator to enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs.  This document
specifies DNS64, and provides suggestions on how it should be
deployed in conjunction with IPv6/IPv4 translators.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Feb 2010 11:48:37 -0500

Dear colleagues,

> 	Filename        : draft-ietf-behave-dns64-06.txt

This version of the draft includes our responses to the comments
received during and since the previous WGLC.  Follow-up comments are
appreciated.

Best regards,

Andrew

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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 18 Feb 2010 14:10:01 +0100

Hi

I have read this version of the draft and I support it.

I am not too happy about the special error (RCODE) handling in section
5.1.2, but the reasons to still query for A records and try synthesis I
can understand.

In the same spirit, I miss text about how a DNS64 recursor would behave
on a timed out event when requesting AAAA records. We have seen servers
that are not responsive for AAAA RRs, but are responsive for other
RRtypes (presumably because of a firewall). I would classify these type
of servers the same as those that respond to SERVFAIL or REFUSED upon a
AAAA query.

Proposed text:

A query that results in a temporary error because the request was timed
out (and therefor terminated) is treated as though the RCODE were 0 and
the answer section were empty.

Best regards,

Matthijs

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Feb 2010 08:25:17 -0500

> the answer section were empty.

+1

We've seen this in the wild, and this is how it should be handled.

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: Thu, 18 Feb 2010 11:23:51 -0500

Thanks for the review!

> the answer section were empty.

This makes sense to me.  I see someone else has weighed in supporting
it as well.  Any objection?

A

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Feb 2010 09:45:54 +1100

In message <[email-masked]>, Matthijs Mekking writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi
> 

This senario is pretty rare these days.  Just SERVFAIL the client
on timeout.  It's time to get rid of the last of these broken load
balancers and if that means some pain for the clients so be it.
It's also the correct long term strategy.  Working around broken
boxes does not get the problems fixed.

This is really not different to not making a A query when the load
balancer incorrectly returns NXDOMAIN on AAAA.
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 19 Feb 2010 09:29:53 +0100

Or you handle a time out event as a SERVFAIL (and thus for DNS64 you may
query for A records).

Or you mention that this set up is broken, just like returning NXDOMAIN
is on AAAA query (but there are other records on that name).

Either way, additional text to clarify would be useful imo.
Than my preference is the first option, since you already got into
special error handling.

Also its not that hard to query for A records after a timed out event,
especially if the resolver already treats it as SERVFAIL. So its little
work to reduce the pain for clients.

Best regards,

Matthijs

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Feb 2010 21:10:15 +1100

> work to reduce the pain for clients.

Except for the 99.999 of RFC compliant servers out there trying a
A will not succeed after the AAAA times out.  Remember the recursive
server has already possibly made lots of queries in attempts to get
through broken firewalls and has most probably tried multiple
servers with the AAAA query.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 19 Feb 2010 11:26:51 +0100

The same amount of name servers would also not return false RCODE
responses. Why make exceptions for those name servers?

Matthijs

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Feb 2010 08:24:35 -0500

On 2010-02-18 17:45, Mark Andrews wrote:
> on timeout.

 From an implementation point of view, in both Unbound and Bind, this 
would be hard. From where the DNS64 functionality is, we see a SERVFAIL 
on timeout. We have no way of knowing whether this was caused by a 
timeout or otherwise.

It would be the same situation if a DNS64 was using a forwarder which 
returned SERVFAIL on timeout from an authoritative server.

Handling timeout like SERVFAIL (not as NXDOMAIN) makes more sense.

Simon

---

From: Mark Andrews <[email-masked]>
Date: Sat, 20 Feb 2010 09:16:29 +1100

> Handling timeout like SERVFAIL (not as NXDOMAIN) makes more sense.

Handling NOTIMP/REFUSED/SERVFAIL as SERVFAIL to the client would
actually make more sense.  The survey of the top 3000(?) sites
showed that error responses to A and AAAA responses were basically
consistent.  They will also only get more consistent as time goes
on.  Lets not code workarounds for broken servers into DNS64.

If a site has a load balance that returns NOTIMP to a AAAA query a
decade after the introduction of AAAA records rather than a
NOERROR/NODATA response they don't deserve to have a A query made.
If you don't implement AAAA they you definitely can't return AAAA
but you can say you have no AAAA records.  The only record type
where NOTIMP is correct are the reserved meta types.

If a site incorrectly returns REFUSED to AAAA query they don't
deserve a A query.  "I won't tell you I don't any AAAA records but
I'll tell you I have A records." is what that response is saying.

>From a implemention point of view you have success (NOERROR or
NXDOMAIN) and failure of the AAAA query.  Requerying for A after
failure made some sense 10 years ago but should have been removed
about 5 years ago.  All it is doing now is causing extra work to
be done for almost no benefit.

Mark

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 22 Feb 2010 10:38:12 +0100

> be done for almost no benefit.

I was rereading the thread DNS64: 'SERVFAIL on AAAA query, but A record
available'
[http://www.ietf.org/mail-archive/web/behave/current/msg07668.html]

And this has all been discussed before. True: querying for A records
after a AAAA query failed increases extra work for almost no benefit.
The reason (I believe, correct me if I'm wrong) to put it in the draft
anyway is that dual-stack also, already makes that increase, so NAT64
can be just as 'gentle'. My first remark is that if you are going to do
this, you should also mention other failures (like time out).

Now, I don't think 'dual-stack is doing it' is a good reason to make
this decision. 'Additional work for almost no benefit' is a stronger
reason. So, only if the resolver believes that requerying benefits the
end user, it should do so. FORMERR, SERVFAIL, NXDOMAIN, NOTIMPL*,
REFUSED and time out are no valid reasons. NOERROR (no data) is.

In that case, I prefer section 5.1.2 from draft-ietf-behave-dns64-04.

Best regards,

Matthijs

* If NOTIMPL is being returned, you can argue that the name server does
not implement IPv6 address records. But, it should have handled the
query type as an unknown DNS RR type.