Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Mark Andrews]

In message <20120907071041.ga1...@nic.fr>, Stephane Bortzmeyer writes:
> On Thu, Sep 06, 2012 at 10:43:12AM -0700,
>  Wessels, Duane  wrote 
>  a message of 39 lines which said:
> 
> > I wouldn't say our setup assumes only one recursive in the path,
> 
> >From my colleague Kim Minh Kaplan:
> 
> In the case where one of the forwarders is non validating, it will
> happily accept and cache the non signed response. When the local
> validating resolver retries its query to the non validating forwarder,
> the forwarder can reply with the cached, non signed answer.

And is a perfect example of why CD=1 always is *wrong* as it disables
validation in the forwarder.

> My understanding is that many dnssec-trigger users will be in such a
> setup.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Ralf Weber]

Moin!

On 06.09.2012, at 19:43, "Wessels, Duane"  wrote:
> We changed the RRSIG-remover so that it won't remove the signatures
> from "validatorsearch.verisignlabs.com" itself.  Hopefully that
> allows you to view the page now.
While the signatures are constant on now for the A record they still seem to 
change for the SOA, NS and more importantly for the DNSKEY record which at 
least for me makes the domain still failing validation.

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
Nominum Inc.
2000 Seaport Blvd. Suite 400 
Redwood City, California 94063
ralf.we...@nominum.com

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Stephane Bortzmeyer]

On Thu, Sep 06, 2012 at 10:43:12AM -0700,
 Wessels, Duane  wrote 
 a message of 39 lines which said:

> I wouldn't say our setup assumes only one recursive in the path,

>From my colleague Kim Minh Kaplan:

In the case where one of the forwarders is non validating, it will
happily accept and cache the non signed response. When the local
validating resolver retries its query to the non validating forwarder,
the forwarder can reply with the cached, non signed answer.

My understanding is that many dnssec-trigger users will be in such a
setup.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Vernon Schryver]

> From: =?ISO-8859-1?Q?Matth=E4us_Wander?= 

> > I assume I'm odd, because I'm not eagar to put the invisible HREF
> > anchor on my web pages because of the extra DNS transactions imposed
> > on users.  I also have vague worries I can't articulate about privacy
> > concerns.
> >=20
> > My answer to putting a simple  beacon on my web pages would
> > be a flat "never."  There are too many technical and legal issues.
> > For example, what about privacy issues with the referer string?
> >=20

> Can't argue with that. If privacy is an issue, you won't become friends
> with foreign HTTP resources.

I don't understand that.  Whether an HTTP server is foreign or domestic
(for any value of domestic) does not by itself determine its
trustworthiness.  I start by assuming any HTTP server is untrustworthy,
but that doesn't imply that I should involve third parties.

The privacy issues I meant involve the third parties counting DNSSEC
aware resolvers.  The commercial hit counters also claim to be
trustworthy, even as they sell their measurements.  I assume that none
of you guys would do something like correlating referer strings, your
results, and WHOIS or other e-appended values to send email to web
masters offering to sell better DNS resolver software.  I also assume
that if a financial institution put your beacons on their TLS web
pages, none would try to 'leverage' the resulting referer, weak DNS
resolver, and IP address data.  And so forth and so on including other
attacks I can't imagine.  However, a security policy based on assumed
good intentions is incompetent.


Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Wessels, Duane]

On Sep 6, 2012, at 11:43 AM, Ralf Weber wrote:

> the white listing that you do for Vantio also only works in the case where 
> you can query the resolver inbound from the Internet on the query source IP.

Yes, absolutely.

> The approach from Matthäus described earlier in the thread using javascript 
> and two pics, one validating and one not seems cleaner to me and can deal 
> with all the cases Olafur, myself and others had problems with. 


Yes, Matthäus' technique certainly has some advantages.  But I'm glad we
didn't just do the same thing.  First, he would accuse us of stealing his
good idea.  Second, IMHO any time you try to do measurements like this
you'll find flaws and inaccuracies.  So I look forward to comparing our
results to his and finding where they agree and where they differ.

Duane W.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Matthäus Wander]

Hi,

