George Barwood | 2 May 08:47 2011
Picon

Authority and additional section questions

For some time I have had some questions about what RRsets are sent in the authority and additional sections.

There are 4 types of question:

What must be sent and why?
What should be sent and why?

Example questions:

In a positive recursive response, why is the NS RRset sent?

Should signatures for A/AAAA RRsets in the additional section be sent if available, and why?

I'm thinking of  writing a document (possibly a draft) that attempts to address these questions in a fairly
comprehensive way, but before I start I wondered if there are any existing documents (IETF or otherwise)
that I'm unaware of that addresses these questions ( especially the "why" parts ). I'm aware of the main
DNS RFCs, 1034,1035,2181,4033-35.

Thanks,
George

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Internet-Drafts | 6 May 20:30 2011
Picon

I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-22.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

    Title         : Update to DNAME Redirection in the DNS
    Author(s)     : S. Rose, et al
    Filename      : draft-ietf-dnsext-rfc2672bis-dname-22.txt
    Pages         : 18
    Date          : 2011-05-02

   The DNAME record provides redirection for a sub-tree of the domain
   name tree in the DNS system.  That is, all names that end with a
   particular suffix are redirected to another part of the DNS.  This is
   a revision of the original specification in RFC 2672, also aligning
   RFC 3363 and RFC 4294 with this revision.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-22.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.
A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

(Continue reading)

Paul Vixie | 9 May 17:50 2011

compression in UPDATE

this is a possible RFC 2136 errata.  2136 does not mention compression at
all, which is an oversight, it ought to have said "compression shall not
be used".  in the absence of such a statement i believe that implementors
of UPDATE responders have decompressed any of the RR types they understand,
which is fine under the robustness principle but may create the misleading
expectation that all types are understood and that compression is supported.

therefore my question: does any UPDATE initiator actually use compression?
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Brian Wellington | 9 May 20:33 2011

Re: compression in UPDATE


On May 9, 2011, at 8:50 AM, Paul Vixie wrote:

> this is a possible RFC 2136 errata.  2136 does not mention compression at
> all, which is an oversight, it ought to have said "compression shall not
> be used".  in the absence of such a statement i believe that implementors
> of UPDATE responders have decompressed any of the RR types they understand,
> which is fine under the robustness principle but may create the misleading
> expectation that all types are understood and that compression is supported.
> 
> therefore my question: does any UPDATE initiator actually use compression?

It's possible I'm misunderstanding the question, but wouldn't compression be expected?  None of the
implementations I'm familiar with conditionalize name compression based on opcode, so any types which
can be compressed in QUERY responses could also be compressed in UPDATE requests.

nsupdate appears to be compressing both owner names and names in rdata, for example.

Brian
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Tony Finch | 9 May 20:30 2011
Picon

Re: compression in UPDATE

Paul Vixie <vixie <at> isc.org> wrote:
>
> therefore my question: does any UPDATE initiator actually use compression?

BIND's nsupdate tool compresses owner names and names in the RDATA of RFC
1035 RR types. This is consistent with RFC 3597, which makes sense.

I don't think RFC 2136 needs to forbid compression; it just needs to say
that records (owner names and RDATA) are compared after they have been
decompressed and the RDLENGTH adjusted to match.

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Paul Vixie | 9 May 20:57 2011

Re: compression in UPDATE

> From: Brian Wellington <brian.wellington <at> nominum.com>
> Date: Mon, 9 May 2011 11:33:52 -0700
> 
> nsupdate appears to be compressing both owner names and names in
> rdata, for example.

so i see.  ouch.  in fact the bind8 version of this goes well beyond
RFC 3597's constraints on "known types".  i suggest that we draw a new
line in the sand and require that compression be understood for all
types that any now-current implementation is known to compress for.
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Paul Vixie | 9 May 22:26 2011

Re: compression in UPDATE

