headers
Dean Anderson | 3 May 2004 22:48

Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt


On Thu, 29 Apr 2004 bmanning <at> vacation.karoshi.com wrote:

> 	So... I guess what you are really saying is that -DNS-
> 	is not required. 

No, I am saying that IN-ADDR is not required to have a fully working DNS.

> 
> 	If this is the case, why do you maintain the fiction of 
> 	the "av8.com" delegation when raw addresses work just fine?

You seem to be confusing forward DNS delegations with in-addr. They are 
not the same. (As I think you well know, so I take your misdirection here 
to be intentional.)

> 	Or could it be that some applications would really prefer
> 	to have a working DNS structure in play and they drive the
> 	requirement?  Hum... could be!

The fiction is that in-addr is not required to have a "working DNS
structure".  One does not need in-addr to have "av8.com" work.

Indeed, speaking of fiction, the proponents of this draft are the very
same people who promote the fictional idea that "reverse DNS checking"  
somehow adds trustworthy-ness information.

Further fiction in this draft is the misquoting of other agencies
statements in order to mislead people.  Apparently, you have forgotten
this message:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 4 May 2004 11:09
Picon

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

Hi,

On Fri, 30 Apr 2004, Alain Durand wrote:
> > "Substantially" - because of the glue question and the truncation 
> > issue in DNS, you can't specify that the answer "is" the same.
> >
> > Another case to consider is the the query type any.  If my v4 
> > recursive server does not share the same memory (RAM) as my v6 server, 
> > chances are strong that the caches in the two will differ over time.  
> > QTYPE ANY queries ask for "what you have" about a name, not the 
> > complete data at the name (as far as an authoritative server is 
> > concerned).  It's reasonable to consider that the exact responses from 
> > the two servers will differ, regardless of the fact that they are on 
> > different network layers.
> 
> Thank you for this clarification I now understand you point.  We
> might want to add text that only focus on those issues. This is an
> operational issue that is somehow different from the one described
> in the transport guideline document. I think it should go into the
> ipv6-dns-issues document, which is the one you commented on first,
> so I withdraw my previous comment.

Does this need to be stated? As Rob explained, QTYPE=* is a beast
that's not really used except by folks playing with "dig" and
"nslookup"; the resolvers don't use them, so we might not need to care
about them?

I haven't edited ipv6-dns-issues on this subject, but if there are 
concrete suggestions which do not conflict with the transport 
guidelines document, shoot! :)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pekka Savola | 4 May 2004 11:24
Picon

handling of additional data [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

Hi,

Let's take an issue separately from the rest.  Me and Jinmei discussed
this, but were OK with as it is.  However, if WG has clear opinions,
now might be time for modifying the text and/or recommiding changes to
the additional data processing.

As described by ipv6-dns-issues, section 4.4, there are two kinds of 
additional data:

   1.  "critical" additional data; this must be included (all the
       possible RRsets) in all scenarios, and

   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well, but which could lead to non-optimal results.

[[ see examples of each in the draft.]]

Imagine the event where the additional data section would include both
A and AAAA RRsets and would be too large, but omitting one RRset would 
make it small enough.

Now, the questions are:

A)  Is there consensus that it's better to set TC bit than to return 
    only some RRsets of critical additional data?

B)  Is it better to omit all the courtesy addional data, rather than 
    omit some RRsets?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Edward Lewis | 4 May 2004 13:41

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

I think the crux of the matter is that the document should refer to 
the contents and availability of every zone ought to be available on 
all commonly used transports - as opposed to stating that there 
should always be a server on IPv4.

Secondly, I think that maintaining rationale in documents is a good 
idea.  E.g., there is a requirement in a document in another WG.  I 
had been asked to see if a proposed specification met the 
requirements.  When I came to the requirement, the words made no 
sense to me.  I asked the WG what the requirement meant and was only 
given a change history (MUST to MUST NOT to MUST on certain 
revisions).  Even searching the archives, there has never been an 
explanation of why it was even discussed (the context).

Granted, the issue here is small, and traditionally we leave change 
history to the mail archives.  In this case, the example of QTYPE=ANY 
isn't significant to the document.  It doesn't impact the text as 
stated in the document but it impacts the suggested replacement 
(above), so it's not all that important.

In summary, I propose replacing this inside section 1.3:

#                                                                 the
#   recommendation is to always keep at least one authoritative server
#   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.

With

"the recommendation is to always make available equivalent copies of all
zones on all commonly used network layers.  E.g., the set of authoritative
(Continue reading)

Permalink | Reply | 2 comments |
headers
Edward Lewis | 4 May 2004 15:15

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

At 8:55 -0700 4/30/04, Alain Durand wrote:
>Thank you for this clarification I now understand you point.

Sorry for being unclear at first.  Yet another instance of me 
figuring out what I meant to say well after sending the message. ;)
--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

If time travel were ever to be realized, public key crypto is toast.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Edward Lewis | 4 May 2004 15:14

