[Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

​​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.196s)
Test with IPv6 DNS record
ok (0.115s) using ipv6
Test with Dual Stack DNS record
timeout (11.882s)
Test for Dual Stack DNS and large packet
timeout (11.817s)
Test IPv4 without DNS
ok (0.214s) using ipv4
Test IPv6 without DNS
ok (0.204s) using ipv6
Test IPv6 large packet
ok (0.120s) using ipv6
Test if your ISP's DNS server uses IPv6
slow (8.752s)
Find IPv4 Service Provider
timeout (11.968s)
Find IPv6 Service Provider
ok (0.126s) using ipv6 ASN 7922
Test for buggy DNS
undefined (5.003s)

DNS server addresses look reasonable for Comcast.
DNS 1: 75.75.75.75
DNS 2: 75.75.76.76
DNS 1: 2001:558:feed::1
DNS 2: 2001:558:feed::2

Today, the problem seems consistent with turning dnssec on and off on the
router.  If enabled, I have problems; if disabled, I get a clean bill of
health out of test-ipv6.com.
                                             - Jim

[-- Attachment #2: Type: text/html, Size: 5604 bytes --]

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys <jg@freedesktop.org> 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.196s)
> Test with IPv6 DNS record
> ok (0.115s) using ipv6
> Test with Dual Stack DNS record
> timeout (11.882s)
>

I  don't  know what this test does. try a local query over ipv6?

Test for Dual Stack DNS and large packet
> timeout (11.817s)
> Test IPv4 without DNS
> ok (0.214s) using ipv4
> Test IPv6 without DNS
> ok (0.204s) using ipv6
> Test IPv6 large packet
> ok (0.120s) using ipv6
> Test if your ISP's DNS server uses IPv6
> slow (8.752s)
> Find IPv4 Service Provider
> timeout (11.968s)
> Find IPv6 Service Provider
> ok (0.126s) using ipv6 ASN 7922
> Test for buggy DNS
> undefined (5.003s)
>
> DNS server addresses look reasonable for Comcast.
> DNS 1: 75.75.75.75
> DNS 2: 75.75.76.76
>

To try to isolate  things a little  bit, you can turn off fetching ipv4 dns
servers
with

option peerdns  '0'

in the wan (ge00) stanza  of /etc/config/network

and let the wan6 stanza fetch them.

A packet capture of it working vs not working would be good.

tcpdump  -i ge00 -w cap1.cap port 53

Also  capture on the local interface.

DNS 1: 2001:558:feed::1
> DNS 2: 2001:558:feed::2
>
> Today, the problem seems consistent with turning dnssec on and off on the
> router.  If enabled, I have problems; if disabled, I get a clean bill of
> health out of test-ipv6.com.
>                                              - Jim
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 
Dave Täht

NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

[-- Attachment #2: Type: text/html, Size: 7205 bytes --]

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

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.

It is falling back to trying a recursive lookup on the default domain (
ipv6.test-ipv6.com.home.lan ) - which it does do a nxdomain for
immediately...



On Mon, Apr 28, 2014 at 10:03 AM, Dave Taht <dave.taht@gmail.com> wrote:

>
>
>
> On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys <jg@freedesktop.org> 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.196s)
>> Test with IPv6 DNS record
>> ok (0.115s) using ipv6
>> Test with Dual Stack DNS record
>> timeout (11.882s)
>>
>
> I  don't  know what this test does. try a local query over ipv6?
>
>  Test for Dual Stack DNS and large packet
>> timeout (11.817s)
>> Test IPv4 without DNS
>> ok (0.214s) using ipv4
>> Test IPv6 without DNS
>> ok (0.204s) using ipv6
>> Test IPv6 large packet
>> ok (0.120s) using ipv6
>> Test if your ISP's DNS server uses IPv6
>> slow (8.752s)
>> Find IPv4 Service Provider
>> timeout (11.968s)
>> Find IPv6 Service Provider
>> ok (0.126s) using ipv6 ASN 7922
>> Test for buggy DNS
>> undefined (5.003s)
>>
>> DNS server addresses look reasonable for Comcast.
>> DNS 1: 75.75.75.75
>> DNS 2: 75.75.76.76
>>
>
> To try to isolate  things a little  bit, you can turn off fetching ipv4
> dns servers
> with
>
> option peerdns  '0'
>
> in the wan (ge00) stanza  of /etc/config/network
>
> and let the wan6 stanza fetch them.
>
> A packet capture of it working vs not working would be good.
>
> tcpdump  -i ge00 -w cap1.cap port 53
>
> Also  capture on the local interface.
>
> DNS 1: 2001:558:feed::1
>> DNS 2: 2001:558:feed::2
>>
>> Today, the problem seems consistent with turning dnssec on and off on the
>> router.  If enabled, I have problems; if disabled, I get a clean bill of
>> health out of test-ipv6.com.
>>                                               - Jim
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>



-- 
Dave Täht

NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

[-- Attachment #2: Type: text/html, Size: 8574 bytes --]

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

I see A and AAAA requests for for "ds.test-ipv6.com" that fail.


On Mon, Apr 28, 2014 at 11:37 AM, Dave Taht <dave.taht@gmail.com> 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/baddns/
>
> definately a lot of missing responses when captured at this end. the local
> laptop is using a local dnsmasq forwarder.
>
> It is falling back to trying a recursive lookup on the default domain (
> ipv6.test-ipv6.com.home.lan ) - which it does do a nxdomain for
> immediately...
>
>
>
> On Mon, Apr 28, 2014 at 10:03 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys <jg@freedesktop.org> 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.196s)
>>> Test with IPv6 DNS record
>>> ok (0.115s) using ipv6
>>> Test with Dual Stack DNS record
>>> timeout (11.882s)
>>>
>>
>> I  don't  know what this test does. try a local query over ipv6?
>>
>>  Test for Dual Stack DNS and large packet
>>> timeout (11.817s)
>>> Test IPv4 without DNS
>>> ok (0.214s) using ipv4
>>> Test IPv6 without DNS
>>> ok (0.204s) using ipv6
>>> Test IPv6 large packet
>>> ok (0.120s) using ipv6
>>> Test if your ISP's DNS server uses IPv6
>>> slow (8.752s)
>>> Find IPv4 Service Provider
>>> timeout (11.968s)
>>> Find IPv6 Service Provider
>>> ok (0.126s) using ipv6 ASN 7922
>>> Test for buggy DNS
>>> undefined (5.003s)
>>>
>>> DNS server addresses look reasonable for Comcast.
>>> DNS 1: 75.75.75.75
>>> DNS 2: 75.75.76.76
>>>
>>
>> To try to isolate  things a little  bit, you can turn off fetching ipv4
>> dns servers
>> with
>>
>> option peerdns  '0'
>>
>> in the wan (ge00) stanza  of /etc/config/network
>>
>> and let the wan6 stanza fetch them.
>>
>> A packet capture of it working vs not working would be good.
>>
>> tcpdump  -i ge00 -w cap1.cap port 53
>>
>> Also  capture on the local interface.
>>
>>  DNS 1: 2001:558:feed::1
>>> DNS 2: 2001:558:feed::2
>>>
>>> Today, the problem seems consistent with turning dnssec on and off on
>>> the router.  If enabled, I have problems; if disabled, I get a clean bill
>>> of health out of test-ipv6.com.
>>>                                               - Jim
>>>
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>
>>
>> --
>> Dave Täht
>>
>> NSFW:
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>>
>
>
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>



