Re: Does anyone have DNSSEC problem with uscg.mil
Not at this moment : $ dig @8.8.8.8 mx uscg.mil. +dnssec ; DiG 9.8.4-rpz2+rl005.12-P1 @8.8.8.8 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 42506 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;uscg.mil. IN MX ;; ANSWER SECTION: uscg.mil. 8478IN MX 40 smtp-gateway-4.uscg.mil. uscg.mil. 8478IN MX 40 smtp-gateway-4a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2.uscg.mil. uscg.mil. 8478IN MX 20 smtp-gateway-5a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-1.uscg.mil. uscg.mil. 8478IN MX 20 smtp-gateway-5.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-1a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2a.uscg.mil. uscg.mil. 8478IN RRSIG MX 7 2 86400 20131118074336 20131113074105 53369 uscg.mil. F... Observe : AD bit set. Kind regards, On Thu, Nov 14, 2013 at 7:00 PM, Khuu, Linh Contractor linh.k...@ssa.govwrote: Hi, Does anyone have any DNSSEC problem with uscg.mil. On our DNS servers, we have seen broken trust chain error and the validation failed. 14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.573 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.658 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.743 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: in authvalidated 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: authvalidated: got broken trust chain 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: resuming nsecvalidate 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: starting 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: attempting positive response validation 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: in fetch_callback_validator 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: fetch_callback_validator: got failure 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: starting 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: attempting positive response validation 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: in fetch_callback_validator 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: fetch_callback_validator: got failure Thanks, Linh Khuu Network Security Specialist Northrop Grumman IS | Civil Systems Division (CSD) Office: 410-965-0746 Pager: 443-847-7551 Email: linh.k...@ssa.gov ___ 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: Does anyone have DNSSEC problem with uscg.mil
And the name server 199.211.218.6 does not seem lame either : $ dig @199.211.218.6 mx uscg.mil. +dnssec ; DiG 9.8.4-rpz2+rl005.12-P1 @199.211.218.6 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 61958 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 Observe : AA bit set, 10 answers. Kind regards, On Thu, Nov 14, 2013 at 7:00 PM, Khuu, Linh Contractor linh.k...@ssa.govwrote: Hi, Does anyone have any DNSSEC problem with uscg.mil. On our DNS servers, we have seen broken trust chain error and the validation failed. 14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.573 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.658 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.743 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: in authvalidated 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: authvalidated: got broken trust chain 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: resuming nsecvalidate 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: starting 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: attempting positive response validation 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: in fetch_callback_validator 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: fetch_callback_validator: got failure 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: starting 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: attempting positive response validation 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: in fetch_callback_validator 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: fetch_callback_validator: got failure Thanks, Linh Khuu Network Security Specialist Northrop Grumman IS | Civil Systems Division (CSD) Office: 410-965-0746 Pager: 443-847-7551 Email: linh.k...@ssa.gov ___ 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: Does anyone have DNSSEC problem with uscg.mil
Hello, dnsstuff.com gives me all green for DNSSEC of uscg.mil. dnsviz.net gives warnings (not : errors) on all RRSIG's - something with TTL values. What is odd - but should not be fatal - is that uscg.mil authoritative name servers send replies with strange TTL values. 1) uscg.mil. 77481 IN MX 40 smtp-gateway-4.uscg.mil. 2) uscg.mil. 77439 IN MX 40 smtp-gateway-4.uscg.mil. -- TTL is decreasing for that RR (strangely enough, TTL does not decrease for other RR's in the RRset, and consequently : different the one shown above) Now the RRSIG over the MX RRset says the TTL in the zone file is 86400 : uscg.mil. 80850 IN RRSIG MX 7 2 86400 ... Although weird : 1) TTL values of all RR's in the RRset should be identical 2) the authoritative name server partly behaves like it were replying from cache these abnormalities should not be fatal, in my opinion. I wonder what kind of name servers uscg.mil uses ? Kind regards, On Thu, Nov 14, 2013 at 7:22 PM, Khuu, Linh Contractor linh.k...@ssa.govwrote: *Hi Marc,* *Yes, on my DNS server, if I do a dig @8.8.8.8 http://8.8.8.8, I got answer (with AD bit set). I also do a dig @pac1.nipr.mil http://pac1.nipr.mil, I got answer (with AA bit set).* *However, when I do dig @localhost, that is where I don’t get any result at all.* *All the DNSSEC tools out there, like dnsviz.net http://dnsviz.net, dnsstuff.com http://dnsstuff.com, dnscheck.iis.se http://dnscheck.iis.se, they all show DNSSEC error for uscg.mil http://uscg.mil.* *Linh KhuuNetwork Security SpecialistNorthrop Grumman IS | Civil Systems Division (CSD)Office: 410-965-0746 410-965-0746Pager: 443-847-7551 443-847-7551Email: linh.k...@ssa.gov linh.k...@ssa.gov* *From:* Marc Lampo [mailto:marc.lampo.i...@gmail.com] *Sent:* Thursday, November 14, 2013 1:16 PM *To:* Khuu, Linh Contractor *Cc:* Bind Users Mailing List *Subject:* Re: Does anyone have DNSSEC problem with uscg.mil Not at this moment : $ dig @8.8.8.8 mx uscg.mil. +dnssec ; DiG 9.8.4-rpz2+rl005.12-P1 @8.8.8.8 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 42506 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;uscg.mil. IN MX ;; ANSWER SECTION: uscg.mil. 8478IN MX 40 smtp-gateway-4.uscg.mil . uscg.mil. 8478IN MX 40 smtp-gateway-4a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2.uscg.mil . uscg.mil. 8478IN MX 20 smtp-gateway-5a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-1.uscg.mil . uscg.mil. 8478IN MX 20 smtp-gateway-5.uscg.mil . uscg.mil. 8478IN MX 10 smtp-gateway-1a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2a.uscg.mil. uscg.mil. 8478IN RRSIG MX 7 2 86400 20131118074336 20131113074105 53369 uscg.mil. F... Observe : AD bit set. Kind regards, On Thu, Nov 14, 2013 at 7:00 PM, Khuu, Linh Contractor linh.k...@ssa.gov wrote: Hi, Does anyone have any DNSSEC problem with uscg.mil. On our DNS servers, we have seen broken trust chain error and the validation failed. 14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.573 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.658 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.743 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: in authvalidated 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: authvalidated: got broken trust chain 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: resuming nsecvalidate 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: starting 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: attempting positive response validation 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: in fetch_callback_validator 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: fetch_callback_validator: got failure 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: starting 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: attempting positive response validation 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX
Re: Does anyone have DNSSEC problem with uscg.mil
Interesting - like other respondent already observed : with or without AD flag set ? Anyhow, I redid the query with a validating Bind 9.8 in the office : $ dig @127.0.0.1 mx uscg.mil. +dnssec ; DiG 9.8.4-rpz2+rl005.12-P1 @127.0.0.1 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4486 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 Observe : AD bit set, 10 answers (and no warnings in the name server log file) Kind regards, On Thu, Nov 14, 2013 at 10:29 PM, Kevin Oberman rkober...@gmail.com wrote: On Thu, Nov 14, 2013 at 11:19 AM, Marc Lampo marc.lampo.i...@gmail.comwrote: Hello, dnsstuff.com gives me all green for DNSSEC of uscg.mil. dnsviz.net gives warnings (not : errors) on all RRSIG's - something with TTL values. What is odd - but should not be fatal - is that uscg.mil authoritative name servers send replies with strange TTL values. 1) uscg.mil. 77481 IN MX 40 smtp-gateway-4.uscg.mil. 2) uscg.mil. 77439 IN MX 40 smtp-gateway-4.uscg.mil. -- TTL is decreasing for that RR (strangely enough, TTL does not decrease for other RR's in the RRset, and consequently : different the one shown above) Now the RRSIG over the MX RRset says the TTL in the zone file is 86400 : uscg.mil. 80850 IN RRSIG MX 7 2 86400 ... Although weird : 1) TTL values of all RR's in the RRset should be identical 2) the authoritative name server partly behaves like it were replying from cache these abnormalities should not be fatal, in my opinion. I wonder what kind of name servers uscg.mil uses ? Kind regards, On Thu, Nov 14, 2013 at 7:22 PM, Khuu, Linh Contractor linh.k...@ssa.gov wrote: *Hi Marc,* *Yes, on my DNS server, if I do a dig @8.8.8.8 http://8.8.8.8, I got answer (with AD bit set). I also do a dig @pac1.nipr.mil http://pac1.nipr.mil, I got answer (with AA bit set).* *However, when I do dig @localhost, that is where I don’t get any result at all.* *All the DNSSEC tools out there, like dnsviz.net http://dnsviz.net, dnsstuff.com http://dnsstuff.com, dnscheck.iis.se http://dnscheck.iis.se, they all show DNSSEC error for uscg.mil http://uscg.mil.* *Linh Khuu Network Security SpecialistNorthrop Grumman IS | Civil Systems Division (CSD)Office: 410-965-0746 410-965-0746Pager: 443-847-7551 443-847-7551 Email: linh.k...@ssa.gov linh.k...@ssa.gov* *From:* Marc Lampo [mailto:marc.lampo.i...@gmail.com] *Sent:* Thursday, November 14, 2013 1:16 PM *To:* Khuu, Linh Contractor *Cc:* Bind Users Mailing List *Subject:* Re: Does anyone have DNSSEC problem with uscg.mil Not at this moment : $ dig @8.8.8.8 mx uscg.mil. +dnssec ; DiG 9.8.4-rpz2+rl005.12-P1 @8.8.8.8 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 42506 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;uscg.mil. IN MX ;; ANSWER SECTION: uscg.mil. 8478IN MX 40 smtp-gateway-4.uscg.mil. uscg.mil. 8478IN MX 40 smtp-gateway-4a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2.uscg.mil. uscg.mil. 8478IN MX 20 smtp-gateway-5a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-1.uscg.mil. uscg.mil. 8478IN MX 20 smtp-gateway-5.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-1a.uscg.mil. uscg.mil. 8478IN MX 10 smtp-gateway-2a.uscg.mil. uscg.mil. 8478IN RRSIG MX 7 2 86400 20131118074336 20131113074105 53369 uscg.mil. F... Observe : AD bit set. Kind regards, On Thu, Nov 14, 2013 at 7:00 PM, Khuu, Linh Contractor linh.k...@ssa.gov wrote: Hi, Does anyone have any DNSSEC problem with uscg.mil. On our DNS servers, we have seen broken trust chain error and the validation failed. 14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.573 lame-servers: error (broken trust chain) resolving 'uscg.mil/A/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.658 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:57:37.743 lame-servers: error (broken trust chain) resolving 'uscg.mil/MX/IN': 199.211.218.6#53 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: in authvalidated 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: authvalidated: got broken trust chain 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: uscg.mil: resuming nsecvalidate 14-Nov
Re: Forwarding requests when DNS name doesn't exist?
An unwise decision, from security point of view ! You are about to open the DNS channel - public DNS resolving available for internal clients. Consequently data leakage, file transfer in/out over DNS become possible ... As far as the question about internal fake zones is concerned : if the name server has knowledge, because it is authoritative, it will use that knowledge and will not try to query name servers on the Internet. It becomes bogus for that zone : no delegation, but having knowledge. Kind regards, Marc On Thu, Oct 10, 2013 at 10:28 AM, Peter Olsson p...@leissner.se wrote: (This is probably a silly question, but I want to explore every possibility.) We have a proxy firewall, with no contact between inside and outside. We have a fake internal DNS root for zones that we use internally. This works fine, since lookup of external names are only made from the outside of the proxy servers. We are about to change to a transparent firewall, which means that we remove the proxy servers. Then we have to let the inside get access to real outside DNS. Is there any way with bind, or any other DNS product, to keep our internal fake zones and have them selectively forwarded to external DNS for all names that don't exist in the internal fake zones? Clients would first ask internal DNS, and if the name exists there they will use that, but if the name doesn't exist internally they won't get a negative response. Instead their request would be forwarded to external DNS. Thanks! Peter Olsson ___ 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: adding DS record via nsupdate
Precisely ! That is why one of the sanity checks is if NS records exist at all. If not, no DS records will be added. And reversely : if all NS records are removed, any DS record will be removed as well. Just as Mark Andrews indicated. Kind regards, Marc Lampo On Wed, Feb 6, 2013 at 9:59 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 02/06/2013 12:56 AM, Doug Barton wrote: I do the following as an example: nsupdate -d server ip addr zone test.net update add subzone.test.net IN DS 34845 7 1 325AA7B83FAC7DB621678EB2FB9035B51A0A504F I don't think this makes sense. Shouldn't you have a proper zone for subzone.test.net? What utility would a DS record have in this location? Eh? DS records always live in the parent zone, exactly like delegating NS records. ___ 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: DNSSEC for NS delegation record
Hello, (the easiest way) 1) The admins of sub1.testing.net. should generate ZSK and KSK. à The parent cannot do this for the child 2) You do not need the key file*s* of the child, in the parent. If, by using the plural form, you mean both public (.key) and private (.private) file. 3) The easiest way : using the bind tools (and this is the bind mailing list) the child will find a dsset- file after signing its zone à the parent can include *this* file in its testing.net zone Alternatively : The child can provide the public part of the KSK and, using the bind tool dnssec-dsfromkey the parent can obtain the DS records itself. 4) How to include : you are already using $INCLUDE statements now, so, include the file with DS info, Id say. One additional comment : By signing the child sub1.testing.net. only, not much will happen, for DNSSEC. You need to complete the chain of trust by also signing the parent testing.net. - and having its DS information published in its parent net. ! Kind regards, Marc Lampo Security Officer EURid From: Khuu, Linh Contractor [mailto:linh.k...@ssa.gov] Sent: dinsdag 17 juli 2012 16:36 To: 'bind-users@lists.isc.org' Subject: DNSSEC for NS delegation record Hi, I have questions about how to configure the DNS with NS delegation record once its signed. My DNS server is the parent zone, for example, testing.net and is signed with DNSSEC. My zone configuration is as follows: $TTL 36000 $INCLUDE /var/named9/dnssec-testing/Ktesting.net..+007+32934.key ; key signing key $INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+46725.key ; zone signing key $INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+32367.key ; pre-published zone signing key @ IN SOA dns1.testing.net. root.testing.net. (2011031200 3600 600 1209600 14400) Testing.net. IN NS dns1.testing.net. Testing.net. IN NS dns2.testing.net. www IN A 168.168.168.168 access IN NS sub1.testing.net. As of right now, the sub1.testing.net isnt DNSSEC compliant yet. We want sub1.testing.net to be DNSSEC aware. My question is, do we (as parent of testing.net zone) need to generate the key (KSK) and zone key (ZSK) for the sub1.testing.net or should sub1.testing.net server will need to do that? If they generate the keys to sign all the records in their server, do they need to send us their key files? How do we (as parent) to include those keys in our zone file? Thanks, Linh Khuu ___ 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: BIND, DNSSEC AD
Hello, Yes, would be ideal … I understand you want to make the Windows DNS service “DNSSEC capable” (by feeding it KSK’s of domains that have the same name internally as externally). However : you are aware that Windows DNS service understands DNSSEC algorithm 5 (RSA/SHA-1 – NSEC) at most ? à since the root zone is already algo 8 (RSA/SHA-256) à since most tld’s are 7 or 8 and most with NSEC3 the Windows DNS service is going to treat most of DNSSEC’d name space as “unsigned” anyway … (another argument to switch to Bind, internally ?) Kind regards, Marc Lampo Security Officer EURid (for .eu) From: John Williams [mailto:john.1...@yahoo.com] Sent: 29 June 2012 04:53 PM To: Marc Lampo; bind-users@lists.isc.org Subject: Re: BIND, DNSSEC AD The purpose behind this is not to protect the internal AD DNS from hijacking. But rather to allow internal clients to run DNSSEC related queries without having to reference external resolvers. dig +dnssec somedomain By the way, integrating BIND into AD will not be permitted. The AD staff will not allow that. That would be ideal though. Thanks, JT _ From: Marc Lampo marc.la...@eurid.eu To: 'John Williams' john.1...@yahoo.com; bind-users@lists.isc.org Sent: Friday, June 29, 2012 3:07 AM Subject: RE: BIND, DNSSEC AD Hello, (not a Bind related question !) Last time I looked at Microsoft documentation I remember having seen that DNSSEC is for static files only, *not* for “Active Directory integrated” domains ! If that is still true, I think the question about importing keys is irrelevant … You would be needing Bind – from 9.7 onwards – for the DNS servers of the AD domains. Bind can do the trick (DNSSEC + dynamic updating). It would be sufficient to share the KSK, ZSK’s can be separate (as they are signed by the then shared KSK). But is the an internal AD domain really an plausible attack vector for hackers ? Kind regards, Marc Lampo Security Officer EURid (for .eu) From: John Williams [mailto:john.1...@yahoo.com] Sent: 28 June 2012 10:35 PM To: bind-users@lists.isc.org Subject: BIND, DNSSEC AD I have an environment that hosts a BIND based internet facing domain, call it abc.com http://abc.com/ . I also have an internal Active Directory instance that hosts a MS based DNS instance called abc.com as well. Everything works fine until we decided to implement DNSSEC on Active Directory. Here is my question, is it possible to integrate the two domains? Can I import the BIND DNSSEC keys into MS AD and build DNSSEC into AD using that method? Is there better method? I don't want to have AD DNS be my forward (Internet) facing application. Thanks. JT ___ 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: Truncated DNS message over UDP
Hello, Several RFC's on DNS do state that name servers (not only Bind) should avoid, if possible, to send messages that would require the TC bit set in the reply. Replies can be stay shorter if some sections (authority/additional) are not included in the reply. I know for sure that DNSSEC related RFC's explicitly state to leave authority/additional section empty if filling them would lead to the answer becoming too big and requiring the TC bit to be set. -- it is not a configuration setting, it's RFC defined. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: Sebastiano Di Paola [mailto:sebastiano.dipa...@gmail.com] Sent: 27 June 2012 10:43 AM To: bind-users@lists.isc.org Subject: Truncated DNS message over UDP Hello everyone, before sending this email I tried do some seaches on this topic, but no luck so far...so before bothering bind-workers here's my question I was wondering if a configuration option exists in order to force bind server to send a minimal (from size and number of returned record point of view) response in case the trucated bit is set in the header. Let me explain better... 1) Client asks for www.mydomain.com type ANY to my server (RD bit is set) 2) Server gets the response (does not matter if from cache or not) but the answer is bigger than 512 bytes (or the server has udp-max-size 512 parameter in configuration) 3) Server send answer with TC bit = 1, but instead of giving partial response header is like this QDCOUNT = 1, ANCOUNT = 0, NSCOUTN = 0, ADDITIONAL=0 (if there is no EDSN0 in query) and just sent back the question section. 4) Client (if needed) re-do the query using TCP (some clients does not use records contained in packets with TC bit set in the header) If I'm not wrong RFCs does not state that partial answer must be returned to the client, so probably there is no issue in getting rid of them (with a configuration option :) ) Is there any parameter that could let me achieve this result? Kind regards. Seba ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
Switch from NSEC to NSEC3 !!! This is a statement with potentially huge consequences, IMHO. Only valid where DNSSEC algorithms allow either method (like algo #8 and algo #10, unsure about others). For algorithm like #5, NSEC is implied. So suggesting that it is easy to switch (between NSEC and NSEC3), without mentioning the link with the algorithm without mentioning the consequences if chain-of-trust is established (and (DNSSEC) data might be cached out there) is probably not the right thing to do. (given recent contributions in this list that DNSSEC management is not easy ...) Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- ... (Also, if you want to switch to NSEC instead of NSEC3, you can use 'rndc signing -nsec3param none'.) -- 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: lists.isc.org rDNS failed, DNSSEC?
Please allow a, partly/mostly, non-technical feedback as security officer for a tld (.eu) First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Point taken, but let me come back on those later. The (non-technical) response : When I get in my car, I put my safety belt on. (I know some may point at undesired effects, and I do not want to have that discussion in this list), but the point is : I do hope I will never need the protection offered by the safety belt, but if, then I'll be happy I took the precaution. The similarity to DNSSEC is that we all hope we will not need the protection it offers, but if an attacker finds it interesting to attempt to exploit, I will be glad I took the precaution of activating DNSSEC. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. Does this mean we don't have to put the safety belt on ? I daresay : no. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. To conclude (some technical) suggestions : - when offering DNSSEC on authoritative name servers, try to rely on automation (like scripts). (rather than humans to type - and re-type - the same commands over and over) - allow yourself a period of testing. Do *not* immediately have DS information put in the parent zone (thus completing the chain-of-trust but also : making validation mandatory. After all : this is a *test* period) ((look how TLDs migrate towards DNSSEC. Exactly the same : first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) - and may I also plead for validation on caching/forwarding name servers ? Because it makes no sense to add signatures that can be validated to DNS replies, if the signatures are simply ignored. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: michoski [mailto:micho...@cisco.com] Sent: 24 February 2012 06:01 AM To: vinny_abe...@dell.com; kob6...@gmail.com; ma...@isc.org Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ 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: bind public/private domain question
Hello,
Are you letting your internal caching name server forward to an external
one ?
This is *dangerous* - cache poisoning attacks in this setup have
a higher chance of success than the scenario shown by Dan Kaminsky !
(the window of opportunity for success is *seconds*,
rather than fractions of seconds)
I strongly advice not to forward to external, caching name servers.
Or, if you do, also enable DNSSEC validation
(and forward to an external name server that is at least DNSSEC aware
- 8.8.8.8 is not, searches for DS records in the wrong place)
Kind regards,
Marc Lampo
Security Officer
EURid (for .eu)
-Original Message-
From: Marseglia, Michael [mailto:michael.marseg...@chartercare.org]
Sent: 21 February 2012 10:20 PM
To: bind-users@lists.isc.org
Subject: RE: bind public/private domain question
...
named.conf.options
options {
...
forwarders { 8.8.8.8; };
...
___
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: Efficacy of using short timeout values for an A record
More or less ! While I don't think it's a bug - I actually like the good feature ! - Bind does allow to change some values in replies to make them more reasonable. With respect to TTL, there are : max-ncache-ttl : max negative cache time (defaults to 3 hours - with built-in, not changeable, max of 7 days) and max-cache-ttl : max positive cache time (defaults to 7 days) (other values that can be corrected are max and min refresh and retry times, thus protecting a slave server from unreasonable values sent by the master. Recommended ! ) Kind regards, Marc Lampo Security Officer EURid (for the .eu tld) -Original Message- From: Alan Clegg [mailto:a...@clegg.com] Sent: 14 February 2012 08:11 PM To: bind-users@lists.isc.org Subject: Re: Efficacy of using short timeout values for an A record On 2/14/2012 1:42 PM, Chuck Swiger wrote: ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds. It's probably unreasonable to expect other platforms to refetch DNS records faster than that. Uh... no. BIND has always respected TTL when caching information. AlanC -- a...@clegg.com | 1.919.355.8851 ___ 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: which NS record will be cached?
Hello, The question is less about TTL, but rather credibility. The answer from the root name server are referrals - AA bit in reply is not set; The answer from ns2.google.com. is from an authoritative NS (has the AA bit set). The latter answer has credibility AUTH, which is the highest -- stored should be the answer from the authoritative NS And think one step further : what if the list of NS's in the parent (the root in this case) is different from the list of NS's at the domain level itself ? The danger here is that the name server still has the names in cache (credibility AUTH) but the associated glue records may have timed out (eg because of lower TTL). When there are no more addresses available, the name server should go back via the parent. But if the parent replies with a different list of NS names (then still in the cache), the name server should *refuse* to believe that info (because it still has a better answer). Consequently : since the info is not believed, no answers can be provided for that domain (until the list of names, cached with credibility AUTH, times out itself) -- domain kind of bounces from accessible to inaccessible and back. Cfr http://www.c3.hu/docs/oreilly/tcpip/dnsbind/ch13_02.htm (search for credibility - just before the first match there is a Bind (4!) cache dump; A bit dated, for sure, but Bind 4 still shows credibility in the cache dump. I think Bind 8 does as well, have not found yet were Bind 9 shows this ?) Morale : referral in parent should be identical to (or be a subset) of NS records at domain level. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: MontyRee [mailto:chulm...@hotmail.com] Sent: 12 January 2012 10:10 AM To: bind-users@lists.isc.org Subject: which NS record will be cached? Hi, all. I have one question about NS cache ttl. for example, I can get two different NS TTL like below. $ dig google.com ns +trace google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 173 ms google.com. 345600 IN NS ns4.google.com. google.com. 345600 IN NS ns1.google.com. google.com. 345600 IN NS ns2.google.com. google.com. 345600 IN NS ns3.google.com. ;; Received 164 bytes from 216.239.34.10#53(ns2.google.com) in 43 ms so, on resolving DNS, which NS record TTL will be cached generally? 172800 or 345600? Thanks in advance. ___ 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 authentication and ad parameter
Hello, The authoritative NS for nknsec.in. *does* give answers with corresponding RRSIGs ! $ dig @ns1.nknsec.in. test.nknsec.in. +dnssec +short 10.1.27.25 A 5 3 360 20120204072952 20120105072952 16755 test.nknsec.in. DcLPb3hVDqal64UQe3Vk4NjbMRwSSWHNy4r/Bk42M2WQLZYBt9p7NpIT 6g1AVdP2vyFs2q4CbA/QLUMeVWptvHBNZcA8/M4DpW5GpsOmC3SeZe01 lCUzbANN/+NNg/PwHsPhLUOEatmjZxfrU3lGpxXFF527ohzxXatZdX48 lsM= à there is an A record and a RRSIG over that A record I hope you do not expect that (authoritative) NS to provide answers with AD-bit set ? Because it will not ! Name servers in the authoritative role for a domain will never set the AD-bit; they will provide DNSSEC data (NSEC(3), RRSIG, DNSKEY) allowing validating caching and forwarding name servers to perform validation. Those validating name servers will set the AD-bit to indicate they performed verification and found everything OK. Since, apparently, in .in you cannot get the DS information of your domain published yet, DLV is the only way to somehow establish a chain-of-trust. That requires that validating clients must also be configured for DLV. And my feeling is, with the growing number of top-level-domains getting ready for DNSSEC, there will be less and less demand for DLV (didnt I see a message stating end-of-life ?). Hope this is somehow helpful if only to state that you should not expect AD-bit set from name servers in the authoritative role. Kind regards, Marc Lampo Security Officer EURid (for .eu) From: Gaurav kansal [mailto:gaurav.kan...@nic.in] Sent: 11 January 2012 06:16 AM To: bind-users@lists.isc.org Subject: DNSSEC authentication and ad parameter Dear All, I had purchased a new domain especially for DNSSEC testing. But when I ask my registry to insert my DS keys in .in zone file, I got the answer that .in is still not ready for this although .in is signed. I tried to authenticate my domain through ISC dlv. I upload my DS key there and it is showing a GOOD status for my domain but still I am not getting ad parameter in my dig answer. Anyone please explain what I have to do next so that I can give authenticated answer for test.nknsec.in domain. Zone List https://dlv.isc.org/users/1632/zones/new (add a zone) Zone Name Status DNSKEYs Zone Actions test.nknsec.in Good 1 https://dlv.isc.org/zones/7129/dnskeys/new (add) https://dlv.isc.org/zones/7129 (details) https://dlv.isc.org/zones/7129 (delete) Copyright © 2010 by Internet Systems Consortium. Please don't print this e-mail until unless you really need, it will save Trees on Planet Earth. IPv4 is Over, Are your ready for new Network. Thanks n Regards, GAURAV KANSAL 9910118448 VoIP - 6259 Operation And Routing Unit NIC , NEW DELHI ___ 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: Query regarding dig output
Hello, The fourth record in the ADDITIONAL section is the OPT EDNS0 record, returned by the server. You can see it displayed in the QUESTION SECTION: Also, try dig @180.149.63.3 nkn.in. +dnssec +bufsize=1024 (EDNS0, with D0, but payload of 1024) à in the reply the payload will be 4096 : so the server returns most of EDNS0 info in the query, but replaces the UDP payload size by what it accepts itself. (cfr recent posting of Mark Andrews in IETF dnsext mailing list about finding this out) Kind regards, Marc Lampo Security Officer EURid From: Gaurav Kansal [mailto:gaurav.kan...@nic.in] Sent: 15 November 2011 01:42 PM To: bind-users@lists.isc.org Subject: Query regarding dig output Dear Sir, When I am query through dig for nkn.in domain without any additional parameter, It is showing 3 ADDITIONAL records. And when I am query through dig for same nkn.in domain with +dnssec parameter, It is showing 4 ADDITIONAL records but there are only 3 answers in ;;ADDITIONAL SECTION. Why is it so??? [@gaurav ~]# [@gaurav ~]# dig @180.149.63.3 nkn.in ; DiG 9.3.3rc2 @180.149.63.3 nkn.in ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62605 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;nkn.in.IN A ;; ANSWER SECTION: nkn.in. 86400 IN A 164.100.56.206 ;; AUTHORITY SECTION: nkn.in. 86400 IN NS ns3.nkn.in. nkn.in. 86400 IN NS ns2.nkn.in. nkn.in. 86400 IN NS ns1.nkn.in. ;; ADDITIONAL SECTION: ns1.nkn.in. 86400 IN A 180.149.63.3 ns2.nkn.in. 86400 IN A 180.149.63.66 ns3.nkn.in. 86400 IN 2405:8a00:1000::2 ;; Query time: 2 msec ;; SERVER: 180.149.63.3#53(180.149.63.3) ;; WHEN: Tue Nov 15 17:58:21 2011 ;; MSG SIZE rcvd: 154 [@gaurav ~]# [@gaurav ~]# [@gaurav ~]# dig @180.149.63.3 +dnssec nkn.in ; DiG 9.3.3rc2 @180.149.63.3 +dnssec nkn.in ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 39199 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;nkn.in.IN A ;; ANSWER SECTION: nkn.in. 86400 IN A 164.100.56.206 ;; AUTHORITY SECTION: nkn.in. 86400 IN NS ns1.nkn.in. nkn.in. 86400 IN NS ns3.nkn.in. nkn.in. 86400 IN NS ns2.nkn.in. ;; ADDITIONAL SECTION: ns1.nkn.in. 86400 IN A 180.149.63.3 ns2.nkn.in. 86400 IN A 180.149.63.66 ns3.nkn.in. 86400 IN 2405:8a00:1000::2 ;; Query time: 603 msec ;; SERVER: 180.149.63.3#53(180.149.63.3) ;; WHEN: Tue Nov 15 17:59:33 2011 ;; MSG SIZE rcvd: 165 [@gaurav ~]# Thanks and Regards, Gaurav Kansal 8860785630 9910118448 ___ 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 Signing Key Questions
Hello, For 3) automate zone signing and zsk roll-over I know of no tools that are readily available - there are appliances (look in the IPAM world of products), that handle DNSSEC for you. However, I have in our DNSSEC workshop course environment a setup that looks at time stamps of Linux files : - zone data is stored in files - when the (unsigned) data has newer time stamp then signed data, script regenerates RRSIGs à to resign a zone, simply touch the file with unsigned data (eg once a week) - the script that generates RRSIGs does so with all available keys à to perform ZSK rollover, simply add new ZSK/delete old ZSK (at appropriate time) and touch the file with unsigned data (!!! Do respect key timing for deleting the old ZSK !!!) - same principle works for KSK rollover as well, but the challenge there is to inform the parent of new KSK (!!! + key timing matters !!!) Using time stamps of files kind of uses the Linux file system as database; Should work if the number of files is not too big one would have to consider using a real DB for larger number of zones. Success with your move towards DNSSEC. Kind regards, Marc Lampo Security Officer EURid From: McConville, Kevin [mailto:kmcconvi...@albany.edu] Sent: 04 October 2011 09:10 PM To: bind-users@lists.isc.org Subject: DNSSEC Signing Key Questions Im new to this list, so please bear with me if these are/seem like newbie questions. We are currently evaluating a DNSSEC implementation. We have several static zones that we would like to implement first. We are currently using ISC Bind 9.7.4 In the test environment (1) Authoritative dns server and (1) Resolver dns server, both running RHEL 5.7. We do have an on-hold Opendnssec server w/softhsm (we are trying to look at the built-in utilities of isc bind first). We are trying to make the DNSSEC piece as automatic as possible, so here are where we are having issues. 1) Is there any way to have the zsk be auto-generated based upon the inactive date listed in the zsk meta-data? I know we can pre-publish and then use dnssec-settime to change the meta-data, but still very hands-on. 2) With a static zone, are the update-policy local and auto-dnssec maintain options invalid/dont work? From the docs, they look like they are only for automation of dynamic zones? 3) Are there any ways to automate zone signing and zsk generation/roll-over with a totally static zone environment? 4) What key-management, zone-signing management utilities or programs have you found useful/helpful? Any suggestions, comments, or questions are greatly appreciated. Thank you in advance. Thanks, -Kevin Kevin McConville University at Albany ___ 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 SERVFAIL when parent zone has no DS record
Hello, You do not provide sufficient data for diagnose ! But it seems to me that bind is not complaining about the DS of subdomain.domain.com. but rather about a missing RRSIG for a NSEC when fetching DS of domain.com. Admittingly, logmessages could be somewhat more userfriendly, but I'd check if domain.com. itself is properly signed. Kind regards, Marc Lampo -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 01:57 PM To: bind-users@lists.isc.org Subject: DNSSEC SERVFAIL when parent zone has no DS record Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. ___ 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 SERVFAIL when parent zone has no DS record
After supplying NS's and DS in the parent zone, is that parent zone properly resigned ? (to generate NSEC(3) and RRSIG's) If you ask your validating caching name server for the DS of domain.com. do you get a proper reply with AD bit set ? If you ask your validating caching name server for the DS of subdomain.domain.com. do you get a proper reply with AD bit set ? (no idea yet about the www.subdomain.domain.com observations) Kind regards, Marc -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 02:22 PM To: Marc Lampo Cc: bind-users@lists.isc.org Subject: Re: DNSSEC SERVFAIL when parent zone has no DS record Marc, After suplying DS and the respective NS record for subdomain in the parent zone (domain.com), it works. If I disable dnssec in my recursive server, it also works. So, if a zone is not signed properly (or doesnt have DS records) the query will fail? Isn't it better to query those misconfigured servers without DNSSEC, just like it does when the zone is not signed? And what about the second case, when I query www.subdomain.domain.com . If I run two queries, the first fail with the same error, but the second works (I think the second comes from cache). How can I provide more data for diagnose?? Thanks. 2011/10/5 Marc Lampo marc.la...@eurid.eu: Hello, You do not provide sufficient data for diagnose ! But it seems to me that bind is not complaining about the DS of subdomain.domain.com. but rather about a missing RRSIG for a NSEC when fetching DS of domain.com. Admittingly, logmessages could be somewhat more userfriendly, but I'd check if domain.com. itself is properly signed. Kind regards, Marc Lampo -Original Message- From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com] Sent: 05 October 2011 01:57 PM To: bind-users@lists.isc.org Subject: DNSSEC SERVFAIL when parent zone has no DS record Hi, Dig returns SERVFAIL while trying to resolve a dnssec enabled zone without DS record in parent zone. For example, I have these two DNSSEC enabled zones: domain.com subdomain.domain.com domain.com zone has NO DS record for subdomain.domain.com zone, and subdomain.domain.com has an A record for the zone, and an A record for www . If I query subdomain.domain.com , I get SERVFAIL from dig and these log messages: 03-Oct-2011 11:03:07.893 validating @0x7f9ea305b2d0: domain.com SOA: no valid signature found 03-Oct-2011 11:03:07.894 createfetch: domain.com DS 03-Oct-2011 11:03:07.894 validating @0x7f9ea305df70: domain.com NSEC: no valid signature found 03-Oct-2011 11:03:07.895 createfetch: domain.com DS 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/DNSKEY/IN': x.x.x.x#53 03-Oct-2011 11:03:07.896 error (broken trust chain) resolving 'subdomain.domain.com/A/IN': x.x.x.x#53 If I run the query again, I get NXDOMAIN (from cache). So I can't query subdomain.domain.com zone. Now, if I query www.subdomain.domain.com I get the same, but when I run the query again I get a valid answer (from cache). I know the DS is not configured properly and so DNSSEC shouldn't work, but bind shouldn't behave like this. If the zone is not configured properly, bind should query it anyway, the same way it does when the zone isn't signed. I didn't find any related bugs. Is this a known bug? Btw, I'm using bind 9.7.3 from debian 6.0.2. Thanks. -- Sergio Roberto Charpinel Jr. -- Sergio Roberto Charpinel Jr. ___ 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 question. confused.
Hello, 1) the dig command, as shown, does not ask an authoritative name server for eeoc.gov. but rather addresses a locally configured caching name server (10.120.11.107). (which may explain the difference in size - 1726 bytes - as opposed to the 3918 bytes of Doug Barton) ((some data may already have timed out of the local cache, observe the TTL values)) 2) I'd say : yes, you receive DNSSEC responses. But your caching name server is not validating them : the AD bit is not set in the answer. 3) The OPT RR, with length 4096, is in the *reply*. The server indicates that itself is willing to accept DNS over UDP packets up till that size (eg. for dynamic updates). (while EDNS0 RFC does not explicitly state replying with EDNS0 is mandatory, if a query came in with EDNS0, there is also a statement that claims this (sending EDNS0 and looking in the reply) is a way, for a (dynamic update) client, to find out what the server is willing to accept. This statement seems to imply that EDNS0 in a reply, should be there if the client sent EDNS0. Any other opinions in the list ?) In order to see the packet size in the outgoing query packet, use something like wireshark. 4) DNSSEC query is not precise enough ! For one thing, DNSSEC requires EDNS0, EDNSO announces a buffersize, which can vary. As long as (!) the buffersize is sufficient, UDP will be used, but DNS queries can also be sent over TCP (and is your firewall allowing that ?). My suggestion (from a device that is allowed to send DNS queries to the Internet), try : dig @dnssec9.datamtn.com. eeoc.gov. +dnssec dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +bufsize=512 and dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +vc (and don't forget to have your caching NS validate DNSSEC answers, because providing signatures that are ignored by clients makes the Internet *less* safe) Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Brad Bendily [mailto:brad.bend...@la.gov] Sent: 27 September 2011 10:45 PM To: bind-users@lists.isc.org Subject: dnssec question. confused. When trying the DNSSEC check command from: https://www.dns-oarc.net/oarc/services/replysizetest behind our corporate firewall, I get: rst.x476.rs.dns-oarc.net. rst.x485.x476.rs.dns-oarc.net. rst.x490.x485.x476.rs.dns-oarc.net. Tested at 2011-09-27 20:32:34 UTC 205.172.49.177 sent EDNS buffer size 4096 205.172.49.177 DNS reply size limit is at least 490 Which, based on the website tells me our firewall is blocking or filtering EDNS/DNSSEC packets. However, what I'm confused about is when I run this command: dig +dnssec eeoc.gov I get: ; DiG 9.7.3-P1 +dnssec eeoc.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 40572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;eeoc.gov. IN A ;; ANSWER SECTION: eeoc.gov. 19499 IN A 64.94.64.52 eeoc.gov. 19499 IN RRSIG A 7 2 21600 20111208014816 20110909014816 52909 eeoc.gov. AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B 9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg== ;; AUTHORITY SECTION: eeoc.gov. 66519 IN NS dnssec10.datamtn.com. eeoc.gov. 66519 IN NS dnssec14.datamtn.com. eeoc.gov. 66519 IN NS dnssec11.datamtn.com. eeoc.gov. 66519 IN NS dnssec12.datamtn.com. eeoc.gov. 66519 IN NS dnssec9.datamtn.com. ;; ADDITIONAL SECTION: dnssec9.datamtn.com.3114IN 2001:49f0:a02a:1000::238 dnssec11.datamtn.com. 3114IN 2001:470:1:7a::147 dnssec9.datamtn.com.3114IN RRSIG 7 3 10800 2025185428 20110827185428 21352 datamtn.com. Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6 RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0 prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA== dnssec9.datamtn.com.3114IN RRSIG 8 3 10800 2025185428 20110827185428 61898 datamtn.com. NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101 C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1 jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x /Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId 1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH yLUNrjhcO0cj
DNSSEC : once correct, always correct ?
Hello, Experimenting with key roll-over timing conditions, with a Bind 9.7.3 setup, I noticed, today, that this version does not re-validate DNSSEC data, once something makes it into its cache. I wonder though, if that is correct ? What I noticed : - some data (with long TTL) is queried for a first time -- answer is with AD bit set (I know : for info only) and with corresponding RRSIG (generated with old ZSK) - then I replaced the ZSK : old ZSK -- new ZSK (a quick ZSK roll-over) and resigned the zone -- new RRSIG (generated with new ZSK) - when the DNSKEY RRset timed-out from the caching name server, I queried for the same data again (to my surprise) -- the answer is again with AD bit set, and again with the (old) RRSIG (querylog from the auth NS does not show any query for DNSKEY information) - indeed, when queried for DNSKEY RRset, with +norecurse, -- no DNSKEY's in the cache, 0 returned - when queried for DNSKEY RRset, *without* +norecurse, -- *new* DNSKEY RRset is in the cache (in the cache are now both the *old* RRSIG and the *new* ZSK) - again : querying for the initial data (with long TTL) still yields the old RRSIG (that cannot be decrypted with the new DNSKEY) It looks like once DNSSEC'd data validates correctly, that version of Bind will keep reusing that data (until TTL expires). While it may make sense, to save on CPU cycles, I am unsure if that behaviour is correct : suppose a validating *forwarding* name server (or validating resolvers in clients, once we they become available) addresses this caching name server in that condition. It would : 1) receive, from the cache, the data + (old) RRSIG 2) when queried for it, because the forwarding name server wants to validate, it will deliver the (new) DNSKEY's -- validation should now fail !!! Very confusing for debugging : One validating name server yields AD-'d data; the other, using the first one, yields SERVFAIL ... If I overlooked something obvious, sorry for the interrupt (but thanks for sending clarifying references). Thanks and kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! ___ 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 and MS AD
Unless I'm very mistaken, an AD Integrated (as opposed to primary/secondary) zone cannot be protected by DNSSEC. (remember having read this in the MS's DNSSEC document). Also (in that document) : max algorithm supported is 5 (RSASHA1). This means that using MS DNS as validating caching name server is pointless, as the root uses algorithm 8 and domains with unknown algorithms are treated as unsigned. -- for MS DNS, the chain-of-trust breaks right at the top level, not ? Kind regards, Marc Lampo EURid Security Officer -Original Message- From: John Williams [mailto:john.1...@yahoo.com] Sent: 09 August 2011 06:13 PM To: bind-users@lists.isc.org Subject: DNSSEC and MS AD My company (as many) run Microsoft Active Directory internally and we use BIND for our Internet DNS presence. We have had our domain singed for some time. Now I've been tasked to look into Signing our AD implementation. MS has their own version of DNSSEC for their DNS but my question is would this work, at all? My (signed) external zone running on BIND is aaa.com, and my internal AD domain is aaa.com as well. I don't believe I can have two signatures (or DS records) for a child domain on the parent. The only solution I can think of is import my BIND keys into Active Directory DNS. I don't know if that is doable at this time. I know this is not uniquely a BIND issue but I'm hoping that someone has run into this and can possibly provide insight to a solution. ___ 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: Is there a way to disable dnssec validation for a single zone?
Hello, As a *temporary* solution, you could configure you validating caching name server as authoritative for that name. The authoritative part/answer is taken before the cache, regardless of DS records in the parent indicating that RRSIG's should be present. One point of attention : don't have validating forwarders forward to such a caching name server - for a validating forwarder both the DS and the fake authoritative answer end up in its cache ! (if you use validating forwarders, you would have to make each forwarder authoritative for that something... ) Only a *temporary* solution, until the remote side DNS administrators get their thing fixed !!! Kind regards, Marc Lampo Security Officer EURid vzw/asbl -Original Message- From: Dodson, Ron [mailto:ron.dod...@lmco.com] Sent: 04 August 2011 05:47 PM To: bind-users@lists.isc.org Subject: Is there a way to disable dnssec validation for a single zone? Hello, Is there a way to disable dnssec validation for a single zone? The people who run the dns for ojp.usdoj.gov have broken dnssec. Usdoj.gov delegates ojp.usdoj.gov and has a DS record for ojp.usdoj.gov. Ojp.usdoj.gov is unsigned, and has no corresponding dnskey record, so validation fails. Users here, who must reach various something.ojp.usdoj.gov hosts cannot do so as the names are unresolvable on our network. The last time there was a dns issue with usdoj.gov, it took about 3 weeks for them to fix it. I'd like to come up with a way to resolve ojp.usdoj.gov names without disabling validation altogether until they fix their issues. I've tried setting ojp.usdoj.gov as a forward zone and forwarding to a non-validating resolver, but that doesn't seem to work. Ron Dodson Sr. Network Engineer ron.dod...@lmco.commailto:ron.dod...@lmco.com 301-519-6502 ___ 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: about the dig
I guess not, since it does not work ;-) After deleting all entries, did you : 1) dig @dns.name. ... or 2) dig @IP.address or 3) No @... argument used at all ? In cases 1 3, dig will need data from /etc/resolv.conf. Only in case 2 dig can do without. Kind regards, Marc Lampo -Original Message- From: Feng He [mailto:short...@gmail.com] Sent: 19 July 2011 07:33 AM To: bind-users@lists.isc.org Subject: about the dig Hi list, When I deleted all the entries in /etc/resolv.conf (I am using Linux), dig can't work. I was thinking since dig is a standard resolver, it should have the capibility to follow the referrel from root, thus it will work fine even there is no system dns resolving. Am I right? 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: Single nameserver doesn't show signed SOA-RRs
+ / let me guess / you use Smart Signing ? Weird, this week, in my verification of DNSSEC'd domains by our registrars I picked up exactly the same error : no RRSIG on the SOA. They filed a bug report to ISC about this. Might be related to this Smart Signing thing - can you confirm you are also using this ? Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Stefan Foerster [mailto:c...@incertum.net] Sent: 29 June 2011 10:57 PM To: bind-us...@isc.org Subject: Single nameserver doesn't show signed SOA-RRs Hello world, I'm having a problem with a single authoritative server that seems to not receive a signed zone. I used www.zonecheck.fr to check the zones incertum.net and billigmail.org and it complains that ns3.wars-nicht.de doesn't have a signed SOA. I already tried increasing the serial for those zones to retransfer them, but the error seems to persist. The affected nameserver is a Debian/lenny running 9.6.ESV.R4, the two other nameservers are Debian/squeeze running 9.7.3. On the affected nameserver, the only configuration with regards to DNSSEC was to add dnssec-enable yes; to the named configuration file (and restart it afterwards). Can anyone enlighten me on what I'm doing wrong here? I'd like to iron out this before I submit my keys to my registrar. Cheers Stefan ___ 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: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
Yes, this is a setup I tested (with Bind as name server). You would be getting answers, not with the AD bit set. Kind regards, Marc Lampo -Original Message- From: Carlos Vicente [mailto:cvicente.li...@gmail.com] Sent: 20 May 2011 07:53 PM To: Marc Lampo Cc: bind-users@lists.isc.org Subject: Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses So, if I understand you correctly, if I were to sign my authoritative zone and my caching nameserver, which is bogus for this zone, is dnssec enabled, and also validating, and no other validating nameserver is querying this bogus nameserver, then it's OK? cv On Thu, May 19, 2011 at 11:16 PM, Marc Lampo marc.la...@eurid.eu wrote: Implementation specific, probably, but with Bind it's the authoritative part that wins ! (assuming the caching name server is DNSSEC enabled, possibly even validating DNSSEC, then) If Bind is caching for all, but authoritative for some domains (I think this is called : bogus for some domains), a query for something in those domains where it is bogus, gets a reply with AA set. This regardless of the fact if the official/public domain has or has no DNSSEC information itself. -- so, the bogus name server will produce acceptable results (yes, we - the Internet community - has been doing this for years, make our caching name server bogus for our own public domains) But the problem is for validating resolvers (like validating forwarding name server), that use this name server : because the validating resolver asks for DS records, because the DS records are in the *parent* zone, the validating resolver gets DS records (for public, signed, domains) and will *insist* on replies it can validate (signed with correct key). If the bogus domain is not signed, that will fail ... (cfr http://www.eurid.eu/files/Insights_DNSSEC2.pdf, combine info on pages 15+16 (bogus NS) and 17+18 (forwarding NS) ) Kind regards, Marc Lampo Security Officer EURid ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
Implementation specific, probably, but with Bind it's the authoritative part that wins ! (assuming the caching name server is DNSSEC enabled, possibly even validating DNSSEC, then) If Bind is caching for all, but authoritative for some domains (I think this is called : bogus for some domains), a query for something in those domains where it is bogus, gets a reply with AA set. This regardless of the fact if the official/public domain has or has no DNSSEC information itself. -- so, the bogus name server will produce acceptable results (yes, we - the Internet community - has been doing this for years, make our caching name server bogus for our own public domains) But the problem is for validating resolvers (like validating forwarding name server), that use this name server : because the validating resolver asks for DS records, because the DS records are in the *parent* zone, the validating resolver gets DS records (for public, signed, domains) and will *insist* on replies it can validate (signed with correct key). If the bogus domain is not signed, that will fail ... (cfr http://www.eurid.eu/files/Insights_DNSSEC2.pdf, combine info on pages 15+16 (bogus NS) and 17+18 (forwarding NS) ) Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Matthew Pounsett [mailto:m...@conundrum.com] Sent: 20 May 2011 06:49 AM To: Carlos Vicente Cc: bind-users@lists.isc.org Subject: Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses On 2011-05-20, at 00:35, Carlos Vicente wrote: That's news to me. What's the failure mode? Does the server return SERVFAIL, or does it not set the AD flag, or...? It's another undefined condition in the RFCs, and so the outcome is implementation specific. I believe in the case of BIND the authoritative algorithm wins out, and so you get RRSIGs and no AD flag. I haven't tested this one out personally, but I vaguely recall the problem coming up on one of the DNS operations lists several months ago, so someone else may have a more detailed answer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: [DNSSEC] Resolver behavior with broken DS records
Hello, Just tried with Bind 9.7.2-P3 (in our course environment for our DNSSEC workshop). I can *not* confirm this behaviour there : 1 correct DS record, 1 DS record, correct in everything but the algorithm -- validating caching name servers nicely return answers with AD bit set. All name servers in this environment are 9.7.2-P3, by the way. The correct DS was referring to algorithm 5, the wrong DS to algorithm 8 (the corresponding algorithm in the DNSKEY record was 5) Kind regards, Marc -Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] Sent: 06 May 2011 03:40 PM To: bind-users@lists.isc.org Subject: [DNSSEC] Resolver behavior with broken DS records In an (involuntary) experiment under .FR, I discovered that the rule at least one DS must match for a child zone to be authenticated is wrong if a broken DS is present. In our case, the field Algorithm in the DS did not match the one in the DNSKEY. While there was another correct DS for the child zone, BIND 9.6 and 9.8 servfail. So, the incorrect DS made the child zone bogus. If there are DS and that one of them is dangling (going to an unexisting key) or unknown (new algorithm), BIND validates if there is at least one DS it can process. I won't discuss the legality of this behaviour (my reading of the RFC on this point is that a resolver can do what it wants) but I believe that the current BIND behaviour is: * inconsistent: BIND uses a at least one DS policy when there are dangling DS but a all the DS when there are broken DS. * dangerous: a simple mistake in one of the DS will make the zone bogus. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: [DNSSEC] Resolver behavior with broken DS records
So far - no SHA-2 records. Only DS records with SHA-1. I'll add DS records with SHA-2 and try again ... So the error of the mismatched must be in the SHA-2 DS records ? And *not* in the SHA-1's ? Or in both ? Kind regards, Marc -Original Message- From: 'Stephane Bortzmeyer' [mailto:bortzme...@nic.fr] Sent: 09 May 2011 01:46 PM To: Marc Lampo Cc: bind-users@lists.isc.org Subject: Re: [DNSSEC] Resolver behavior with broken DS records On Mon, May 09, 2011 at 01:00:03PM +0200, Marc Lampo marc.la...@eurid.eu wrote a message of 47 lines which said: 1 correct DS record, 1 DS record, correct in everything but the algorithm And one DS record hashed with SHA-1 and one hashed with SHA-2? This was necessary to trigger the problem, because of RFC 4509, section 3 (SHA-1 records are ignored if SHA-2 ones are present). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: [DNSSEC] Resolver behavior with broken DS records
Sorry, I still cannot confirm the problem with Bind 9.7.3-P2 version ... 4 DS's in total, for each KSK 1 DS with SHA-1, one with SHA-2 for one KSK, the algorithm used was changed from 5 to 8. (I needed to do extra change of output of dnssec-dsfromkey, because that tool calculates the keyid and ended up with a value 3 higher then the one of the key in the child. But now, the same keyid is in the child zone and in the DS-record at the parent. And I still have authenticated (AD-bit) answers) Kind regards, Marc -Original Message- From: 'Stephane Bortzmeyer' [mailto:bortzme...@nic.fr] Sent: 09 May 2011 01:52 PM To: Marc Lampo Cc: bind-users@lists.isc.org Subject: Re: [DNSSEC] Resolver behavior with broken DS records On Mon, May 09, 2011 at 01:41:08PM +0200, Marc Lampo marc.la...@eurid.eu wrote a message of 28 lines which said: So the error of the mismatched must be in the SHA-2 DS records ? Yes. And *not* in the SHA-1's ? Or in both ? RFC 4509 section 3 gives a strong priority to SHA-2. So, there is no symmetry: the problem exists only if the invalid DS is the one hashed with SHA-2. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: how to check if a slave zone is expired
Hugo, This must be a configuration error on ns2.skynet.be. The other 3 authoritative name servers answer fine, for omega-pharma.be; ns2.skynet.be. returns the list of root name servers, meaning it isn't configured to be slave for that domain. Contact Skynet/Belgacom helpdesk to get this corrected. Kind regards, Marc Lampo EURid vzw/asbl Security Officer From: hugo hugoo [mailto:hugo...@hotmail.com] Sent: 04 May 2011 08:53 AM To: bind-users@lists.isc.org Subject: how to check if a slave zone is expired Dear all, Is there a way to check that a slave zone is expired? I use dig in the following way to see that the zone is not responding on my server...but is this due to the fact that the zone is expired or another problem? dnszone002:/etc/bind/zones/slave# dig @localhost omega-pharma.be soa ; DiG 9.3.4 @localhost omega-pharma.be soa ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26868 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;omega-pharma.be. IN SOA ;; AUTHORITY SECTION: . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. - How can I see that it is because the zone is expired? - Is there a way to visualise all the zones that are expired (to make a cleanup of the configuration) Thanks for your feedback, Hugo, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: how to check if a slave zone is expired
Hugo, zones dont expire, like DNSSEC RRSIG with their end of validity time stamp. At worst, a slave name server is unable to verify the SOA record on the master for expiry time. At that point, the slave name server still knows it is authoritative, but has no data it could answer with à (at least Bind) will reply with a SERVFAIL (not the list of root name servers !) The second worst thing is that the serial number on the master is lower then what the slaves last zone transferred. As already commented in another reaction, check the logs of the slaves, they (should) signal this (Bind does). Hope this helps. Kind regards, Marc Lampo Security Officer EURid vzw/asbl From: hugo hugoo [mailto:hugo...@hotmail.com] Sent: 04 May 2011 09:56 AM To: marc.la...@eurid.eu; bind-users@lists.isc.org Subject: RE: how to check if a slave zone is expired Marc, This example was maybe not the best one. My questions remains as other zones are well unavailable on all name servers. Regards, Hugo, _ From: marc.la...@eurid.eu To: hugo...@hotmail.com; bind-users@lists.isc.org Subject: RE: how to check if a slave zone is expired Date: Wed, 4 May 2011 09:18:56 +0200 Hugo, This must be a configuration error on ns2.skynet.be. The other 3 authoritative name servers answer fine, for omega-pharma.be; ns2.skynet.be. returns the list of root name servers, meaning it isnt configured to be slave for that domain. Contact Skynet/Belgacom helpdesk to get this corrected. Kind regards, Marc Lampo EURid vzw/asbl Security Officer From: hugo hugoo [mailto:hugo...@hotmail.com] Sent: 04 May 2011 08:53 AM To: bind-users@lists.isc.org Subject: how to check if a slave zone is expired Dear all, Is there a way to check that a slave zone is expired? I use dig in the following way to see that the zone is not responding on my server...but is this due to the fact that the zone is expired or another problem? dnszone002:/etc/bind/zones/slave# dig @localhost omega-pharma.be soa ; DiG 9.3.4 @localhost omega-pharma.be soa ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26868 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;omega-pharma.be. IN SOA ;; AUTHORITY SECTION: . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. - How can I see that it is because the zone is expired? - Is there a way to visualise all the zones that are expired (to make a cleanup of the configuration) Thanks for your feedback, Hugo, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC, whitehouse, isc, and troubleshooting...
What should be clear to all (DNSSEC) administrators is that it is useless to sign *your* zone(s) if they refer to other, non-signed, zones themselves ! The danger is that the attacker will not try to cache poison your CNAME, but the final destination A record ! Cache poisoning - Dan Kaminsky style - attacks glue (A) records anyway (not CNAME's). Recommendation : If you need to refer to other zones (webhosting, email-in-the-cloud), *insist* that they as well implement DNSSEC for their zones ! Kind regards, Marc Lampo Security Officer for EURid vzw/asbl -Original Message- From: Paul Wouters [mailto:p...@xelerance.com] Sent: 18 April 2011 08:35 PM To: John Williams Cc: bind-us...@isc.org Subject: Re: DNSSEC, whitehouse, isc, and troubleshooting... On Mon, 18 Apr 2011, John Williams wrote: Subject: DNSSEC, whitehouse, isc, and troubleshooting... From my signed domain when I query www.isc.org (w/ +dnssec) I get the ad flag as expected. I don't see that flag when I query whitehouse.gov (w/ +dnssec) and I know that zone is signed. Is anyone else seeing this behavior? Also, is there a link that addresses troubleshooting or diagnosing DNSSEC based queries? works for me: [paul@bofh ~]$ dig +dnssec whitehouse.gov ; DiG 9.7.3-RedHat-9.7.3-1.fc14 +dnssec whitehouse.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 14133 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;whitehouse.gov.IN A ;; ANSWER SECTION: whitehouse.gov. 20 IN A 59.151.148.110 whitehouse.gov. 20 IN RRSIG A 7 2 20 20110420224012 20110417214012 43676 whitehouse.gov. M3z/ZHkI07JM+CC25GFf3NZnO9nVddZ+qnGtqnx2pVUtV0AFRa+VX+TX G8qgWL49xNEQzce4vrf0CocEGoqgDf/x0R+qntMy2GmK7go06KrvNoLG pJW0grr9ZLx0k6uN8xRcSDlI/H9/SJyfCWPJq1pHJpDCsHTeiSXtEb0J gnU= Note that www.whitehouse.gov is a CNAME into akamai that's unsigned, so you don't get the AD bit when querying that, unless you specifically ask for the CNAME: ; DiG 9.7.3-RedHat-9.7.3-1.fc14 +dnssec -t cname www.whitehouse.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29148 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.whitehouse.gov.IN CNAME ;; ANSWER SECTION: www.whitehouse.gov. 3527IN CNAME www.whitehouse.gov.edgesuite.net. www.whitehouse.gov. 3527IN RRSIG CNAME 7 3 3600 20110420224012 20110417214012 43676 whitehouse.gov. n+pU7FVUMC3VvJ3yUQs7HrKCj6fQs4xTL9H35YvaSnKxc42GnoqfrbwM X1dRndkE9qBlD9PnEiu2mJDUgsz/8GDbZQ61/Bphdl/M+2533QwiAB9w dEj0AFRUTmkJFNZrUqM12YS84yvbArIv38OPvCxSGYSO21F4naxcla50 n5U= Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves and views
Chris, What's the difference between a stub zone and a static-stub zone? I have been thinking they are the same. With a stub zone, your server would ask the server with bad NS records for the NS record set, and would then try to resolve all queries against the zone using that NS rrset. With a static-stub zone (new in BIND 9.8), your server would not prime its cache with the bad NS rrset from the authoritative server. It would simply start all query resolution for the domain in question (possibly bigger than the zone) at that server, thus bypassing the bad NS rrset. Then, what is the different between static-stub and a forwarding zone ? Kind regards, Marc ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: bind and IPV6
Hello, I don't think BIND is the problem, here. Are the network and attached devices (routers/firewalls/switches/ISP) IPv6 ready ? That might prove to be harder. (at least : here in Belgium, our ISP's, for commercial connections are not in a hurry to offer IPv6 connectivity) Kind regards, Marc Lampo From: hugo hugoo [mailto:hugo...@hotmail.com] Sent: 22 February 2011 12:00 PM To: bind-users@lists.isc.org Subject: bind and IPV6 Dear all, In the scope of the IPV6 deployment, I have been asked if oiyr DNS servers are IPV6 compliant. We are now upgrading all our servers to bind-9.6-ESV-R3. - Can anybody give some feedback on the IPV6 compliancy? IS bind-9.6-ESV-R3 totally compliant with IPV6? Thanks in advance to share your experience/knowledge. Regards, Hugo, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC - mismatch between algorithm and type of NSEC
Hello, And my best whishes for the new year 2011 ! May we have lots of interesting questions, where we all can learn from ;-) (hope my question is also in that category ...) As .eu top level domain we try to avoid inserting DS records in our zone where corresponding DNSKEY information is missing from the customers' zone file, thus avoiding to activated DNSSEC with an already broken chain-of-trust. However, we now found the following case : 1) registrar offers us DNSKEY information with algorithm 7 : RSASHA1-NSEC3-SHA1 2) in the zone file, there are NSEC (and not NSEC3) records Public DNSSEC verification tools (dnsviz, verisignlabs) don't seem to make a problem out of this (they do signal an insecure delegation, obviously : we don't publish a DS record). ((there must be a wildcard in the zone file, So I can enter a domain name where the verification tools get NSEC records)) I can simulate the case in a test environment, of course, But then I only see the behaviour of a specific name server implementation. But what is the list's interpretation of this situation : erronous or not ? Does any DNSSEC RFC mention this case and prescribe a reaction to this ? (I didn't find any - RFC5155 states the new algorithms - 6 and 7 - *must* be used when NSEC3 is used, But not a word - unless I overlooked it - about using algorithm 7 and yet, NSEC ...) Looking forward to your comments. Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC - 1 RRSIG - expires while in cache
Hello, In my opinion, the following situation should be avoided, but I'd welcome motivated second opinions. A DNSSEC verification script yielded a warning, this morning : HIDDEN : (soa = HIDDEN) (# RRSIGS : 1) (keyid : HIDDEN) inception: 20101124231706 ok now : 20101127083003 expiration : 20101129231706 ok ttl : 259200 expiration - ttl : 20101126231706 WARNING (becomes invalid during TTL) In summary : There is one (1) RRSIG available, Which is valid now and not yet expired. However, given the TTL, the signature will expire while still in the cache. Q1: If a RRSIG is found in the cache (cache hit), but it is expired. ? should a validating caching name server ignore the RRSIG in the cache and look for a refresh ? ? will Bind do so ? Q2: Does Bind automatic resigning take the TTL into account ? (so that it does not resign later then present expiration - TTL) Or is this irrelevant because the answer to earlier question is that an expired RRSIG in the cache must be refreshed. Thanks and kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! Register your .eu domain name and win an iPod though this X-Mas http://www.winwith.eu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
forwarding + validating name server : protocol error or simply unexplored fields ?
Hello, Much attention has been given to DNSSEC - how it brings security - the chain-of-trust - the root zone signed - activities of tld's to get signed - ... but we - I belong to an organisation in charge of a tld - should also pay attention to the validating, client, side of DNSSEC. What I see in practice, but which might simply be implementation of a name service, is that a forwarding + validating name server, that forwards to a caching name server which is not aware of DNSSEC, cannot resolve anything : all responses for either signed or unsigned domains return SERVFAIL ! Packet sniffing and query logging of respective name servers show that the forwarding name server 1) Performs a first query, to which it receives a reply 2) Performs a second query for the DS record of the domain. To which the caching, DNSSEC unaware, name server always replies with : 0 answers. Thereupon the reply to the initial client, of the forwarding name server, is : SERVFAIL. And this regardless of the fact that there are or are not DS records available. The problem seems to be that the DNSSEC unaware caching name server looks for the DS records in the wrong place : it queries the authoritative NS's of the domain, (rather than the parent domain !) Consequently, the 0 answers reply comes with the SOA record of the domain, *not* the SOA record of its parent. I suppose the forwarding + validating name server then concludes there is a problem, and fails towards its client. My questions to the community : ? is this a principal DNSSEC protocol error ? ? is this specific behaviour of a name server implementation (Bind 9.7), failing precise definition of how to behave in this case : unexplored fields ? While this gets sorted out, be careful when adding DNSSEC validation to forwarding name servers : only if the caching name server(s), to which queries are forwarded, are DNSSEC aware themselves will the combination forwarding + validating be successful. Comments welcome ! Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 mailto:christine.van.rill...@eurid.eu marc.la...@eurid.eu http://www.eurid.eu/ http://www.eurid.eu cid:image001.jpg@01C96CD5.54741F60 Want a .eu web address in your own language? http://www.eurid.eu/en/eu-domain-names/idns-eu Find out how so you don't miss out! image001.jpg___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
