draft-ietf-ipngwg-dns-lookups-04.txt

Jim Bound bound at zk3.dec.com
Wed Jun 23 11:53:17 UTC 1999


Matt,

I have added BIND V9 mail list and BIND workers as this affects our IPv6
A6 rollout and any fixes to 8.1.2 which is about ready to go into
production and in kits for IPv6 Customers; who by the way have not
widely deployed A6 records quite yet :--).

I would also like to hear Bob Halley's take on this too.

>  Our area dissectors would like to have the A6 document specify just
>how the resolver is supposed to act with respect to requesting AAAA
>or A6 records when an IPv6 address lookup is needed.

Why for the record and so its in the archives for future reference OK?

>  Down the road a short (?) way, the option will exist of using
>multiple questions in a single query, with the choice of requesting
>answers to all, or the first which gets a non-empty answer.  I can't
>find a document which outlaws or deprecates multiple questions today,
>but we all know that they don't work.

Yes this will be part of BIND v9 for that code base which will be about
in 6 months long before massive IPv6 deployment?  

The meta query has been a BIND vendor request for some time and should 
be here real soon.

So why the urgency with BIND v9 so close?

>  As soon as the A6 draft is implemented, I expect to see A6 records
>appear in zone files.  And when they are in zone files, I hope to see
>A6-aware resolvers looking for them.  But for some period, A6 records
>will be rarer than AAAA records.

Agreed.

>  The rules for A6 processing in the server specify that A and AAAA
>are returned as additional data.  So requesting A6 from an A6-aware
>server which holds no A6 records won't waste a round-trip.

I want this to happen but for the record I always have thought this was
a bad idea as a MUST requirement and should be able to be overriden by
some code to the server.  A client may not want the A or AAAA records
back and we want to be able to permit that behavior for the future when
A and AAAA records are very  rare.  But I just thought of that so sorry
but I will now check this for last call.  Or before DS happens.

>  Aside from using multiple questions in one UDP packet, the
>following possibilities exist.

The meta query will be able to do this fyi.

>  1* Use a TCP connection to make successive queries if needed.
>  Multiple queries and replies on one connection is allowed, and
>  encouraged at least for the case of SOA+AXFR.  (Are there real-
>  world implementation facts that would preclude this?)

This increases the packets to the server for every request and why we
use UDP in the first place.  At least that is what current thinking
suggests for intensive client server processing should use UDP.  Of
course I don't agree with that current thinking.

>  2* Ask for both A6 and AAAA in separate UDP packets, without waiting
>  for an answer in between.

Yuck.  That puts more state in the resolver awaiting to reply to the
application.

>  3* Ask for A6, then for AAAA if RCODE=0 and ANCOUNT=0 and no AAAA
>  records are returned as additional information.

This sounds like the solution but we need a way as I said above to shut
this down to not return add'l section records too.

>  4* Ask for AAAA, then for A6 if RCODE=0 and ANCOUNT=0.

This should be permitted.

>  5* Only ask for A6, never AAAA.

This should be permitted.

>  6* Only ask for AAAA, never A6.

This should be permitted.

>  The last of these is today's state, and we want to transition to
>some other, possibly number 5.  1, 2, and 3 are all plausible
>intermediate states, each with its own drawback.

We should permit 5 and 6 for "transition" and 5 gives us 3 by default.

>  An orthogonal but important question is that of how to cause the
>resolver to alter its behavior without extra redeployment steps.  It
>could pick up its instruction from some magic word in a configuration
>file (or environment or registry entry), or some special cue in a
>zone file (but then some implementations may have to make a query for
>that cue in every new process).

This is where the BIND v9 and BIND workers need to discuss this because
it is an important point.  I am not sure the spec should get into
specifying this because then we would have to assume we know all the
ways products will provide deployment of resolvers.  The best we can do
is provide an example abstraction.

I would like to see us stay away from environment variables and config
files, as this type of fix can cause release number problems for
product sets.  So I think that is a bad idea but will defer to ISC and
folks there.  But as a vendor I have gotten burned messing with config
files for DNS parts.

I need to think on this one a bit more and get back to you.
But its an important point and very critical.

>  As a starting point for discussion, I propose the following text to
>be added to section 7 ("Transition from AAAA Records")

>    Applications or libraries implementing the function of looking up
>    IPv6 addresses by means of either A6 or AAAA records MUST be
>    configurable to operate in at least the following modes:
>    requesting A6 records before AAAA, AAAA before A6, and A6 only.
????  I think you have a logic error in the above sentence ???
>    The default mode SHOULD be to request A6 before AAAA.

When asking a user if they are using IPv6 on their node I envision
asking them are you ready for A6 records.  If they say yes then I could
use the default above but I would ask them if they wanted the default
and they should not if they know there are no A6 records deployed.
So your SHOULD above is OK I think.  

But as I said above if a site has gotten rid of AAAA records or simply
does not want them don't want to see them in the hostent structure or
the A records but that is an API function I think we have covered in
2553.

/jim 


More information about the bind-workers mailing list