-- 
Dave Täht

NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

[-- Attachment #2: Type: text/html, Size: 9363 bytes --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

On 28/04/14 19:56, Dave Taht wrote:
> I see A and AAAA 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<<- opcode: QUERY, status: SERVFAIL, id: 63751
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ds.test-ipv6.com.		IN	DS

;; Query time: 1186 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 28 20:19:34 2014
;; MSG SIZE  rcvd: 34

The latest fix I made (when the SERVFAIL reply comes, try the next
possible secure-nonexistent DS record at test-ipv6.com) works sometimes,
but the query above is taking long enough to fail that sometimes the
original requestor has timed out before it gets the answer and tries again.

Neither of authoritative nameservers for test-ipv6.com return answers to
the DS query, they just time out. They do return answers for A and AAAA
queries. That looks broken to me.

Problems like this have been at the root of most (but not all) of the
DNSSEC failures that have been reported.

Cheers,

Simon.

> 
> On Mon, Apr 28, 2014 at 11:37 AM, Dave Taht <dave.taht@gmail.com>
> 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/baddns/
>> 
>> definately a lot of missing responses when captured at this end.
>> the local laptop is using a local dnsmasq forwarder.
>> 
>> It is falling back to trying a recursive lookup on the default
>> domain ( ipv6.test-ipv6.com.home.lan ) - which it does do a
>> nxdomain for immediately...
>> 
>> 
>> 
>> On Mon, Apr 28, 2014 at 10:03 AM, Dave Taht <dave.taht@gmail.com>
>> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys <jg@freedesktop.org>
>>> 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.196s) Test with IPv6 DNS record ok (0.115s) using ipv6 
>>>> Test with Dual Stack DNS record timeout (11.882s)
>>>> 
>>> 
>>> I  don't  know what this test does. try a local query over ipv6?
>>> 
>>> Test for Dual Stack DNS and large packet
>>>> timeout (11.817s) Test IPv4 without DNS ok (0.214s) using ipv4 
>>>> Test IPv6 without DNS ok (0.204s) using ipv6 Test IPv6 large
>>>> packet ok (0.120s) using ipv6 Test if your ISP's DNS server
>>>> uses IPv6 slow (8.752s) Find IPv4 Service Provider timeout
>>>> (11.968s) Find IPv6 Service Provider ok (0.126s) using ipv6 ASN
>>>> 7922 Test for buggy DNS undefined (5.003s)
>>>> 
>>>> DNS server addresses look reasonable for Comcast. DNS 1:
>>>> 75.75.75.75 DNS 2: 75.75.76.76
>>>> 
>>> 
>>> To try to isolate  things a little  bit, you can turn off
>>> fetching ipv4 dns servers with
>>> 
>>> option peerdns  '0'
>>> 
>>> in the wan (ge00) stanza  of /etc/config/network
>>> 
>>> and let the wan6 stanza fetch them.
>>> 
>>> A packet capture of it working vs not working would be good.
>>> 
>>> tcpdump  -i ge00 -w cap1.cap port 53
>>> 
>>> Also  capture on the local interface.
>>> 
>>> DNS 1: 2001:558:feed::1
>>>> DNS 2: 2001:558:feed::2
>>>> 
>>>> Today, the problem seems consistent with turning dnssec on and
>>>> off on the router.  If enabled, I have problems; if disabled, I
>>>> get a clean bill of health out of test-ipv6.com. - Jim
>>>> 
>>>> 
>>>> _______________________________________________ Cerowrt-devel
>>>> mailing list Cerowrt-devel@lists.bufferbloat.net 
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>> 
>>>> 
>>> 
>>> 
>>> -- Dave Täht
>>> 
>>> NSFW: 
>>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>>>
>>
>>
>>
>>
>>> 
--
>> Dave Täht
>> 
>> NSFW: 
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>>
>
>> 
> 
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

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 <simon@thekelleys.org.uk>wrote:

...

> Neither of authoritative nameservers for test-ipv6.com return answers to
> the DS query, they just time out. They do return answers for A and AAAA
> queries. That looks broken to me.
>
> Problems like this have been at the root of most (but not all) of the
> DNSSEC failures that have been reported.
>

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Phil Pennock]

On 2014-04-28 at 20:32 +0100, Simon Kelley wrote:
> On 28/04/14 19:56, Dave Taht wrote:
> > I see A and AAAA 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

> The latest fix I made (when the SERVFAIL reply comes, try the next
> possible secure-nonexistent DS record at test-ipv6.com) works sometimes,
> but the query above is taking long enough to fail that sometimes the
> original requestor has timed out before it gets the answer and tries again.

Er, DS records are authoritative in the parent domain and are equivalent
to glue; they are not expected to exist below the zone cut.

This is why you'll get results from:

    $ dig -t ds spodhuis.org @a2.org.afilias-nst.info

but a NOERROR from:

    $ dig -t ds spodhuis.org @nsauth.spodhuis.org

An NS query for "ds.test-ipv6.com" gives "test-ipv6.com", so that is the
zone cut, so it's in the COM. zone that you should expect to find any DS
records for "test-ipv6.com" and there's no need for a DS for anything
below that unless there's also a zone cut, in which case there's a DS at
the delegation point.

RFC 4033:
----------------------------8< cut here >8------------------------------
3.1.  Data Origin Authentication and Data Integrity
[...]
   The Delegation Signer (DS) RR type simplifies some of the
   administrative tasks involved in signing delegations across
   organizational boundaries.  The DS RRset resides at a delegation
   point in a parent zone and indicates the public key(s) corresponding
   to the private key(s) used to self-sign the DNSKEY RRset at the
   delegated child zone's apex.  The administrator of the child zone, in
   turn, uses the private key(s) corresponding to one or more of the
   public keys in this DNSKEY RRset to sign the child zone's data.  The
   typical authentication chain is therefore
   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
   RRs within a zone.
----------------------------8< cut here >8------------------------------

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

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 AAAA 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
> 
>> The latest fix I made (when the SERVFAIL reply comes, try the next
>> possible secure-nonexistent DS record at test-ipv6.com) works sometimes,
>> but the query above is taking long enough to fail that sometimes the
>> original requestor has timed out before it gets the answer and tries again.
> 
> Er, DS records are authoritative in the parent domain and are equivalent
> to glue; they are not expected to exist below the zone cut.
> 
> This is why you'll get results from:
> 
>     $ dig -t ds spodhuis.org @a2.org.afilias-nst.info
> 
> but a NOERROR from:
> 
>     $ dig -t ds spodhuis.org @nsauth.spodhuis.org

A NOERROR answer from the authoritative server for test-ipv6.com would
be fine. What actually happens is no answer at all and a timeout (or a
closed TCP connection if TCP is used.)


