Re: ZSK rollover weirdness

[Lawrence K. Chen, P.Eng.]

- Original Message -

> So, can I just remove the Revoke line (is there an option in
> dnssec-settime to do this?) and have things fixed...

guess dnssec-settime -A none -R none will remove itbut guessing there's 
more to fixing my current mess? 

-- 

Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator 
For: Enterprise Server Technologies (EST) -- & SafeZone Ally 
Snail: Computing and Telecommunications Services (CTS) 
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu 
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Evan Hunt]

> So, can I just remove the Revoke line (is there an option in
> dnssec-settime to do this?)

"dnssec-settime -R none" can do that.  But I gather the key has already
had its REVOKE flag set in the zone, so if you want to get things back to
the status quo, you probably want to purge and restore the key.  Something
like this ought to work:

dnssec-settime -R none -I now -D now 
rndc loadkeys ksu.edu
sleep 1
dnssec-settime -I  -D  
rndc loadkeys ksu.edu

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Phil Mayers]

On 06/09/13 17:28, Lawrence K. Chen, P.Eng. wrote:


And, the prior ZSK was 14565

; This is a zone-signing key, keyid 14565, for ksu.edu.
; Created: 2013060109 (Sat Jun  1 04:00:00 2013)
; Publish: 20130601090007 (Sat Jun  1 04:00:07 2013)
; Activate: 20130601090007 (Sat Jun  1 04:00:07 2013)
; Revoke: 2013090109 (Sun Sep  1 04:00:00 2013)
; Inactive: 2013091509 (Sun Sep 15 04:00:00 2013)
; Delete: 2013092909 (Sun Sep 29 04:00:00 2013)
ksu.edu. IN DNSKEY 256 3 8 
AwEAAc1HU7nrlgFeGLZSgHCytd+BItSNgR5gY4iemDCAX9+z+cpyq/Pe 
52kLuFxDjCj89EzdjKFDGAkPRDPImWlTQLCr3WQl8g5SIOs67bBR72hv 
q2tHmgpK+/j9Z4yqLRyld/Kpl2FRNWc7dvqh8i+Sd0or5WrLO3ocftS1 t3rQaznB


This looks like the culprit, currently being served up from your 
nameservers:


86350 IN DNSKEY 384 3 8 (
AwEAAc1HU7nrlgFeGLZSgHCytd+BItSNgR5gY4iemDCA
X9+z+cpyq/Pe52kLuFxDjCj89EzdjKFDGAkPRDPImWlT
QLCr3WQl8g5SIOs67bBR72hvq2tHmgpK+/j9Z4yqLRyl
d/Kpl2FRNWc7dvqh8i+Sd0or5WrLO3ocftS1t3rQaznB
) ; ZSK; alg = RSASHA256; key id = 14693

Note the crazy "flags" value (384).

If you calculated the key ID with the data you list above, you get 
14565. If you replace flags "256" with "384" the ID changes to 14693.



Where is 14693 coming from?  And, how do I get it work right.


I would guess you've either mangled the key files somehow, or you've hit 
a bug, but it's not obvious from your infodump how you're signing your 
zones.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Registrars supporting DNSSEC + DS Records

[David White]

I've only recently joined this bind-users@ list, so please feel free to
smack me if this is considered off-topic and an unwanted discussion.

I've recently done research into DNSSEC to understand its intricacies and
possibly implement it onto my (low traffic) authoritative BIND servers for
a number of domains I run.

But I'm annoyed.

It seems like comparatively few registrars actually support DNSSEC and/or
DS records. Mine certainly does not.

I know registrars such as GoDaddy and Gandi do support it, but I'm not a
huge fan of GoDaddy (and try to avoid them whenever possible), and up until
a few days ago when I was starting this research to finally learn DNSSEC, I
had never heard of Gandi.

Does anyone have any insight into why so few registrars actually support
DNSSEC? It seems to me that if the demand were there, then more registrars
would support it as they would have an incentive. For now, my guess is
there isn't much incentive (or they would already have done it).

So, as a second question, why isn't there a demand? How can systems
administrators raise awareness of DNSSEC and help create a demand?