Am 06.09.2012 21:54, schrieb Vernon Schryver:
>> From: Ralf Weber 
> 
>> The protocol doesn't mandate a resolver to retry, ...
> 
> Which protocol is that?  I'm not disagreeing since the claim matches
> my intuition, but only asking for an RFC number (or numbers) so
> that I can understand the exegesis.

RFC 4035 Section 5 explains how to validate signatures and what to do it
that fails (5.5). It says nothing about doing or not doing retries.
BIND and Unbound retry a couple of times and scatter the queries among
all authoritative NS.

> How is javascript involved?  That sounds like a pair of ordinary
>  beacons.
> 
> If javascript is involved, do you figure that browsers with javascript
> controlled manually or automatically (e.g. with NoScript) are
> insignificant or that the resolvers of users that do such things
> should not be counted?

JavaScript is only needed if you want to show the result to the user.
For statistics the  tags suffice, no JS involved.

> I assume I'm odd, because I'm not eagar to put the invisible HREF
> anchor on my web pages because of the extra DNS transactions imposed
> on users.  I also have vague worries I can't articulate about privacy
> concerns.
> 
> My answer to putting a simple  beacon on my web pages would
> be a flat "never."  There are too many technical and legal issues.
> For example, what about privacy issues with the referer string?
> 
> I'd have trouble responding politely to a request that I add
> javascript to my web pages.  I don't think I'm religiously opposed
> to javascript, since I'm taking a break from fighting some javascript
> bugs to write this.  It's just simple security and operational
> prudence to never code that is not strictly necessary.

Can't argue with that. If privacy is an issue, you won't become friends
with foreign HTTP resources.

Kind regards,
Matt

-- 
Universität Duisburg-Essen
Fachgebiet Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg
Tel: +49 203 379 2767



smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Stephane Bortzmeyer]

On Thu, Sep 06, 2012 at 10:43:12AM -0700,
 Wessels, Duane  wrote 
 a message of 39 lines which said:

> We changed the RRSIG-remover so that it won't remove the signatures
> from "validatorsearch.verisignlabs.com" itself.  Hopefully that
> allows you to view the page now.

But we still have no signatures on the NSEC.

% dig +dnssec @vfns1.verisignlabs.com.  validatorsearch.verisignlabs.com
   

; <<>> DiG 9.8.1-P1 <<>> @vfns1.verisignlabs.com.  
validatorsearch.verisignlabs.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10061
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;validatorsearch.verisignlabs.com. IN   

;; AUTHORITY SECTION:
validatorsearch.verisignlabs.com. 3600 IN SOA   vfns1.verisignlabs.com. 
root.packet-pushers.com. 2012080700 3600 300 604800 3600
validatorsearch.verisignlabs.com. 3600 IN NSEC  
*.validatorsearch.verisignlabs.com. A NS SOA RRSIG NSEC DNSKEY

;; Query time: 94 msec
;; SERVER: 72.13.58.100#53(72.13.58.100)
;; WHEN: Thu Sep  6 21:55:53 2012
;; MSG SIZE  rcvd: 148

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Vernon Schryver]

> From: Ralf Weber 

> The protocol doesn't mandate a resolver to retry, ...

Which protocol is that?  I'm not disagreeing since the claim matches
my intuition, but only asking for an RFC number (or numbers) so
that I can understand the exegesis.


> The approach from Matthäus described earlier in the thread using
> javascript and two pics, one validating and one not seems cleaner
> to me and can deal with all the cases Olafur, myself and others had
> problems with.

Is that the scheme mentioned on
https://lists.dns-oarc.net/pipermail/dns-operations/2012-September/008724.html

] Our test methodology is to load 1px images from two domain names, one
] correctly signed and the other one with a broken signature.

How is javascript involved?  That sounds like a pair of ordinary
 beacons.

If javascript is involved, do you figure that browsers with javascript
controlled manually or automatically (e.g. with NoScript) are
insignificant or that the resolvers of users that do such things
should not be counted?

I assume I'm odd, because I'm not eagar to put the invisible HREF
anchor on my web pages because of the extra DNS transactions imposed
on users.  I also have vague worries I can't articulate about privacy
concerns.