It's maybe worth expanding on what we're trying to do here. The original
query is "A ds.test-ipv6.com". The answer to that comes back fine, but
there are no RRSIGs proving that that answer is good. Now we have to
distinguish between no signatures because the domain isn't signed, and
no signatures because the answer has come from the Bad Guys.

To do that, we need to find proof (NSEC or NSEC3 records) that a DS
doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in
mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it
doesn't know where the zone cuts are.

The current strategy it to start at ds.test-ipv6.com and do DS queries.
There are three possible results.

unsigned NOERROR -> chop one label off the RHS and repeat
DS record        -> definite Bad Guy activity, return BOGUS
signed no DS record -> we expect unsigned original answer, return
INSECURE result.ds.test-ipv6.com


The other alternative approach is to start from the root and add labels,
but that has a problem.

Consider

department.campus.university.edu

where there are zone cuts between university and edu and between
department and campus.

All the zones are signed, so if we look up something under .department,
we expect a signature, if we don't get it, we check

DS .edu gives an answer
DS university.edu gives secure NODATA

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 we're not at a zone cut, except if we know
where the zone cuts are, and we don't.


That's why dnsmasq works up from the bottom. The first secure no-DS
answer we find marks the boundary between signed and unsigned tree.

Dnsmasq is acting as a validating stub resolver here. That's a supported
role for DNSSEC, so this must be possible. If it's not then we have a
standards problem.


> 
> An NS query for "ds.test-ipv6.com" gives "test-ipv6.com", so that is the
> zone cut, so it's in the COM. zone that you should expect to find any DS
> records for "test-ipv6.com" and there's no need for a DS for anything
> below that unless there's also a zone cut, in which case there's a DS at
> the delegation point.
ds.test-ipv6.com
Doing NS queries to find zone cuts is a possible solution, but I know of
ISP nameservers that elide the Authority section for "performance".


Simon.

> 
> RFC 4033:
> ----------------------------8< cut here >8------------------------------
> 3.1.  Data Origin Authentication and Data Integrity
> [...]
>    The Delegation Signer (DS) RR type simplifies some of the
>    administrative tasks involved in signing delegations across
>    organizational boundaries.  The DS RRset resides at a delegation
>    point in a parent zone and indicates the public key(s) corresponding
>    to the private key(s) used to self-sign the DNSKEY RRset at the
>    delegated child zone's apex.  The administrator of the child zone, in
>    turn, uses the private key(s) corresponding to one or more of the
>    public keys in this DNSKEY RRset to sign the child zone's data.  The
>    typical authentication chain is therefore
>    DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
>    DS->DNSKEY subchains.  DNSSEC permits more complex authentication
>    chains, such as additional layers of DNSKEY RRs signing other DNSKEY
>    RRs within a zone.
> ----------------------------8< cut here >8------------------------------
> 

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Phil Pennock]

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 the tree, and
> secure lack of DS because we're not at a zone cut, except if we know
> where the zone cuts are, and we don't.

Fair point.

> That's why dnsmasq works up from the bottom. The first secure no-DS
> answer we find marks the boundary between signed and unsigned tree.
> 
> Dnsmasq is acting as a validating stub resolver here. That's a supported
> role for DNSSEC, so this must be possible. If it's not then we have a
> standards problem.

You have a standards vs reality problem: lots of loadbalancer appliances
suck at DNS and are only just now managing to return errors, instead of
dropping the query (hanging), when queried for AAAA records instead of A
records.