> Date: Mon, 9 May 2011 16:03:59 -0400
> From: Edward Lewis <Ed.Lewis <at> neustar.biz>
> 
> >so i see.  ouch.  in fact the bind8 version of this goes well beyond
> >RFC 3597's constraints on "known types".  i suggest that we draw a new
> >line in the sand and require that compression be understood for all
> >types that any now-current implementation is known to compress for.
> 
> I'd go the other way.  There's little harm in never compressing an outgoing
> message (the loss is that extra octets are moved).  There's more harm in
> compressing a type the receiver doesn't know, especially because the
> receiver wouldn't know that there was compression in use. (Compression
> isn't transitive, message to message, that is.)

i agree, and that was my first inclination also, but i hate breaking the
installed base just for the sake of purity.  nsupdate is a huge contributor
to the world's supply of UPDATE messages and i am loathe to declare it
broken.
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Edward Lewis | 9 May 22:03 2011

Re: compression in UPDATE

At 18:57 +0000 5/9/11, Paul Vixie wrote:

>so i see.  ouch.  in fact the bind8 version of this goes well beyond
>RFC 3597's constraints on "known types".  i suggest that we draw a new
>line in the sand and require that compression be understood for all
>types that any now-current implementation is known to compress for.

I'd go the other way.  There's little harm in never compressing an 
outgoing message (the loss is that extra octets are moved).  There's 
more harm in compressing a type the receiver doesn't know, especially 
because the receiver wouldn't know that there was compression in use. 
(Compression isn't transitive, message to message, that is.)

Having been involved in a few "clarification" documents I'm not all 
that eager to see any more lines in the sand redrawn. ;)  It's never 
pain-free.  Recently I privately offered to write a document to cover 
over all the dead types and got no statements of support.

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

(Continue reading)

Brian Wellington | 9 May 22:41 2011

Re: compression in UPDATE


On May 9, 2011, at 1:26 PM, Paul Vixie wrote:

>> Date: Mon, 9 May 2011 16:03:59 -0400
>> From: Edward Lewis <Ed.Lewis <at> neustar.biz>
>> 
>>> so i see.  ouch.  in fact the bind8 version of this goes well beyond
>>> RFC 3597's constraints on "known types".  i suggest that we draw a new
>>> line in the sand and require that compression be understood for all
>>> types that any now-current implementation is known to compress for.
>> 
>> I'd go the other way.  There's little harm in never compressing an outgoing
>> message (the loss is that extra octets are moved).  There's more harm in
>> compressing a type the receiver doesn't know, especially because the
>> receiver wouldn't know that there was compression in use. (Compression
>> isn't transitive, message to message, that is.)
> 
> i agree, and that was my first inclination also, but i hate breaking the
> installed base just for the sake of purity.  nsupdate is a huge contributor
> to the world's supply of UPDATE messages and i am loathe to declare it
> broken.

A few more points:

RFC 1035 (in section 4.1.4. Message compression) doesn't say anything about opcode.  UPDATE was defined
later, so obviously wouldn't be mentioned there, but there's also no specific mention of QUERY, IQUERY,
or STATUS; the text says "In order to reduce the size of messages".

RFC 1996 (NOTIFY) also doesn't mention compression; is anyone suggesting that compression be outlawed
there as well?
(Continue reading)

Donald Eastlake | 9 May 23:55 2011
Picon

Fwd: New Version Notification for draft-eastlake-dnsext-xnamercode-04

I have updated dates, version number, author info, and boilerplate.
And I've unambiguously removed "unambiguously"...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 <at> gmail.com

---------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
Date: Tue, May 10, 2011 at 6:51 AM
Subject: New Version Notification for draft-eastlake-dnsext-xnamercode-04
To: d3e3e3 <at> gmail.com

A new version of I-D, draft-eastlake-dnsext-xnamercode-04.txt has been
successfully submitted by Donald Eastlake 3rd and posted to the IETF
repository.

Filename:        draft-eastlake-dnsext-xnamercode
Revision:        04
Title:           xNAME RCODE and Status Bits Clarification
Creation_date:   2011-05-09
WG ID:           Independent Submission
Number_of_pages: 9

Abstract:
The Domain Name System (DNS) has long provided means, such as CNAME
(Continue reading)


Gmane