-- 
David White
Founder & CEO
*
*
*Develop CENTS *
Computing, Equipping, Networking, Training & Supporting
Nonprofit Organizations Worldwide
http://developcents.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Lawrence K. Chen, P.Eng.]

- Original Message -
> Lawrence K. Chen, P.Eng.  wrote:
> >
> > And, the prior ZSK was 14565
> >
> > ; This is a zone-signing key, keyid 14565, for ksu.edu.
> > ; Created: 2013060109 (Sat Jun  1 04:00:00 2013)
> > ; Publish: 20130601090007 (Sat Jun  1 04:00:07 2013)
> > ; Activate: 20130601090007 (Sat Jun  1 04:00:07 2013)
> > ; Revoke: 2013090109 (Sun Sep  1 04:00:00 2013)
> > ; Inactive: 2013091509 (Sun Sep 15 04:00:00 2013)
> 
> I think your problem here is that the inactive date is after the
> revoke
> date, so the key will still be used to sign the zone after it has
> been
> revoked.
> 
> > ; Delete: 2013092909 (Sun Sep 29 04:00:00 2013)
> > ksu.edu. IN DNSKEY 256 3 8
> > AwEAAc1HU7nrlgFeGLZSgHCytd+BItSNgR5gY4iemDCAX9+z+cpyq/Pe
> > 52kLuFxDjCj89EzdjKFDGAkPRDPImWlTQLCr3WQl8g5SIOs67bBR72hv
> > q2tHmgpK+/j9Z4yqLRyld/Kpl2FRNWc7dvqh8i+Sd0or5WrLO3ocftS1 t3rQaznB
> >
> > Where is 14693 coming from?
> 
> It is the same key as 14565 but the addition of the revoke bit has
> changed
> the tag.
> 
> 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.
> 

Okay, I found where it says 128 is added.

As for the timing, the documentation says:

Publish: date key is to be published.  After this date, the key will be 
included in the zone but not used to sign it.  default is now.

Activate: date key is to be activated.  After this date, the key will be 
included in the zone and used to sign it. default is now.

Revoked: date key is to be revoked.  After this date, the key will be flagged 
as revoked.  It will be included in the zone and used to sign it.

Inactive: date key is to be retired.  After this date, the key will still be 
included in the zone, but it will not be used to sign it.

Delete: date key is to be deleted.  After this date, the key will no longer be 
included in the zone.


That makes it sound like Revoke comes before Inactive, so the dates are right.  
IIRC, the 2 week spacing comes from the zone TTL being 4 weeks.

So what could be causing other ISPs like comcast to not work now?

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Lawrence K. Chen, P.Eng.]

- Original Message -

> On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt < e...@isc.org > wrote:

> > The revoke bit has no defined meaning for a ZSK.
> 
> While it's true the revoke bit really has no use for a true ZSK
> (i.e., a key where there's another key, a KSK, that is used to
> authenticate it), RFC 5011 doesn't distinguish based on either
> signing roles (ZSK/KSK) or presence of the SEP bit [1]:
> A key is considered revoked when the resolver sees the key in a
> self-signed RRSet and the key has the REVOKE bit (see Section 7
> below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
> NOT use this key as a trust anchor or for any other purpose except to
> validate the RRSIG it signed over the DNSKEY RRSet specifically for
> the purpose of validating the revocation.
> In other words, if the revoke bit is set, that key is no good for
> signing anything other than itself, which is why DNSViz complains
> about it. And just to clarify, the use of the SEP bit is purely an
> administrative/user convention or "hint", but is not considered
> during validation [2,3]. Thus whether a key is action as a "ZSK" or
> a "KSK" really depends on how they are used.

> Casey

> [1] http://tools.ietf.org/html/rfc5011#section-2.1
> [2] http://tools.ietf.org/html/rfc6840#section-6.2
> [3] http://tools.ietf.org/html/rfc4034#section-2.1.1

> > It's used for updating
> 
> > trust anchors via RFC 5011. The code allows you to set it (just as
> > it
> 
> > allows you to use a ZSK as a KSK), but I don't recommend it.
> 

> > Unless there are resolvers that have managed-key trust anchors
> > configured
> 
> > for ksu.edu , you shouldn't bother with the revoke bit for your KSK
> > either.
> 

> > --
> 
> > Evan Hunt -- e...@isc.org
> 
> > Internet Systems Consortium, Inc.
> 

So, is the problem that everything is still being signed by the revoked key, 
along with the current key. Or that due to the 7 second delay in the 
publish/activate and there being 31 days in july and august...and the old key 
was revoked 7 seconds before the new key became active? Which didn't happen 
because I did the alg 7 to 8 transition, so June/July/August ZSK started later, 
so ended a bit into September. 

Hmmm, this is interestingRevoke doesn't exist in my older keys... Revoke 
only appears with old key and current keys. Wonder what caused it to appear 

Looks like when I suggested we change from annual KSK rollover to every 3 years 
(which was good, because the sysadmin in another department that interacts with 
our registrar...left and now those interactions are done through our business 
office because registrars also need to get paid every yearand that former 
sysadmin was the last to have direct spending ability, left over from when she 
used to be a manager. Hopefully in 2015 when we do our KSK rollover, they 
understand all the aspects of interacting with a registrarbeyond buying and 
renewing domains. And, perhaps someday fix the missing NS for some domains, or 
the incorrect glue for others.)... 

The dnssec-keygen calls acquired -A and -R switches. And, the intent was for -A 
to be +7d, but the d got missedso that's why its 7 seconds after creation. 

So, can I just remove the Revoke line (is there an option in dnssec-settime to 
do this?) and have things fixed...or do I need to do some kind of emergency ZSK 
rollover to get things sane again? 

Though why is the only a problem with Comcastthe other report named Xfinity 
as the ISP, which is Comcast 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Casey Deccio]

On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt  wrote:

> The revoke bit has no defined meaning for a ZSK.


While it's true the revoke bit really has no use for a true ZSK (i.e., a
key where there's another key, a KSK, that is used to authenticate it), RFC
5011 doesn't distinguish based on either signing roles (ZSK/KSK) or
presence of the SEP bit [1]:

   A key is considered revoked when the resolver sees the key in a
   self-signed RRSet and the key has the REVOKE bit (see Section 7

   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
   NOT use this key as a trust anchor or for any other purpose except to
   validate the RRSIG it signed over the DNSKEY RRSet specifically for
   the purpose of validating the revocation.

In other words, if the revoke bit is set, that key is no good for signing
anything other than itself, which is why DNSViz complains about it.  And
just to clarify, the use of the SEP bit is purely an administrative/user
convention or "hint", but is not considered during validation [2,3].  Thus
whether a key is action as a "ZSK" or a "KSK" really depends on how they
are used.

Casey

[1] http://tools.ietf.org/html/rfc5011#section-2.1
[2] http://tools.ietf.org/html/rfc6840#section-6.2
[3] http://tools.ietf.org/html/rfc4034#section-2.1.1


> It's used for updating
> trust anchors via RFC 5011. The code allows you to set it (just as it
> allows you to use a ZSK as a KSK), but I don't recommend it.
>
> Unless there are resolvers that have managed-key trust anchors configured
> for ksu.edu, you shouldn't bother with the revoke bit for your KSK either.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Registrars supporting DNSSEC + DS Records

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 2013-09-06 at 13:03 -0400, David White wrote:

> It seems like comparatively few registrars actually support DNSSEC
> and/or DS records. Mine certainly does not.

I like gkg.net - supports DS records and ipv6 glue, with an API to upoad
your new DS records when you do KSK key rollovers.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlIqH9UACgkQL6j7milTFsGj5QCfRq7ZRKKNBNuUbYMIvtANKLz+
+LQAnRDV4KEd3wRYrPASslZeWJWG4dor
=G7bb
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Evan Hunt]

> The current ZSK is 44538
> 
> ; This is a zone-signing key, keyid 44538, for ksu.edu.
[...]
> ; Revoke: 2013120209 (Mon Dec  2 03:00:00 2013)

The revoke bit has no defined meaning for a ZSK. It's used for updating
trust anchors via RFC 5011. The code allows you to set it (just as it
allows you to use a ZSK as a KSK), but I don't recommend it.

