headers
George Barwood | 2 May 2011 08:47
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Paul Vixie | 9 May 2011 17:50

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
Permalink | Reply | 7 comments |
headers
Brian Wellington | 9 May 2011 20:33

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
Permalink | Reply | 5 comments |
headers
Tony Finch | 9 May 2011 20:30
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Paul Vixie | 9 May 2011 20:57

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
Permalink | Reply | 4 comments |
headers
Paul Vixie | 9 May 2011 22:26

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
Permalink | Reply | 2 comments |
headers
Edward Lewis | 9 May 2011 22:03
Favicon

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)

Permalink | Reply | 3 comments |
headers
Brian Wellington | 9 May 2011 22:41

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)

Permalink | Reply | 1 comment |
headers
Donald Eastlake | 9 May 2011 23:55
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)

Permalink | Reply | 0 comments |
headers
Mark Andrews | 10 May 2011 00:16

Re: compression in UPDATE


In message <F859DC5E-B25F-47A3-9FDC-2C63D395D258 <at> nominum.com>, Brian Wellington
 writes:
> 
> 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 outgoin
> g
> >> 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 o
> pcode.  UPDATE was defined later, so obviously wouldn't be mentioned there, b
(Continue reading)

Permalink | Reply | 0 comments |

Gmane