[dns-operations] What's wrong with my domain?
I am sure I messed up something, but cant figure out what! Some DNS servers, notably Google's, return SERVFAIL, since a couple of days now. This dns report says the NS records do not have A records... but they do in my zone data. http://www.dnssy.com/report.php?q=gu.edu ➜ ~ dig any gu.edu @8.8.8.8 ; DiG 9.9.5-3-Ubuntu any gu.edu @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 24840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;gu.edu. IN ANY ;; Query time: 80 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jul 02 06:21:49 EDT 2014 ;; MSG SIZE rcvd: 35 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
Mohamed Seeing similar errors here: http://mydnscheck.com/?domain=gu.edu Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Mohamed Lrhazi Sent: Wednesday, July 2, 2014 11:29 AM To: dns-operations Subject: [dns-operations] What's wrong with my domain? I am sure I messed up something, but cant figure out what! Some DNS servers, notably Google's, return SERVFAIL, since a couple of days now. This dns report says the NS records do not have A records... but they do in my zone data. http://www.dnssy.com/report.php?q=gu.edu ➜ ~ dig any gu.eduhttp://gu.edu @8.8.8.8http://8.8.8.8 ; DiG 9.9.5-3-Ubuntu any gu.eduhttp://gu.edu @8.8.8.8http://8.8.8.8 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 24840 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;gu.eduhttp://gu.edu. IN ANY ;; Query time: 80 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jul 02 06:21:49 EDT 2014 ;; MSG SIZE rcvd: 35 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
The DS record for gu.edu does not have a matching self signed DNSKEY record. The DS record is for keyid 3078. There are no DNSKEY records with that keyid nor signatures generated with that keyid for the DNSKEY rrset. I suspect a botched KSK key rollover. Mark ; DiG 9.11.0pre-alpha ds gu.edu ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1308 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gu.edu.IN DS ;; ANSWER SECTION: gu.edu. 86083 IN DS 3078 7 1 B4C9FB14D6519C3ECE5CC43E80C463D5847D73ED ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jul 02 21:01:54 EST 2014 ;; MSG SIZE rcvd: 71 ; DiG 9.11.0pre-alpha +dnssec +rrcomments dnskey gu.edu @141.161.200.28 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 19143 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;gu.edu.IN DNSKEY ;; ANSWER SECTION: gu.edu. 86400 IN DNSKEY 257 3 7 AwEAAb6JcEZnTcIg2P2yv7uIBG8F8ZNOFh1EzJHp2OlYnNZL70KufziL Xye72PEeCoMKCArnw3vH/7zV9SvFfFsfaEEAPDwASUYs4kGlP0IJ297C hm9x1b+vQ+tMIbGhf8z9qGqFqT/N63EGcN5Wl6B9JhFrWWZIw/7hpX6Y GSNM9fHgE79O363FOQNnUk4tUkaPSKhBZRh4jYtGKCcFt0Sc0SiDjdz1 vPhzzq2p2XklLijHUAOHfuMFfDSUFu5/8JOz84CvtGhjpoSAJ7MffcTz M9Luzk9/DkvDoteK3VHtn90vZoOea/V8CbNWX2i7S0keZQ7f9SmMg3PE gRXue/kZVnE= ; KSK; alg = NSEC3RSASHA1; key id = 39339 gu.edu. 86400 IN DNSKEY 257 3 7 AwEAAa2FnxIFT7YpOPNV6VLfpzWCh5W5Fo9zsvA1zI4psLtj//c2Xrwy UFsCYktsIVnGD8mElKXq1w1zfxeo8xudMrS2v7QQmVnioF84rFHhh+CR RVPd+8DKD+hVSQVfUfticewC9DBLLrDSuprxFIZt8VHUn3vzTN9zYK45 /dGGSOXCN8Pj7kXvhLSOYy3WjKwLK84j+gr3jTytH9gsaRTl9FrOskB+ pyYqOOro4UolRa5aPYv2BVqENYgauuowfghSqObpWATIpLCujpm5SBRX IfW4veFKIfhBlNoHLG/iQKmcrj8DAtEe8ZTNJt2GNhn8dt+J7IJOSaYb QUGRzzZ9//0= ; KSK; alg = NSEC3RSASHA1; key id = 35043 gu.edu. 86400 IN DNSKEY 256 3 7 AwEAAb/7TwBkoZFMtAzV7MrojlnEM52p43LGGbm2XyaxrZYZ2dgO6aFv GZKUkzTDKn6a0Ko3qDL71uxAVdqInARg2DDv1mjC1ONS8axhu2T4clIb wUE9R0sWKW+AzlX048bC7yFfolhg8bocnrbBLe4ED8zJw4TGHEW1PoDH DMGgXmB4ZP/UP7FBOPOMbAk0/dGKjiiRBezF3i8GmQ2w9sZB5Y9ns+uE N3BqJE5rM21kNw/KB8GCfhiDqI4jsq8w3EQ3gM/slbdHFl3oUbaEho2B ZMpmQ+lRwEVG2XBGrxwMxU4gKhmS6anPAywBjMl/I+49FgqV2FtNcCIl sHJZQkqKrX8= ; ZSK; alg = NSEC3RSASHA1; key id = 38702 gu.edu. 86400 IN DNSKEY 256 3 7 AwEAAbk4F64sFJvk8JEtpOW2sa/8No8f5MNT4N1qQaXZHfhobBKw8Jb7 JxNQqGLhmCnzHXMXS28zMx00YsgTUV90rE0fAY6d6pA5khO4Fq+nTLyS jbLeGozYFsLRvr3WnAc1j3Htsuo7phZWb/rAxe0KvVT6oV0JnGptflGh GjFTlFAIQiO4RldyVEOSk9pu9vZAGc75318JREcdez9QI1GM6yxT9qgh H1WrRHSBA/Mn3CitLMgIgatZ7N4tkclH+P0lphWPrREumIC9Il5ZAi6e Ayh/BSMpcpugPX03dXHssVRJEKXC6h6JoP7W1ZL4i4K6coLF+6QmXxjn N+GILy70XzU= ; ZSK; alg = NSEC3RSASHA1; key id = 25247 gu.edu. 86400 IN RRSIG DNSKEY 7 2 86400 20140705183107 20140628183107 39339 gu.edu. V90hsL73pY7thRDBFUICo5M/m46+nvR8nSkC7FCjSSCK6ZVuwIO2GoPV ytvmX9zVLcVZmgkP/a3nyV79ENN76j1RGhTrJLq8ekD6fl7P4djk66sB yrMiyijY8dr6CcuVVp1LnMzgDACSyPMoWnmsXEAX2zxgCJxN1FKm3INM AzEL8d/AThWG2fRTww6whQlISKYkvuN9zflK4qxUsucshccmimQj0799 7GjQh50yUYhjVOFdYdiyU3q/MtHOmjMOL7bnmquiBvXC39Qan2+e1Kys CT17b4zWUYy54qF6hEejafCsrsTy6jZIk5aXGhqA1LG/mqPI1gt74Bpu 2JI+WQ== gu.edu. 86400 IN RRSIG DNSKEY 7 2 86400 20140705183107 20140628183107 35043 gu.edu. Im5/h/K08KpcnZIXKXjTBTshEYTjMdeZeCx1qgVzhRq5jQs9ERXG8wzn Plvs809SGTuvHbSBqoziCw7eWbGhlDthj1sc7AzAr22lGRRZB7KuKJx6 BbyGRSCcte2cbec03tzf4axFIjV/AWUKPVwZz+FyLjlE8M+1m+9wf1rd RAC/sHyeRIk+UgMzbxfu4NtP+obeh3QK00acFSWzGq/GOvijub8AiD40 tMAl8eszWhi6nvRgXgCIbrILJscL0dVZVgUxe4wdJPM9l0t97y8D8/jA 8RWFSETipEgN9x1SK9OBjCA0+e7Xb1GL5u2XvgZ+47I6t5fI9a2aCTuZ cdjRxA== gu.edu. 86400 IN RRSIG DNSKEY 7 2 86400 20140705183107 20140628183107 38702 gu.edu. I0hR/eirR7oCcWXty592yeHa7ceOePt4h/ktKAMcptlYzxzyVsNZE00p JVO2RwTTyc4ROG7IjU4hrlXk47w8cRFh2HlawF/wDbqxrMAJnZl1cR/4 lNpdpdDCAvXE0YCNE9MDJJ2RlTdK0EKE1/Z6uxvdZwlLSNmdTRQZq3U6 Er8BrKydIpyaOATGTHEeDVdv6862cp/JnGbyfnPQH8zUqLwjeEwV++q7 EzdX8009sqoM0qKS+QSKD33rTwfBmgDYX4A4KePCK8VqLg3VFVuMzjLv +mlm4QJ7QVxpiKPoiCPDUCw5OPZICl3ZPgbB06FgHHAbqf1USG63Vazg SmTujQ== gu.edu. 86400 IN RRSIG DNSKEY 7 2 86400 20140705183107 20140628183107 25247 gu.edu. E4HC0HzDzSwXhRHCJuPPuLeLAsOs7hjEHqnKxt9SRx4oKOt5g/A33mHZ tr7YbGtuf5+5MkPeXaIAAwaywBzkGCFbUVlD6tGEvpDLrm/Cw12w8rfs FY0OfvJrovr15ZeH57SswhiLtTuh1NA5WqALxmbENRg/ja9Due86Js6I G7ImoajhkD2oSS0QCpwuk+pKv0xpfllawE/pzszL7vcLZSCPmXvsAwr9 TqmvmP70B+YjnGeNlEFAx1YGgS4urnNIf7/aMSk+sqrFH+1su8Q6zO94 miiz18q2xbCebSQJoRkf61n84gdVyJ+My4UfQ9sP1um8w4yD+M0i84SZ r02fGg==
Re: [dns-operations] What's wrong with my domain?
On 2 Jul 2014, at 11:29, Mohamed Lrhazi ml...@georgetown.edu wrote:
I am sure I messed up something, but cant figure out what! Some DNS
servers, notably Google's, return SERVFAIL, since a couple of days now.
DNSSEC for gu.edu appears to be broken. google's 8.8.8.8 service does DNSSEC
validation. SERVFAILs get returned when validation fails. FWIW my name servers
also do DNSSEC validation and they get SERVFAILs for your domain too.
It looks to me like someone/something rolled gu.edu's KSK and forgot to get the
parent delegation updated. .edu has one DS record for gu.edu which is for a key
with fingerprint 3078. None of the DNSKEYs in gu.edu have that footprint. This
makes it impossible to validate any signed data under gu.edu:
% drill -TD gu.edu ns
...
[T] gu.edu. 86400 IN DS 3078 7 1 b4c9fb14d6519c3ece5cc43e80c463d5847d73ed
;; Domain: gu.edu.
;; Signature ok but no chain to a trusted key or ds record
[S] gu.edu. 86400 IN DNSKEY 257 3 7 ;{id = 35043 (ksk), size = 2048b}
gu.edu. 86400 IN DNSKEY 257 3 7 ;{id = 39339 (ksk), size = 2048b}
gu.edu. 86400 IN DNSKEY 256 3 7 ;{id = 25247 (zsk), size = 2048b}
gu.edu. 86400 IN DNSKEY 256 3 7 ;{id = 38702 (zsk), size = 2048b}
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On 02.07.2014 12:29, Mohamed Lrhazi wrote: I am sure I messed up something, but cant figure out what! Some DNS servers, notably Google's, return SERVFAIL, since a couple of days now. DNSSEC validation fails for your domain. The DS record in .edu refers to a KSK with ID 3078 which doesn't match either of the two KSK DNSKEYs in gu.edu. More remarkably, Google Public DNS seems to have DNSSEC validation enabled by default now, not depending on the query flags anymore. HTH, Hauke. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
Fantastic! thanks a lot guys. I had forgotten that I did setup dnssec on
this zone a while back.
Thanks,
Mohamed.
On Wed, Jul 2, 2014 at 7:15 AM, Jim Reid j...@rfc1035.com wrote:
On 2 Jul 2014, at 11:29, Mohamed Lrhazi ml...@georgetown.edu wrote:
I am sure I messed up something, but cant figure out what! Some DNS
servers, notably Google's, return SERVFAIL, since a couple of days now.
DNSSEC for gu.edu appears to be broken. google's 8.8.8.8 service does
DNSSEC validation. SERVFAILs get returned when validation fails. FWIW my
name servers also do DNSSEC validation and they get SERVFAILs for your
domain too.
It looks to me like someone/something rolled gu.edu's KSK and forgot to
get the parent delegation updated. .edu has one DS record for gu.edu
which is for a key with fingerprint 3078. None of the DNSKEYs in gu.edu
have that footprint. This makes it impossible to validate any signed data
under gu.edu:
% drill -TD gu.edu ns
...
[T] gu.edu. 86400 IN DS 3078 7 1 b4c9fb14d6519c3ece5cc43e80c463d5847d73ed
;; Domain: gu.edu.
;; Signature ok but no chain to a trusted key or ds record
[S] gu.edu. 86400 IN DNSKEY 257 3 7 ;{id = 35043 (ksk), size = 2048b}
gu.edu. 86400 IN DNSKEY 257 3 7 ;{id = 39339 (ksk), size = 2048b}
gu.edu. 86400 IN DNSKEY 256 3 7 ;{id = 25247 (zsk), size = 2048b}
gu.edu. 86400 IN DNSKEY 256 3 7 ;{id = 38702 (zsk), size = 2048b}
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On Wed, Jul 02, 2014 at 06:29:22AM -0400, Mohamed Lrhazi wrote: I am sure I messed up something, but cant figure out what! Some DNS servers, notably Google's, return SERVFAIL, since a couple of days now. Mohamed, I checked most things I can check, and it all looks fine. It may be good to note that asking ANY queries of a resolver is a recipe for fail, which is what you try below with 8.8.8.8. It also fails with an A query, though. Also, www.gu.edu does not have an IP address in your zone. But then again, this should not break 'dig -t a gu.edu'. Your SOA record is a tad weird, but should not break things. The 'dnssy.com' report that your nameservers have no IP address in your zone appears to be bogus, at least when seen from here. Sorry I can't be more helpful! Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On Wed, Jul 02, 2014 at 06:29:22AM -0400, Mohamed Lrhazi ml...@georgetown.edu wrote a message of 82 lines which said: Some DNS servers, notably Google's, return SERVFAIL, When using a validating resolver, like Google's, always test *also* with +cd (Checking Disabled). If it works with +cd and servfails without, you can be pretty sure it is a DNSSEC problem (see Mark Andrews' analysis). This dns report says the NS records do not have A records... but they do in my zone data. http://www.dnssy.com/report.php?q=gu.edu A poor tool, specially because it reacts badly when there are IPv6 addresses. For better tools, see the article in http://www.bortzmeyer.org/tests-dns.html (updates and comments welcome). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
So many useful tips, thank you all. gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it It makes DNSsec easy, but not that easy Thanks, Mohamed. On Wed, Jul 2, 2014 at 7:46 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Jul 02, 2014 at 12:08:36PM +0100, Tony Finch d...@dotat.at wrote a message of 25 lines which said: Your DS record doesn't match your DNSKEY records. The OP could also use the excellent DNSviz: http://dnsviz.net/d/gu.edu/U7Pp0g/dnssec/ which rightly says: gu.edu/DNSKEY:DS RRs exist for algorithm(s) 7 in the edu zone, but no matching DNSKEYs of algorithm(s) 7 were used to sign the gu.edu DNSKEY RRset. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
Mohamed Lrhazi ml...@georgetown.edu wrote: gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it Surely it has an interlock to prevent a KSK rollover going ahead without a DS change?! Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire: Westerly 3 or 4, backing southwesterly 5 or 6 for a time. Slight or moderate. Rain for a time. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
It would seem bad that the DNSSEC Implementation in f5’s would complete a KSK rollover (IE remove the old key) without some confirmation that the DS had been seen in the parent. Automation gone too far. Brett On 2 Jul 2014, at 12:56, Mohamed Lrhazi ml...@georgetown.edumailto:ml...@georgetown.edu wrote: So many useful tips, thank you all. gu.eduhttp://gu.edu/ is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it It makes DNSsec easy, but not that easy Thanks, Mohamed. On Wed, Jul 2, 2014 at 7:46 AM, Stephane Bortzmeyer bortzme...@nic.frmailto:bortzme...@nic.fr wrote: On Wed, Jul 02, 2014 at 12:08:36PM +0100, Tony Finch d...@dotat.atmailto:d...@dotat.at wrote a message of 25 lines which said: Your DS record doesn't match your DNSKEY records. The OP could also use the excellent DNSviz: http://dnsviz.net/d/gu.edu/U7Pp0g/dnssec/ which rightly says: gu.edu/DNSKEY:DShttp://gu.edu/DNSKEY:DS RRs exist for algorithm(s) 7 in the edu zone, but no matching DNSKEYs of algorithm(s) 7 were used to sign the gu.eduhttp://gu.edu/ DNSKEY RRset. ___ dns-operations mailing list dns-operations@lists.dns-oarc.netmailto:dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
Yeah, it looks like it is the case, as the F5 docs say: Providing DS records to the parent domain Each time a new generation of a key-signing key is created, you must provide the updated DS record to the administrators of the parent zone. For example, in Figure 10.1 https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm_config_10_2/gtm_dnssec.html?sr=38618833#1016065, the value of the Rollover Period of the key is 30 days, and the value of the Expiration Period of the key is 37 days. In the case of a key-signing key, a new generation of the key is created every 30 days, and you have seven days before the old generation of the key expires to provide the new DS record to the administrators of the parent zone. These administrators sign the new DS record with their own key and upload it their zone. On Wed, Jul 2, 2014 at 8:44 AM, Brett Carr brett.c...@nominet.org.uk wrote: It would seem bad that the DNSSEC Implementation in f5’s would complete a KSK rollover (IE remove the old key) without some confirmation that the DS had been seen in the parent. Automation gone too far. Brett On 2 Jul 2014, at 12:56, Mohamed Lrhazi ml...@georgetown.edu wrote: So many useful tips, thank you all. gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it It makes DNSsec easy, but not that easy Thanks, Mohamed. On Wed, Jul 2, 2014 at 7:46 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Jul 02, 2014 at 12:08:36PM +0100, Tony Finch d...@dotat.at wrote a message of 25 lines which said: Your DS record doesn't match your DNSKEY records. The OP could also use the excellent DNSviz: http://dnsviz.net/d/gu.edu/U7Pp0g/dnssec/ which rightly says: gu.edu/DNSKEY:DS RRs exist for algorithm(s) 7 in the edu zone, but no matching DNSKEYs of algorithm(s) 7 were used to sign the gu.edu DNSKEY RRset. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
However it states and you have seven days” but doesn’t really say what happens after the seven days (although i think we know) or how you can delay that. Certainly in the case of a TLD where you have to interact with IANA and your own admin and tech contacts getting this done in seven days can be a real challenge. Brett On 2 Jul 2014, at 14:04, Mohamed Lrhazi ml...@georgetown.edumailto:ml...@georgetown.edu wrote: Yeah, it looks like it is the case, as the F5 docs say: Providing DS records to the parent domain Each time a new generation of a key-signing key is created, you must provide the updated DS record to the administrators of the parent zone. For example, in Figure 10.1https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm_config_10_2/gtm_dnssec.html?sr=38618833#1016065, the value of the Rollover Period of the key is 30 days, and the value of the Expiration Period of the key is 37 days. In the case of a key-signing key, a new generation of the key is created every 30 days, and you have seven days before the old generation of the key expires to provide the new DS record to the administrators of the parent zone. These administrators sign the new DS record with their own key and upload it their zone. On Wed, Jul 2, 2014 at 8:44 AM, Brett Carr brett.c...@nominet.org.ukmailto:brett.c...@nominet.org.uk wrote: It would seem bad that the DNSSEC Implementation in f5’s would complete a KSK rollover (IE remove the old key) without some confirmation that the DS had been seen in the parent. Automation gone too far. Brett On 2 Jul 2014, at 12:56, Mohamed Lrhazi ml...@georgetown.edumailto:ml...@georgetown.edu wrote: So many useful tips, thank you all. gu.eduhttp://gu.edu/ is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it It makes DNSsec easy, but not that easy Thanks, Mohamed. On Wed, Jul 2, 2014 at 7:46 AM, Stephane Bortzmeyer bortzme...@nic.frmailto:bortzme...@nic.fr wrote: On Wed, Jul 02, 2014 at 12:08:36PM +0100, Tony Finch d...@dotat.atmailto:d...@dotat.at wrote a message of 25 lines which said: Your DS record doesn't match your DNSKEY records. The OP could also use the excellent DNSviz: http://dnsviz.net/d/gu.edu/U7Pp0g/dnssec/ which rightly says: gu.edu/DNSKEY:DShttp://gu.edu/DNSKEY:DS RRs exist for algorithm(s) 7 in the edu zone, but no matching DNSKEYs of algorithm(s) 7 were used to sign the gu.eduhttp://gu.edu/ DNSKEY RRset. ___ dns-operations mailing list dns-operations@lists.dns-oarc.netmailto:dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On Wed, Jul 2, 2014 at 8:19 AM, Tony Finch d...@dotat.at wrote: Mohamed Lrhazi ml...@georgetown.edu wrote: gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it Surely it has an interlock to prevent a KSK rollover going ahead without a DS change?! Obligatory pointer at document that *should* automate this, and so prevent bad KSK rolls (if deployed :-)): https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/ Basically, when the signing tool rolls the key, it publishes the new key in the zone, the parent (registrar or registry) periodically scrapes the zone and then publishes the new DS. Currently with the RFC Editor. W (FD: author). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire: Westerly 3 or 4, backing southwesterly 5 or 6 for a time. Slight or moderate. Rain for a time. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On 07/02/14 08:22, Warren Kumari wrote: On Wed, Jul 2, 2014 at 8:19 AM, Tony Finch d...@dotat.at wrote: Mohamed Lrhazi ml...@georgetown.edu wrote: gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it Surely it has an interlock to prevent a KSK rollover going ahead without a DS change?! Obligatory pointer at document that *should* automate this, and so prevent bad KSK rolls (if deployed :-)): https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/ Basically, when the signing tool rolls the key, it publishes the new key in the zone, the parent (registrar or registry) periodically scrapes the zone and then publishes the new DS. Currently with the RFC Editor. W (FD: author). Hmmm, wonder if educause will implement this for us...and can it be done without involving our business office. Otherwise, wonder what I could do in my home grown automatation scripts to check for new DS and somehow extend the rollover time automatically? Though our next scheduled KSK rollover is a year away, and we have new F5's that'll be going into service somedaywhere we purchased the better package for, so I think having the GTM do DNSSEC would take concern of whether we can satisfy expectations for instant DNS updates when I'm forced to move our master nameserver from the 16 core physical server into a VM Last KSK rolloverI had a 31 day windowSo, (Aug 1, 2012) I email the new DS info to the person that manages our educause account. And, they finally put it in on Aug 31st Except that our key alg is 8 (RSASHA256). And, they selected 7 (RSASHA1-NSEC3-SHA1) from the dropdown menu. We're doing NSEC3. At least I don't get flooded with tickets about us not resolving in various parts of the world until I get after Labor Day. (the parts that do DNSSEC validation and don't fallback to DLV) Since things worked from home where my provider did this, but users on Comcast were left in the dark Person that had done the update, had done it just before going on vacation for a couple of weeks...but was able to fix it from remote Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire: Westerly 3 or 4, backing southwesterly 5 or 6 for a time. Slight or moderate. Rain for a time. Good, occasionally moderate. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- SafeZone Ally ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's wrong with my domain?
On 07/02/2014 04:54 PM, Lawrence K. Chen, P.Eng. wrote: Otherwise, wonder what I could do in my home grown automation scripts to check for new DS and somehow extend the rollover time automatically? If there's no such automation in place (parent monitoring child for new KSK in order to update its DS records) I wouldn't use an automated KSK rollover. I'd do it manually (KSK double-signature rollover) when the time arrives. That way I'm in control (e.g. I won't delete old KSK until I make sure parent has new DS wait for the old DS' TTL time). I really think this is the best approach when there's no such automation. If there's a better way I'd be glad to hear it (I'm staring out with DNSSEC :) Regards, Jorge ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