Unless there are resolvers that have managed-key trust anchors configured
for ksu.edu, you shouldn't bother with the revoke bit for your KSK either.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Phil Mayers]

On 06/09/13 17:39, Tony Finch wrote:



It is the same key as 14565 but the addition of the revoke bit has changed
the tag.


Oops yes, not crazy flags - revoke bit.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ZSK rollover weirdness

[Tony Finch]

Lawrence K. Chen, P.Eng.  wrote:
>
> And, the prior ZSK was 14565
>
> ; This is a zone-signing key, keyid 14565, for ksu.edu.
> ; Created: 2013060109 (Sat Jun  1 04:00:00 2013)
> ; Publish: 20130601090007 (Sat Jun  1 04:00:07 2013)
> ; Activate: 20130601090007 (Sat Jun  1 04:00:07 2013)
> ; Revoke: 2013090109 (Sun Sep  1 04:00:00 2013)
> ; Inactive: 2013091509 (Sun Sep 15 04:00:00 2013)

I think your problem here is that the inactive date is after the revoke
date, so the key will still be used to sign the zone after it has been
revoked.

> ; Delete: 2013092909 (Sun Sep 29 04:00:00 2013)
> ksu.edu. IN DNSKEY 256 3 8 
> AwEAAc1HU7nrlgFeGLZSgHCytd+BItSNgR5gY4iemDCAX9+z+cpyq/Pe 
> 52kLuFxDjCj89EzdjKFDGAkPRDPImWlTQLCr3WQl8g5SIOs67bBR72hv 
> q2tHmgpK+/j9Z4yqLRyld/Kpl2FRNWc7dvqh8i+Sd0or5WrLO3ocftS1 t3rQaznB
>
> Where is 14693 coming from?

It is the same key as 14565 but the addition of the revoke bit has changed
the tag.

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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ZSK rollover weirdness

[Lawrence K. Chen, P.Eng.]

Getting resports of people with certain ISPs (like comcast) can't resolve my 
domains now.

Did a dnsvis on my domain and the error is:

RRSIG ksu.edu/A by ksu.edu/DNSKEY alg 8, key 14693:The RRSIG was made by a 
revoked key.

Which makes no sense, because I have no key with that id in my key repository.

The files in my repository are:

Kksu.edu.+008+09339.key   Kksu.edu.+008+09339.private
Kksu.edu.+008+14565.key   Kksu.edu.+008+14565.private
Kksu.edu.+008+29826.key   Kksu.edu.+008+29826.private
Kksu.edu.+008+31279.key   Kksu.edu.+008+31279.private
Kksu.edu.+008+44538.key   Kksu.edu.+008+44538.private
Kksu.edu.+008+51720.key   Kksu.edu.+008+51720.private
Kksu.edu.+008+51909.key   Kksu.edu.+008+51909.private

Which represents all the Alg 8 keys since we switched to it from 7 on Jun 1st.  
Haven't decided on adding to current automation to clean up the old keys, or 
find different automation.  The old 7 keys weren't deleted, I just moved aside 
(my record that we went signed on Jul 28, 2010, and first delegated subdomain 
was signed Nov 3, 2011even though it didn't work correctly until last 
December, when I upgraded from 9.7.6-P4 to 9.9.2-P1, since the main feature of 
the subdomain is a wildcard record NSEC3...the mailer is supposed masquerade 
everything in the subdomain as the subdomain, but sometimes host names leak 
out... :) 

But, dnssec-signzone says this:

Fetching KSK 31279/RSASHA256 from key repository.
Fetching ZSK 14693/RSASHA256 from key repository.
Fetching ZSK 44538/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
  ZSKs: 1 active, 0 stand-by, 1 revoked
ksu.edu.signed

The current ZSK is 44538

