DNSSEC resolution
I want to Know what programmes, process, and files (in Bind) that are involved in a DNSSEC resolution when we launch the "dig" command. Thank you -- Kaouthar CHETIOUI ___ 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: DNSSEC resolution
Can you be more specific as to what exactly you want to know? What specific dig commands are you using? Do you actually know how DNSSEC works? Have you read chapter 11.4 in "DNS and BIND" (ISBN:0596100574)? A quick Google query brought back quite a few resources on using dig with DNSSEC https://www.google.co.uk/search?q=dig+dnssec have you looked at any of those? Steve On 9 October 2013 13:58, kaouthar chetioui wrote: > I want to Know what programmes, process, and files (in Bind) that are > involved in a DNSSEC resolution when we launch the "dig" command. > > Thank you > > -- > Kaouthar CHETIOUI > > > ___ > 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: inactivating and deleting DNSSEC keys
On 10/8/13 5:54 PM, Mark Andrews wrote:
> In message <52548a5d.3070...@networktest.com>, David Newman writes:
>> bind 9.9.4
>>
>> How to troubleshoot issues when keys are supposed to be invalidated or
>> deleted on specific dates, but aren't?
>>
>> In this case, a KSK was supposed to be inactivated on 29 September 2013
>> and deleted on 9 October 2013.
>>
>> >From the .key file:
>>
>> ; This is a key-signing key, keyid 56989, for networktest.com.
>> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
>> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
>>
>> Problem is, dig says the key is still active, and will be until 29
>> October 2013:
>
> Named stopped SIGNING with this record on October 29.
Since this is in the future, I think you mean "will stop signing"?
> Inception (20130929181450) is over a hour (clock skew allowance)
> before the Inactivation (20130929201510) time.
OK, do I understand correctly that because the RRSIG got created just
before the inactivate date, it will live on for sig-validity-interval
(30 days in this case), regardless of the key's deletion date?
>
> The RRSIG will be replaced when the record is due to be re-signed
> which is based on the sig-validity-interval.
>
> I would be extending the deletion date to 30 days (sig-validity-interval)
> after the inactivation date.
Right, understood.
In UTC terms, we've already passed the key's deletion date. Can I
retroactively extend the key's deletion date?
Thanks
dn
>
> Mark
>
>> $ dig networktest.com @localhost +multi rrsig | grep 56989
>>
>> 20131029191450 20130929181450 56989 networktest.com.
>>
>> named.conf has this:
>>
>> options {
>> ..
>> // DNSSEC stuff
>> managed-keys-directory "managed-keys";
>> dnssec-enable yes;
>> dnssec-validation auto;
>> }
>>
>> ..
>>
>> zone "networktest.com" {
>> type master;
>> ..
>> key-directory "managed-keys/networktest.com";
>> inline-signing yes;
>> auto-dnssec maintain;
>> };
>>
>> $ ls -l managed-keys/networktest.com/ | grep 56989
>> -rw-r- 1 bind bind 719 Jul 31 13:15 Knetworktest.com.+008+56989.key
>> -rw--- 1 bind bind 1824 Jul 31 13:15
>> Knetworktest.com.+008+56989.private
>>
>> I don't understand the disconnect between the configured inactive/delete
>> times and the ones returned by dig, and presume this is because I've
>> misconfigured something.
>>
>> Thanks in advance for troubleshooting clues.
>>
>> dn
>>
>> ___
>> 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: inactivating and deleting DNSSEC keys
In message <525590bd.8030...@networktest.com>, David Newman writes:
>
>
> On 10/8/13 5:54 PM, Mark Andrews wrote:
> > In message <52548a5d.3070...@networktest.com>, David Newman writes:
> >> bind 9.9.4
> >>
> >> How to troubleshoot issues when keys are supposed to be invalidated or
> >> deleted on specific dates, but aren't?
> >>
> >> In this case, a KSK was supposed to be inactivated on 29 September 2013
> >> and deleted on 9 October 2013.
> >>
> >> >From the .key file:
> >>
> >> ; This is a key-signing key, keyid 56989, for networktest.com.
> >> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
> >> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
> >>
> >> Problem is, dig says the key is still active, and will be until 29
> >> October 2013:
> >
> > Named stopped SIGNING with this record on October 29.
>
> Since this is in the future, I think you mean "will stop signing"?
Actually it was September 29 so it has now passed.
> > Inception (20130929181450) is over a hour (clock skew allowance)
> > before the Inactivation (20130929201510) time.
>
> OK, do I understand correctly that because the RRSIG got created just
> before the inactivate date, it will live on for sig-validity-interval
> (30 days in this case), regardless of the key's deletion date?
Yes.
> > The RRSIG will be replaced when the record is due to be re-signed
> > which is based on the sig-validity-interval.
> >
> > I would be extending the deletion date to 30 days (sig-validity-interval)
> > after the inactivation date.
>
> Right, understood.
>
> In UTC terms, we've already passed the key's deletion date. Can I
> retroactively extend the key's deletion date?
Yes. The files are not removed. You will need to tell named to re-read
the .private file using "rndc signzone" after setting the time the deletion
time.
> Thanks
>
> dn
>
> >
> > Mark
> >
> >> $ dig networktest.com @localhost +multi rrsig | grep 56989
> >>
> >> 20131029191450 20130929181450 56989 networktest.com.
> >>
> >> named.conf has this:
> >>
> >> options {
> >> ..
> >>// DNSSEC stuff
> >> managed-keys-directory "managed-keys";
> >> dnssec-enable yes;
> >> dnssec-validation auto;
> >> }
> >>
> >> ..
> >>
> >> zone "networktest.com" {
> >> type master;
> >>..
> >> key-directory "managed-keys/networktest.com";
> >> inline-signing yes;
> >> auto-dnssec maintain;
> >> };
> >>
> >> $ ls -l managed-keys/networktest.com/ | grep 56989
> >> -rw-r- 1 bind bind 719 Jul 31 13:15 Knetworktest.com.+008+56989.ke
> y
> >> -rw--- 1 bind bind 1824 Jul 31 13:15
> >> Knetworktest.com.+008+56989.private
> >>
> >> I don't understand the disconnect between the configured inactive/delete
> >> times and the ones returned by dig, and presume this is because I've
> >> misconfigured something.
> >>
> >> Thanks in advance for troubleshooting clues.
> >>
> >> dn
> >>
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
> ibe
> >> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: inactivating and deleting DNSSEC keys
On 10/9/13 1:24 PM, Mark Andrews wrote: >> In UTC terms, we've already passed the key's deletion date. Can I >> retroactively extend the key's deletion date? > > Yes. The files are not removed. You will need to tell named to re-read > the .private file using "rndc signzone" after setting the time the deletion > time. Thanks, Mark. The signzone command didn't work, but "rndc sign " worked fine. dn ___ 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
authoritative rDNS
I set up a subnet on my server, complete with rdns, and ARIN has been adjusted for my two dns servers (ns.qcislands.net & ns2.qcislands.net) the subnet: 23.235.75.0/24 if you do a lookup of, for instance: 23.235.75.10 and bounce that nslookup off of other dns servers, SOME say: Authoritative answers can be found from: others, well, at least google 8.8.8.8 do not show anything as authoritative, altho the IP DOES resolve. I am curious if 8.8.8.8 isn't trying, or instead, am I missing something which 8.8.8.8 considers incomplete and therefore un-authoritative ? I just want to make sure my setup is accurate. Thanks. ___ 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: authoritative rDNS
In article , Jim Pazarena wrote: > I set up a subnet on my server, complete with rdns, and ARIN has been > adjusted for my two dns servers (ns.qcislands.net & ns2.qcislands.net) > > the subnet: 23.235.75.0/24 > > if you do a lookup of, for instance: 23.235.75.10 > and bounce that nslookup off of other dns servers, SOME say: > Authoritative answers can be found from: > > others, well, at least google 8.8.8.8 do not show anything as > authoritative, altho the IP DOES resolve. > > I am curious if 8.8.8.8 isn't trying, or instead, am I missing > something which 8.8.8.8 considers incomplete and therefore > un-authoritative ? > > I just want to make sure my setup is accurate. Thanks. Including the Authority Section in a response is optional (unless it's a delegation or negative response). If you ask them explicitly for the NS records they show it: $ dig @8.8.8.8 -x 23.235.75 ns ;; ANSWER SECTION: 75.235.23.in-addr.arpa. 21600 IN NS ns2.qcislands.net. 75.235.23.in-addr.arpa. 21600 IN NS ns.qcislands.net. -- Barry Margolin Arlington, MA ___ 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