My answer to putting a simple  beacon on my web pages would
be a flat "never."  There are too many technical and legal issues.
For example, what about privacy issues with the referer string?

I'd have trouble responding politely to a request that I add
javascript to my web pages.  I don't think I'm religiously opposed
to javascript, since I'm taking a break from fighting some javascript
bugs to write this.  It's just simple security and operational
prudence to never code that is not strictly necessary.


Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Ralf Weber]

Moin!

On 06.09.2012, at 19:43, "Wessels, Duane"  wrote:
> I wouldn't say our setup assumes only one recursive in the path, but it 
> certainly
> does assume the validator will retry.  In our tests most implementations do 
> retry.
> Nominum doesn't of course, and we have numerous reports that Unbound doesn't 
> always
> retry.  So either its version-dependent or something else is going on.
The protocol doesn't mandate a resolver to retry, so it's not a requirement and 
the white listing that you do for Vantio also only works in the case where you 
can query the resolver inbound from the Internet on the query source IP. 
Something that you can not take for granted and the reason why the resolver 
behind my home gateway did not work. 

The approach from Matthäus described earlier in the thread using javascript and 
two pics, one validating and one not seems cleaner to me and can deal with all 
the cases Olafur, myself and others had problems with. 

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
Nominum Inc.
2000 Seaport Blvd. Suite 400 
Redwood City, California 94063
ralf.we...@nominum.com



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Wessels, Duane]

On Sep 6, 2012, at 7:50 AM, o...@ogud.com wrote:

> Duane, 
> 
> I can not reach the webserver on my laptop, running DNSSEC-trigger 

We changed the RRSIG-remover so that it won't remove the signatures
from "validatorsearch.verisignlabs.com" itself.  Hopefully that
allows you to view the page now.


> that has Unbound on the local machine, forwarding to a Unbound on a local 
> router, 
> that forwards to Unbound, Bind or Nominum  server. 
> 
> In short your setup assumes that there is only one recursive resolver between 
> the user 
> and authoritative server, that is not the case anymore :-)

I wouldn't say our setup assumes only one recursive in the path, but it 
certainly
does assume the validator will retry.  In our tests most implementations do 
retry.
Nominum doesn't of course, and we have numerous reports that Unbound doesn't 
always
retry.  So either its version-dependent or something else is going on.


> 
> Why can't you just use DNSKEY RRset with TTL of few seconds 
> to detect validating resolvers?
> 

Sorry, I don't quite follow.  We were looking for more evidence
than "I sent a DNSKEY query so therefore I must be a validator."

DW
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[ogud]

Duane, 

I can not reach the webserver on my laptop, running DNSSEC-trigger 
that has Unbound on the local machine, forwarding to a Unbound on a local 
router, 
that forwards to Unbound, Bind or Nominum  server. 

In short your setup assumes that there is only one recursive resolver between 
the user 
and authoritative server, that is not the case anymore :-) 

Why can't you just use DNSKEY RRset with TTL of few seconds 
to detect validating resolvers?

   Olafur

-Original Message-
From: "Wessels, Duane" 
Sent: Wednesday, 5 September, 2012 13:40
To: "Stephane Bortzmeyer" 
Cc: dns-operati...@mail.dns-oarc.net
Subject: Re: [dns-operations] Research Project: Identifying DNSSEC Validators


On Sep 5, 2012, at 3:48 AM, Stephane Bortzmeyer wrote:

> 
>> It's really weird. The name servers are serving two versions of the zone,
>> one signed and one unsigned, and they seem to be alternating between
>> them.
> 
> I assume it is on purpose, part of the experiment, to probe the
> resolver's behavior.

Yes, that is correct.  It is a relatively simple test.  First response
has RRISGs removed, second response within a short time leaves the
RRISGs in.

We find that most implementations will retry, although we know of one
that does not (Nominum/Vantio).  In this work we whitelist Nominum after
a followup version.bind query.

Duane W.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> OK, but the problem is that the official Web page
>  is not visible if you have
> a validating resolver... (Unbound, in my case, I had to use another
> Internet access to see it.)

