Yes, thank you. Seems like the information context was lost in the translation
somewhere along the way.
O.
--
Ondřej Surý
ond...@isc.org
> On 31 Jul 2018, at 00:38, Wessels, Duane wrote:
>
>
>
>> On Jul 29, 2018, at 2:03 PM, Evan Hunt wrote:
>>
>> On Sun, Jul 29, 2018 at 10:55:31AM +0200,
> On 31 Jul 2018, at 00:44, Paul Hoffman wrote:
>
> And, even if it is possible to imagine that, requiring a hash function that
> has no collision attacks (like SHA-256) would suffice.
Yes, that’s exactly what I had suggested in the first place. Now we have a
full circle to my original messa
> > The draft states in the Motivation section:
> >
> > "The motivation and design of this protocol enhancement is tied to the
> DNS root zone [InterNIC]."
>
> That may be a motivation, but as a prospective user I want to use
> it for much more. My LocalRoot server is already going to be
> s
On 24 Jul 2018, at 9:44, Stephane Bortzmeyer wrote:
> Some work for draft-ietf-dnsop-terminology-ter? Define spoofing,
> poisoning and hijacking?
I think it's arguable either way whether to go for a -ter edition or to bring
out a companion document with its scope restricted to abuses, attacks, a
Hi Philip,
Are you suggesting that web servers can't be massively scaleable? I'm not sure
I understand your examples.
You cite overprovisionoing in the root server system as a reason not to try and
supplement it, but I think it makes sense to look at it the other way round --
if there were way
Philip Homburg writes:
> I think there is a big difference between distributing the root zone and
> distributing a few 'local' zones.
>
> In the first case you need something that is massively scalable.
I'm afraid I don't see those as different problems like you do. I'd
like a massively scalab
> On Jul 31, 2018, at 5:44 AM, Philip Homburg
> wrote:
>
> I wonder if there still is a use case for distributing the root zone. With
> QNAME minimization and NXDOMAIN based on NSEC records, the major use cases
> seem to be gone. Compared to other zones, the root is massively over
> provisione
> Are you suggesting that web servers can't be massively scaleable
> ?
> I'm not sure I understand your examples.
Yes, you can build massively scaleable web servers, but at what price?
What if some popular IoT device starts to fetch the root zone. And at a
high rate?
> You cite overprovisionoing
In your letter dated Tue, 31 Jul 2018 06:49:04 -0700 you wrote:
>> I think there is a big difference between distributing the root zone and
>> distributing a few 'local' zones.
>>
>> In the first case you need something that is massively scalable.
>
>I'm afraid I don't see those as different probl
Petr Špaček wrote:
> On 30.7.2018 15:32, Tony Finch wrote:
> >
> > I keep thinking it might make sense to sign non-authoritative delegation
> > records, though it's really hard to see how we could get there from here.
> > For instance, there isn't a flags field in RRSIG so you can't explicitly
> >
In article you write:
>I think there is a big difference between distributing the root zone and
>distributing a few 'local' zones.
>
>In the first case you need something that is massively scalable.
Fortunately, Cloudflare, Edgecast, Limelight, Azure, and Akamai are
only a phone call away. That
In article you write:
>Yes, huge zones like .com and similar are not possible. But there are
>many other TLDs that likely are possible to pre-cache and serve locally.
I have most of the TLD zone files that it is possible to get. They're
all gzipped so if you wanted to estimate the uncompressed
On 31 Jul 2018, at 9:04, John Levine wrote:
So, yeah, there are plenty of TLDs you could pre-cache if you wanted
to.
This would only be useful for zones whose children don't change often
and whose TTLs are long. Many TLDs don't have those properties. Let's
focus on the ones that do.
--Pa
On Tue, 31 Jul 2018, Paul Hoffman wrote:
On 31 Jul 2018, at 9:04, John Levine wrote:
So, yeah, there are plenty of TLDs you could pre-cache if you wanted
to.
This would only be useful for zones whose children don't change often and
whose TTLs are long. Many TLDs don't have those propertie
I hear there are proposals to sign the entire contents of zones. zonemd/xhash
in some subject lines.
(Forgive me if SIG(AXFR) was mentioned before...)
"Domain Name System Security Extensions", a'la RFC 2065, section 4.1.3 Zone
Transfer (AXFR) SIG:
"However, to efficiently
assure the complet
On Jul 27, 2018, at 12:33 AM, Spencer Dawkins
wrote:
> I really like this document, and think it's headed the right direction. Of
> course I have four pages of comments, because reasons, but the only part I'm
> really confused about is this one ...
>
> I would have thought that if you end up wit
> On Jul 31, 2018, at 10:51 AM, Edward Lewis wrote:
>
> I wish I could recall why. (Anyone else recall why this was dropped? I
> recall realizing it was a fool's errand but not the reasons.) Yes, today's
> network is different.
Olafur wrote a little about this a couple weeks ago. He sai
> On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-session-signal-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Fee
> On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote:
>
>>
>> If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>> ([TBA2] tentatively 11), then the client MUST assume that the server
>> does not implement DSO at all. In this case the client is permitted
>> to continue
On Jul 31, 2018, at 4:14 PM, Tom Pusateri wrote:
> My co-authors reminded me about the TCP framing for DNS which gives the
> length of the DNS message so it can easily be skipped so this isn’t a problem.
And just as an additional data point, I just now pointed my DNSSD Discovery
Relay implement
On Tue, Jul 31, 2018 at 04:14:41PM -0400, Tom Pusateri wrote:
>
>
> > On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote:
> >
> >>
> >> If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
> >> ([TBA2] tentatively 11), then the client MUST assume that the server
> >> does no
On Jul 31, 2018, at 2:41 PM, Ted Lemon wrote:
> The client may perform as many DNS operations as it wishes using the
> -newly created DSO Session. Operations SHOULD be pipelined (i.e., the
> -client doesn't need wait for a response before sending the next message).
> +newly created DSO Session. W
Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refe
On Tue, Jul 31, 2018 at 6:28 PM, Eric Rescorla wrote:
> IMPORTANT
> S 5.3.
> > field set to zero, and MUST NOT elicit a response.
> >
> > Every DSO request message (QR=0) with a nonzero MESSAGE ID field is
> > an acknowledged DSO request, and MUST elicit a corresponding
> response
On Tue, Jul 31, 2018 at 7:28 PM, Ted Lemon wrote:
> On Tue, Jul 31, 2018 at 6:28 PM, Eric Rescorla wrote:
>
>> IMPORTANT
>> S 5.3.
>> > field set to zero, and MUST NOT elicit a response.
>> >
>> > Every DSO request message (QR=0) with a nonzero MESSAGE ID field is
>> > an acknowle
On Tue, Jul 31, 2018 at 10:28 PM, Ted Lemon wrote:
> The server is specifying the retry delay, so if the client adds
> randomness, that could result in more collisions rather than fewer.
>
>
>> S 8.2.
>> > The table below indicates, for each of the three TLVs defined in
>> this
>> > doc
On Tue, Jul 31, 2018 at 10:55 PM, Eric Rescorla wrote:
> Yeah, this seems fine. Didn't mean to make you do a lot of work here, just
> noticed as I was reading.
>
No problem, I think your comments on this and some other points that you
probably thought of as asides resulted in significant improve
On Tue, Jul 31, 2018 at 8:21 PM, Ted Lemon wrote:
>
> Sorry, has this been changed in a new version?
>>
>
> The text you commented on is the new version, with some additional text to
> address a point raised in the gen-art review. We gamed this out pretty
> thoroughly—I don't think there's an a
28 matches
Mail list logo
