Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Oct 2012 14:26:18 -0400

Dear colleagues,

As usual, a day late and a dollar short.  

On Thu, Sep 20, 2012 at 09:07:44PM +0000, Dave Thaler wrote:
> All comments received during the first WGLC (on -09) have been
> resolved.
> 
> This email initiates another two-week Working Group Last Call
> on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude
> Thursday October 4th.

I have read -11.  There are several uses of "NXRRSET".  I have
no idea what that means.  It's not a term with which I'm familiar, so
it probably needs defining.

There is a typo of RFC 1034 for 1035 in item 2 of 3.1.2.

Other than that, I can live with it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Sat, 27 Oct 2012 23:27:38 +0000

NXRRSET is RCODE 8, specified in RFC 2136 and listed in the DNS RCODE registry at
http://www.iana.org/assignments/dns-parameters
I believe it means the name exists but no records of the requested type exist.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Sullivan
> Sent: Friday, October 26, 2012 11:26 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-
> 11
> 
> Dear colleagues,
> 
> > This email initiates another two-week Working Group Last Call on
> > draft-ietf-behave-nat64-discovery-heuristic-11, to conclude Thursday
> > October 4th.
> 
> I have read -11.  There are several uses of "NXRRSET".  I have no idea what
> that means.  It's not a term with which I'm familiar, so it probably needs
> defining.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 27 Oct 2012 23:08:41 -0400

> http://www.iana.org/assignments/dns-parameters

Doh, what an idiot.  Of course it is.  I knew that I'd seen the term
before, but couldn't place it while sitting on the plane.

It's a response that you normally only get in DNS Dynamic Update
responses.  I'm not sure how it's likely to apply to the use cases of
this draft.  I suppose there's no harm in leaving it it, but I bet
others will be as puzzled by its inclusion as I was.

> I believe it means the name exists but no records of the requested type exist.

Only in a dynamic update context.  In a standard query/response
context, the response to a query for a name that exists, but without
the RRTYPE you're requesting, will yield NOERROR (RCODE==0) and ANCOUNT
of 0 -- an "empty answer", which is different from RCODE==3 (Name
Error or NXDOMAIN).

I _think_ what the -11 text is looking for either an NXDOMAIN or
NODATA response.  See RFC 2308 for the definition of the NODATA
response, but basically it's the case where you get NOERROR and
ANCOUNT == 0, and it's not a referral.  You have to determine it
algorithmically.  Isn't DNS fun?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Sun, 28 Oct 2012 07:51:56 +0000

The NXRRSET stuff originates from discussions on behave mailing list on June. Please see e.g. http://www.ietf.org/mail-archive/web/behave/current/msg10459.html

It is of course possible that the discussions ended in the draft partially wrong and we got some regress in -10 when compared to -09.

Looking at the instances of NXRRSET, I would think that in "3. Node Behavior" the first instance is ok (discuss about hijacking), but in the second and third instance we'd need improvements. Could we just be somewhat agnostic and, for the case of second and third instance (both in same paragraph), just say:
--
   In the case of a negative or empty response, or a DNS query
   timeout: a DNS64 server is not available on the access network, the
   access network filtered out the well-known query, or something went
   wrong in the DNS resolution.  All unsuccessful cases result in a node
   being unable to perform local IPv6 address synthesis.  In the case of
   timeout, the node SHOULD retransmit the DNS query like any other DNS
   query the node makes [RFC1035].  In the case of a negative or empty
   response, the node MUST obey the Time-To-Live [RFC1035] of
   the response before resending the AAAA resource record query.  The
   node MAY monitor for DNS replies with IPv6 addresses constructed from
   the WKP, in which case if any are observed the node SHOULD use the
   WKP as if it were learned during the query for the well-known name.
--

Best regards,

Teemu
________________________________________
From: [email-masked] [[email-masked]] on behalf of ext Andrew Sullivan [[email-masked]]
Sent: Sunday, October 28, 2012 5:08 AM
To: [email-masked]
Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11

Best,

A

--
Andrew Sullivan
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Sun, 28 Oct 2012 17:36:11 -0400

Le 2012-10-28 03:51, [email-masked] a écrit :
> The NXRRSET stuff originates from discussions on behave mailing list
> on June. Please see e.g.
> http://www.ietf.org/mail-archive/web/behave/current/msg10459.html

Andrew is right, of course. I meant NODATA.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Mon, 29 Oct 2012 10:05:07 +0000

So would these be correct pieces of text:

-- (not changed)
In some scenarios NXDOMAIN and NXRRSET hijacking performed by the access network may result in a false positive.
--
and
-- (changed slightly)
   In the case of a negative (NXDOMAIN) or empty response (NODATA), or a DNS query

Best regards,

        Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Simon Perreault
> Sent: 28. lokakuuta 2012 23:36
> To: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Oct 2012 15:45:49 +0100

Looks good!

Simon