On 30.7.2018 15:32, Tony Finch wrote:
> Paul Wouters wrote:
>>
>> We are looking at a way to distribute the root zone, presumably to
>> make the root servers less mission critical and for enhanced
>> privacy and reduced NXDOMAIN queries.
>
> RFC 8198 with qname minimization give you the latter
On Jul 30, 2018, at 5:03 PM, Wes Hardaker wrote:
>> I think the use for non-root zones is quite a different use case,
I don’t.
>> so if
>> I ignore that, we are looking at specifically the root zone only.
>
> Please don't ignore that. We really do ourselves a disservice when we
> design a solu
Paul Wouters writes:
> What I see is that:
>
> We are looking at a way to distribute the root zone
> maybe this is also useful for non-root zones, so the method was sort
> of made to apply generically.
> I think the use for non-root zones is quite a different use case, so if
> I ignore
Tim Wicinski writes:
> 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 go
Paul Wouters writes:
> That leaves glue and NS, but there is a reason those aren't signed,
> and any attacker shouldn't get anything out of that by modifying it.
Yes, the glue isn't authoritative and thus not signed by DNSSEC.
But, if you're transferring a zone from an original source to any
se
On 30 Jul 2018, at 16:12, Evan Hunt wrote:
On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote:
I am still mystified about the scenario in which a malicious zone
operator creates two zone files with the same ZONEMD hash, one with
the
right set of addresses for unsigned child zones, a
On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote:
> I am still mystified about the scenario in which a malicious zone
> operator creates two zone files with the same ZONEMD hash, one with the
> right set of addresses for unsigned child zones, and a different one
> with one of more of
On 30 Jul 2018, at 14:44, Wessels, Duane wrote:
While I wouldn't necessarily be opposed to having an RR count field of
some kind if there is good reason to have it, my preference would be
to omit it and keep the record simpler.
I am still mystified about the scenario in which a malicious zone
> On Jul 29, 2018, at 2:03 PM, Evan Hunt wrote:
>
> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
>> You need to know the hash is valid before you start the download.
>> Therefore the hash has to be signed.
>
> Before you *start* the download? Or before you use what you download
> On Jul 26, 2018, at 7:39 PM, Steve Crocker wrote:
>
> The passage below puzzles me. Why do you want servers to get the root zone
> from less trusted sources?
Steve,
I wouldn't put it that way. I'd say that the servers shouldn't have to trust
the sources, they should have the ability to
You can do what BGP implementations have been doing for decades and
just put a count in that allows for some growth. Named and I presume
other servers already has the ability to track records during a zone
transfer (AXFR and IXFR) and abort if the count becomes too large.
The following allows fo
> On Jul 24, 2018, at 7:32 AM, John Levine wrote:
>
> In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>> The ZONEMD record should contain a size indicator for the zone,
>> something that allows a receiver to stop downloading if it is clear
>> that the served zone is too large. Otherwi
> On Jul 28, 2018, at 2:30 AM, Tim Wicinski wrote:
>
> (these are just my comments alone. So take it as such)
Thanks Tim,
I don't think these questions are already answered, so thank you for bringing
them up.
>
> The draft states in the Motivation section:
> "The motivation and design of
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Terminology'
as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comme
Mirja Kühlewind 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. (Feel free to cut this
introductory paragraph, however.)
Please refer t
Hi Ben, hi all,
as you summoned an TSV AD...
> Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk :
>
> I should probably leave this to my (transport-area?) colleagues to discuss
> further, but I'm not sure that the interaction of this mechanism with
> high-RTT connections is fully covered -- for exa
Hi Mirja,
On Mon, Jul 30, 2018 at 08:11:52PM +0200, Mirja Kuehlewind (IETF) wrote:
> Hi Ben, hi all,
>
> as you summoned an TSV AD...
>
> > Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk :
> >
> > I should probably leave this to my (transport-area?) colleagues to discuss
> > further, but I'm not
No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME,
or ANY, or lots of things.
I'm just using "could I implement this with TXT?" as a proxy for whether
it's a major change to the way the DNS works, or just a thing we can move
forward on with expert review.
Ah. I gather the
On Mon, Jul 30, 2018 at 09:19:14AM +0200, Ondřej Surý wrote:
> I know some people have 40Gbps at mothers house, but for general
> usefulness you want to prevent downloading fake (or otherwise invalid)
> zone before you start downloading it.
While this does seem like a potentially useful feature, I
On Mon, Jul 30, 2018 at 11:03:25AM +1000, Mark Andrews wrote:
> Actually it needs to be a type code. How do you hash the TXT RRset and
> RRSIG(TXT) RRset when you need to modify both of them after computing the
> hash? You need to be able to cleanly exclude the records from the ZONEMD /
> XHASH c
On Sun, Jul 29, 2018 at 09:26:19PM -0400, John Levine wrote:
> Well, heck, we could do the whole DNS with TXT records.
No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME,
or ANY, or lots of things.
I'm just using "could I implement this with TXT?" as a proxy for whether
it's
We slept for the last 35 years!
"the software originated in the early 1980s at the University of
California at Berkeley [...] Not much about the DNS protocol has
changed since then."
https://www.networkworld.com/article/3293006/internet/ns1s-private-dns-enables-modern-applications-devops-and-more
On Mon, 30 Jul 2018, Ondřej Surý wrote:
I know some people have 40Gbps at mothers house, but for general usefulness you
want to prevent downloading fake (or otherwise invalid) zone before you start
downloading it.
This feels like what we call in the US moving the goalposts.
How do you know n
Hi Spencer, hi authors,
please see a few comments below. More might be coming as I’m currently
reviewing the doc.
> Am 27.07.2018 um 06:33 schrieb Spencer Dawkins
> :
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-dnsop-session-signal-12: Discuss
>
> When respo
On Sun, Jul 29, 2018 at 3:09 PM Steve Crocker wrote:
>
> Joe,
>
> As an individuals, you, I, or anyone else, can do whatever we like, of
> course. On the other hand, as system designers we presumably look at the
> overall system and try to put in place an operational structure that
> anticipat
Paul Wouters wrote:
>
> We are looking at a way to distribute the root zone, presumably to
> make the root servers less mission critical and for enhanced
> privacy and reduced NXDOMAIN queries.
RFC 8198 with qname minimization give you the latter two.
> We are depening on DNSSEC for integrity of
John R Levine wrote:
>
> I'm also thinking the hash wouldn't need to include the RRSIG records, since
> those are mechanically derived from the underlying records and the ZSK.
If you omit the RRSIGs from the hash, you'll have to verify all the RRSIGs
to ensure you aren't serving a bogus zone, and
I know some people have 40Gbps at mothers house, but for general usefulness you
want to prevent downloading fake (or otherwise invalid) zone before you start
downloading it.
Especially, it might be very harmful if the client could be tricked into
downloading any data distributed via torrent. Yo
28 matches
Mail list logo