It works with validating BIND which retries persistently enough to get a
copy of the RRSIGs.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Stephane Bortzmeyer]

On Wed, Sep 05, 2012 at 10:40:03AM -0700,
 Wessels, Duane  wrote 
 a message of 20 lines which said:

> Yes, that is correct. 

OK, but the problem is that the official Web page
 is not visible if you have
a validating resolver... (Unbound, in my case, I had to use another
Internet access to see it.)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Wessels, Duane]

On Sep 5, 2012, at 3:48 AM, Stephane Bortzmeyer wrote:

> 
>> It's really weird. The name servers are serving two versions of the zone,
>> one signed and one unsigned, and they seem to be alternating between
>> them.
> 
> I assume it is on purpose, part of the experiment, to probe the
> resolver's behavior.

Yes, that is correct.  It is a relatively simple test.  First response
has RRISGs removed, second response within a short time leaves the
RRISGs in.

We find that most implementations will retry, although we know of one
that does not (Nominum/Vantio).  In this work we whitelist Nominum after
a followup version.bind query.

Duane W.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Stephane Bortzmeyer]

On Wed, Sep 05, 2012 at 11:45:23AM +0100,
 Tony Finch  wrote 
 a message of 80 lines which said:

> It's really weird. The name servers are serving two versions of the zone,
> one signed and one unsigned, and they seem to be alternating between
> them.

I assume it is on purpose, part of the experiment, to probe the
resolver's behavior.

Except on this list, nobody actually tried the link :-) (Because it is
invisible and not meant to be actuated.)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> On my machines, I can resolve the name with BIND but not with Unbound
> (SERVFAIL, even with ). On OARC's ODVR both BIND and Unbound work.
>
> My analysis: the NSEC is not signed. It is surprising that BIND acceps
> that:

It's really weird. The name servers are serving two versions of the zone,
one signed and one unsigned, and they seem to be alternating between them.
It took me quite a long time to work out where my name server was getting
the RRSIGs from 


; <<>> DiG 9.9.2-vjs197.15b1 <<>> +multiline +norec +dnssec 
prefetch.validatorsearch.verisignlabs.com. @72.13.58.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44694
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;prefetch.validatorsearch.verisignlabs.com. IN A

;; ANSWER SECTION:
prefetch.validatorsearch.verisignlabs.com. 604800 IN A 127.0.0.1

;; AUTHORITY SECTION:
validatorsearch.verisignlabs.com. 3600 IN NS vfns2.verisignlabs.com.
validatorsearch.verisignlabs.com. 3600 IN NS vfns1.verisignlabs.com.

;; Query time: 90 msec
;; SERVER: 72.13.58.100#53(72.13.58.100)
;; WHEN: Wed Sep  5 11:43:31 2012
;; MSG SIZE  rcvd: 126


; <<>> DiG 9.9.2-vjs197.15b1 <<>> +multiline +norec +dnssec 
prefetch.validatorsearch.verisignlabs.com. @72.13.58.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18857
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;prefetch.validatorsearch.verisignlabs.com. IN A

;; ANSWER SECTION:
prefetch.validatorsearch.verisignlabs.com. 604800 IN A 127.0.0.1
prefetch.validatorsearch.verisignlabs.com. 604800 IN RRSIG A 5 4 604800 (
20120906203607 20120807203607 58962 
validatorsearch.verisignlabs.com.
vL12YMxvy1nX4EzWUAr/j4taPyxKlo/YmnDvaV2z0TmD
1yhIgVQDHL/fOUHLXXuO+uQeNDo3iRFXFg5DRj6AisDU
hSpjGch/6c+j/yvzcsRNPHuef5nZl91+UYe15PerLh6E
z5YVQF24iNBDmj4EgG3+F4IAgnPFX/+BBFnSb58= )

