Subject: [BEHAVE] DNS64 and SRV records

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Feb 2010 15:12:52 -0500

Dear colleagues,

We have received an interesting observation from Rick van Rein about
the DNS64 draft.

The current draft says that DNS64 MUST NOT alter the Additional
section when assembling the answer.

Some records habitually include A and AAAA records in the Additional
section in order to allow a querying client to proceed without
querying again for the answer.  The particular case that troubles Rick
van Rein is the case of SRV records (but MX records and similar might
have this problem as well).

The RFC 2782 (which specifies the SRV RR) encourages servers to
include records in the additional section in order that targets of SRV
records can be resolved without additional queries.  It notes,
however, that clients cannot depend on there being data in the
Additional section, because the TTLs on (say) an SRV record and an A
record to match the target could be different; so an SRV might be
satisfied from cache without a corresponding A for the additional.

Now, suppose a client gets an SRV record with data in the additional
containing only A records.  Suppose also that the client has only IPv6
connectivity, so the A records do the client no good.

My reading is that the client _should_ go and query for the AAAA of
the target in the SRV record, because there's no data in the
additional section that will be useful to the client.  If the client
does this, it should end up with a synthetic AAAA as usual, and
everything will work.

The question is whether we know that there are clients that won't just
query for the AAAA.  If we do know of such clients, then the approach
currently in the draft won't work.  In that case, I propose changing
the draft to require the additional section to be truncated whenever
it does not contain at least one AAAA record.

Thoughts?

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Feb 2010 11:39:54 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> query for the AAAA.

If there are such clients they are already broken.  Ignore them.

There is no guarentee about any records in the additional section.
The may not be there for many reasons.  The authoritative server
is returning minimal responses, the records didn't fit due to space
considerations, the authorative server doesn't serve the zone the
referred to names live in, differing TTLs.  All of these are non
DNS64 issues that the SRV client has to deal with. 

If the client can't cope with these adding DNS64 to the list of
things it doesn't cope with is not a issue we need to worry about.

If the client copes with these then it will cope with what DNS64 does.

>  If we do know of such clients, then the approach
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Feb 2010 13:41:35 -0500

Ok, as a result of feedback here and in the DNSEXT WG, I have
concluded we should still leave the Additional section alone.  Here's
some additional text that I propose to make clearer the reasoning:

           <section title="Handling the additional section" anchor="addl_sec">
             <t>DNS64 synthesis MUST NOT be performed on any records
             in the additional section of synthesized answers.  The
             DNS64 MUST pass the additional section unchanged.</t>

             <t>It may appear that adding synthetic records to the
             additional section is desirable, because clients
             sometimes use the data in the additional section to
             proceed without having to re-query.  There is in general
             no promise, however, that the additional section will
             contain all the relevant records, so any client that
             depends on the additional section being able to satisfy
             its needs (i.e. without additional queries) is
             automatically broken.  An IPv6-only client that needs a
             AAAA record, therefore, will send a query for the
             necessary AAAA record if it is unable to find such a
             record in the additional section of an answer it is
             consuming.</t>

             <t>The alternative, of removing the A records in the
             additional section and replacing them with synthetic AAAA
             records, may cause a host behind a NAT64 to query
             directly a nameserver that is unaware of the NAT64 in
             question.  The result in this case will be resolution
             failure anyway, only later in the resolution operation.</t>

Ok?

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Feb 2010 10:48:48 +1100

In message <[email-masked]>, Andrew Sullivan writes:
>            <section title="Handling the additional section" anchor="addl_sec"
> >

I would just drop the last paragraph.