10:07 a.m.
With the DNSSEC feature enabled as per the testing instructions, I'm
sometimes (but not always) getting failures for popular geek blog Boing
Boing, when public DNS still works:
$ host boingboing.net
Host boingboing.net not found: 2(SERVFAIL)
$ host boingboing.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
boingboing.net is an alias for boingboing.net.global.prod.fastly.net.
boingboing.net.global.prod.fastly.net is an alias for
global-ssl.fastly.net.
global-ssl.fastly.net is an alias for fallback.global-ssl.fastly.net.
fallback.global-ssl.fastly.net has address 199.27.76.249
fallback.global-ssl.fastly.net has address 23.235.46.249
What's going on here? How can I diagnose it, and how can we fix it so
that users don't have to diagnose these situations?
I'm concerned that if it's happening with this site (which Alexa rates
as in the top 1000 websites in the US), it'll happen with a lot of
others.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:44 a.m.
On 30.06.2015 17:07, Matthew Miller wrote:
With the DNSSEC feature enabled as per the testing instructions,
I'm
sometimes (but not always) getting failures for popular geek blog Boing
Boing, when public DNS still works:
$ host boingboing.net
Host boingboing.net not found: 2(SERVFAIL)
$ host boingboing.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
boingboing.net is an alias for boingboing.net.global.prod.fastly.net.
boingboing.net.global.prod.fastly.net is an alias for
global-ssl.fastly.net.
global-ssl.fastly.net is an alias for fallback.global-ssl.fastly.net.
fallback.global-ssl.fastly.net has address 199.27.76.249
fallback.global-ssl.fastly.net has address 23.235.46.249
What's going on here? How can I diagnose it, and how can we fix it so
that users don't have to diagnose these situations?
I'm concerned that if it's happening with this site (which Alexa rates
as in the top 1000 websites in the US), it'll happen with a lot of
others.
Hi Matt.
Please file a bug against dnssec-trigger. It will be better for getting additional
information. Also please see the reply by Paul Wouters to your previous email.
Thanks in advance.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
11:55 a.m.
On Tue, Jun 30, 2015 at 06:44:41PM +0200, Tomas Hozza wrote:
Please file a bug against dnssec-trigger. It will be better for
getting additional information. Also please see the reply by Paul
Wouters to your previous email.
Oh hey. I forgot that I posted this already, and didn't see the reply.
Ugh, time for a vacation!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:01 p.m.
With that many CNAMEs requiring validation and intermittent failure, my guess is your wifi
is dropping a significant amount of queries.
This is a case where shorter negative cache lifetimes should help a lot. This should come
into dnssec-trigger very soon.
What will also help is once edns-query-chain is implemented and supported by the upstream
resolver, as that reduces the query to one tcp query
Sent from my iPhone
On Jun 30, 2015, at 13:55, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Tue, Jun 30, 2015 at 06:44:41PM +0200, Tomas Hozza wrote:
> Please file a bug against dnssec-trigger. It will be better for
> getting additional information. Also please see the reply by Paul
> Wouters to your previous email.
Oh hey. I forgot that I posted this already, and didn't see the reply.
Ugh, time for a vacation!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2:22 p.m.
On Tue, Jun 30, 2015 at 02:01:19PM -0300, Paul Wouters wrote:
With that many CNAMEs requiring validation and intermittent failure,
my guess is your wifi is dropping a significant amount of queries.
This is a case where shorter negative cache lifetimes should help a
lot. This should come into dnssec-trigger very soon.
That makes sense, especially with the negative cache lifetime
being long. My main concern is that this was previously masked and now,
from a naive user point of view, looks like "Fedora can't connect to
popular site, works fine in $otheros".
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:23 p.m.
On 06/30/2015 07:01 PM, Paul Wouters wrote:
With that many CNAMEs requiring validation and intermittent failure,
my guess is your wifi is dropping a significant amount of queries.
It could also be NAT state table overflow.
This is a case where shorter negative cache lifetimes should help a
lot. This should come into dnssec-trigger very soon.
If it's the state table overflow, this won't help and could make the
situation worse.
Disabling DNS prefetching in the browser might improve things. So would
using TCP. Few consumer NAT devices are optimized for DNS over UDP with
active source port randomization. (It's difficult to configure this
even with iptables because the relevant tools are undocumented.)
Disabling various Unbound hardening options also reduces the number of
flows needed. In the end, it could be necessary to perform queries for
which a secure answer is expected with a constant source port.
--
Florian Weimer / Red Hat Product Security
4:30 p.m.
Hi Matt,
the SERVFAIL is probably not caused by DNSSEC because the zone is not
signed. The problem is that the zone is broken. There is a CNAME
record in the zone apex, which is a violation of the DNS specification
(https://tools.ietf.org/html/rfc2181#section-10.1).
Random resolution failures are quite usual expression of this
particular RFC misconduct.
Unbound might be able to cope with this problem on it's own. But when
used with dnssec-trigger, the DNS queries might be just forwarded to
the DNS resolver from DHCP configuration. And that one might cause the
failure.
Cheers,
Jan
On Tue, Jun 30, 2015 at 5:07 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
With the DNSSEC feature enabled as per the testing instructions,
I'm
sometimes (but not always) getting failures for popular geek blog Boing
Boing, when public DNS still works:
$ host boingboing.net
Host boingboing.net not found: 2(SERVFAIL)
$ host boingboing.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
boingboing.net is an alias for boingboing.net.global.prod.fastly.net.
boingboing.net.global.prod.fastly.net is an alias for
global-ssl.fastly.net.
global-ssl.fastly.net is an alias for fallback.global-ssl.fastly.net.
fallback.global-ssl.fastly.net has address 199.27.76.249
fallback.global-ssl.fastly.net has address 23.235.46.249
What's going on here? How can I diagnose it, and how can we fix it so
that users don't have to diagnose these situations?
I'm concerned that if it's happening with this site (which Alexa rates
as in the top 1000 websites in the US), it'll happen with a lot of
others.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3234
days inactive
3234
days old
6 comments
5 participants
participants (5)
-
Florian Weimer -
Jan Včelák -
Matthew Miller -
Paul Wouters -
Tomas Hozza