;; AUTHORITY SECTION:
validatorsearch.verisignlabs.com. 3600 IN NS vfns1.verisignlabs.com.
validatorsearch.verisignlabs.com. 3600 IN NS vfns2.verisignlabs.com.
validatorsearch.verisignlabs.com. 3600 IN RRSIG NS 5 3 3600 (
20120906203607 20120807203607 58962 
validatorsearch.verisignlabs.com.
rWe8hzHOfLmi/NwT7LC64sL2LqjtIgPS1bDL6o6/PYlk
gBpBDzEprYlLkJM/d3KsJzpvSwfcK1KFoDk7mwKdNED5
Z3QCSnRrt2qlYD1H1KgOAeFXCciD380ZV7Qsn+Ubpygd
mGja6wTHqNAyiRgX7DIuMNjxytkT5xI0UluSv1U= )

;; Query time: 84 msec
;; SERVER: 72.13.58.100#53(72.13.58.100)
;; WHEN: Wed Sep  5 11:43:31 2012
;; MSG SIZE  rcvd: 510


Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Stephane Bortzmeyer]

On Tue, Sep 04, 2012 at 01:57:20PM -0700,
 Wessels, Duane  wrote 
 a message of 36 lines which said:

> http://prefetch.validatorsearch.verisignlabs.com";>

On my machines, I can resolve the name with BIND but not with Unbound
(SERVFAIL, even with ). On OARC's ODVR both BIND and Unbound work.

With my Unbound, validation fails, but I can get data with +cd:

% dig +cd A prefetch.validatorsearch.verisignlabs.com 

; <<>> DiG 9.8.1-P1 <<>> +cd A prefetch.validatorsearch.verisignlabs.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43366
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;prefetch.validatorsearch.verisignlabs.com. IN A

;; ANSWER SECTION:
prefetch.validatorsearch.verisignlabs.com. 604500 IN A 127.0.0.1

;; AUTHORITY SECTION:
validatorsearch.verisignlabs.com. 3296 IN NSvfns2.verisignlabs.com.
validatorsearch.verisignlabs.com. 3296 IN NSvfns1.verisignlabs.com.
validatorsearch.verisignlabs.com. 3296 IN RRSIG NS 5 3 3600 20120906203607 
20120807203607 58962 validatorsearch.verisignlabs.com. 
rWe8hzHOfLmi/NwT7LC64sL2LqjtIgPS1bDL6o6/PYlkgBpBDzEprYlL 
kJM/d3KsJzpvSwfcK1KFoDk7mwKdNED5Z3QCSnRrt2qlYD1H1KgOAeFX 
CciD380ZV7Qsn+UbpygdmGja6wTHqNAyiRgX7DIuMNjxytkT5xI0UluS v1U=

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Sep  5 10:36:57 2012
;; MSG SIZE  rcvd: 318

The log says:

Sep  5 10:31:53 batilda unbound: [1976:0] info: iterator operate: query 
validatorsearch.verisignlabs.com.  IN
Sep  5 10:31:53 batilda unbound: [1976:0] info: processQueryTargets: 
validatorsearch.verisignlabs.com.  IN
Sep  5 10:31:53 batilda unbound: [1976:0] debug: cache memory msg=4456279 
rrset=4456090 infra=2550870 val=1090917
Sep  5 10:31:53 batilda unbound: [1976:0] debug: iterator[module 1] operate: 
extstate:module_wait_reply event:module_event_reply
Sep  5 10:31:53 batilda unbound: [1976:0] info: iterator operate: query 
validatorsearch.verisignlabs.com.  IN
Sep  5 10:31:53 batilda unbound: [1976:0] info: sanitize: removing overreaching 
NSEC RRset: validatorsearch.verisignlabs.
com. NSEC IN
Sep  5 10:31:53 batilda unbound: [1976:0] info: response for 
validatorsearch.verisignlabs.com.  IN
Sep  5 10:31:53 batilda unbound: [1976:0] info: reply from 
 72.13.58.101#53
Sep  5 10:31:53 batilda unbound: [1976:0] info: query response was DNSSEC LAME

My analysis: the NSEC is not signed. It is surprising that BIND acceps
that:

%  dig +dnssec @vfns1.verisignlabs.com.  
prefetch.validatorsearch.verisignlabs.com 

; <<>> DiG 9.7.3 <<>> @vfns1.verisignlabs.com.  
prefetch.validatorsearch.verisignlabs.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10966
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;prefetch.validatorsearch.verisignlabs.com. IN 

