Paul,
On Feb 14, 2019, at 1:57 PM, Paul Vixie wrote:
> 7706 is wrong headed on a number of levels, but its worst offense is to think
> that the root zone is special.
Operationally, the root zone actually is special. It is, after all, the
starting point of the name space. As far as I can tell,
sorry, because of my english level, i misused the word "protect".
i know the difference between channel security and object security.
but in my proposal, the premise is the recursive server should completely trust
an Authenticated server.
i think this is simialr in DNSSEC, because if an
On Thu, Feb 14, 2019 at 04:58:38PM +0800,
zuop...@cnnic.cn wrote
a message of 126 lines which said:
> if an DNSSEC_enabled authotative server(no matter it is Alice or
> Bob) is evil and modifies DNS records, it will succeed because it
> has private key
It is completely false. (You seem to
On Wed, Feb 13, 2019 at 10:51:00PM +0100,
Vladimír Čunát wrote
a message of 118 lines which said:
> Technically you can run DoT on whatever port you like.
> Example: with knot-resolver it's easy - you just add @443, either on
> side of server and/or on the side of forwarding over TLS.
The
> for instance a DoH or DoT server that intentionally or accidentally returns
> false data. DNSSEC can counter that.
I dont understand why.
If a server intentionally returns false data , it can fake anything because it
owns the private key, DNSSEC does not help either.
> Indeed. That’s
On Thu, Feb 14, 2019 at 04:31:35PM +0800,
zuop...@cnnic.cn wrote
a message of 74 lines which said:
> > for instance a DoH or DoT server that intentionally or
> > accidentally returns false data. DNSSEC can counter that.
>
> I dont understand why.
> If a server intentionally returns false
Stephane,
On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
On Wed, Feb 13, 2019 at 10:51:00PM +0100,
Vladimír Čunát wrote
a message of 118 lines which said:
Technically you can run DoT on whatever port you like.
Example: with knot-resolver it's easy - you just add @443, either on
side
On Thu, Feb 14, 2019 at 02:36:14PM +0800,
zuop...@cnnic.cn wrote
a message of 86 lines which said:
> i think both DNSSEC and DoH(or DoT) can protect DNS data,
"Protect" is like "security", a word so vague, which includes so many
different (and sometimes contradictory) services that it is
On Thu, Feb 14, 2019 at 04:11:20PM +0800,
zuop...@cnnic.cn wrote
a message of 102 lines which said:
> No. i might did not explain it clearly.
It was clear but you repeat the same stuff, without taking into
account the remarks (or the existing documents, such as
> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote:
>
> the premise is the recursive server should completely trust an Authenticated
> server
You’ve already made that clear. The problem with that premise is it’s a false
one. It represents a naive/unrealistic view of how the DNS is used.
On 2/14/19 9:05 AM, Stephane Bortzmeyer wrote:
>> Technically you can run DoT on whatever port you like.
>>
>> Example: with knot-resolver it's easy - you just add @443, either on
>> side of server and/or on the side of forwarding over TLS.
> The problem is that you cannot then share this port
Vladimír Čunát writes:
> You can still multiplex based on SNI sent by the client. HTTPS clients
> surely send it commonly. DoT clients perhaps not so often, but that's
> just an implementation detail (which I was fixing in the past few weeks
> in knot-resolver, incidentally).
My understanding
On 14 Feb 2019, at 05:03, Shane Kerr wrote:
> On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
>> On Wed, Feb 13, 2019 at 10:51:00PM +0100,
>> Vladimír Čunát wrote
>> a message of 118 lines which said:
>>> Technically you can run DoT on whatever port you like.
>>> Example: with knot-resolver
Bjørn Mork wrote:
>
> My understanding of the reference to BCP195 from
> https://tools.ietf.org/html/rfc7858#section-3.2
> is that SNI support is required for all DoT implementations.
>
> It's simple to do with haproxy at least:
>
On 14.02.19 11:03, Shane Kerr wrote:
Stephane,
Is there a write-up on this?
Thinking about it naively, a demultiplexer really only needs to say "is there a
non-ASCII character in the first 2 or 3 bytes of a TLS session?".
Hi,
please think of HTTP/2, which is a binary protocol
Klaus,
On 14/02/2019 14.00, Klaus Malorny wrote:
On 14.02.19 11:03, Shane Kerr wrote:
Is there a write-up on this?
Thinking about it naively, a demultiplexer really only needs to say
"is there a non-ASCII character in the first 2 or 3 bytes of a TLS
session?".
please think of HTTP/2,
The call for acceptance for draft-song-atr-large-resp is closed, and it
is clear that there is insufficient support to adopt the concept as a
DNSOP WG document.
There was some concern about the increased number of packages involved
in a legitimate exchange (half of them being ICMP messages,
On Thu, Feb 14, 2019 at 8:59 AM Tony Finch wrote:
> Jiankang Yao wrote:
> >
> >A new draft about root data caching is proposed, which aims to solve
> >the similar problem presented in RFC7706 and gives the DNS
> >administrator one more option.
>
> How does this relate to:
>
>
> On 14 Feb 2019, at 16:12, Warren Kumari wrote:
>
>
>
> On Thu, Feb 14, 2019 at 8:59 AM Tony Finch wrote:
> Jiankang Yao wrote:
> >
> >A new draft about root data caching is proposed, which aims to solve
> >the similar problem presented in RFC7706 and gives the DNS
> >
Jiankang Yao wrote:
>
>A new draft about root data caching is proposed, which aims to solve
>the similar problem presented in RFC7706 and gives the DNS
>administrator one more option.
How does this relate to:
https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
On Mon, Jan 07, 2019 at 12:30:10PM -0800,
internet-dra...@ietf.org wrote
a message of 44 lines which said:
> Title : Extended DNS Errors
> Authors : Warren Kumari
> Evan Hunt
> Roy Arends
>
On Thu, Feb 07, 2019 at 04:47:01PM +0100,
Petr Špaček wrote
a message of 129 lines which said:
> > 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
> >
> >The resolver attempted to perform DNSSEC validation, but a DNSKEY
> >RRSET contained only unknown
On 2/14/19 12:51 PM, Stephane Bortzmeyer wrote:
> On Mon, Jan 07, 2019 at 12:30:10PM -0800,
> internet-dra...@ietf.org wrote
> a message of 44 lines which said:
>
>> Title : Extended DNS Errors
>> Authors : Warren Kumari
>> Evan Hunt
On Thursday 14 February 2019 14:58:58 CET, Tony Finch wrote:
How does this relate to:
https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
https://tools.ietf.org/html/draft-ietf-dnsop-7706bis
It originates in various ideas Jiankang and I have chatted about.
I didn't like 7706, because I
In article <9a7b4bc4-018a-9f8c-d3fd-2428356d6...@time-travellers.org> you write:
>I think that HTTP/2 preserves the initial handshake of HTTP/1.1.
Seems to me you could make it work using SNI, so long as the name you
use for the web and DNS servers are different. I realize this makes
it more
7706 is wrong headed on a number of levels, but its worst offense is to
think that the root zone is special. we need dns to have leases on its
delegation chain including glue and dnssec metadata. everything you
might need to use in order to reach a zone authority and trust its
results should
> On 15 Feb 2019, at 8:57 am, Paul Vixie wrote:
>
> 7706 is wrong headed on a number of levels, but its worst offense is to think
> that the root zone is special. we need dns to have leases on its delegation
> chain including glue and dnssec metadata. everything you might need to use in
>
On Thu, Feb 14, 2019 at 12:29 PM Arnt Gulbrandsen
wrote:
> On Thursday 14 February 2019 14:58:58 CET, Tony Finch wrote:
> > How does this relate to:
> >
> > https://tools.ietf.org/html/draft-wkumari-dnsop-hammer
> > https://tools.ietf.org/html/draft-ietf-dnsop-7706bis
>
> It originates in
On Thu, Feb 14, 2019 at 12:34 PM Warren Kumari wrote:
>
>
> On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer
> wrote:
>
>> On Mon, Jan 07, 2019 at 12:30:10PM -0800,
>> internet-dra...@ietf.org wrote
>> a message of 44 lines which said:
>>
>> > Title : Extended DNS Errors
On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer
wrote:
> On Mon, Jan 07, 2019 at 12:30:10PM -0800,
> internet-dra...@ietf.org wrote
> a message of 44 lines which said:
>
> > Title : Extended DNS Errors
> > Authors : Warren Kumari
> >
so, you would like the DNS to be resilient enough to "see" what was
topologically reachable and build a connected graph of those assets? I
think that has been done, both academically and in a more limited way,
commercially, but its not called DNS so as not to upset the DNS mafia. Or
do you want
william manning wrote on 2019-02-14 17:35:
so, you would like the DNS to be resilient enough to "see" what was
topologically reachable and build a connected graph of those assets?
no. that's not possible, and not desireable in any case.
I think that has been done, both academically and in
On 2/14/19 6:51 PM, Paul Vixie wrote:
i want the metadata i need to reach and trust assets on my side of any
connectivity loss event, to be kept in warm storage, and made subject to
trusted invalidation on an opportunistic basis, at the discretion of the
authority operators who own the data i
You are welcome. I think, modulo minor differences in terminology, we are
saying pretty much the same thing.
pragmatically, DNS infrastructure dependencies can not be maintained and
work on data resiliency is where the useful work lies.
/Wm
On Thu, Feb 14, 2019 at 5:51 PM Paul Vixie wrote:
>
Grant Taylor wrote on 2019-02-14 18:27:
Please explain how "warm storage" relates to priming issues. Does
warm mean that it's something you have queried? Or does it also
include pertinent (meta)data for interesting things (but not
everything) that you've not yet queried?
i don't expect
On Thu, Feb 14, 2019 at 04:05:22PM -0800, Paul Vixie wrote:
> nope. because it did not prototype any partial replication. i'm not
> going to mirror COM because i need it to reach FARSIGHTSECURITY.COM.
I didn't say anybody's going to mirror COM, I said I suspect zone
mirroring will find
As we discussed during the interim dprive meeting held last December, we need
more empirical studies looking at performance as well as attack vectors. I’m
aware of Sinodun’s efforts in this area but are there others that address
performance and attack vectors specifically for both DoT and DoH
Mark Andrews wrote on 2019-02-14 14:13:
...
the fact that i have to hotwire my RDNS cache with local zone glue in order to
reach my own servers when my comcast circuit is down or i can't currently reach
the .SU authorities to learn where VIX.SU is, should not only concern, but also
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote:
> unbound has pioneered a bit of this by automatically refetching data
> that's near its expiration point.
[...]
> _that_ would be complexity worth its cost. 7706 was not. HAMMER is not.
I'm confused, what's the difference between
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote:
> indeed nothing which treats the root zone as special is worth pursuing,
> since many other things besides the root zone are also needed for
> correct operation during network partition events.
This point is well taken, but sometimes
Evan Hunt wrote on 2019-02-14 15:56:
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote:
indeed nothing which treats the root zone as special is worth
pursuing, since many other things besides the root zone are also
needed for correct operation during network partition events.
41 matches
Mail list logo
