Raymond Drew Walker wrote:
>
> After reading this, RFC1034, and conferring with the original implementor
> of DNS at our institution, I have a better wrangle on the NS issue. Child
> zone NS records were never populated in the parent because all zones were
> under the same name servers, and "it ju
In message , Raymond Drew Walker writes:
> -Original Message-
>
> From: Tony Finch
> Date: Tue, 4 Oct 2011 20:30:43 +0100
> To: Raymond Walker
> Cc: "bind-users@lists.isc.org"
> Subject: Re: DNSSEC not populating parent zone files with DS records
&
-Original Message-
From: Tony Finch
Date: Tue, 4 Oct 2011 20:30:43 +0100
To: Raymond Walker
Cc: "bind-users@lists.isc.org"
Subject: Re: DNSSEC not populating parent zone files with DS records
>Raymond Drew Walker wrote:
>
>> In testing, this pipe sets up the
Raymond Drew Walker wrote:
> In testing, this pipe sets up the following for nsupdate which fails:
Sorry, I forgot the TTL command. Adjust its value as you require...
dig +noall +answer dnskey $child |
dnssec-dsfromkey -f /dev/stdin $child |
(echo "zone $parent"; echo "ttl 3600"; sed 's/^
On Tue, Oct 04, 2011 at 06:31:03PM +, Raymond Drew Walker wrote:
> I have been unable to determine the correct method to add a DS record by
> hand. The ultimate goal would be the automation of this process.
Generate the DS record with dnssec-dsfromkey, cut and paste it into the zone
file, the
-Original Message-
From: Tony Finch
Date: Mon, 3 Oct 2011 14:59:38 +0100
To: Michael Sinatra
Cc: , , Raymond Walker
Subject: Re: DNSSEC not populating parent zone files with DS records
>Michael Sinatra wrote:
>>
>> There are ways of getting the DS records into the zon
Michael Sinatra wrote:
>
> There are ways of getting the DS records into the zone(s). Here are some
> steps that I took on some test zones:
Alternatively, set "update-policy local;" on your parent zone and use this
little pipeline on the master server. Substitute $parent and $child as
necessary:
Bill Owens wrote:
>
> However, in this case I believe your problem is the lack of NS records
> in nau.edu for extended.nau.edu. It's difficult to know for sure, but it
> appears that the only signature for the NS RRSET is using the ZSK for
> extended.nau.edu, not the ZSK for nau.edu.
This is norm
On 10/01/11 04:54, Bill Owens wrote:
On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
In our initial implementation of DNSSEC, we chose to try out the
"auto" functionalities in version 9.8.0 P4 ie. using "auto-dnssec
maintain" in all master zones.
When going live, we found t
On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> In our initial implementation of DNSSEC, we chose to try out the "auto"
> functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> all master zones.
>
> When going live, we found that though all zones that we a
On Fri, Sep 30, 2011 at 6:16 PM, Hauke Lampe wrote:
> Aside from the missing DS, I don't see why BIND complains about the
> NXDOMAIN response at first and then returns that cached record set in
> response to later queries for the same name. dig +sigchase validates it,
> if provided with the nau.e
On 01.10.2011 02:48, Jeff Reasoner wrote:
> Hmm, I see an A record using the same query:
> [foo@dns1 ~]$ dig +dnssec extended.nau.edu a
I get a SERVFAIL response for the first query and NXDOMAIN for
subsequent request:
named: client 127.0.0.1#54707: query: extended.nau.edu IN A +ED (127.0.0.1)
na
On Fri, Sep 30, 2011 at 08:48:56PM -0400, Jeff Reasoner wrote:
> Hmm, I see an A record using the same query:
Interesting. . . my validating resolver (also 9.8.1) will only give me an A if
I ask with +cd. And if I follow that query with another, without the +cd, I get
SERVFAIL; then re-querying
Hmm, I see an A record using the same query:
[foo@dns1 ~]$ dig +dnssec extended.nau.edu a
; <<>> DiG 9.8.1 <<>> +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13732
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITI
On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> In our initial implementation of DNSSEC, we chose to try out the "auto"
> functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> all master zones.
>
> When going live, we found that though all zones that we a
In our initial implementation of DNSSEC, we chose to try out the "auto"
functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
all master zones.
When going live, we found that though all zones that we are acting as
master for would populate their own DS records, but there would be
16 matches
Mail list logo