( This has led to no end of pain in the IPv6 world; Happy Eyeballs,
  expectations around improved _client_ behaviour, handle other parts of
  the puzzle and tends to require the concurrency that a client also
  needs to handle DNS problems, but it's still distinct. )

You're not going to get such loadbalancers responding sanely to a DS
query any time soon, and with the other DNS client software all being
recursors which work fine because they know where zone cuts are, you're
going to be fighting a long hard battle with vendors and sites to get
them to fix their brokenness when "it works for everyone else".

So the standards 100% support what you're doing, but they don't match
common stupidity in deployed (high end, expensive) equipment.

To support DNSSEC in the real world without changing from being a
forwarder, you're going to need new insight.  My only thoughts are
around whether or not this might provide impetus for TKEY-based TSIG for
forwarders to establish trust links to recursors elsewhere, in which
case once you have a TSIG key (whether TKEY-derived or OOB manual) then
you might delegate trust to the remote recursor.

Sorry to be the bearer of bad news,
-Phil

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
<cerowrt-devel+phil@spodhuis.org> 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 the tree, and
>> secure lack of DS because we're not at a zone cut, except if we know
>> where the zone cuts are, and we don't.
>
> Fair point.
>
>> That's why dnsmasq works up from the bottom. The first secure no-DS
>> answer we find marks the boundary between signed and unsigned tree.
>>
>> Dnsmasq is acting as a validating stub resolver here. That's a supported
>> role for DNSSEC, so this must be possible. If it's not then we have a
>> standards problem.
>
> You have a standards vs reality problem: lots of loadbalancer appliances
> suck at DNS and are only just now managing to return errors, instead of
> dropping the query (hanging), when queried for AAAA records instead of A
> records.
>
> ( This has led to no end of pain in the IPv6 world; Happy Eyeballs,
>   expectations around improved _client_ behaviour, handle other parts of
>   the puzzle and tends to require the concurrency that a client also
>   needs to handle DNS problems, but it's still distinct. )
>
> You're not going to get such loadbalancers responding sanely to a DS
> query any time soon, and with the other DNS client software all being
> recursors which work fine because they know where zone cuts are, you're
> going to be fighting a long hard battle with vendors and sites to get
> them to fix their brokenness when "it works for everyone else".
>
> So the standards 100% support what you're doing, but they don't match
> common stupidity in deployed (high end, expensive) equipment.

The only idea I have is to adopt some sort of whitelisting technology,
and simultaneously nag the folk with busted implementations.

>
> To support DNSSEC in the real world without changing from being a
> forwarder, you're going to need new insight.  My only thoughts are
> around whether or not this might provide impetus for TKEY-based TSIG for
> forwarders to establish trust links to recursors elsewhere, in which
> case once you have a TSIG key (whether TKEY-derived or OOB manual) then
> you might delegate trust to the remote recursor.

I see there have been a few commits to dnsmasq that address some stuff.

>
> Sorry to be the bearer of bad news,

I'm delighted to have got this far.

Is the consensus to not run with negative proofs on at this juncture?

> -Phil



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

On 30/04/14 18:26, Dave Taht wrote:
> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
> <cerowrt-devel+phil@spodhuis.org> 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 the tree, and
>>> secure lack of DS because we're not at a zone cut, except if we know
>>> where the zone cuts are, and we don't.
>>
>> Fair point.
>>
>>> That's why dnsmasq works up from the bottom. The first secure no-DS
>>> answer we find marks the boundary between signed and unsigned tree.
>>>
>>> Dnsmasq is acting as a validating stub resolver here. That's a supported
>>> role for DNSSEC, so this must be possible. If it's not then we have a
>>> standards problem.
>>
>> You have a standards vs reality problem: lots of loadbalancer appliances
>> suck at DNS and are only just now managing to return errors, instead of
>> dropping the query (hanging), when queried for AAAA records instead of A
>> records.
>>
>> ( This has led to no end of pain in the IPv6 world; Happy Eyeballs,
>>   expectations around improved _client_ behaviour, handle other parts of
>>   the puzzle and tends to require the concurrency that a client also
>>   needs to handle DNS problems, but it's still distinct. )
>>
>> You're not going to get such loadbalancers responding sanely to a DS
>> query any time soon, and with the other DNS client software all being
>> recursors which work fine because they know where zone cuts are, you're
>> going to be fighting a long hard battle with vendors and sites to get
>> them to fix their brokenness when "it works for everyone else".
>>
>> So the standards 100% support what you're doing, but they don't match
>> common stupidity in deployed (high end, expensive) equipment.
> 
> The only idea I have is to adopt some sort of whitelisting technology,
> and simultaneously nag the folk with busted implementations.
> 
>>
>> To support DNSSEC in the real world without changing from being a
>> forwarder, you're going to need new insight.  My only thoughts are
>> around whether or not this might provide impetus for TKEY-based TSIG for
>> forwarders to establish trust links to recursors elsewhere, in which
>> case once you have a TSIG key (whether TKEY-derived or OOB manual) then
>> you might delegate trust to the remote recursor.
> 
> I see there have been a few commits to dnsmasq that address some stuff.
> 
>>
>> Sorry to be the bearer of bad news,
> 
> I'm delighted to have got this far.
> 
> Is the consensus to not run with negative proofs on at this juncture?

If you want stuff to just work, turn off negative proofs, if you want to
push the envelope, leave them on and complain to domain-admins.

I had some feeling that something like this might be a problem, hence
the discrete controls.


Cheers,

Simon

> 
>> -Phil
> 
> 
> 

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Rich Brown]

On May 1, 2014, at 2:37 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:

> On 30/04/14 18:26, Dave Taht wrote:
>> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
>> <cerowrt-devel+phil@spodhuis.org> wrote:

snip, snip snip...

>> Is the consensus to not run with negative proofs on at this juncture?
> 
> If you want stuff to just work, turn off negative proofs, if you want to
> push the envelope, leave them on and complain to domain-admins.
> 
> I had some feeling that something like this might be a problem, hence
> the discrete controls.

I apologize that I haven't been following this closely, but so I'm going to ask a TL;DR question.

Which places in the OpenWrt/CeroWrt GUI (or the config files) do I use to wiggle these levers?

Thanks!

Rich

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

On Thu, May 1, 2014 at 1:26 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>
> On May 1, 2014, at 2:37 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:
>
>> On 30/04/14 18:26, Dave Taht wrote:
>>> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
>>> <cerowrt-devel+phil@spodhuis.org> wrote:
>
> snip, snip snip...
>
>>> Is the consensus to not run with negative proofs on at this juncture?
>>
>> If you want stuff to just work, turn off negative proofs, if you want to
>> push the envelope, leave them on and complain to domain-admins.
>>
>> I had some feeling that something like this might be a problem, hence
>> the discrete controls.
>
> I apologize that I haven't been following this closely, but so I'm going to ask a TL;DR question.
>
> Which places in the OpenWrt/CeroWrt GUI (or the config files) do I use to wiggle these levers?

There is no gui support as yet. enablement is via /etc/dnsmasq.conf

I disabled (commented out) the negative proof checks in the 3.10.38-2 release.

> Thanks!
>
> Rich



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Sebastian Moeller]

Hi List, hi Dave,

On May 2, 2014, at 00:27 , Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, May 1, 2014 at 1:26 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>> 
>> On May 1, 2014, at 2:37 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:
>> 
>>> On 30/04/14 18:26, Dave Taht wrote:
>>>> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock
>>>> <cerowrt-devel+phil@spodhuis.org> wrote:
>> 
>> snip, snip snip...
>> 
>>>> Is the consensus to not run with negative proofs on at this juncture?
>>> 
>>> If you want stuff to just work, turn off negative proofs, if you want to
>>> push the envelope, leave them on and complain to domain-admins.
>>> 
>>> I had some feeling that something like this might be a problem, hence
>>> the discrete controls.
>> 
>> I apologize that I haven't been following this closely, but so I'm going to ask a TL;DR question.
>> 
>> Which places in the OpenWrt/CeroWrt GUI (or the config files) do I use to wiggle these levers?
> 
> There is no gui support as yet. enablement is via /etc/dnsmasq.conf
> 
> I disabled (commented out) the negative proof checks in the 3.10.38-2 release.

	So, I installed this just now and to my amazement it directly picked up my ISP's dns servers immediately, unlike with the last two? releases I did not have to resort to google's dns servers. So this looks like the deutsche telekom setup is not ready for full dnssec (at least not when trying to use the dns server on the primary dt router...). 

Best Regards
	Sebastian

> 
>> Thanks!
>> 
>> Rich
> 
> 
> 
> -- 
> Dave Täht
> 
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

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 the tree, and
>> secure lack of DS because we're not at a zone cut, except if we know
>> where the zone cuts are, and we don't.
> 
> Fair point.
> 
>> That's why dnsmasq works up from the bottom. The first secure no-DS
>> answer we find marks the boundary between signed and unsigned tree.
>>
>> Dnsmasq is acting as a validating stub resolver here. That's a supported
>> role for DNSSEC, so this must be possible. If it's not then we have a
>> standards problem.
> 
> You have a standards vs reality problem: lots of loadbalancer appliances
> suck at DNS and are only just now managing to return errors, instead of
> dropping the query (hanging), when queried for AAAA records instead of A
> records.
> 
> ( This has led to no end of pain in the IPv6 world; Happy Eyeballs,
>   expectations around improved _client_ behaviour, handle other parts of
>   the puzzle and tends to require the concurrency that a client also
>   needs to handle DNS problems, but it's still distinct. )
> 
> You're not going to get such loadbalancers responding sanely to a DS
> query any time soon, and with the other DNS client software all being
> recursors which work fine because they know where zone cuts are, you're
> going to be fighting a long hard battle with vendors and sites to get
> them to fix their brokenness when "it works for everyone else".

A valid point, but "every leaf system has to be a recursor" is not a
pleasant outcome of widely implementing DNSSEC. I wonder, do the
browser-based validators suffer from this, or are they recursors under
the hood? This is a judgement for integrators, not for me, but if
there's anything widely deployed enough to act as a lever to get this
fixed, it's dnsmasq.

> 
> So the standards 100% support what you're doing, but they don't match
> common stupidity in deployed (high end, expensive) equipment.
> 
> To support DNSSEC in the real world without changing from being a
> forwarder, you're going to need new insight.  My only thoughts are
> around whether or not this might provide impetus for TKEY-based TSIG for
> forwarders to establish trust links to recursors elsewhere, in which
> case once you have a TSIG key (whether TKEY-derived or OOB manual) then
> you might delegate trust to the remote recursor.

That's nice, but it needs recursors to play ball too, so it's even
further into the indefinite future than what we have now.
> 
> Sorry to be the bearer of bad news,

Better to know.


Cheers,

Simon.

> -Phil
> 

Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[James Cloos]

>>>>> "SK" == Simon Kelley <simon@thekelleys.org.uk> 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 every system will
have its own validating recursor.

SK> I wonder, do the browser-based validators suffer from this, or are
SK> they recursors under the hood?

They are full validating recursors.  Often using libunbound to do the
heavy lifting.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Anders Kaseorg]

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 proof (NSEC or NSEC3 records) that a DS
> doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in
> mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it
> doesn't know where the zone cuts are.
>
> The current strategy it to start at ds.test-ipv6.com and do DS queries.
> There are three possible results.
>
> unsigned NOERROR -> chop one label off the RHS and repeat
> DS record        -> definite Bad Guy activity, return BOGUS
> signed no DS record -> we expect unsigned original answer, return
> INSECURE result.ds.test-ipv6.com

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.campus.university.edu example, where 
campus and edu are signed zones, and university is not a zone.

• An attacker forges an evil response for A department, and forges an 
unsigned NODATA for DS department.
• dnsmasq chops off one label, and the attacker forges an unsigned 
NODATA for DS campus.
• dnsmasq chops off another label, and gets the legitimately signed 
NODATA for DS university.
• dnsmasq incorrectly concludes that everything inside university is 
expected to be unsigned, and returns the INSECURE evil response.

So if nothing else, the top-down algorithm seems less impractical and 
equally insecure.  And maybe we can fix it; see below.

> The other alternative approach is to start from the root and add labels,
> but that has a problem.
>
> Consider
>
> department.campus.university.edu
>
> where there are zone cuts between university and edu and between
> department and campus.
>
> All the zones are signed, so if we look up something under .department,
> we expect a signature, if we don't get it, we check
>
> DS .edu gives an answer
> DS university.edu gives secure NODATA
>
> 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 we're not at a zone cut, except if we know
> where the zone cuts are, and we don't.

Having just looked through RFC 5155 for clues: isn’t that the purpose of 
the NS type bit in the NSEC3 record?  In this example, DS university 
would give an NSEC3 record with the NS bit clear.  That signals that we 
should go down a level and query DS campus.  In this case we find a 
signed DS there.  But if we were to find an NSEC3 with the NS bit set, 
then we’d know that we’ve really found an unsigned zone and can stop 
going down.

Anders

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

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.campus.university.edu example, where 
> campus and edu are signed zones, and university is not a zone.

This issue is why trust anchors were devised so people could start deploying
DNSSEC before stuff like .COM got signed.

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Anders Kaseorg]

On Fri, 3 Oct 2014, Valdis.Kletnieks@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.campus.university.edu example, 
> > where campus and edu are signed zones, and university is not a zone.
> 
> This issue is why trust anchors were devised so people could start 
> deploying DNSSEC before stuff like .COM got signed.

No, you’re misreading.  Trust anchors address the case where 
campus.university.edu is a signed zone and university.edu is an unzigned 
zone.  We’re talking about the case where university.edu is not a zone at 
all, so that campus.university.edu is served directly from the edu zone.

Obviously this won’t happen at the real edu zone, but real examples exist: 
env.state.ma.us, state.ma.us, us are signed zones, and ma.us is not a 
zone.

Anders

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Anders Kaseorg]

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 we're not at a zone cut, 
> > except if we know where the zone cuts are, and we don't.
> 
> Having just looked through RFC 5155 for clues: isn’t that the purpose of 
> the NS type bit in the NSEC3 record?  In this example, DS university 
> would give an NSEC3 record with the NS bit clear.  That signals that we 
> should go down a level and query DS campus.  In this case we find a 
> signed DS there.  But if we were to find an NSEC3 with the NS bit set, 
> then we’d know that we’ve really found an unsigned zone and can stop 
> going down.

Aha: and this is exactly the answer given at 
http://tools.ietf.org/html/rfc6840#section-4.4 .

Anders

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

-----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 sending DNSSEC queries  to
DNSSEC-unaware servers in the unsigned parts of the tree.

This was quite a big change, and it could do with some serious
testing. Available now on the dnsmasq git repo, or as 2.73test3 in a
tarball.

There are other DNSSEC fixes in there too, Check the changelog.


Cheers,

Simon.


On 04/10/14 22:45, Anders Kaseorg wrote:
> 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
>>> we're not at a zone cut, except if we know where the zone cuts
>>> are, and we don't.
>> 
>> Having just looked through RFC 5155 for clues: isn’t that the
>> purpose of the NS type bit in the NSEC3 record?  In this example,
>> DS university would give an NSEC3 record with the NS bit clear.
>> That signals that we should go down a level and query DS campus.
>> In this case we find a signed DS there.  But if we were to find
>> an NSEC3 with the NS bit set, then we’d know that we’ve really
>> found an unsigned zone and can stop going down.
> 
> Aha: and this is exactly the answer given at 
> http://tools.ietf.org/html/rfc6840#section-4.4 .
> 
> Anders
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUrrGDAAoJEBXN2mrhkTWitZ0P/1T8AaAAlcgI6Z9oDXBGKR+Q
gw0E0bUcmMsvOf5YepR4jqNqonMYBDEv5aSx4EG13LEYBdEekVjUWlakcTSFGCCH
r4bx91XmxZBBSjBM2UNRd4B/dGY34YydbjPFnV/Mmzv5FdUzmVxG3PRQ3E0EyyLp
Eczm+s0Dxz4pGzEINhFHZ6T8sByDeSjAb3adBNidofKFSevwIv/iOMOQJ5moQfem
VkY+azpFzSmpdeNpIU+uboMfcg4jhFpVU3WRr7umTmLc0KOus1j7ao9GxSujPQHo
S7q+IwSwKHUPMEeEmQh+j7yJ2seweGuqGl0quWkHaqGUIOh2C2E756qZfXeenUcv
ia00dcKmpCYi0Ay3nXdgIq91aRwc78GsR93MEBTuvJwDmAUDupsbZMdlA/3D6tOd
ZTREvBmxkFz/QYOo731N/JzdaflQeLUrNPIwRJKpYFW9caotiJ3EiihRGrqrjHBk
a7h8QXy8bQKxc3G0LLKlJNIkxApnNzG6YGSmD6t9bzRPn/sSqar0Ws0IIYd5nYDv
hB4ggfpHvrnEbke4lkfoEBLbJmFFcnSngJh7oDCMT6XEpqeUH7HT0RmYEncnbH1C
9ZRpzUlzxyhZawjBbXWQBNmxhT2Z/KFYkLUkKMPnb060CBtn8DwlkZ22b2dqOvH8
TeRUKySnx6ieH+55fjG4
=CehB
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

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
ipv6 for dns (it reduced ipv4 nat pressure significantly!), but it
hung after a few days and I never got back to it. Were any problems
like this experienced and/or fixed for dnsmasq in the past 8 months or
so?

Anyway... enough incremental fixes have landed all across the board in
openwrt, and the chaos calmer process seems to have settled down
enough, to consider doing an entirely updated cerowrt based on 3.14
and pushing things like dnsmasq further forward...

