Re: DNSSEC not populating parent zone files with DS records
Raymond Drew Walker ray.wal...@nau.edu 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 just worked (circa the early 90's.) I mistakenly inherited on this understanding... until now. There's a note about this in the BIND ARM documentation for stub zones: Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in named.conf. This usage is not recommended for new configurations, and BIND 9 supports it only in a limited way. In BIND 4/8, zone transfers of a parent zone included the NS records from stub children of that zone. This meant that, in some cases, users could get away with configuring child stubs only in the master server for the parent zone. BIND 9 never mixes together zone data from different zones in this way. Therefore, if a BIND 9 master serving a parent zone has child stub zones configured, all the slave servers for the parent zone also need to have the same child stub zones configured. As for better automation of DNSSEC, my research lends little to no information on proper child/parent DS record population. I am curious about how to properly deploy in the future. It's hard. There is deliberately very little coupling between a child zone and its parent, which is good because it makes the DNS more robust, but bad because you have to use out-of-band and often manual procedures to keep the zone's delegation in sync. This is true whether or not you have DNSSEC. If you run both the child and parent zones then dnssec-signzone can be told to manage DS records automatically: it generates dsset files when signing a child zone, and inserts DS records when signing a parent zone based on those dsset files. Sadly auto-dnssec doesn't do this. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger, Fisher: Westerly veering northwesterly 6 to gale 8, occasionally 5 at first in South Utsire. Moderate or rough in Cromarty, Forth and Tyne, otherwise rough or very rough. Squally showers. Moderate or good, occasionally poor at first in Fisher. ___ 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 not populating parent zone files with DS records
-Original Message- From: Tony Finch d...@dotat.at Date: Tue, 4 Oct 2011 20:30:43 +0100 To: Raymond Walker ray.wal...@nau.edu Cc: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: DNSSEC not populating parent zone files with DS records Raymond Drew Walker ray.wal...@nau.edu 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/^/update add /'; echo send) | nsupdate -l Thanks much, this makes much more sense. Am I also missing somewhere in the RFC where NS records of children zones need be populated in the parent? Is this something that has changed with the addition of DNSSEC? No, it has always been an error. See RFC 2181 section 6. DNSSEC just makes the breakage more obvious. 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 just worked (circa the early 90's.) I mistakenly inherited on this understanding... until now. As for better automation of DNSSEC, my research lends little to no information on proper child/parent DS record population. I am curious about how to properly deploy in the future. My assumptions are the following: -Sign a zone, then insert it's corresponding DS data into it's parent by hand (nsupdate). -Keep track of update DS record data on a regular schedule. Potentially via nsupdate, by deleting all DS record data in the parent zone for said child, then inserting new DS records. Yikes, I was hoping auto-dnssec would handle these tasks. ;) Am I missing any elegant solutions? Much thanks to the list for their insightful comments... Raymond Walker Software Systems Engineer Sr. ITS Northern Arizona University ___ 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 not populating parent zone files with DS records
-Original Message- From: Tony Finch d...@dotat.at Date: Mon, 3 Oct 2011 14:59:38 +0100 To: Michael Sinatra mich...@rancid.berkeley.edu Cc: ow...@nysernet.org, bind-users@lists.isc.org, Raymond Walker ray.wal...@nau.edu Subject: Re: DNSSEC not populating parent zone files with DS records Michael Sinatra mich...@rancid.berkeley.edu 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: dig +noall +answer dnskey $child | dnssec-dsfromkey -f /dev/stdin $child | (echo zone $parent; sed 's/^/update add /'; echo send) | nsupdate -l In testing, this pipe sets up the following for nsupdate which fails: zone nautest.edu update add test3.nautest.edu. IN DS 35113 5 1 4D27C35B0F638218659F740252604980CE445F16 update add test3.nautest.edu. IN DS 35113 5 2 843544D4F01EE147257FBDB92D9AC3C51129DEF0FC7D972D57EB6E20 550E4161 Send The error is: ttl 'IN': not a valid number syntax error 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. Am I also missing somewhere in the RFC where NS records of children zones need be populated in the parent? Is this something that has changed with the addition of DNSSEC? Raymond Walker Software Systems Engineer Sr. ITS Northern Arizona University ___ 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 not populating parent zone files with DS records
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, then re-sign the zone (or add it with nsupdate, or however you put records into the nau.edu zone). Am I also missing somewhere in the RFC where NS records of children zones need be populated in the parent? Is this something that has changed with the addition of DNSSEC? AFAIK that's always been the case; RFC1034 references it: As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. Bill. ___ 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 not populating parent zone files with DS records
Raymond Drew Walker ray.wal...@nau.edu 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/^/update add /'; echo send) | nsupdate -l Am I also missing somewhere in the RFC where NS records of children zones need be populated in the parent? Is this something that has changed with the addition of DNSSEC? No, it has always been an error. See RFC 2181 section 6. DNSSEC just makes the breakage more obvious. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fisher: Southwesterly 5 to 7, occasionally gale 8. Rough or very rough. Showers then rain. Moderate or good. ___ 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 not populating parent zone files with DS records
Bill Owens ow...@nysernet.org 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 normal. DNSSEC does not sign delegation RRsets (NS records and glue A and records) because they are part of the child zone. DS records are special because although they live at the name of the child zone, they are considered part of the parent zone and are therefore signed by the parent, which forms a link in the chain of trust. For example, DiG 9.9.0a2 +dnssec ns cam.ac.uk. @ns0.ja.net. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1490 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;cam.ac.uk. IN NS ;; AUTHORITY SECTION: cam.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS authdns0.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS dns1.cl.cam.ac.uk. cam.ac.uk. 86400 IN NS bitsy.mit.edu. cam.ac.uk. 86400 IN NS ns2.ic.ac.uk. cam.ac.uk. 86400 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 86400 IN NS dns0.cl.cam.ac.uk. cam.ac.uk. 86400 IN DS 5998 5 1 4FC806508D1FA1FE40AAF366A9180E052331D574 cam.ac.uk. 86400 IN DS 5998 5 2 B398A3523E2D6A10C0C3B349FA7AD0639551950F2FBD9E82A6B69370 C2725548 cam.ac.uk. 86400 IN RRSIG DS 8 3 86400 20111029080710 20110929080710 20880 ac.uk. PjKjwnwTrMin9srEn5t+2LZhwRzndokxJit/0339LhaGhtrB7Mr7Jo5M 5D2nqYdJr2oo7LXIN90p1RLitHVQrP05B6G8jyjJZJhPB6UlWMfvdIuQ k+FClgxnvWLBraXLdVWGmrMbp08i63KoYnBbtWOJEmts9CPnKMXLOtji 1K8= ;; ADDITIONAL SECTION: ns2.ic.ac.uk. 86400 IN A 155.198.142.82 dns0.cl.cam.ac.uk. 86400 IN A 128.232.0.19 dns0.eng.cam.ac.uk. 86400 IN A 129.169.8.8 dns1.cl.cam.ac.uk. 86400 IN A 128.232.0.18 authdns0.csx.cam.ac.uk. 86400 IN A 131.111.8.37 authdns0.csx.cam.ac.uk. 86400 IN 2001:630:212:8::d:a0 authdns1.csx.cam.ac.uk. 86400 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 86400 IN 2001:630:212:12::d:a1 ;; Query time: 4 msec ;; SERVER: 2001:630:0:9::14#53(2001:630:0:9::14) ;; WHEN: Mon Oct 3 14:25:26 2011 ;; MSG SIZE rcvd: 601 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North Utsire: Southerly veering southwesterly 6 to gale 8, occasionally severe gale 9 at first in northwest Viking. Moderate or rough becoming very rough or high. Rain then squally showers. Moderate or good, occasionally poor. ___ 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 not populating parent zone files with DS records
Michael Sinatra mich...@rancid.berkeley.edu 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: dig +noall +answer dnskey $child | dnssec-dsfromkey -f /dev/stdin $child | (echo zone $parent; sed 's/^/update add /'; echo send) | nsupdate -l Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin: Southwesterly 7 to severe gale 9, occasionally storm 10 at first in northeast Rockall, decreasing 5 or 6 later. Very rough or high, occasionally very high at first in north Rockall. Squally showers. Moderate or poor, occasionally good. ___ 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 not populating parent zone files with DS records
On Fri, Sep 30, 2011 at 6:16 PM, Hauke Lampe la...@hauke-lampe.de 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.edu DNSKEY: The issue can be seen by querying the authoritative source, rather than what the resolver returns. As someone posted earlier, the cause of the issue is the lack of NS RRs for extended.nau.edu in the nau.edu zone. Prior to DNSSEC deployment this wasn't really an issue (even though it was certainly a misconfiguration) if all the authoritative servers for the parent zone were also authoritative for the child zone. In this case the parent authoritative servers knew and could properly respond with the NS RRs. However, the DS RR is a new beast, and even though it carries the name of the child zone (e.g., extended.nau.edu), the parent zone (e.g., nau.edu) answers authoritatively for that record type. So when querying for DS vs. other record types the responses are different: $ dig @ns1.nau.edu extended.nau.edu ds | grep status ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 39613 $ dig @ns1.nau.edu extended.nau.edu ns | grep status ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28073 DS queries in this case result in NXDOMAIN for the name because the parent zone has no records of that name (because of the lack of NS RRs for the child). NS records, however, return NOERROR because the response comes from the child zone which has records of that name. The resolver returns inconsistent responses based on its configuration (validation, which causes querying for DS RRs) and the state of its cache. The lack of NS RRs in the parent is also shown in the DNSViz output for extended.nau.edu: http://dnsviz.net/d/extended.nau.edu/dnssec/ Regards, Casey ___ 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 not populating parent zone files with DS records
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 are acting as master for would populate their own DS records, but there would be no population of a child zone's DS record in the corresponding parent master zone file. The ARM for 9.8.1 has this to say about dnssec-signzone: Any keyset files corresponding to secure subzones should be present. The zone signer will generate NSEC, NSEC3 and RRSIG records for the zone, as well as DS for the child zones if '-g' is specified. If '-g' is not specified, then DS RRsets for the secure child zones need to be added manually. I take that to mean that if I have a pair of zones served by the same master, dnssec-signzone will figure out the relationship and install DS records in the parent zone. However, that assumes two things - that both zones are on the same master (as seems to be the case for you), and that there are NS records in the parent to provide a delegation point (which doesn't seem to be true for nau.edu and extended.nau.edu, at least). I couldn't tell whether this also applies to auto-dnssec; either the ARM doesn't say or I missed it ;) We have since backed out DNSSEC until we can get a resolution of the issue. Incidentally, you haven't - you're still serving a signed zone for nau.edu and extended.nau.edu, which causes the problems noted in the other responses to your original note. I think you could fix it very quickly though, by adding the NS records to the nau.edu zone. Bill. ___ 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 not populating parent zone files with DS records
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 that though all zones that we are acting as master for would populate their own DS records, but there would be no population of a child zone's DS record in the corresponding parent master zone file. The ARM for 9.8.1 has this to say about dnssec-signzone: Any keyset files corresponding to secure subzones should be present. The zone signer will generate NSEC, NSEC3 and RRSIG records for the zone, as well as DS for the child zones if '-g' is specified. If '-g' is not specified, then DS RRsets for the secure child zones need to be added manually. I take that to mean that if I have a pair of zones served by the same master, dnssec-signzone will figure out the relationship and install DS records in the parent zone. However, that assumes two things - that both zones are on the same master (as seems to be the case for you), and that there are NS records in the parent to provide a delegation point (which doesn't seem to be true for nau.edu and extended.nau.edu, at least). I couldn't tell whether this also applies to auto-dnssec; either the ARM doesn't say or I missed it ;) I am pretty sure that it doesn't, at least not in 9.8.1. There's no place to specify the location of the dsset or keyset files in named.conf, and that's what the signer process needs to insert the DS records. When I put dsset files in the parent zone's directory with the key files and did 'rndc sign', the DS records still didn't get automagically put in. There are ways of getting the DS records into the zone(s). Here are some steps that I took on some test zones: 0. First, I made sure there were proper delegation NS records in the parent zone(s)! 1. Ensure that there are no pending dynamic updates and run 'rndc freeze'. 2. Create a central directory to hold the keyset and dsset files. I used /var/named/etc/namedb/master/signed-zonefiles/keysets on a FreeBSD system with named running in a chroot environment. 3. Assuming keys have already been generated, run the following command in the *child* zones first, substituting sub1.gost.radiofreebeer.net for your child zone and substituting 'zone.db.signed' for the signed version of the zone that named is configured to read on startup: /usr/sbin/dnssec-signzone -C -g -p -d /var/named/etc/namedb/master/signed-zonefiles/keysets -o sub1.gost.radiofreebeer.net. -e +518400 -N unixtime zone.db.signed K*.private This will produce zone.db.signed.signed. NOTE that this assumes that each zone has its own directory with its keys in that directory (and no other zone's keys). 4. Then run the same command on any parent of any signed zone, *after* you have run the command on the signed child zone. 5. For every *parent* zone, you will need to 'mv zone.db.signed.signed zone.db.signed' so that the version with the DS records will go into production. This is only necessary with parent zones, but it can also be done on the child zones just to keep things clean. 6. 'rndc thaw' You can also use a signing tool like zkt, which will basically generate all of the keys and do the DSification of parent zones automatically. There are other features of tools like zkt and opendnssec that auto-dnssec can't (yet) do, such as key rollovers. auto-dnssec will do rollovers, once the keys with proper activation and inactivation dates have been created. But something else needs to generate the keys, set the metadata according to a policy defined by the administrator, and remove stale keys so that auto-dnssec can do its work. As far as I can tell, there isn't yet an auto-dnssec-savvy tool that can handle these tasks so it needs to be custom-scripted. We have since backed out DNSSEC until we can get a resolution of the issue. Incidentally, you haven't - you're still serving a signed zone for nau.edu and extended.nau.edu, which causes the problems noted in the other responses to your original note. I think you could fix it very quickly though, by adding the NS records to the nau.edu zone. Bill's right--this needs to be fixed right away. michael ___ 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 not populating parent zone files with DS records
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 are acting as
master for would populate their own DS records, but there would be no
population of a child zone's DS record in the corresponding parent master
zone file.
This means upon go-live, any DNSSEC validation of our children zones
(X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
(nau.edu) would validate fine.
We have since backed out DNSSEC until we can get a resolution of the issue.
After much research, I'm not sure why this is happening... Any suggestions
or ideas?
I think there's something else going on here. If you have DNSKEY records in the
child but no DS in the parent, everything should still be okay - there's no
chain of trust, but there's also no assertion from the parent that there
*should be* a chain of trust (that's what the DS record does).
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.
In the olden days you could get away with that since the same servers are
authoritative for both zones, and they'd answer correctly. In the new world of
DNSSEC, if you ask for extended.nau.edu, you get this:
paperboy {owens}% dig +dnssec extended.nau.edu a
; DiG 9.9.0a2 +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 60942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu. IN A
;; AUTHORITY SECTION:
ewb.nau.edu.10199 IN RRSIG NSEC 5 3 86400 20111019222812
20110919220129 7485 nau.edu.
SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U
VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV
00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
ewb.nau.edu.10199 IN NSECfacdevnet.nau.edu. CNAME RRSIG
NSEC
nau.edu.10199 IN SOA ns3.nau.edu.
DNS-Contact.nau.edu. 4779 1800 900 604800 86400
nau.edu.10199 IN RRSIG SOA 5 2 86400 20111030191258
20110930181258 7485 nau.edu.
xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9
fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI
G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
nau.edu.10199 IN RRSIG NSEC 5 2 86400 20111020001752
20110919233312 7485 nau.edu.
GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP
/JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk
UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
nau.edu.10199 IN NSEC_tcp.nau.edu. A NS SOA MX TXT
RRSIG NSEC DNSKEY TYPE65534
No records, so no delegation, so nowhere to go to get the A record (which is
actually configured).
As for BIND automatically populating DS records, I don't even know whether
that's a feature. Is it in the docs? I don't remember seeing it, but it's a big
manual and I might have missed that reference. . .
Bill.
___
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 not populating parent zone files with DS records
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, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu. IN A
;; ANSWER SECTION:
extended.nau.edu. 86349 IN A 134.114.104.140
extended.nau.edu. 86349 IN RRSIG A 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
Oa5g4Nla0O4T2yUIwsKU17VacHWDGLg1ElTKxunftZDcXhiRhH4jwoe8
IWcLdKQ/6VRE9JikTo5MOqV/PbXH+6yzBSzfzmJKP0+KAW6KnNRhETmL
B60UHJmqpWZC8VoV1FOZ2Ma54dSXsw0HKaTksJ1ubGILeWMNb5C1TTrK bzc=
;; AUTHORITY SECTION:
extended.nau.edu. 86349 IN NS ns3.nau.edu.
extended.nau.edu. 86349 IN NS ns2.nau.edu.
extended.nau.edu. 86349 IN NS ns1.nau.edu.
extended.nau.edu. 86349 IN RRSIG NS 5 3 86400 20111019233054
20110919230651 36030 extended.nau.edu.
E8Q9Db8ncNOVdw0cdlHT2iY3SYkdBtPsGP2Xmacn95Br8pxe0Y5Hq3fZ
k0b/v6D872DcmELDcVliOGbNPNLxm2rtl3CG3QjcOr4qUZjQDTqnApgZ KfJ
+V2RUEd0LqcF1PAPmHOn8c/TkBq1m9ir29N77k/x5WW8seRwyRvcD iEU=
;; Query time: 1 msec
;; SERVER: 10.241.0.10#53(10.241.0.10)
;; WHEN: Fri Sep 30 20:42:38 2011
;; MSG SIZE rcvd: 467
On Fri, 2011-09-30 at 19:56 -0400, 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 that though all zones that we are acting as
master for would populate their own DS records, but there would be no
population of a child zone's DS record in the corresponding parent master
zone file.
This means upon go-live, any DNSSEC validation of our children zones
(X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
(nau.edu) would validate fine.
We have since backed out DNSSEC until we can get a resolution of the issue.
After much research, I'm not sure why this is happening... Any suggestions
or ideas?
I think there's something else going on here. If you have DNSKEY records in
the child but no DS in the parent, everything should still be okay - there's
no chain of trust, but there's also no assertion from the parent that there
*should be* a chain of trust (that's what the DS record does).
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.
In the olden days you could get away with that since the same servers are
authoritative for both zones, and they'd answer correctly. In the new world
of DNSSEC, if you ask for extended.nau.edu, you get this:
paperboy {owens}% dig +dnssec extended.nau.edu a
; DiG 9.9.0a2 +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 60942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu.IN A
;; AUTHORITY SECTION:
ewb.nau.edu. 10199 IN RRSIG NSEC 5 3 86400 20111019222812
20110919220129 7485 nau.edu.
SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U
VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV
00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
ewb.nau.edu. 10199 IN NSECfacdevnet.nau.edu. CNAME RRSIG
NSEC
nau.edu. 10199 IN SOA ns3.nau.edu.
DNS-Contact.nau.edu. 4779 1800 900 604800 86400
nau.edu. 10199 IN RRSIG SOA 5 2 86400 20111030191258
20110930181258 7485 nau.edu.
xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9
fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI
G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
nau.edu. 10199 IN RRSIG NSEC 5 2 86400 20111020001752
20110919233312 7485 nau.edu.
GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP
/JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk
UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
nau.edu. 10199 IN NSEC_tcp.nau.edu. A NS SOA MX TXT
RRSIG NSEC DNSKEY TYPE65534
No records, so no delegation, so nowhere to go to get the A record (which is
actually configured).
As for BIND automatically populating DS records, I don't even know whether
that's a feature. Is it in the docs? I don't remember seeing it, but it's a
big manual and I might have missed that reference. . .
Bill.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
Re: DNSSEC not populating parent zone files with DS records
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 with +cd gives NXDOMAIN. Do you have validation enabled as well? Bill. ___ 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 not populating parent zone files with DS records
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) named: createfetch: extended.nau.edu A named: createfetch: extended.nau.edu DNSKEY named: createfetch: extended.nau.edu DS named: createfetch: nau.edu DNSKEY named: createfetch: nau.edu DS named: createfetch: edu DNSKEY named: createfetch: nau.edu.dlv.isc.org DLV named: validating @0x7f36f7f17680: nau.edu SOA: no valid signature found named: validating @0x7f36f7eed410: nau.edu NSEC: no valid signature found named: validating @0x7f36f7eed410: ewb.nau.edu NSEC: no valid signature found named: error (broken trust chain) resolving 'extended.nau.edu/DNSKEY/IN': 134.114.138.3#53 named: error (broken trust chain) resolving 'extended.nau.edu/A/IN': 134.114.96.4#53 named: client 127.0.0.1#54707: query failed (SERVFAIL) for extended.nau.edu/IN/A at query.c:6302 named: client 127.0.0.1#55872: query: extended.nau.edu IN A +ED (127.0.0.1) Unbound resolves the record on the first try. 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.edu DNSKEY: nau.edu. 86400 IN SOA ns3.nau.edu. DNS-Contact.nau.edu. 4779 1800 900 604800 86400 nau.edu. 86400 IN RRSIG SOA 5 2 86400 20111030191258 20110930181258 7485 nau.edu. xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc= nau.edu. 86400 IN NSEC_tcp.nau.edu. A NS SOA MX TXT RRSIG NSEC DNSKEY TYPE65534 nau.edu. 86400 IN RRSIG NSEC 5 2 86400 20111020001752 20110919233312 7485 nau.edu. GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP /JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk= ewb.nau.edu. 86400 IN NSECfacdevnet.nau.edu. CNAME RRSIG NSEC ewb.nau.edu. 86400 IN RRSIG NSEC 5 3 86400 20111019222812 20110919220129 7485 nau.edu. SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs= ;; Received 710 bytes from 134.114.96.4#53(134.114.96.4) in 189 ms Hauke. signature.asc Description: OpenPGP digital 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