Re: handling of additional data [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

At 12:24 +0300 5/4/04, Pekka Savola wrote:
>A)  Is there consensus that it's better to set TC bit than to return
>     only some RRsets of critical additional data?

This is an issue that ought to be raised on namedroppers as the 
protocol rules cover the setting of the TC bit.

>B)  Is it better to omit all the courtesy addional data, rather than
>     omit some RRsets?

There's a tradeoff.  If the sender omits information, it'll get hit 
with another query.  If it sends more information, it may mislead the 
client.

The ingredients to this question also involve EDNS0.

I'd assume this, but it's not necessarily what I'd recommend now -

If the query arrives without EDNS0 (no OPT RR), then the client is 
older, hence is probably not fully functional on IPv6.  In this case, 
the choice would be to send nothing or just the A record, whatever 
fits in the 512 byte message.

If the query arrives with EDNS0, it'll probably advertise a much 
larger acceptable return size, rendering this a non-issue.  But in 
the odd event that the advertised larger size isn't enough for both, 
then I'd assume AAAA is preferred because this is a newer DNS client.

I wouldn't bet much on that assumption though.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alain Durand | 4 May 2004 19:07
Picon

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]


On May 4, 2004, at 4:41 AM, Edward Lewis wrote:
> In summary, I propose replacing this inside section 1.3:
>
> #                                                                 the
> #   recommendation is to always keep at least one authoritative server
> #   IPv4-enabled, and to ensure that recursive DNS servers support 
> IPv4.
>
> With
>
> "the recommendation is to always make available equivalent copies of 
> all
> zones on all commonly used network layers.  E.g., the set of 
> authoritative
> servers for each and every zone ought to include at least a server on 
> IPv4
> and IPv6 while both are commonly carried on the Internet.  In addition,
> recursive name servers ought to be able to queried and be able to 
> itself query servers on all network layers in common use."

"...every zone ought to include at least a server on IPv4 and IPv6 
while both are commonly carried on the Internet."

We are not here yet. unfortunately.

	- Alain.

.
dnsop resources:_____________________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward Lewis | 4 May 2004 19:45

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

At 10:07 -0700 5/4/04, Alain Durand wrote:
>"...every zone ought to include at least a server on IPv4 and IPv6 
>while both are commonly carried on the Internet."
>
>We are not here yet. unfortunately.

I think the wording is fine, but, yes, getting the servers up is still "TBD."

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

If time travel were ever to be realized, public key crypto is toast.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Rob Austein | 4 May 2004 20:15

Re: DNS transport guidelines [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

<hat co-chair=off just-another-bozo=on>

  Ed,

  First off, I probably need to recuse as WG co-chair on this one,
  since the transport guidelines doc is partly based on a back of a
  (virtual) envelope proposal I made several years ago.  Anyway....

  In principle, I agree with you that what the doc ought to say is
  "every zone should be available via every version of IP", full stop.

  The difficulty is that the situation is not as symmetrical as it
  might seem.  IPv4 is already deployed, and we can't do much about
  all the zones for which all the authoritative name servers are
  IPv4-only.  We can say that it'd be nice for the world to fix this,
  but IPv6 does not yet have enough traction for this to be much more
  than wishful thinking, and I've never much cared for inventing rules
  that we know aren't going to be enforced.  We can, however, expect
  that IPv6 deployment will take interoperability with IPv4 into
  account, thus it's reasonable for us to say how to do that.

  Some day, a decade or so from now, when everything that matters is
  dual stack and keeping IPv4 running costs more than it's worth, we
  can write a new RFC that says that IPv4 support isn't required
  anymore.  But trying to write a document now for that far future day
  just dilutes the message that today's document is to trying to send.

  So, while I understand where you're coming from, and can live with
  the change you're proposing if that's the consensus, I think it'd be
  better to leave the text alone.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Masataka Ohta | 4 May 2004 21:29
Picon

Re: handling of additional data [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]

Pekka Savola;

> Let's take an issue separately from the rest.  Me and Jinmei discussed
> this, but were OK with as it is.  However, if WG has clear opinions,
> now might be time for modifying the text and/or recommiding changes to
> the additional data processing.

OK.

> As described by ipv6-dns-issues, section 4.4, there are two kinds of 
> additional data:
> 
>    1.  "critical" additional data; this must be included (all the
>        possible RRsets) in all scenarios, and
>                                                                                              
>    2.  "courtesy" additional data; this could be sent in full, with only
>        a few RRsets, or with no RRsets, and can be fetched separately as
>        well, but which could lead to non-optimal results.

The classification is not enough.

For an authoritative server answering a query, there are
"glue", that is, "critical", additional data and all the
other additionals are "courtesy". So, please don't invent
new terminologies and just say "glue".

For a resolver receiving a response, it is not distinguishable
whether A for NS of referral response is "glue" or not. On the
other hand, for resolvers, there can be "safe" and "unsafe"
additonal data distinguishable. "safe" data is on node in
(Continue reading)

Permalink | Reply | 3 comments |

Gmane