;; AUTHORITY SECTION:
validatorsearch.verisignlabs.com. 3600 IN SOA   vfns1.verisignlabs.com. 
root.packet-pushers.com. 2012080700 3600 300 604800 3600
prefetch.validatorsearch.verisignlabs.com. 3600 IN NSEC 
validatorsearch.verisignlabs.com. A RRSIG NSEC

;; Query time: 92 msec
;; SERVER: 72.13.58.100#53(72.13.58.100)
;; WHEN: Wed Sep  5 10:39:31 2012
;; MSG SIZE  rcvd: 154
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Research Project: Identifying DNSSEC Validators

[Matthäus Wander]

Hi,

Am 04.09.2012 22:57, schrieb Wessels, Duane:
> Within Verisign Labs we have a project underway to quantify the number of
> DNSSEC-validating resolvers in use on the Internet.  In particular, we
> want to identify recursive name servers which have configured the root
> zone trust anchor.  We find this data a useful metric for DNSSEC adoption
> and especially helpful for informing discussions about key rollovers for
> the root zone.

My research group has a similar project that you may be interested in.
We run a DNSSEC validation test with user feedback at
http://dnssec.vs.uni-due.de (for fun) and a hidden test in some websites
(for research). We gathered 69k results from 54k distinct IP addresses
since May this year. The validation ratio was 4.4% which is close to the
3.25% of the current VeriSign 'prefetch' results. Our results vary
significantly by country, US is ~13% (Comcast...), some European
countries up to 4% and the others are basically zero (this might be
inaccurate, the majority of our results are from DE and US).

> In order for our our measurements to be meaningful, we need to receive
> queries from a wide variety of recursive name servers.  To achieve this
> goal we ask members of the DNS and networking communities to assist by
> adding the following single line of HTML code to your web pages:
> 
> http://prefetch.validatorsearch.verisignlabs.com";>
> 
> This HTML snippet should have no visible impact on a rendered page.  Since
> nearly all web browsers now implement DNS prefetching, the code above
> results in a DNS query for the name shown and allows us to characterize
> the recursive name server that the query goes through.

Our test methodology is to load 1px images from two domain names, one
correctly signed and the other one with a broken signature.

> Please note that we are not interested in identifying individual users who
> have loaded the web page.  The name above points to the localhost IP address
> (127.0.0.1) so even if someone does manage to "click" on it, that request
> does not reach us.

Definitely an advantage over our test as we generate more traffic and
log HTTP requests.

> For some preliminary results, please visit the project web page at
> http://validatorsearch.verisignlabs.com/

Here's some more information about our measurements:
http://www.vs.uni-due.de/personal/wander/20120821_DNSSEC_Validation/

I'm right now putting all results together in a paper for PAM2013
(submission is next week).

Kind regards,
Matt

-- 
Universität Duisburg-Essen
Fachgebiet Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg
Tel: +49 203 379 2767
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Research Project: Identifying DNSSEC Validators

[Wessels, Duane]

Within Verisign Labs we have a project underway to quantify the number of
DNSSEC-validating resolvers in use on the Internet.  In particular, we
want to identify recursive name servers which have configured the root
zone trust anchor.  We find this data a useful metric for DNSSEC adoption
and especially helpful for informing discussions about key rollovers for
the root zone.

In order for our our measurements to be meaningful, we need to receive
queries from a wide variety of recursive name servers.  To achieve this
goal we ask members of the DNS and networking communities to assist by
adding the following single line of HTML code to your web pages:

http://prefetch.validatorsearch.verisignlabs.com";>

This HTML snippet should have no visible impact on a rendered page.  Since
nearly all web browsers now implement DNS prefetching, the code above
results in a DNS query for the name shown and allows us to characterize
the recursive name server that the query goes through.

Please note that we are not interested in identifying individual users who
have loaded the web page.  The name above points to the localhost IP address
(127.0.0.1) so even if someone does manage to "click" on it, that request
does not reach us.

For some preliminary results, please visit the project web page at
http://validatorsearch.verisignlabs.com/

We look forward to presenting the full results at a future OARC meeting.

Duane W.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs