As long as we're in UDP, with DNSSEC, and many NS, packetsize in DNS
will be a "thing" and revoking label compression pushes to fragments
and/or TCP.
Personally, I think TCP is fine, and the emergence of long-lived
bindings in DNS is fine, and this is a bit overblown as a problem.
But, I get remin
On Wed, Oct 24, 2018 at 04:26:37PM -0400, Ted Lemon wrote:
> The good news is that in a typical DNS message, N is pretty small.
> Although I suppose in an internet-facing name server, pretty small is
> still pretty big...
In BIND, name compression is still one of the big consumers of CPU. It
was
How can it go WGLC with section 6 an open question?
in every other respect I like the document. Bad Hair and all.
I would like to understand if we could work out a way to do traceroute
in the codes, with some defined code to ask the DNS resolver to
perform a TTL drop on a counter and mark itself
The good news is that in a typical DNS message, N is pretty small.
Although I suppose in an internet-facing name server, pretty small is
still pretty big...
On Wed, Oct 24, 2018 at 4:25 PM Shane Kerr
wrote:
> John,
>
> On 24/10/2018 15.38, John Dickinson wrote:
> > On 24 Oct 2018, at 10:01, Vik
John,
On 24/10/2018 15.38, John Dickinson wrote:
On 24 Oct 2018, at 10:01, Viktor Dukhovni wrote:
My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:
4.1.4. Message compression
In order to reduce the size of me
No.
> On 25 Oct 2018, at 6:52 am, Ted Lemon wrote:
>
> Is there ever a valid reason to have a pointer to a pointer, though? This
> is dead easy to detect.
>
> On Wed, Oct 24, 2018 at 6:48 AM Martin Hoffmann
> wrote:
> Tony Finch wrote:
> >
> > Note that limiting the overall length of the
Is there ever a valid reason to have a pointer to a pointer, though? This
is dead easy to detect.
On Wed, Oct 24, 2018 at 6:48 AM Martin Hoffmann
wrote:
> Tony Finch wrote:
> >
> > Note that limiting the overall length of the name isn't enough,
> > because a pointer can loop without making the
On Wed, Oct 24, 2018 at 5:49 AM Wessels, Duane
wrote:
>
> > On Oct 22, 2018, at 6:53 PM, Bob Harold wrote:
> >
> > Just my opinions:
> >
> > Keep the Reserved field
> >
> > Include occluded data - it is part of the zone, even if never served.
> (Similar to glue data when a server has both a pare
On Oct 24, 2018, at 2:57 AM, Wessels, Duane
wrote:
>
>
>
>> On Oct 24, 2018, at 12:16 AM, Paul Hoffman wrote:
>>
>> Section 5 says:
>>
>> FOR DISCUSSION: The authors are willing to remove the Reserved field
>> from this specification if the working group would prefer it. It
>> would mea
Viktor Dukhovni wrote:
>
> c. The most recent pointer expands to a domain that moves
> past the location of the pointer, without arriving at that
> pointer, because it is just part of the data of some label.
> For example:
>
>... 10 05 l a r r y 10 m o e N
On Oct 24, 2018, at 5:57 AM, dnsop-requ...@ietf.org wrote:
> Surely any sequence of labels that terminates with a pointer to any
> label within that same sequence is an existence proof of such a loop.
> The degenerate case is a single label terminated by a pointer to
> itself.
So I gather that
Ray Bellis wrote:
> On 24/10/2018 11:45, Tony Finch wrote:
> >
> > * Keep a high-water-mark separate from the current location, and require
> > pointers to be strictly less than the HWM. (I prefer this way.)
>
> Right, but to be safe the HWM should be initialised with the position of
> the _star
On 24/10/2018 11:45, Tony Finch wrote:
> There are two basic ways to avoid it:
>
> * Keep a high-water-mark separate from the current location, and require
> pointers to be strictly less than the HWM. (I prefer this way.)
Right, but to be safe the HWM should be initialised with the position of
On 24 Oct 2018, at 10:01, Viktor Dukhovni wrote:
My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes
a
compressio
Tony Finch wrote:
>
> Note that limiting the overall length of the name isn't enough,
> because a pointer can loop without making the name longer.
You are, of course, right.
Kind regards,
Martin
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
Viktor Dukhovni wrote:
>
> My reading of RFC 1035 is that DNS name "compression" via "pointers" is
> restricted to name strictly earlier in the DNS message: [snip]
>
> And yet, here and there I see mention of having to take care to avoid "loops",
> but loops are impossible in a monotone strictly d
HI Duane,
On Oct 24, 2018, at 11:57, Wessels, Duane
wrote:
> Personally I feel like keeping the Reserved field is potentially useful in
> the future, but harmless if it never gets used. Can you say more about why
> keeping it prevents independent work?
I would also appreciate more words on t
bert hubert wrote:
> On Wed, Oct 24, 2018 at 05:01:53AM -0400, Viktor Dukhovni wrote:
> > And yet, here and there I see mention of having to take care to
> > avoid "loops", but loops are impossible in a monotone strictly
> > decreasing sequence.
>
> Yes. This is one of the best ways of preventin
> On Oct 24, 2018, at 12:16 AM, Paul Hoffman wrote:
>
> Section 5 says:
>
> FOR DISCUSSION: The authors are willing to remove the Reserved field
> from this specification if the working group would prefer it. It
> would mean, however, that a future version of this protocol designed
>
> On Oct 22, 2018, at 6:53 PM, Bob Harold wrote:
>
> Just my opinions:
>
> Keep the Reserved field
>
> Include occluded data - it is part of the zone, even if never served.
> (Similar to glue data when a server has both a parent and child zone.)
>
> If you might have multiple zonemd record
On Oct 24, 2018, at 11:01, Viktor Dukhovni wrote:
> And yet, here and there I see mention of having to take care to avoid "loops",
> but loops are impossible in a monotone strictly decreasing sequence.
Surely any sequence of labels that terminates with a pointer to any
label within that same seq
Viktor,
On 24/10/2018 11.01, Viktor Dukhovni wrote:
My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
comp
On Wed, Oct 24, 2018 at 05:01:53AM -0400, Viktor Dukhovni wrote:
> And yet, here and there I see mention of having to take care to avoid "loops",
> but loops are impossible in a monotone strictly decreasing sequence.
Yes. This is one of the best ways of preventing such loops. Some libraries
accide
My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain
24 matches
Mail list logo