... but I, personally, am still, not in the position to easily build
and test a new dnsmasq package for cerowrt and have no funding or time
for further development based on chaos calmer. Hopefully someone else
in the openwrt or cerowrt world can take up the slack. I see that
several bleeding edge sub-distros of openwrt have also emerged on
their forums...

(Yet.... I will still try to produce a test dnsmasq version from the
cerowrt-3.10 tree but I doubt it would be safe to do an opkg update
for it.)

On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley <simon@thekelleys.org.uk> wrote:
> -----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 sending DNSSEC queries  to
> DNSSEC-unaware servers in the unsigned parts of the tree.
>
> This was quite a big change, and it could do with some serious
> testing. Available now on the dnsmasq git repo, or as 2.73test3 in a
> tarball.
>
> There are other DNSSEC fixes in there too, Check the changelog.
>
>
> Cheers,
>
> Simon.
>
>
> On 04/10/14 22:45, Anders Kaseorg wrote:
>> 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
>>>> we're not at a zone cut, except if we know where the zone cuts
>>>> are, and we don't.
>>>
>>> Having just looked through RFC 5155 for clues: isn’t that the
>>> purpose of the NS type bit in the NSEC3 record?  In this example,
>>> DS university would give an NSEC3 record with the NS bit clear.
>>> That signals that we should go down a level and query DS campus.
>>> In this case we find a signed DS there.  But if we were to find
>>> an NSEC3 with the NS bit set, then we’d know that we’ve really
>>> found an unsigned zone and can stop going down.
>>
>> Aha: and this is exactly the answer given at
>> http://tools.ietf.org/html/rfc6840#section-4.4 .
>>
>> Anders
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUrrGDAAoJEBXN2mrhkTWitZ0P/1T8AaAAlcgI6Z9oDXBGKR+Q
> gw0E0bUcmMsvOf5YepR4jqNqonMYBDEv5aSx4EG13LEYBdEekVjUWlakcTSFGCCH
> r4bx91XmxZBBSjBM2UNRd4B/dGY34YydbjPFnV/Mmzv5FdUzmVxG3PRQ3E0EyyLp
> Eczm+s0Dxz4pGzEINhFHZ6T8sByDeSjAb3adBNidofKFSevwIv/iOMOQJ5moQfem
> VkY+azpFzSmpdeNpIU+uboMfcg4jhFpVU3WRr7umTmLc0KOus1j7ao9GxSujPQHo
> S7q+IwSwKHUPMEeEmQh+j7yJ2seweGuqGl0quWkHaqGUIOh2C2E756qZfXeenUcv
> ia00dcKmpCYi0Ay3nXdgIq91aRwc78GsR93MEBTuvJwDmAUDupsbZMdlA/3D6tOd
> ZTREvBmxkFz/QYOo731N/JzdaflQeLUrNPIwRJKpYFW9caotiJ3EiihRGrqrjHBk
> a7h8QXy8bQKxc3G0LLKlJNIkxApnNzG6YGSmD6t9bzRPn/sSqar0Ws0IIYd5nYDv
> hB4ggfpHvrnEbke4lkfoEBLbJmFFcnSngJh7oDCMT6XEpqeUH7HT0RmYEncnbH1C
> 9ZRpzUlzxyhZawjBbXWQBNmxhT2Z/KFYkLUkKMPnb060CBtn8DwlkZ22b2dqOvH8
> TeRUKySnx6ieH+55fjG4
> =CehB
> -----END PGP SIGNATURE-----



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

-----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 showing the same behaviour it was back in
April (!) as far as I can see. Queries to test-ipv6.com (which is what
tripped up Jim in the first place) work fine on the latest dnsmasq,
code, forwarding to 8.8.8.8

> 
> Is there another site that demonstrates this problem?

There were three in Aaron Wood's original posting (subject: Had to
disable dnssec today)

- - Bank of America (sso-fi.bankofamerica.com)
- - Weather Underground (cdnjs.cloudflare.com)
- - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net)


All three work for me with the new code. I didn't try old dnsmasq, to
see if the repair was from that or the DNS configuration.

> 
> BTW: For a while there (on comcast), in production, I ran with
> pure ipv6 for dns (it reduced ipv4 nat pressure significantly!),
> but it hung after a few days and I never got back to it. Were any
> problems like this experienced and/or fixed for dnsmasq in the past
> 8 months or so?
> 

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=5782649ad95382dd558df97b33b64e854d8789fb

is a possible candidate.

> Anyway... enough incremental fixes have landed all across the board
> in openwrt, and the chaos calmer process seems to have settled
> down enough, to consider doing an entirely updated cerowrt based on
> 3.14 and pushing things like dnsmasq further forward...
> 
> ... but I, personally, am still, not in the position to easily
> build and test a new dnsmasq package for cerowrt and have no
> funding or time for further development based on chaos calmer.
> Hopefully someone else in the openwrt or cerowrt world can take up
> the slack. I see that several bleeding edge sub-distros of openwrt
> have also emerged on their forums...
> 
> (Yet.... I will still try to produce a test dnsmasq version from
> the cerowrt-3.10 tree but I doubt it would be safe to do an opkg
> update for it.)

There shouldn't be any non backwards-compatible changes in dnsmasq to
bite you. Don't know about other stuff.


Cheers,

Simon.


> 
> On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley
> <simon@thekelleys.org.uk> wrote: 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 sending DNSSEC queries  to DNSSEC-unaware
> servers in the unsigned parts of the tree.
> 
> This was quite a big change, and it could do with some serious 
> testing. Available now on the dnsmasq git repo, or as 2.73test3 in
> a tarball.
> 
> There are other DNSSEC fixes in there too, Check the changelog.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> On 04/10/14 22:45, Anders Kaseorg wrote:
>>>> 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 we're not at a zone cut, except if we
>>>>>> know where the zone cuts are, and we don't.
>>>>> 
>>>>> Having just looked through RFC 5155 for clues: isn’t that
>>>>> the purpose of the NS type bit in the NSEC3 record?  In
>>>>> this example, DS university would give an NSEC3 record with
>>>>> the NS bit clear. That signals that we should go down a
>>>>> level and query DS campus. In this case we find a signed DS
>>>>> there.  But if we were to find an NSEC3 with the NS bit
>>>>> set, then we’d know that we’ve really found an unsigned
>>>>> zone and can stop going down.
>>>> 
>>>> Aha: and this is exactly the answer given at 
>>>> http://tools.ietf.org/html/rfc6840#section-4.4 .
>>>> 
>>>> Anders
>>>> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUrsduAAoJEBXN2mrhkTWiRLwP/2tUY2VLgehYWiAtBXcfjLMU
ZBPpRqwQmvXfypcXoqcZPvutDJCXPw4N/UGN3ole1eDCILBPQ6k8asujNLs0wZnN
m7/mrgS0JEWWSbVsqcTy3JgLh2TcGO0DG7LcOUKZX0VIbNwPVvG6Bv4eBk9afVJ1
sXwxAzdPLoQ5RBnjBCcpcVqRijU5jFClsBXSPsg725xKr9LYh4ZmUJB4TIgHGS/D
UfywntWAvF2hhEZNAIdE6wenQmTlmnQ0mEJK9mn5OfKP3WnDyOlvTI7E3gZ/9gRc
qj+4QSjK31pCam3CoyCHLW8jEDy0/GkEWCCJt58ZelpZz7jh34aiPclalaRVGKNz
PcXiGnmoQnk7ZALaE8VqEEtLh5XLZ067QditsR89Syu8g1iwIOIDR4yJ2gN+0VKD
qs48K7FgxVX+DCpJjCoVfu9F0dWf3haeJetMchFw1WsJdVyIg1yBvc2x+3JD+j8j
idv196X1rb1P68ufGzFILwHcX9oWXDhKaYyZLSZnfPLAUq6is3bnTBY74SHrRYOw
gmPpZ0ysY+gVH7DAMhSViT5fsmUHzho8LLJ4gTuzYyrLAx91CamD6sX/cYXAXZ5t
RNSMp6jOiMV7N9/d1R8WTeX3b9lJ5dZHzql2ldllRhRvlCrb/Lx7+E1frn19dwGe
/cL5NcnFWYc5n32K8mTF
=i31t
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

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 few tests on the former dnssec problematic sites and
everything looked kosher. As for the variety of the dnssec testing web
sites.... about half seem down or mis-behaving. Sigh. the ongoing
costs of keeping core internet test tools going strikes again...

