use of this term, see
https://en.wikipedia.org/wiki/Split-horizon_DNS
It is not, to me, too great an overlap with split-horizon routing.
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[This topic is not directly relevant to dnsop working group events, but
the WG overlaps with the right set of technical folks, so pardon the
distraction.]
To improve B-Root DNS service, B-Root will be activating anycast on
2017-05-01, providing service from a new site in Miami in addition to
our
TCP does not require protocol changes, but it may
require implementation changes. (As per RFC-7766.)
TCP perhaps solves the "give me A + + MX" case.
Case (2) is the ability to have a server give back the answers to
questions you did not yet ask. Isn't that what the &q
sing-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html
The KB article talks about doing it in response to a large number of
NXDOMAINs per unit time, as it sounds like you encountered.
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, 25 Nov 2015 09:23:50 +1100, Mark Andrews wrote:
>
>
>In message <17673.1448400...@dash.isi.edu>, John Heidemann writes:
>> On Mon, 23 Nov 2015 20:25:29 +, "Wessels, Duane" wrote:
>> >
>> >> On Nov 23, 2015, at 11:58 AM, Mukund Siva
message maybe large enough that it is split into
multiple TCP segments (each a separate packet).
The statement: "an AXFR consists of the following 3 messages: Message1:
beginning SOA and some RRs, Message2: some intermediate RRs, Message3:
some more intermediate RRs..." I think conflates th
oad in the same segment is buggy
becuase, in general, there is NO way for sender to guarantee that
property. This is the limitation Jinmei pointed out.
Fortunately, app-level messages that are split across multiple TCP
segments (and therefore may require mutliple read() calls) are well
known to TCP deve
On Sun, 26 Jul 2015 22:56:10 -0700, Paul Vixie wrote:
>
>
>
>John Heidemann wrote:
>> ...
>>
>>> since you brought it up, i do want to know what the udp response policy
>>> will be for servers who have a new-style (explicitly negotiated) persistent
>
On Sat, 25 Jul 2015 19:24:17 -0700, Paul Vixie wrote:
>
>
>John Heidemann wrote:
>> On Sat, 18 Jul 2015 10:27:41 -0700, Paul Vixie wrote:
>>
>>>> ... With modern routers my understanding is it's usually bitrate not
>>>> packet count that is th
On Sat, 18 Jul 2015 10:27:41 -0700, Paul Vixie wrote:
>
>
>
>John Heidemann wrote:
>> ...
>> I think one has to be careful comparing TCP and UDP attacks here.
>>
>> Yes, this is a DoS attack. The question is not can TCP be used to
>> attack, but is i
(that is:
rate-limit queries per connection, connections per IP, and use SYN
cookies). See Figure 4 and section V-B in
http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf for graphs.
(These do not include your specific attack, but do consider spoofing and
non-spoofing.)
Use of TCP will require hardening DNS servers' TCP compared to today.
But in today's hostile Internet, such hardening seems necessary anyway.
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
are useful across MANY
deployment choices that are connection-based.
DNS-over-HTTP will see similar connection reuse rates as
DNS-over-TCP. TCP fastopen is good for HTTP and HTTP2 and DNS over TCP
and DNS over HTTP.
Please don't throw these babies out with the deployment bathwater.
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
s
initiators to other responders? How many responders keep your TCP
connection on and actually allow multiple queries? (There are concerns
about TCP port 53 being firewalled, or responders not handling TCP at
all.)
-John Heidemann
___
DNSOP mailing list
On Sun, 25 Jan 2015 09:44:24 +1100, Mark Andrews wrote:
>
>In message <54c40d28.7050...@redbarn.org>, Paul Vixie writes:
>> > Mark Andrews <mailto:ma...@isc.org>
>> > Thursday, January 22, 2015 6:29 PM
>> > In message <32707.1421975...@dash.isi.
[Warning to rubberneckers: seems like at least two topics here: about
the spec and about TCP as a DoS.]
On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote:
>#
> John Heidemann
>Wednesday, January 21, 2015 1:53 PM
>On Wed, 21 Jan 2015 09:30:44 +, Ray
On Wed, 21 Jan 2015 16:58:32 -0500, Christopher Morrow wrote:
>On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann wrote:
>> I don't see how DoS is an argument against TCP for DNS. (Unless one
>> assumes hardware and software at the servers is fixed to something like
>> 2
on't
that also create any DoS problems that stem from TCP?
I don't see how DoS is an argument against TCP for DNS. (Unless one
assumes hardware and software at the servers is fixed to something like
2004 standards.) What am I missing?
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
In Feb. 2014, Zi Hu posted about a study about DNS performance over TCP
and TLS. The context was a proposal to allow DNS to use TLS over TCP,
described in
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-01
We got a lot of input we got from the community (particularly those at
OARC in Wa
[I added dns-privacy to the cc list, since that seems like a relevant
forum for this discussion.]
On Mon, 07 Jul 2014 11:04:56 -0700, Paul Vixie wrote:
>Matthäus Wander wrote:
>
>...
>
>I didn't mean to imply that a DTLS solution can be universally deployed.
>
>
>because the dns is a
ver" without an adjective for (2) risks ambiguity
- recursive resolver vs. recursive server for (2) seem to depend on if
you're approaching the problem from the end-user or the providers
point of view. The challenge is that (2) is both a client AND server,
leading to inconsistency
On Thu, 24 Apr 2014 11:32:12 -0400, Phillip Hallam-Baker wrote:
>...
>
>For me the idea of putting TLS traffic over the same port as non TLS
>traffic without careful attention to how the upgrade is achieved would
>be 'butchering the protocol'. Changing the port number to one that is
>known to work
he
coverage they're paying for.
(Of course, you have to decide if that example is a reason for, or against :-)
-John Heidemann
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
22 matches
Mail list logo
