[Unbound-users] Issue Resolving "packagist.org"

[Paul Niemi]

Hello,

We are an ISP, and experiencing an issue looking up "packagist.org", with
unbound version 1.4.17 on Debian linux When we have DNSSEC enabled (our
normal configuration), and make a query for "packagist.org", we get a reply
that it does not exist (NXDOMAIN). If we disable the DNSSEC, by commenting
the "auto-trust-anchor-file" line in the config, then the query is
successful. We tried turning up the logging verbosity, but we am not sure
what all is going on in the log. Does anyone have any insight into what is
going on here, or what I should be looking for in the log? We have tried
against some other open DNS servers (Google, OpenDNS) and the query is
successful there, as well. It just seems to be our unbound DNS server with
DNSSEC enabled, that fails.

Thank you,

Paul
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by e-mail if you have received this email by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

[Casey Deccio]

Post by Paul Niemi
Hello,
We are an ISP, and experiencing an issue looking up "packagist.org", with
unbound version 1.4.17 on Debian linux When we have DNSSEC enabled (our
normal configuration), and make a query for "packagist.org", we get a
reply that it does not exist (NXDOMAIN). If we disable the DNSSEC, by
commenting the "auto-trust-anchor-file" line in the config, then the query
is successful. We tried turning up the logging verbosity, but we am not
sure what all is going on in the log. Does anyone have any insight into
what is going on here, or what I should be looking for in the log? We have
tried against some other open DNS servers (Google, OpenDNS) and the query
is successful there, as well. It just seems to be our unbound DNS server
with DNSSEC enabled, that fails.

Hi Paul,

FWIW, I am unable to reproduce the NXDOMAIN on my own instance of unbound
of the same version and platform:

$ dig +dnssec +noall +answer @localhost packagist.org
packagist.org. 42979 IN A 87.98.253.214
packagist.org. 42979 IN RRSIG A 7 2 43200 20150127124709
20141228124709 36677 packagist.org.
DsdSPygfMm2q0m6bq2Sk/atUQ4qhjh0A/HcjRBU1N5c7pMpTGA23cC7m
pqZXqnCvaZoklh/sP54ImZHM62S5vLLF4hpceXMxIvPhzNQOqQIbveA6
DiiANUA7vVgpxuliAG95OCwKMxqf5u182R5KV6+Q1Wuufo5JKzKfbgJS 8eI=


That being said, the domain has (at least) some issues with consistency
across anycast instances. ns200 shows two different serials from two
different locations:

client1$ dig +dnssec +noall +answer @ns200.anycast.me packagist.org soa |
awk '$4 ~ /SOA/ { print $7 }'
2014122801
client2$ dig +dnssec +noall +answer @ns200.anycast.me packagist.org soa |
awk '$4 ~ /SOA/ { print $7 }'
2014122800

Likewise, ns200 returns RRSIGs from one location, and not from the other.

client1$ dig +dnssec @ns200.anycast.me packagist.org mx | grep RRSIG | wc -l
1
client2$ dig +dnssec @ns200.anycast.me packagist.org mx | grep RRSIG | wc -l
0

DNSViz sees this too:
http://dnsviz.net/d/packagist.org/VKxTjA/dnssec/

Regards,
Casey

[Paul Niemi]

Hello,

