> On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman wrote:
>
> Hi Nicholas
>
> On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote:
>> This way, you can deploy this solution today using white lies, and as
>> resolvers are updated, this reduces the potential n
is deployable today and
has improved security (key can only fake NXDOMAIN) tomorrow.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http
on not the path. Unknown record
types seem to be well supported from a transport viewpoint.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
P
> On Nov 12, 2015, at 8:43 AM, John Kristoff wrote:
>
> On Thu, 12 Nov 2015 08:00:50 -0800
> Nicholas Weaver wrote:
>
> After a DNS over TCP discussion a student of mine indicated that they
> recently fixed a problem in their network where DNS messages over 512
> byte
SP
> firewalls are interfering with EDNS?
We've done some of this in Netalyzr. Captive portals in particular are a
problem, with about 1% of systems measured in Netalyzr unable to use EDNS0 to
get DNSSEC information either from the recursive resolver OR directly from the
roo
eventing you from serving up common NXDOMAIN records, and the DOS only
affects the NXDOMAIN side anyway: you can probably get the same results in most
cases by serving up an NXDOMAIN without an NSEC3 RRSET, as the resolver will go
"this doesn't validate" and give a se
> On Mar 13, 2015, at 7:59 PM, Paul Vixie wrote:
> > Nicholas Weaver Saturday, March 14, 2015 5:07 AM
>>
>>> ...
>>>
>>> Overall, unless you are validating on the end host rather than the
>>> recursive resolver, DNSSEC does a lot of harm
ween the recursive resolver and the user lies.
Again, validation from the recursive resolver works how?
Overall, unless you are validating on the end host rather than the recursive
resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no
good.
--
Nicholas Weaver
idated by upgraded resolvers, and you still get
the protection against enumeration when the resolver isn't upgraded, and you
don't need to upgrade the resolver in order for this to be deployed.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edu
at Fragmentation Does Not Work with
IPv4, and Really Does Not Work with IPv6.
This will cause timeouts until the resolver realizes it should use a smaller
EDNS0 MTU and in that case, the resolver will failover to TCP for that query,
which some in the DNS community view as anathema...
--
Nicholas W
ge proposal bears on this, but today, it's 3
> rtt, 7 pkt, and that's assuming that the response fits in one window. axfr is
> obviously much longer.
And this is wrong: The f+a RTT doesn't matter, thats AFTER the result has been
received. TCP is 2 RTT to actuall
cp change proposal bears on this, but today, it's 3
> rtt, 7 pkt, and that's assuming that the response fits in one window. axfr is
> obviously much longer.
And this is wrong: The f+a RTT doesn't matter, thats AFTER the result has been
received. TCP is 2 RTT to actuall
an amusing list. i can understand EXAMPLE, LOCALHOST, and TEST.
> maybe even WHOIS and WWW. but the rest sure look as if lawyers wanted
> and got what is in effect a super trademark.
Its also missing one thats actually really important to be reserved: .onion.
--
Nicholas Weaver
irst seen by me in looking at Comcast's DNS infrastructure):
In the lower 64 bits of the IPv6 address, encode as human-readable the IPv4
address. So, for example, if a machine's V4 address is 10.1.2.4, the IPv6
address is 2101:{...}:10:1:2:4
--
Nicholas Weaver it is a
t is fetched
out of the cache at least X times, when you expire it from the cache
immediately trigger a new fetch for that name.
This would have a much better performance benefit than a root zone mirror.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edu
DNS traffic already. But my
> question about why not just hijack the address of an existing root
> stands.
This happens in China (on CERNET I believe): there are a set of root mirrors
that hijack most (but not all) of the root IPs. As far as we can tell, the
servers are legitimate, r
ore the developer started keeping a changelog.
Short of setting deliberate viral brush fires designed to brick old devices,
we're stuck with them and need to plan around them.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull o
On Jul 28, 2014, at 8:42 AM, Stephane Bortzmeyer wrote:
>> Quite a few folks usually argue "oh, that's simple: we'll use TCP",
>
> There are many good reasons to use TCP but, in that case, I do not see
> why we need it. First, IPv6 users typically don't use extension
> headers and, second, if th
adversary running a pretty conventional real-time or even near
real time IDS. Doing it on the backbone is not hard, and overall, its no more
complex than analysis we know they do like identify ALL users based on cookies
and HTTP replies.
It is AMAZING the IDS analyses you can run o
er what the hostname was in question in many
cases, and at least the domain in almost all cases.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: h
osal: A server
would have to know about the NOTE record to receive them in a zone transfer, so
as long as the source knows what its doing, the recipient will only receive the
NOTE records if they know what they are.
The only case would be if a server is reading a zone file, not a transfer,
lly since bits themselves are not precious (DNS requests are no where
near getting near 512b, let alone the ~1500b where fragmentation is an issue),
and this is primarily for zone transfer queries anyway, which means the
overhead is going to be near zero anyway.
--
Nicholas
one, and
you then use a dictionary attack: NSEC3 in a static case, even with a huge
number of bogus NSEC3 records you can only hide names if names are not a-priori
predictable from a reasonable attacker.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkel
uot;semi-online": The names
you care about have at least some history/cacheability, and some level of
finite space, but only on the order of a minute. Once that property is there,
you can do dynamic signing to your heart's content.
--
Nicholas Weaver it is a tale, to
s a finite,
identifiable, priority set, and cache the responses. Thus if you have 10k
valid names, each with 100 different possible responses, and have a max 1
minute TTL on signatures, thats only 16k signatures/s in the absolute worst
case, which you can do on a single, 16 core computer.
--
N
S, and supports dynamic
signatures (including dynamic NSEC3 lies), tell me, I can give you my
(ugly-ass) source.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .si
t something implemented, do it. If you want to argue about it, with
people who object to it on philosophical grounds of enabling "stupid DNS
tricks", write an RFC.
This discussion is just one more datapoint in the set of "This is why the IETF
is where protocols go to die".
--
frankly, a mess
to map "client subnet to recursive resolver", but it is an insanely powerful
optimization when you can.
edns_client_subnet makes this mapping trivial, and therefore acts to
significantly improve end user performance.
--
Nicholas Weaver it is a tale, t
from running new services without firewall rule modifications, but
outbound blocking is far less common. (Our test port for this is TCP 1947 with
Netalyzr).
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fu
talking about mucking with the handshake.
b: DO NOT USE PORT 53 for this: There are far far too many networks (1%+)
that reinterpret DNS requests or just outright block all DNS to non-approved
servers, and more still which block non-DNS over DNS.
--
Nicholas Weaver it is
nts on IPv4),
rather than skipping directly down to EDNS with an MTU of 512B, and if multiple
authority servers require this fallback, the recursive resolver should use this
MTU for all authorities, and just accept the minor latency hit incurred in
having to shift to TCP more in the very rar
ecord and use a 'root key ratchet': never
accept a key who's expiration is older than the inception date of the RRSIG on
the youngest root ZSK seen, or have some other defense to roll-back-the-clock
attacks.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea..
those that do have
> decent “excuses” (read: unusual use cases) and so they are not used in the
> peer pressure arguments.
And that does no good unless the upstream in the path of trust, starting at the
root, actually use real length keys.
The difference between 2^80 and 2^100 effort is
ich
force the user to use the configured recursive resolver. Fortunately, most of
those support fetching DNSSEC records. But note that I said most, not all
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edu
idating DNSSEC, everything is signed, yet you
can't afford to run on a single modern dual-CPU oct-core system, you get no
sympathy from me.
>> And yeah, DNS is peaky, but that's also why this task is being run on a
>> cluster already, and each cluster node has a lot of CPUs.
y won't notice 50
milliseconds...
> Weakening the crypto algorithms to make the architecture work is always a
> sign that the wrong architecture is being applied.
And weakening the crypto needlessly like this is even worse. IMO, all DNSSEC
software should simply refuse to gen
2048b keys.
And yeah, DNS is peaky, but that's also why this task is being run on a cluster
already, and each cluster node has a lot of CPUs.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903
On Mar 28, 2014, at 1:34 AM, Stephane Bortzmeyer wrote:
> On Thu, Mar 27, 2014 at 01:15:00PM -0700,
> Nicholas Weaver wrote
> a message of 75 lines which said:
>
>> But fixing this going forward requires a 1-line change in the ZSK
>> script:
>
> I have nothin
-line change in the ZSK script:
-b 2048
That's it. Since the KSKs are already 2048b, and therefore there are
appropriate RRSIGs, its clear that the server side is set up to handle real key
lengths.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkele
ontrast, DNSSEC seems mired in a 1024b swamp at the root, and when you can
use an old key (which you can for the root, since you can fake everything up
below that dynamically and fake NTP so that your bad key is still kosher),
breaking a root key really would be breaking DNSSEC.
--
Nicholas Weave
On Mar 27, 2014, at 7:22 AM, Joe Abley wrote:
>
> On 27 Mar 2014, at 22:56, Nicholas Weaver wrote:
>
>> Bits are not precious: Until a DNS reply hits the fragmentation limit of
>> ~1500B, size-matters-not (tm, Yoda Inc).
>>
>> So why are both root and
On Mar 27, 2014, at 6:56 AM, Nicholas Weaver wrote:
> And, frankly speaking, a 3500 node cluster for a day is $75K thanks to EC2.
>
> Do you really want someone like me to try to get an EC2 academic grant for
> the cluster and a big slashdot/boingboing crowd for the sieving t
e ago, but
hey...
If people actually want DNSSEC to be taken seriously as a PKI-type resource
(a'la DANE), the DNS community needs to actually, well, use secure crypto.
1024b RSA is not secure. Go Big or Go Home.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea.
Thanks. Indeed I was stupid: wrong base32 encoding
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver
19c4ed041c959edcf3b9f741060d7e5d42f96'
But at the same time, this matches the sha1sum for a file containing just the
string "\x03com\x00", so the hash is correct for sha1.
So the conclusion is I'm not putting in the right input into the hash function.
Thoughts on what I'm
On Jan 6, 2014, at 12:54 PM, Andrew Sullivan wrote:
> On Mon, Jan 06, 2014 at 01:48:04PM -0500, Ted Lemon wrote:
>> It seems to me that TOR is a pretty vital application, even if it's
>> not as popular as .local (which, let's be honest, is almost never
>> seen, much less typed, by an end user).
ICSI, but not our DNS server, so you know the route goes to the west
coast of the US)
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying noth
he random output
to make it predictable).
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nwea
Future protocols MUST support "Connect by multiple name" semantics: Given
MULTIPLE names, only connect if all K names have the same IP after resolution.
(This enables multiple-validation-path DNSSEC, which is a pretty uni).
--
Nicholas Weaver it is a tale, told by an i
nly a single CA, you end up having to trust the entire universe of
certificate authorities.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
P
p on the
TLS PKI for their own use in Chrome: they hardcode the Google sub-CA.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi
es are generated on the fly, are
almost certainly going to be developed to utilize this infrastructure.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .sig
addition will include the ability to add a NONCE to guarantee
cache-busting, too).
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.ics
configuring
DNSSEC, there is an assumed minimum clue level"
Has anyone yet studied whether the DS and NS RRSETs tend to change at the same
time for major domains?
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufu
s, now basically everyone gets
protected since Nominum's usage by Comcast for recursive resolver validation
guarentees that there is a large customer base which will be behind such
protection, making this very visible.
Thoughts? Comments?
--
Nicholas Weaver i
On Jun 18, 2013, at 8:22 AM, Mark Andrews wrote:
>> My goal as it were was to look at if fragmentation were expected to work
>> that I don't really want to expose myself to reciving a 4k response (via
>> UDP) because the risk of an amplification attack becomes very large
>> indeed. Even if I f
Lets just say if you think the IPv4 fragmentation problem is bad, IPv6 makes it
look positively benign by comparison on the IPv6 kit deployed today.
Basically, use a 1400B EDNS0 mtu, and failover to TCP.
___
DNSOP mailing list
DNSOP@ietf.org
https://ww
On Apr 4, 2013, at 1:19 PM, Paul Hoffman wrote:
>> I think nothing is needed here except perhaps a statement of the bleeding
>> obvious: "if you miss too many key rollovers, Very Bad Things will happen so
>> make sure you have a foolproof way of recovering from that".
>
> We need that statemen
How do recursive resolvers react to unknown EDNS0 options?
Are the requests simply dropped?
Is the unknown option removed and ignored?
Passed to the authority unchanged?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/d
On Jun 27, 2012, at 11:15 AM, Joe Abley wrote:
> Hi all,
>
> The only suggestion I have heard relating to this draft is that if we
> supplied custom software to synthesise answers we could avoid the
> overly-broad SOA RR returned with the NXDOMAIN.
> (My personal opinion is that this leads us
On Jun 12, 2012, at 8:17 AM, Joe Abley wrote:
>> 121.14.34.10.in-addr.arpa. 300 IN SOA prisoner.iana.org.
>> hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
>>
>> as the SOA?
>
> That would involve custom software. At present, anybody can run an AS112
> server us
On Jun 12, 2012, at 7:40 AM, Warren Kumari wrote:
> Hi there all,
>
> So, back in (AFAIR) Taipei I proposed making AS112 instances simply be
> authoritative for *everything*, and then simply delegating and undelegating
> things to it as appropriate (this would make things much simpler as there
On Apr 13, 2012, at 2:18 PM, Patrik Fältström wrote:
>
> On 13 apr 2012, at 22:44, Nicholas Weaver wrote:
>
>> Because practice has shown that it is the recursive resolver, not the
>> authority, that gets blamed.
>
> As you saw in my mail, I completely di
On Apr 13, 2012, at 1:24 PM, Patrik Fältström wrote:
>
> On 13 apr 2012, at 22:09, Evan Hunt wrote:
>
>> On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
>>> i'm opposed to negative trust anchors, both for their security
>>> implications if there were secure applications in existence
On Apr 11, 2012, at 6:02 AM, Ralf Weber wrote:
>> Suggested rewrite:
>>
>> Furthermore, a Negative Trust Anchor MUST only be used for a
>> short duration, perhaps for a day or less. Implementations MUST
>> require an end-time configuration associated with any negative
>> tru
On Mar 1, 2012, at 7:59 AM, John R Levine wrote:
>> It is the caching of non-asked-for data, be it Auth, Additional, CNAME
>> chains, etc, which enables race-until-win attacks like the Kaminski attack.
>>
>> Thus a resolver MUST NEVER cache data that wasn't specifically asked for if
>> it can'
On Mar 1, 2012, at 6:08 AM, John R Levine wrote:
>>> the additional section. MX queries already have their kludge,
>>> returning A and records.
>>
>> I'm pretty sure MX queries do NOT have a kludge. I don't believe that
>> the additional section is actually used by any servers these days,
>
On Feb 28, 2012, at 10:04 AM, Paul Vixie wrote:
> On 2/28/2012 5:57 PM, Nicholas Weaver wrote:
>> But since if you could coalesce you could do parallel, this savings doesn't
>> help latency much at all: just the transit time for 50B out and 50B back.
>> If anything,
Just some BotE: Overhead for each DNS datagram (on an Ethernet) is 8 B for the
Ethernet Preamble, 14B for the Ethernet header, 20B for the IP header, and 8
bytes for the UDP header, for a total of 50B.
Assuming the question is 50B, and the answer is 150B, the overhead saved is Not
That Much
On Jan 18, 2012, at 11:14 AM, Paul Vixie wrote:
> On 1/18/2012 7:06 PM, W.C.A. Wijngaards wrote:
>>> this sounds very cool; is there an internet draft or tech note
>>> describing the protocol so that others may also implement this?
>>
>> It exists to bypass deep inspection firewalls, and it work
On Sep 30, 2011, at 5:56 PM, Masataka Ohta wrote:
> Nicholas Weaver wrote:
>
>> Correct. But this is why you need to have queries that check the
>> caching server AS WELL. The CHAOS queries are useful here, as
>> are queries for the cached normal data, and queries wh
Your technical comments:
>> b: These should have a TTL of 0 seconds and/or support a
>> prepended, cache-busting wildcard.
>
> Loss of synchronization can occur between cached normal data
> and uncached identification data. And, as I already mentioned
> what is broken may be the caching serve
Note: The following is manually formatted because
you are incapable of using a modern mail reader OR
have deliberately misconfigured your modern mail reader
OR are reading the message using a buggy archive:
On Sep 29, 2011, at 9:34 AM, Masataka Ohta wrote:
> Nicholas Weaver wrote:
>
On Sep 29, 2011, at 7:40 AM, Masataka Ohta wrote:
>>
>> And we're already seeing today, and expect more in the future,
>> systems where the front-line support instructions include
>> "run a one-click or two-click tool", rather than "run dig".
>
> It means those who can use "run a one-click or tw
On Sep 29, 2011, at 4:05 AM, Masataka Ohta wrote:
>> that happens sometimes. however, i often end up in an email conversation
>> with
>> a problem reporter, and i often ask them to run certain "dig" commands. so,
>> even if i can't reach a recursive server, a feature like this can still help
>>
On Sep 28, 2011, at 7:34 AM, Edward Lewis wrote:
> As far as DNS as a service, I'd rather just have the customer say "I can't do
> this, and this is where I am". Once customers begin to diagnose the
> situation, they generally set up incorrect expectations. With incorrect
> expectations comes
On Sep 28, 2011, at 5:47 AM, Joe Abley wrote:
>
> On 2011-09-27, at 14:21, Edward Lewis wrote:
>
>>> We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
>>> VERSION.SERVER as well as RFC5001/NSID on L-Root, for example.
>>
>> It's not a matter of honesty.
>
> No inferen
On Jan 17, 2011, at 6:25 AM, Ted Lemon wrote:
> On Jan 17, 2011, at 9:22 AM, Andrew Sullivan wrote:
>> (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow
>> to have authenticated the DNS server in question otherwise before
>> accepting the claims about signature validation. I c
Much to my embarrassment, our Netalyzr test for RFC3597 (unknown RRTYPE
handling. We used RRTYPE=169 for our testing, as its unassigned yet a
convenient mnemonic) was broken for us by the upstream authorities in our path
without my realizing it:
Bad enough is that all of the a
One thing we've observed in Netalyzr is that RFC3597 (handling unknown
RRTYPEs as opaque binary data) is almost universally ignored.
Does anyone have a good set of open recursive resolvers from different
vendors that can be queried against for testing?
_
Since there is now both a signed root and signed TLD (cz), does anyone
have some good test names for DNSSEC both with and without NSEC3?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Jul 29, 2010, at 12:27 PM, Tore Anderson wrote:
> * Nicholas Weaver
>
>> Could someone with a IPv6 connected recursive resolver do a favor for
>> me?
>>
>> Validate that
>>
>> ipv6_dns.eaoe.n1.netalyzr.icsi.berkeley.edu
>>
>>
Could someone with a IPv6 connected recursive resolver do a favor for
me?
Validate that
ipv6_dns.eaoe.n1.netalyzr.icsi.berkeley.edu
resolves to
67.202.37.63
(this is a new test name being integrated into Netalyzr, where the only
authority reco
On Apr 1, 2010, at 7:51 AM, Jason Livingood wrote:
> 2 - Describe all the various methods and tactics by which end user
> "brokenness" can be detected. This may include website-based detection,
> DNS-query-based detection, or a variety of other methods.
>
> Suggestions: (Nick Weaver I think h
A far better "solution" would be to instead segregate with different DNS server
IPs.
ISPs already have multiple DNS resolvers (eg, "no wildcarding" resolvers,
DNSSEC test resolvers). And the ISP knows if its giving out a v6 address or
not for a client and routing IPv6 for that client.
And e
On Mar 31, 2010, at 6:42 AM, Edward Lewis wrote:
> At 3:28 -0400 3/31/10, Igor Gashinsky wrote:
>
>> You are absolutely right -- it's not a DNS problem, it *is* a host
>> behavior problem. The issue is that it takes *years* to fix a host
>> behavior problem, and we need to engineer and deploy a
On Mar 31, 2010, at 12:28 AM, Igor Gashinsky wrote:
>
> You are absolutely right -- it's not a DNS problem, it *is* a host
> behavior problem. The issue is that it takes *years* to fix a host
> behavior problem, and we need to engineer and deploy a fix much sooner
> then that (hopefully about
On Mar 30, 2010, at 9:15 AM, Andrew Sullivan wrote:
> I am not among those who think that the number of clients involved
> with this is "insignificant". I know that something people sometimes
> hear, but the abolute number of people involved does make this a real
> problem. I just don't think th
On Mar 30, 2010, at 8:56 AM, Mohacsi Janos wrote:
> Dear All,
>
> Sorry for crossposting.
>
>
> This proposal is the opposite with the principle how the DNS is developed a
> while ago. The DNS is a highly distributed, hierarchical, autonomous,
> reliable database with very useful extensions.
On Mar 20, 2010, at 1:50 AM, George Barwood wrote:
>> Enshrining "tho shalt never fragment" into the Internet Architecture is
>> dangerous, and will cause far MORE problems. Having something which
>> >regularly exercises fragmentation as critical to the infrastructure and we
>> wouldn't have th
On Mar 19, 2010, at 12:01 PM, George Barwood wrote:
>
> Anyway, do we yet agree that 1450 is the best default for max-udp-size, and
> that higher values are dangerous?\
No: I agree it is the proper default for the TLD authorities and roots, but
for everything else, the higher value should be
On Mar 19, 2010, at 9:41 AM, Ted Lemon wrote:
> On Mar 19, 2010, at 12:20 PM, Nicholas Weaver wrote:
>> HAHAHA. Not bloodly likely IMO: a lot of the "open resolvers" are broken
>> end-user NATS and similar. Those will only be updated sometime around when
>> hel
On Mar 19, 2010, at 9:10 AM, George Barwood wrote:
>
>>> It cuts the response from 4K to 1.5K, and I think fragmentation that
>>> contributes
>>> to these attacks being damaging.
>
>> All I need to do is find a set of open resolvers which don't have such
>> limits to do juuust fine.
>
> Ev
On Mar 19, 2010, at 8:32 AM, George Barwood wrote:
>
>>> There are advantages besides messages being lost.
>>> It also prevents spoofing of fragments, and limits amplification attacks.
>
>> It doesn't limit amplification attacks by much if at all
>
> It cuts the response from 4K to 1.5K, and I
On Mar 19, 2010, at 6:09 AM, George Barwood wrote:
>
> - Original Message -
> From: "Nicholas Weaver"
> To: "George Barwood"
> Cc: "Nicholas Weaver" ; "Matt Larson"
> ;
> Sent: Friday, March 19, 2010 12:33 PM
> Subjec
On Mar 19, 2010, at 12:21 AM, George Barwood wrote:
> I suggest the default value in BIND for max-udp-size should be 1450.
> This appears to be best practice.
> Since few zones are currently signed, it's not too late to make this change.
> Later on it may be more difficult.
Actually, I'd say thi
On Mar 17, 2010, at 5:23 AM, Jim Reid wrote:
> On 17 Mar 2010, at 11:28, George Barwood wrote:
>
>> It seems that m.root-servers.net is now serving DNSSEC, but does not have
>> TCP, so the following queries all fail
>
> Well these queries work just fine for me. Perhaps your problems are cause
A little more, from Comcast SF bay area:
Its responding to large EDNS MTUs just fine for me:
dig +dnssec any . @m.root-servers.net
works (4096B MTU)
but with a 512B MTU (no EDNS) it doesn't because there is no working TCP:
dig any . @m.root-servers.net
;; Truncated, retrying in TCP mode.
;; Co
On Mar 9, 2010, at 7:17 AM, Matt Larson wrote:
> On Mon, 08 Mar 2010, George Barwood wrote:
>> It's interesting to note that currently
>>
>> dig any . @a.root-servers.net +dnssec
>>
>> truncates, leading to TCP fallback
>>
>> but
>>
>> dig any . @l.root-servers.net +dnssec
>>
>> does not tru
On Mar 8, 2010, at 9:31 AM, Thierry Moreau wrote:
> Joe Abley wrote:
>> On 2010-03-08, at 10:27, Paul Wouters wrote:
>>> On Mon, 8 Mar 2010, Joe Abley wrote:
>>>
Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I
think be paraphrased as follows:
- howeve
1 - 100 of 112 matches
Mail list logo