In an orgy of self-flagellation, and *only because I have native ipv6*
I also turned off dns queries over ipv4 entirely (this is option
peerdns '0'  in /etc/config/networks on cerowrt's ge00 config), and
will pound on it a few days/weeks. I send this email prior to actually
trying that, however....


On Thu, Jan 8, 2015 at 10:07 AM, Simon Kelley <simon@thekelleys.org.uk> wrote:
> -----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 showing the same behaviour it was back in
> April (!) as far as I can see.

My bad. The "modern openwrt" I am behind does not have the dnsmasq-full
package installed.

> Queries to test-ipv6.com (which is what
> tripped up Jim in the first place) work fine on the latest dnsmasq,
> code, forwarding to 8.8.8.8
>
>>
>> Is there another site that demonstrates this problem?
>
> There were three in Aaron Wood's original posting (subject: Had to
> disable dnssec today)
>
> - - Bank of America (sso-fi.bankofamerica.com)
> - - Weather Underground (cdnjs.cloudflare.com)
> - - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net)
>
>
> All three work for me with the new code. I didn't try old dnsmasq, to
> see if the repair was from that or the DNS configuration.
>
>>
>> BTW: For a while there (on comcast), in production, I ran with
>> pure ipv6 for dns (it reduced ipv4 nat pressure significantly!),
>> but it hung after a few days and I never got back to it. Were any
>> problems like this experienced and/or fixed for dnsmasq in the past
>> 8 months or so?
>>
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=5782649ad95382dd558df97b33b64e854d8789fb
>
> is a possible candidate.

K.

>> Anyway... enough incremental fixes have landed all across the board
>> in openwrt, and the chaos calmer process seems to have settled
>> down enough, to consider doing an entirely updated cerowrt based on
>> 3.14 and pushing things like dnsmasq further forward...
>>
>> ... but I, personally, am still, not in the position to easily
>> build and test a new dnsmasq package for cerowrt and have no
>> funding or time for further development based on chaos calmer.
>> Hopefully someone else in the openwrt or cerowrt world can take up
>> the slack. I see that several bleeding edge sub-distros of openwrt
>> have also emerged on their forums...
>>
>> (Yet.... I will still try to produce a test dnsmasq version from
>> the cerowrt-3.10 tree but I doubt it would be safe to do an opkg
>> update for it.)
>
> There shouldn't be any non backwards-compatible changes in dnsmasq to
> bite you. Don't know about other stuff.

So far so good.

>
>
> Cheers,
>
> Simon.
>
>
>>
>> On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley
>> <simon@thekelleys.org.uk> wrote: 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 sending DNSSEC queries  to DNSSEC-unaware
>> servers in the unsigned parts of the tree.
>>
>> This was quite a big change, and it could do with some serious
>> testing. Available now on the dnsmasq git repo, or as 2.73test3 in
>> a tarball.
>>
>> There are other DNSSEC fixes in there too, Check the changelog.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>> On 04/10/14 22:45, Anders Kaseorg wrote:
>>>>> 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 we're not at a zone cut, except if we
>>>>>>> know where the zone cuts are, and we don't.
>>>>>>
>>>>>> Having just looked through RFC 5155 for clues: isn’t that
>>>>>> the purpose of the NS type bit in the NSEC3 record?  In
>>>>>> this example, DS university would give an NSEC3 record with
>>>>>> the NS bit clear. That signals that we should go down a
>>>>>> level and query DS campus. In this case we find a signed DS
>>>>>> there.  But if we were to find an NSEC3 with the NS bit
>>>>>> set, then we’d know that we’ve really found an unsigned
>>>>>> zone and can stop going down.
>>>>>
>>>>> Aha: and this is exactly the answer given at
>>>>> http://tools.ietf.org/html/rfc6840#section-4.4 .
>>>>>
>>>>> Anders
>>>>>
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUrsduAAoJEBXN2mrhkTWiRLwP/2tUY2VLgehYWiAtBXcfjLMU
> ZBPpRqwQmvXfypcXoqcZPvutDJCXPw4N/UGN3ole1eDCILBPQ6k8asujNLs0wZnN
> m7/mrgS0JEWWSbVsqcTy3JgLh2TcGO0DG7LcOUKZX0VIbNwPVvG6Bv4eBk9afVJ1
> sXwxAzdPLoQ5RBnjBCcpcVqRijU5jFClsBXSPsg725xKr9LYh4ZmUJB4TIgHGS/D
> UfywntWAvF2hhEZNAIdE6wenQmTlmnQ0mEJK9mn5OfKP3WnDyOlvTI7E3gZ/9gRc
> qj+4QSjK31pCam3CoyCHLW8jEDy0/GkEWCCJt58ZelpZz7jh34aiPclalaRVGKNz
> PcXiGnmoQnk7ZALaE8VqEEtLh5XLZ067QditsR89Syu8g1iwIOIDR4yJ2gN+0VKD
> qs48K7FgxVX+DCpJjCoVfu9F0dWf3haeJetMchFw1WsJdVyIg1yBvc2x+3JD+j8j
> idv196X1rb1P68ufGzFILwHcX9oWXDhKaYyZLSZnfPLAUq6is3bnTBY74SHrRYOw
> gmPpZ0ysY+gVH7DAMhSViT5fsmUHzho8LLJ4gTuzYyrLAx91CamD6sX/cYXAXZ5t
> RNSMp6jOiMV7N9/d1R8WTeX3b9lJ5dZHzql2ldllRhRvlCrb/Lx7+E1frn19dwGe
> /cL5NcnFWYc5n32K8mTF
> =i31t
> -----END PGP SIGNATURE-----



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

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 that kills it is a kill -9. I will build a
non-stripped version in the morning... (and I do note that I was
testing two things - one ipv6 upstreams only, and two, dnssec. Prior
to this version I was using both ipv4 and ipv6 upstreams, no issues,
had dnssec on also, usually no issues)