One of my co-workers had also, noticed inconsistencies with this domain
(SOA serial #'s). We are still unable to resolve "pakagist.org" with
DNSSEC enabled, and yet you are able. Perhaps something is different or
missing with our configuration (see below), or it has to do with differing
geographic locations, resulting in a different query path?

Our configuration:

auto-trust-anchor-file: "/var/lib/unbound/root.key"
verbosity: 1
extended-statistics: yes
interface: X.X.X.X
interface: Y.Y.Y.Y
outgoing-interface: X.X.X.X
do-ip6: yes

"access-control" lines

logfile: "/etc/unbound/log/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: yes
root-hints: "/etc/unbound/named.cache"
hide-identity: yes
hide-version: yes

"local-zone/local-data" lines
"stub-zones" lines
"remote-control" lines


Thank you,

Paul

Post by Casey Deccio

Post by Paul Niemi
Hello,
We are an ISP, and experiencing an issue looking up "packagist.org",
with unbound version 1.4.17 on Debian linux When we have DNSSEC enabled
(our normal configuration), and make a query for "packagist.org", we get
a reply that it does not exist (NXDOMAIN). If we disable the DNSSEC, by
commenting the "auto-trust-anchor-file" line in the config, then the query
is successful. We tried turning up the logging verbosity, but we am not
sure what all is going on in the log. Does anyone have any insight into
what is going on here, or what I should be looking for in the log? We have
tried against some other open DNS servers (Google, OpenDNS) and the query
is successful there, as well. It just seems to be our unbound DNS server
with DNSSEC enabled, that fails.

Hi Paul,
FWIW, I am unable to reproduce the NXDOMAIN on my own instance of unbound
packagist.org. 42979 IN A 87.98.253.214
packagist.org. 42979 IN RRSIG A 7 2 43200 20150127124709
20141228124709 36677 packagist.org.
DsdSPygfMm2q0m6bq2Sk/atUQ4qhjh0A/HcjRBU1N5c7pMpTGA23cC7m
pqZXqnCvaZoklh/sP54ImZHM62S5vLLF4hpceXMxIvPhzNQOqQIbveA6
DiiANUA7vVgpxuliAG95OCwKMxqf5u182R5KV6+Q1Wuufo5JKzKfbgJS 8eI=
That being said, the domain has (at least) some issues with consistency
across anycast instances. ns200 shows two different serials from two
awk '$4 ~ /SOA/ { print $7 }'
2014122801
awk '$4 ~ /SOA/ { print $7 }'
2014122800
Likewise, ns200 returns RRSIGs from one location, and not from the other.
1
0
http://dnsviz.net/d/packagist.org/VKxTjA/dnssec/
Regards,
Casey

--
*Paul Niemi, B.Sc., B.Eng.* | Networks and Servers Technician
*Tbaytel *| 241 S. Vickers Street | Thunder Bay, Ontario | P7E 1J5
Tel: [phone]
www.tbaytel.net
<https://anywhere.exchserver.com/owa/redir.aspx?C=470ce06163a045ee9da8a0bc65439d0c&ur>
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by e-mail if you have received this email by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

[Jaap Akkerhuis]

Post by Paul Niemi
Hello,
One of my co-workers had also, noticed inconsistencies with this domain
(SOA serial #'s). We are still unable to resolve "pakagist.org" with
DNSSEC enabled, and yet you are able.

I am as well, but that is probably by accident. According to
<http://dnsviz.net/d/packagist.org/dnssec/> the domain iis bogus and
<http://dnssec-debugger.verisignlabs.com/packagist.org> is not happy
either.

Currently I have no time to dig into the details.

jaap

[Dag-Erling Smørgrav]

According to <http://dnsviz.net/d/packagist.org/dnssec/> the domain
iis bogus and <http://dnssec-debugger.verisignlabs.com/packagist.org>
is not happy either.

It's not bogus, it's just not signed. Or did I miss something?

I have had problems with DNSSEC in the past (although in a completely
different scenario) due to misconfigured root servers. I have a log
somewhere...

DES

[Casey Deccio]

Post by Dag-Erling Smørgrav

According to <http://dnsviz.net/d/packagist.org/dnssec/> the domain
iis bogus and <http://dnssec-debugger.verisignlabs.com/packagist.org>
is not happy either.

It's not bogus, it's just not signed. Or did I miss something?

Here's what it looked like one week ago:

http://dnsviz.net/d/packagist.org/VKxXmQ/dnssec/

Regards,
Casey

[Jaap Akkerhuis]

Post by Dag-Erling Smørgrav

According to <http://dnsviz.net/d/packagist.org/dnssec/> the domain
iis bogus and <http://dnssec-debugger.verisignlabs.com/packagist.org>
is not happy either.

It's not bogus, it's just not signed. Or did I miss something?
I have had problems with DNSSEC in the past (although in a completely
different scenario) due to misconfigured root servers. I have a log
somewhere...

Now it is, yes.

At the time people were complaining an I was looking (some days ago),
dnsviz declared it bogus. The fun of dnsviz is that you can actually
go back in time and check. If you do that, you'll notice that on the
7th this month (Updated: 2015-01-06 21:46:01 UTC (7 days ago) the site
says) it was bogus.


jaap

[Paul Niemi]

I would also, like to add that we contacted the maintainer of the domain,
and brought the DNSSEC issue to his attention. He promptly disabled
DNSSEC, until he can figure out what is wrong and make adjustments. Hence
the view has changed at dnsviz.

Paul

Post by Jaap Akkerhuis

Post by Dag-Erling Smørgrav

According to <http://dnsviz.net/d/packagist.org/dnssec/> the domain
iis bogus and <http://dnssec-debugger.verisignlabs.com/packagist.org>
is not happy either.

It's not bogus, it's just not signed. Or did I miss something?
I have had problems with DNSSEC in the past (although in a completely
different scenario) due to misconfigured root servers. I have a log
somewhere...

Now it is, yes.
At the time people were complaining an I was looking (some days ago),
dnsviz declared it bogus. The fun of dnsviz is that you can actually
go back in time and check. If you do that, you'll notice that on the
7th this month (Updated: 2015-01-06 21:46:01 UTC (7 days ago) the site
says) it was bogus.
jaap

--
*Paul Niemi, B.Sc., B.Eng.* | Networks and Servers Technician
*Tbaytel *| 241 S. Vickers Street | Thunder Bay, Ontario | P7E 1J5
Tel: [phone]
www.tbaytel.net
<https://anywhere.exchserver.com/owa/redir.aspx?C=470ce06163a045ee9da8a0bc65439d0c&ur>
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this email. Please notify the sender
immediately by e-mail if you have received this email by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.