; This is a zone-signing key, keyid 44538, for ksu.edu.
; Created: 2013090109 (Sun Sep  1 04:00:00 2013)
; Publish: 20130901090007 (Sun Sep  1 04:00:07 2013)
; Activate: 20130901090007 (Sun Sep  1 04:00:07 2013)
; Revoke: 2013120209 (Mon Dec  2 03:00:00 2013)
; Inactive: 2013121609 (Mon Dec 16 03:00:00 2013)
; Delete: 2013123009 (Mon Dec 30 03:00:00 2013)
ksu.edu. IN DNSKEY 256 3 8 
AwEAAet97mpbg2GBaA5EhJxPbygYOFIrrjLSV/dAvyEDRSdcyqMjfZXt 
qQNj9lw0GY9Hc9s8vi3W2NApa2z3Ky+OO6SEMhsubN0bLnE76SAL01kW 
KZ8yrs/tu6/Rr7+NEB4Wa978pyosLIHtzF9WYlrY8bcPhQT21bgYonZJ R8r+6EXF

And, the prior ZSK was 14565

; This is a zone-signing key, keyid 14565, for ksu.edu.
; Created: 2013060109 (Sat Jun  1 04:00:00 2013)
; Publish: 20130601090007 (Sat Jun  1 04:00:07 2013)
; Activate: 20130601090007 (Sat Jun  1 04:00:07 2013)
; Revoke: 2013090109 (Sun Sep  1 04:00:00 2013)
; Inactive: 2013091509 (Sun Sep 15 04:00:00 2013)
; Delete: 2013092909 (Sun Sep 29 04:00:00 2013)
ksu.edu. IN DNSKEY 256 3 8 
AwEAAc1HU7nrlgFeGLZSgHCytd+BItSNgR5gY4iemDCAX9+z+cpyq/Pe 
52kLuFxDjCj89EzdjKFDGAkPRDPImWlTQLCr3WQl8g5SIOs67bBR72hv 
q2tHmgpK+/j9Z4yqLRyld/Kpl2FRNWc7dvqh8i+Sd0or5WrLO3ocftS1 t3rQaznB

I'm running bind-9.9.3-P2

Where is 14693 coming from?  And, how do I get it work right.

This problem also affects my other signed domains.

Fetching ZSK 38373/RSASHA256 from key repository.
Fetching ZSK 43247/RSASHA256 from key repository.
Fetching KSK 52261/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
  ZSKs: 1 active, 0 stand-by, 1 revoked
k-state.edu.signed

There is no 43247

Kk-state.edu.+008+06129.key   Kk-state.edu.+008+06129.private
Kk-state.edu.+008+22785.key   Kk-state.edu.+008+22785.private
Kk-state.edu.+008+23166.key   Kk-state.edu.+008+23166.private
Kk-state.edu.+008+38373.key   Kk-state.edu.+008+38373.private
Kk-state.edu.+008+41019.key   Kk-state.edu.+008+41019.private
Kk-state.edu.+008+43119.key   Kk-state.edu.+008+43119.private
Kk-state.edu.+008+52261.key   Kk-state.edu.+008+52261.private

The prior ZSK was 43119

None of the Alg 7 keys have these IDs as well.

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Who is right?

[Phil Mayers]

On 09/06/2013 08:27 AM, Marco Davids (SIDN) wrote:

dig ANY example.org @..



ANY is a tricky record to send to a recursive server. Some DNS servers 
(e.g. bind) just return anything in-cache. Others (e.g. unbound) do 
things differently.


In short: ANY is a debugging tool and can't be relied upon to behave 
consistently. You get marginally more predictable answers if you send to 
an authoritative server, but still...

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Who is right?

[Sten Carlsen]

AFAIK dig any   will return whatever might be in the cache at the
time of the question.

On 06/09/13 9:27, Marco Davids (SIDN) wrote:
> dig ANY example.org @..
>
> Google Public DNS:
> --
> returns DS: no
>
> BIND 9.9.3-P2:
> --
> returns DS: yes
>
> Unbound 1.4.20:
> ---
> returns DS: no
>
> Personally I don't care much, but perhaps someone on this list has a
> strong opinion about these differences that I should know about?
>
> Thank you.
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Who is right?

[Marco Davids (SIDN)]

dig ANY example.org @..

Google Public DNS:
--
returns DS: no

BIND 9.9.3-P2:
--
returns DS: yes

Unbound 1.4.20:
---
returns DS: no

Personally I don't care much, but perhaps someone on this list has a
strong opinion about these differences that I should know about?

Thank you.

-- 
Marco



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users