Other suggestions for debugging the causes of a lockup requested (log
all queries?)

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

-----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 risky, since my IPv6 is
via a sixXS tunnel. If the tunnel goes down, it needs to do DNS
queries to bring it back up.

Cheers,

Simon.


On 09/01/15 08:52, Dave Taht wrote:
> 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 that kills it is a kill -9. I will
> build a non-stripped version in the morning... (and I do note that
> I was testing two things - one ipv6 upstreams only, and two,
> dnssec. Prior to this version I was using both ipv4 and ipv6
> upstreams, no issues, had dnssec on also, usually no issues)
> 
> Other suggestions for debugging the causes of a lockup requested
> (log all queries?)
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUr/VzAAoJEBXN2mrhkTWizvcP/3eCyJEY6kwGSWvh+4QiDulK
CMsz1DJYbhYqu1w+oME287Hazd3LcneSZkn/CH05Qo9gLHNIjnQK48OvxaUPLtw5
rereV59vcgSgIVRyeuTJmVeF6Z4uL4kiNsWsNYWT32RNWfZpLQMrww9svrMuNQlN
2LZknand/1XJXVxDdAFOIyx6DIR5NFtRQPtntSr8GFwWMuvyM3PLEfF7Qu4RbrIt
pFAirlM+uiuUrGmCf1T5h8h9C7z++T7WXdFyCU6fmH7k6ZnXqYdl5OY0YkHeRhNF
UHbcd/Eqr5Onm6F0TZpQKKkKotfyyGoj3HkxBpCn1NrPafexRjUK4Rf4aQkys1ie
eLdiSvQafkLDssdPCuNV9+AGKUkZ6zolsf88gG6vxdksrQbVwFw9h25mdbizEw2M
KfvFbsJLYZ67U/FJGyW0trBc+t5j8Qv1KZCq4vhdiJfIn2dwOjtTn8IEHSZrbOIt
f7zvOKr25rR+fuFsw1PnSOXZwJDlBgKdRB7/1NYg2xrLnzL/luBgpfoOVoJNH1Cf
rzpsxZ3ZwzGfFZljokFbbXNWSTDiEgIDEzjLf9ie6+PJtUclhKbcqy35iGRaVRxL
tuWVgv24bQv5+FiSmPRCtytIJXhehCCqBeC9wXFOWvzFxILQ3n8THvvOwiRx6n4p
lWriAqwv+al2mC9CkthE
=9IWM
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

-----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 (when signed) is
1600-or-so bytes. running dnsmasq with --edns-packet-max=1280 makes it
work.

The tunnel MTU is 1280


Simon.





On 09/01/15 08:52, Dave Taht wrote:
> 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 that kills it is a kill -9. I will
> build a non-stripped version in the morning... (and I do note that
> I was testing two things - one ipv6 upstreams only, and two,
> dnssec. Prior to this version I was using both ipv4 and ipv6
> upstreams, no issues, had dnssec on also, usually no issues)
> 
> Other suggestions for debugging the causes of a lockup requested
> (log all queries?)
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUsAapAAoJEBXN2mrhkTWi6BMP/jXXRw3lQ9vuX28lut4VUsz8
yuVhPB8nQYpewXAT3LRxd33C7mVI6hQfbxcA192Mh7/4N66yAp91a3jeRZTe5pW6
nUS+GDGfXQXNZoVFbeQZrUQEyJ7QF1tj1TqXncp9lbYPGUFWrlruM3r0kDfHEYIb
hHZ7oO/LWg6sYTg5JkidbogL7QwFG97cZ5+6I4++rFTe+rrtfgKRIMSDP4kY+azU
vqzTOzQfwM69TfCPFjm/iJ8AStH8Y99lhORMyK/0F7kSODI0c3fPkcYLDaqslq/S
0GnhWIscAle0FoKG1CUErrUXESN1Q9dn4SKqrzeoRB4494n8tP0QykvmlgkcR/fx
orAxbvshTpWZaNzo0D6fjd9Pk81fFH2jTB6hFz3O1e67+2DOK5wqrOm4+vLU2Kke
gPthCsGDD5s6CcYs93gUfufzjZAllNvCgouvUZJMDWK2YQoMRLTHyGozz/wNeUV5
qI0aZTrXXluUQNaWxs326C4Ej02UXztE4rrPXb1YRiPzyFC0TZSNdco0tv0l/yru
oZQ1s6VFvqrqy7aNHeh/TyjFDEC2OqRVIXvuNOe1SECgjActLTOzxaOhOqfvqgjc
10Py3aZz8Tm40pixW4Q7LCm++QOB770NwzhLMjQ4jvvCEo5ua5dNsMA7whVX6Spf
pVw5V1h6KX4QDNbfZmeC
=HAlX
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Dave Taht]

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.

will go through kernel git logs and see what has happened there since 3.10.50.

Turning on the edns-packet-max feature now, however, as I lack time to
poke into this in more detail, and we're supposed to be testing dnssec
as it is....

Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Simon Kelley]

-----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,

Simon.



On 09/01/15 21:34, Dave Taht wrote:
> 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.
> 
> will go through kernel git logs and see what has happened there
> since 3.10.50.
> 
> Turning on the edns-packet-max feature now, however, as I lack time
> to poke into this in more detail, and we're supposed to be testing
> dnssec as it is....
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUsUcjAAoJEBXN2mrhkTWigEgP/id/tK0SSnRlrnwazoNe1aCg
jgJ0MyDHAxtKhqJgDPniMyScld185lCQ5nE87k6YM2EOW2Os5G4Xos15Pg8R+s8c
Nd5OD0R/sPWnIjD7f8JKN8RndYNBqB5kUiT/OErDW6R0AR+G5kkvMjMppDPUVpPL
JZ+8xckaeIfOSC/x18thRgc2IczLOmzo9cgXgA7PieV70+Zi3nN6ALOc62xeiizU
sAje24z/lBC9J9B+rTnhs3LuL8CCTcMFxqIv66vaNvrCCSvSk5mV4JR6bqHz2U8X
UNo3fXogjNKhFU1n1EeQPKSmb8okoCmtDXZxGCw8HNqmp9tVm2k9LyUFZnc/ojGA
bnF2/h/vwX3FxJE9BZ0rBNFdwn63RO5LYAt54iyRW78NhoWgsp7BZEdsU0R1j6/V
/FpEGXvLRAQ6Iof9sVLMHEVXrIXvEZOHFv0dm5BnIBxIEtKGaNnMRIYV8B0/cpwT
PFcgyTUxYt7tLaRBbnxgVPT9pBcTnUj9WkAifAE4cs82X5FDZP3ht/jOGb84vkU0
H5fxILYgzj7qfbMOIJdpCjjZ9WgK5pwVpid6KtUntL1kQRawn809gWHrdM1Gwg5z
QW/qB2U2VGJ+bCcMIPzbD4H8Ka0j2pbiYpRMlKTXWEdqXSOrvSRX2IpQeDUxu717
dRCGR0Pgyz+VSjoJ8wyY
=A4Ct
-----END PGP SIGNATURE-----