-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OK, that's useful, but not good. The last thing DNSSEC/IPv6 needs is
yet another reason why network access which used to work now doesn't.
edns-packet-max=1280 seems to be working fine here. Please let me know
if you find anything more.
Cheers,
Si
I strongly suspect an ipv6 fragmentation handling bug in the kernel
version cerowrt uses. Have tons of evidence pointing to that now,
starting with some tests run last year from iwl and also the tests
that netalyzer was doing. And: I just locked up the box completely
while doing some dnssec stuff.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
An interesting observation: my IPv6 connectivity is via a sixXS tunnel.
Resolving isc.org through dnsmasq w/DNSSEC to google's IPv6 DNS
servers times out, because dnsmasq was never getting a reply to a
query for the DNSKEY RRset for org. This reply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A backtrace is the most important starting point. A query log _if_
it's query dependent, but that seems unlikely since it doesn't break
when forwarding to IPv4. An easy way to reproduce would be great :-)
I can do the same tests here, but it's a bit
I was able to lock up this version of dnsmasq twice: 100% cpu usage.
No syscalls were visible from strace during the lockup. Lockups
occurred once on nearly at boot, and the second time, after a few
hours of casual usage, with only ipv6 upstreams, on cero-3.10.50-1.
furthermore, the only thing tha
OK, I built this latest dnsmasq as a test for cerowrt-3.10-50 users:
login to the router
cd /tmp
wget
http://snapon.lab.bufferbloat.net/~cero2/dnsmasq/dnsmasq-full_2.73-3_ar71xx.ipk
opkg install ./dnsmasq-full_2.73-3_ar71xx.ipk
(ignore the warnings about not overwriting several files)
I did a fe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/15 17:44, Dave Taht wrote:
> Wow, this thread goes back a ways. Is ds.test-ipv6.com still
> configured wrong, and does it pass now? It passes for me (but I am
> behind a more modern openwrt box right now)
ds.test-ipv6.com is still showi
Wow, this thread goes back a ways. Is ds.test-ipv6.com still
configured wrong, and does it pass now? It passes for me (but I am
behind a more modern openwrt box right now)
Is there another site that demonstrates this problem?
BTW: For a while there (on comcast), in production, I ran with pure
ipv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OK, it's taken some time, but with this insight, I've recoded the
relevant stuff to look for the limits of the signed DNS tree from the
DNS root down. That's clearly the correct way to do it, and should
avoid the original problem here, caused by send
On Fri, 3 Oct 2014, Anders Kaseorg wrote:
> > secure no DS means that the original unsigned answer should be
> > accepted, except that it shouldn't. There's no way to distinguish
> > between secure lack of DS because we've reached an unsigned branch of
> > the tree, and secure lack of DS because
On Fri, 3 Oct 2014, valdis.kletni...@vt.edu wrote:
> On Fri, 03 Oct 2014 05:28:35 -0400, Anders Kaseorg said:
> > This bottom-up algorithm also seems to have a security problem that’s
> > just as bad as one with the top-down algorithm that you rejected
> > below. Consider the same department.cam
I just ran into this timeout behavior myself while testing the new
DNSSEC support in OpenWrt 14.07 (dnsmasq 2.71-4). After staring at the
problem for a few hours, I think there’s something wrong with your
justification.
On 04/29/2014 09:22 AM, Simon Kelley wrote:
To do that, we need to find
> "SK" == Simon Kelley writes:
SK> A valid point, but "every leaf system has to be a recursor" is not a
SK> pleasant outcome of widely implementing DNSSEC.
>From a security POV, every system needs its own local verifier, and every
administrative domain needs its own recursor. Optimally ever
On Thu, May 1, 2014 at 1:26 PM, Rich Brown wrote:
>
> On May 1, 2014, at 2:37 PM, Simon Kelley wrote:
>
>> On 30/04/14 18:26, Dave Taht wrote:
>>> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
>>> wrote:
>
> snip, snip snip...
>
>>> Is the consensus to not run with negative proofs on at this jun
On 30/04/14 18:26, Dave Taht wrote:
> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
> wrote:
>> On 2014-04-29 at 14:22 +0100, Simon Kelley wrote:
>>> secure no DS means that the original unsigned answer should be accepted,
>>> except that it shouldn't. There's no way to distinguish between secure
On 29/04/14 21:57, Phil Pennock wrote:
> On 2014-04-29 at 14:22 +0100, Simon Kelley wrote:
>> secure no DS means that the original unsigned answer should be accepted,
>> except that it shouldn't. There's no way to distinguish between secure
>> lack of DS because we've reached an unsigned branch of
On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
wrote:
> On 2014-04-29 at 14:22 +0100, Simon Kelley wrote:
>> secure no DS means that the original unsigned answer should be accepted,
>> except that it shouldn't. There's no way to distinguish between secure
>> lack of DS because we've reached an unsi
On 29/04/14 00:24, Phil Pennock wrote:
> On 2014-04-28 at 20:32 +0100, Simon Kelley wrote:
>> On 28/04/14 19:56, Dave Taht wrote:
>>> I see A and requests for for "ds.test-ipv6.com" that fail.
>>
>> The root of this failure is that DS ds.test-ipv6.com is broken.
>>
>> <<>> DiG 9.8.1-P1 <<>> @
This timeout, I'm guessing this is older/naive setups that aren't expecting
to support DNSSEC, and thought "over-securing" their setup, have managed to
break the non-existence-proof process?
-Aaron
On Mon, Apr 28, 2014 at 9:32 PM, Simon Kelley wrote:
...
> Neither of authoritative nameservers f
On 28/04/14 19:56, Dave Taht wrote:
> I see A and requests for for "ds.test-ipv6.com" that fail.
>
The root of this failure is that DS ds.test-ipv6.com is broken.
<<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ds ds.test-ipv6.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- o
I see A and requests for for "ds.test-ipv6.com" that fail.
On Mon, Apr 28, 2014 at 11:37 AM, Dave Taht wrote:
> I have put a link up to two of jim's captures going to test-ipv6 via cero,
> one with dnssec enabled, captured at the local laptop
>
> http://snapon.lab.bufferbloat.net/~cero2/ba
I have put a link up to two of jim's captures going to test-ipv6 via cero,
one with dnssec enabled, captured at the local laptop
http://snapon.lab.bufferbloat.net/~cero2/baddns/
definately a lot of missing responses when captured at this end. the local
laptop is using a local dnsmasq forwarder.
On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys wrote:
> Comcast recently lit up IPv6 native dual stack in the Boston area.
>
> The http://test-ipv6.com/ web site complains about DNS problems unless
> dnssec is disabled; if it is, I get various timeouts.
>
>
>
Test with IPv4 DNS record
> ok (4.196
23 matches
Mail list logo
