Re: [dns-operations] Lack of tlsa support
Thank you. That’s wonderful. –Rick From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Kumar Ashutosh Sent: Thursday, May 28, 2015 1:17 AM To: dns-operations Subject: Re: [dns-operations] Lack of tlsa support JFYI, On the Server software side, Windows DNS Server has added support for TLSA records in the latest previews. Thanks Ashu Program Manager | Windows Networking| DNS SDN From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Shumon Huque Sent: Thursday, May 28, 2015 02:26 To: Warren Kumari Cc: dns-operations Subject: Re: [dns-operations] Lack of tlsa support On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.commailto:shu...@gmail.com wrote: Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): Actually, I was wondering why those answers are NODATA rather than NXDOMAIN since presumably there aren't other record types at the name I queried. It looks like this is because this zone is in the controlled interruption mode (it has a wildcard at the apex for A, MX, etc). Shumon Huque. ___ 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] Lack of tlsa support
thanks for letting us know, a fix for v4 is in the works” :-) Note: I am no longer allowed to play with our electrical equipment, I can only wield a small stick. Which I have done…. On May 28, 2015, at 5:40 AM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 20:40, Warren Kumari wrote: On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. I think I must have been referring to the server using its name, which caused dig to use IPv6. I also see timeouts on IPv4. Full dig output included this time, to satisfy Warren's great thirst for cut and paste. Just goes to show, IPv6 is better. :-) These are Neustar-hosted zones. Surely there are still Neustar people on this list who can say thanks for letting us know, a fix for v4 is in the works. Joe [scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +noedns ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. accountant. tlsa +noedns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62146 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 71 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:33 2015 ;; MSG SIZE rcvd: 98 [scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +dnssec ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. accountant. tlsa +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4456 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 accountant. 86400 IN NSEC*.accountant. A NS SOA MX TXT SRV RRSIG NSEC DNSKEY accountant. 7200IN RRSIG SOA 8 1 7200 20150619085628 20150520075628 28309 accountant. P3V+Bfo7JNkH207xoHvboXcIhW9Dulr0YUSMAqllEyepd0ms8Al8Tjs2 TjIcENJbPA5iBwOZzpW5P2fjsq/jWp02aaOMjqRCRNraPRJD4fGxDtx8 4ex06Ysp6sOtFRssaCb4BJZ4kvdizCR64RuQdO56shP1AY5+BSKdBby/ tzU= accountant. 86400 IN RRSIG NSEC 8 1 86400 20150619082936 20150520075628 28309 accountant. Yt28u6y0wz+g2L90l/nP7HsmCdzGJ33Pf7+4277PKvLZIdyn+ksR4Rw8 //3ZgSIn/59P0ZlV5qGh+xlKdOCoh0gMHjXHQkvtXByI5HIg/tXvRA22 bCbcdHFujBy8WHKZQH6G0UAe+IkpEkMVwIFzSZs+5v1ATNliZUZeP9/C 4R0= ;; Query time: 102 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:44 2015 ;; MSG SIZE rcvd: 484 [scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa +noedns ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. something.accountant. tlsa +noedns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 59291 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;something.accountant.IN TLSA ;; AUTHORITY SECTION: accountant. 7200IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 63 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:54 2015 ;; MSG SIZE rcvd: 108 [scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa +dnssec ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. something.accountant. tlsa +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33169 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;something.accountant.IN TLSA ;; AUTHORITY SECTION: accountant. 7200IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 *.accountant. 86400 IN NSECNIC.accountant. A MX TXT SRV RRSIG NSEC *.accountant. 86400 IN RRSIG NSEC 8 1 86400 20150619082936
Re: [dns-operations] Lack of tlsa support
JFYI, On the Server software side, Windows DNS Server has added support for TLSA records in the latest previews. Thanks Ashu Program Manager | Windows Networking| DNS SDN From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Shumon Huque Sent: Thursday, May 28, 2015 02:26 To: Warren Kumari Cc: dns-operations Subject: Re: [dns-operations] Lack of tlsa support On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.commailto:shu...@gmail.com wrote: Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): Actually, I was wondering why those answers are NODATA rather than NXDOMAIN since presumably there aren't other record types at the name I queried. It looks like this is because this zone is in the controlled interruption mode (it has a wildcard at the apex for A, MX, etc). Shumon Huque. ___ 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] Lack of tlsa support
Do we really have to fight to get every new type supported? likely so, especially at the rate the dns-infected invent them randy ___ 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] Lack of tlsa support
On 27 May 2015, at 20:40, Warren Kumari wrote: On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. I think I must have been referring to the server using its name, which caused dig to use IPv6. I also see timeouts on IPv4. Full dig output included this time, to satisfy Warren's great thirst for cut and paste. Just goes to show, IPv6 is better. :-) These are Neustar-hosted zones. Surely there are still Neustar people on this list who can say thanks for letting us know, a fix for v4 is in the works. Joe [scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +noedns ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. accountant. tlsa +noedns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62146 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;accountant.IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 71 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:33 2015 ;; MSG SIZE rcvd: 98 [scallop:~]% dig @ns1.dns.nic.accountant. accountant. tlsa +dnssec ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. accountant. tlsa +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4456 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;accountant.IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 accountant. 86400 IN NSEC *.accountant. A NS SOA MX TXT SRV RRSIG NSEC DNSKEY accountant. 7200 IN RRSIG SOA 8 1 7200 20150619085628 20150520075628 28309 accountant. P3V+Bfo7JNkH207xoHvboXcIhW9Dulr0YUSMAqllEyepd0ms8Al8Tjs2 TjIcENJbPA5iBwOZzpW5P2fjsq/jWp02aaOMjqRCRNraPRJD4fGxDtx8 4ex06Ysp6sOtFRssaCb4BJZ4kvdizCR64RuQdO56shP1AY5+BSKdBby/ tzU= accountant. 86400 IN RRSIG NSEC 8 1 86400 20150619082936 20150520075628 28309 accountant. Yt28u6y0wz+g2L90l/nP7HsmCdzGJ33Pf7+4277PKvLZIdyn+ksR4Rw8 //3ZgSIn/59P0ZlV5qGh+xlKdOCoh0gMHjXHQkvtXByI5HIg/tXvRA22 bCbcdHFujBy8WHKZQH6G0UAe+IkpEkMVwIFzSZs+5v1ATNliZUZeP9/C 4R0= ;; Query time: 102 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:44 2015 ;; MSG SIZE rcvd: 484 [scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa +noedns ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. something.accountant. tlsa +noedns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 59291 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;something.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 63 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Thu May 28 10:35:54 2015 ;; MSG SIZE rcvd: 108 [scallop:~]% dig @ns1.dns.nic.accountant. something.accountant. tlsa +dnssec ; DiG 9.8.3-P1 @ns1.dns.nic.accountant. something.accountant. tlsa +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33169 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;something.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 *.accountant. 86400 IN NSECNIC.accountant. A MX TXT SRV RRSIG NSEC *.accountant. 86400 IN RRSIG NSEC 8 1 86400 20150619082936 20150520075628 28309 accountant. TrjOnCgHxkycajWjg6FW6Q09Udpr7DIQMtRwh+r6ku8dwvUKFvPvJDE2 XFUkmce3NqcxQHZvRnAhCado7fOtjlMecSiX/t8Ai1dOMoiCVoVpwbJJ rqZuJnbiJM7bLn8Wqodkx4PXIG8WpgRVSjZ7SQf2/IWpC4E7Y5OIynR7 O24= accountant. 7200 IN RRSIG SOA 8 1 7200 20150619085628 20150520075628 28309 accountant. P3V+Bfo7JNkH207xoHvboXcIhW9Dulr0YUSMAqllEyepd0ms8Al8Tjs2 TjIcENJbPA5iBwOZzpW5P2fjsq/jWp02aaOMjqRCRNraPRJD4fGxDtx8 4ex06Ysp6sOtFRssaCb4BJZ4kvdizCR64RuQdO56shP1AY5+BSKdBby/ tzU= ;; Query time: 68 msec ;; SERVER:
Re: [dns-operations] Lack of tlsa support
On 28 May 2015, at 0:21, Mark Andrews wrote: In message a5f5f06b-a4bd-4df5-9381-8f25b6677...@hopcount.ca, Joe Abley writ es: It's hard to know what you're testing (what gentypereport does), but if you're looking for TLSA records in the ACCOUNTANT zone above, I'm not sure why; new gTLD operators are constrained by contract as to the RRTypes they're allowed to publish, and TLSA isn't one of them. It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. genreport tests non meta types including a unknown type (below) and checks the rcode returned. For a name that exists the rcode should be NOERROR. You can also specify the type list on the command line which is what I did for tlsa. OK. I'm still trying to work out how it was that I could get NXDOMAIN/NOERROR+ANSWER=0 responses for TLSA queries when other people seem to struggle. I would have pasted the output at the time if I thought it was so interesting :-) We have ICANN checking query rates and uptimes but not protocol basics (like answering all non meta query types) prior to letting new TLDs go live. But again, the servers that serve the TLD zones pragmatically only have to serve the record types that are permitted in the zone in order to give end-users reasonable performance. There's no production reason I can think of that would result of a timeout from a query with QTYPE=TLSA to a zone that is certain never to serve a positive response, and which no client would ever expect to be there. I certainly agree with you in principle that this kind of behaviour is deplorable and bad, but if it was fixed for these particular servers and zones the only noticeable effect would be less mail on this list. ICANN's pre-delegation checklist includes some requirements for protocol compliance, but not all. I imagine it would have been much easier for them to be comprehensive in that area if there was a clear specification for the DNS and a clear test plan for verifying compliance. Mr Hoffman to the courtesy phone. Joe ___ 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] Lack of tlsa support
In message cf32ba1b-1119-465a-aee1-6efce967b...@hopcount.ca, Joe Abley writ es: On 28 May 2015, at 0:21, Mark Andrews wrote: In message a5f5f06b-a4bd-4df5-9381-8f25b6677...@hopcount.ca, Joe Abley writ es: It's hard to know what you're testing (what gentypereport does), but if you're looking for TLSA records in the ACCOUNTANT zone above, I'm not sure why; new gTLD operators are constrained by contract as to the RRTypes they're allowed to publish, and TLSA isn't one of them. It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. genreport tests non meta types including a unknown type (below) and checks the rcode returned. For a name that exists the rcode should be NOERROR. You can also specify the type list on the command line which is what I did for tlsa. OK. I'm still trying to work out how it was that I could get NXDOMAIN/NOERROR+ANSWER=0 responses for TLSA queries when other people seem to struggle. I would have pasted the output at the time if I thought it was so interesting :-) You had a IPv6 path to the servers. The servers work fine over IPv6. We have ICANN checking query rates and uptimes but not protocol basics (like answering all non meta query types) prior to letting new TLDs go live. But again, the servers that serve the TLD zones pragmatically only have to serve the record types that are permitted in the zone in order to give end-users reasonable performance. No. They only have to be able to _load_ the record types permitted in zone. They have to serve (answer) ALL query types. They only have to be able to add records to the answer for the types they are permitted to load. There's no production reason I can think of that would result of a timeout from a query with QTYPE=TLSA to a zone that is certain never to serve a positive response, and which no client would ever expect to be there. Stupid firewall / scrubbing service settings will produce this sort of behaviour. I certainly agree with you in principle that this kind of behaviour is deplorable and bad, but if it was fixed for these particular servers and zones the only noticeable effect would be less mail on this list. No. The servers also block referrals when asked with those qtypes. They would also break dotless queries for these types that happen to hit the zone apex while processing a search list. [servers covers the nameservers and firewalls / scrubbers in front of them.] ICANN's pre-delegation checklist includes some requirements for protocol compliance, but not all. I imagine it would have been much easier for them to be comprehensive in that area if there was a clear specification for the DNS and a clear test plan for verifying compliance. Mr Hoffman to the courtesy phone. Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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] Lack of tlsa support
On Wed, May 27, 2015 at 1:32 PM, Joe Abley jab...@hopcount.ca wrote:
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db | sh
gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not sure
why; new gTLD operators are constrained by contract as to the RRTypes
they're allowed to publish, and TLSA isn't one of them. It's not obvious
that this is a problem for anybody, though; it's not like you'd expect to
see a TLSA RRSet in there.
What is the point you're making?
I think that point is that a timeout is not the right response.
For what it's worth, I have no problem getting a reasonable (negative)
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-)
Unable to parse. Are you saying that you *are* getting a reasonable
(negative) response to ACCOUNTANT/IN/TLSA? Or that you would be OK
getting on if that is what they decided to send you?
I get:
dig TLSA accountant @156.154.144.195
; DiG 9.8.3-P1 TLSA accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached
Same thing for TYPE67 (unassigned):
dig TYPE67 accountant @156.154.144.195
; DiG 9.8.3-P1 TYPE67 accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached
NoERROR/NODATA (yes please), REFUSED, NOTIMP, etc are all better than
just not answering (which means the recursive and stub / app both hang
around burning state).
W
Joe
___
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
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
___
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] Lack of tlsa support
On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Unable to parse. Unsure why. :-) Are you saying that you *are* getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA? Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no EDNS0 (see above). Joe ___ 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] Lack of tlsa support
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db | sh
gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
aig. @156.154.144.6 (ns1.dns.nic.aig.): tlsa=timeout
aig. @156.154.145.6 (ns2.dns.nic.aig.): tlsa=timeout
aig. @156.154.159.6 (ns3.dns.nic.aig.): tlsa=timeout
aig. @156.154.156.6 (ns4.dns.nic.aig.): tlsa=timeout
aig. @156.154.157.6 (ns5.dns.nic.aig.): tlsa=timeout
aig. @156.154.158.6 (ns6.dns.nic.aig.): tlsa=timeout
al. @194.119.192.8 (ns-al.isti.cnr.it.): tlsa=timeout
an. @65.174.238.100 (engine2.una.an.): tlsa=timeout
an. @200.26.199.102 (engine3.una.an.): tlsa=timeout
ao. @2c0f:f828:2::b (ns02.dns.ao.): tlsa=timeout
ar. @2801:140::10 (a.dns.ar.): tlsa=timeout
as. @204.74.112.1 (tld1.ultradns.net.): tlsa=timeout
as. @204.74.113.1 (tld2.ultradns.net.): tlsa=timeout
as. @199.7.66.1 (tld3.ultradns.org.): tlsa=timeout
as. @199.7.67.1 (tld4.ultradns.org.): tlsa=timeout
as. @192.100.59.11 (tld5.ultradns.info.): tlsa=timeout
as. @198.133.199.11 (tld6.ultradns.co.uk.): tlsa=timeout
axa. @156.154.144.20 (ns1.dns.nic.axa.): tlsa=timeout
axa. @156.154.145.20 (ns2.dns.nic.axa.): tlsa=timeout
axa. @156.154.159.20 (ns3.dns.nic.axa.): tlsa=timeout
axa. @156.154.156.20 (ns4.dns.nic.axa.): tlsa=timeout
axa. @156.154.157.20 (ns5.dns.nic.axa.): tlsa=timeout
axa. @156.154.158.20 (ns6.dns.nic.axa.): tlsa=timeout
best. @156.154.144.24 (ns1.dns.nic.best.): tlsa=timeout
best. @156.154.145.24 (ns2.dns.nic.best.): tlsa=timeout
best. @156.154.159.24 (ns3.dns.nic.best.): tlsa=timeout
best. @156.154.156.24 (ns4.dns.nic.best.): tlsa=timeout
best. @156.154.157.24 (ns5.dns.nic.best.): tlsa=timeout
best. @156.154.158.24 (ns6.dns.nic.best.): tlsa=timeout
bf. @193.50.53.3 (ns1.ird.fr.): tlsa=timeout
bf. @2001:5a0:d00:::42c6:9163 (ns2.as6453.net.): tlsa=timeout
bf. @66.198.145.99 (ns2.as6453.net.): tlsa=timeout
bid. @156.154.144.25 (ns1.dns.nic.bid.): tlsa=timeout
bid. @156.154.145.25 (ns2.dns.nic.bid.): tlsa=timeout
bid. @156.154.159.25 (ns3.dns.nic.bid.): tlsa=timeout
bid. @156.154.156.25 (ns4.dns.nic.bid.): tlsa=timeout
bid. @156.154.157.25 (ns5.dns.nic.bid.): tlsa=timeout
bid. @156.154.158.25 (ns6.dns.nic.bid.): tlsa=timeout
biz. @156.154.124.65 (a.gtld.biz.): tlsa=timeout
biz. @156.154.125.65 (b.gtld.biz.): tlsa=timeout
biz. @156.154.127.65 (c.gtld.biz.): tlsa=timeout
biz. @156.154.126.65 (e.gtld.biz.): tlsa=timeout
biz. @209.173.58.66 (f.gtld.biz.): tlsa=timeout
biz. @156.154.128.65 (k.gtld.biz.): tlsa=timeout
bm. @206.53.190.202 (ns1.bm.): tlsa=timeout
bm. @69.17.194.1 (ns2.bm.): tlsa=timeout
bt. @2405:d000:0:100::200 (ns1.druknet.bt.): tlsa=timeout
buzz. @156.154.144.29 (ns1.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.145.29 (ns2.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.159.29 (ns3.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.156.29 (ns4.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.157.29 (ns5.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.158.29 (ns6.dns.nic.buzz.): tlsa=timeout
bw. @2c0f:ff00:0:4::2 (ns1.btc.bw.): tlsa=timeout
caravan. @156.154.144.32 (ns1.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.145.32 (ns2.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.159.32 (ns3.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.156.32 (ns4.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.157.32 (ns5.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.158.32 (ns6.dns.nic.caravan.): tlsa=timeout
cartier. @156.154.144.34 (ns1.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.145.34 (ns2.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.159.34 (ns3.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.156.34 (ns4.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.157.34 (ns5.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.158.34 (ns6.dns.nic.cartier.): tlsa=timeout
cbn. @156.154.144.35 (ns1.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.145.35 (ns2.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.159.35 (ns3.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.156.35 (ns4.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.157.35 (ns5.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.158.35 (ns6.dns.nic.cbn.): tlsa=timeout
ceo. @156.154.144.37 (ns1.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.145.37 (ns2.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.159.37 (ns3.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.156.37 (ns4.dns.nic.ceo.): tlsa=timeout
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
Re: [dns-operations] Lack of tlsa support
Absolutely.
The technology is the easy bit. Deployment is the hard problem.
We are trying to make changes to a machine with ten billion components.
Every single one of which is more complex than the most complex machine
built before the moon landings and some of which are the product of more
human intellectual activity than the sum of all human thought prior to that
date.
Don't expect changing the Internet to be easy, it isn't.
On Wed, May 27, 2015 at 11:16 AM, Mark Andrews ma...@isc.org wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db |
sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
aig. @156.154.144.6 (ns1.dns.nic.aig.): tlsa=timeout
aig. @156.154.145.6 (ns2.dns.nic.aig.): tlsa=timeout
aig. @156.154.159.6 (ns3.dns.nic.aig.): tlsa=timeout
aig. @156.154.156.6 (ns4.dns.nic.aig.): tlsa=timeout
aig. @156.154.157.6 (ns5.dns.nic.aig.): tlsa=timeout
aig. @156.154.158.6 (ns6.dns.nic.aig.): tlsa=timeout
al. @194.119.192.8 (ns-al.isti.cnr.it.): tlsa=timeout
an. @65.174.238.100 (engine2.una.an.): tlsa=timeout
an. @200.26.199.102 (engine3.una.an.): tlsa=timeout
ao. @2c0f:f828:2::b (ns02.dns.ao.): tlsa=timeout
ar. @2801:140::10 (a.dns.ar.): tlsa=timeout
as. @204.74.112.1 (tld1.ultradns.net.): tlsa=timeout
as. @204.74.113.1 (tld2.ultradns.net.): tlsa=timeout
as. @199.7.66.1 (tld3.ultradns.org.): tlsa=timeout
as. @199.7.67.1 (tld4.ultradns.org.): tlsa=timeout
as. @192.100.59.11 (tld5.ultradns.info.): tlsa=timeout
as. @198.133.199.11 (tld6.ultradns.co.uk.): tlsa=timeout
axa. @156.154.144.20 (ns1.dns.nic.axa.): tlsa=timeout
axa. @156.154.145.20 (ns2.dns.nic.axa.): tlsa=timeout
axa. @156.154.159.20 (ns3.dns.nic.axa.): tlsa=timeout
axa. @156.154.156.20 (ns4.dns.nic.axa.): tlsa=timeout
axa. @156.154.157.20 (ns5.dns.nic.axa.): tlsa=timeout
axa. @156.154.158.20 (ns6.dns.nic.axa.): tlsa=timeout
best. @156.154.144.24 (ns1.dns.nic.best.): tlsa=timeout
best. @156.154.145.24 (ns2.dns.nic.best.): tlsa=timeout
best. @156.154.159.24 (ns3.dns.nic.best.): tlsa=timeout
best. @156.154.156.24 (ns4.dns.nic.best.): tlsa=timeout
best. @156.154.157.24 (ns5.dns.nic.best.): tlsa=timeout
best. @156.154.158.24 (ns6.dns.nic.best.): tlsa=timeout
bf. @193.50.53.3 (ns1.ird.fr.): tlsa=timeout
bf. @2001:5a0:d00:::42c6:9163 (ns2.as6453.net.): tlsa=timeout
bf. @66.198.145.99 (ns2.as6453.net.): tlsa=timeout
bid. @156.154.144.25 (ns1.dns.nic.bid.): tlsa=timeout
bid. @156.154.145.25 (ns2.dns.nic.bid.): tlsa=timeout
bid. @156.154.159.25 (ns3.dns.nic.bid.): tlsa=timeout
bid. @156.154.156.25 (ns4.dns.nic.bid.): tlsa=timeout
bid. @156.154.157.25 (ns5.dns.nic.bid.): tlsa=timeout
bid. @156.154.158.25 (ns6.dns.nic.bid.): tlsa=timeout
biz. @156.154.124.65 (a.gtld.biz.): tlsa=timeout
biz. @156.154.125.65 (b.gtld.biz.): tlsa=timeout
biz. @156.154.127.65 (c.gtld.biz.): tlsa=timeout
biz. @156.154.126.65 (e.gtld.biz.): tlsa=timeout
biz. @209.173.58.66 (f.gtld.biz.): tlsa=timeout
biz. @156.154.128.65 (k.gtld.biz.): tlsa=timeout
bm. @206.53.190.202 (ns1.bm.): tlsa=timeout
bm. @69.17.194.1 (ns2.bm.): tlsa=timeout
bt. @2405:d000:0:100::200 (ns1.druknet.bt.): tlsa=timeout
buzz. @156.154.144.29 (ns1.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.145.29 (ns2.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.159.29 (ns3.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.156.29 (ns4.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.157.29 (ns5.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.158.29 (ns6.dns.nic.buzz.): tlsa=timeout
bw. @2c0f:ff00:0:4::2 (ns1.btc.bw.): tlsa=timeout
caravan. @156.154.144.32 (ns1.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.145.32 (ns2.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.159.32 (ns3.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.156.32 (ns4.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.157.32 (ns5.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.158.32 (ns6.dns.nic.caravan.): tlsa=timeout
cartier. @156.154.144.34 (ns1.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.145.34 (ns2.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.159.34 (ns3.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.156.34 (ns4.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.157.34 (ns5.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.158.34 (ns6.dns.nic.cartier.): tlsa=timeout
cbn. @156.154.144.35 (ns1.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.145.35 (ns2.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.159.35 (ns3.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.156.35 (ns4.dns.nic.cbn.): tlsa=timeout
Re: [dns-operations] Lack of tlsa support
On May 27, 2015, at 6:16 PM, Mark Andrews ma...@isc.org wrote: Do we really have to fight to get every new type supported? Is this a trick question? The Empirical Evidence 8-ball would appear to say Yes. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Lack of tlsa support
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db
| sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not
sure why; new gTLD operators are constrained by contract as to the
RRTypes they're allowed to publish, and TLSA isn't one of them. It's not
obvious that this is a problem for anybody, though; it's not like you'd
expect to see a TLSA RRSet in there.
What is the point you're making?
For what it's worth, I have no problem getting a reasonable (negative)
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special
:-)
Joe
___
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] Lack of tlsa support
On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. Can you include a dig (or similar) showing you asking the question and getting an answer (not a timeout?). I've queried from multiple places with no love... W Unable to parse. Unsure why. :-) Are you saying that you *are* getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA? Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no EDNS0 (see above). Joe -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] Lack of tlsa support
On Wed, May 27, 2015 at 3:40 PM, Warren Kumari war...@kumari.net wrote: On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. Can you include a dig (or similar) showing you asking the question and getting an answer (not a timeout?). I've queried from multiple places with no love... W Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): $ get-ns-ip accountant. ns1.dns.nic.accountant. 156.154.144.195 ns1.dns.nic.accountant. 2610:a1:1071::c3 ns2.dns.nic.accountant. 156.154.145.195 ns2.dns.nic.accountant. 2610:a1:1072::c3 ns3.dns.nic.accountant. 156.154.159.195 ns3.dns.nic.accountant. 2610:a1:1073::c3 ns4.dns.nic.accountant. 156.154.156.195 ns4.dns.nic.accountant. 2610:a1:1074::c3 ns5.dns.nic.accountant. 156.154.157.195 ns5.dns.nic.accountant. 2610:a1:1075::c3 ns6.dns.nic.accountant. 156.154.158.195 ns6.dns.nic.accountant. 2610:a1:1076::c3 $ get-ns-ip accountant. | while read hostname ip do echo $hostname $ip dig @$ip _443._tcp.accountant. TLSA echo done ns1.dns.nic.accountant. 156.154.144.195 ; DiG 9.10.1 @156.154.144.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns1.dns.nic.accountant. 2610:a1:1071::c3 ; DiG 9.10.1 @2610:a1:1071::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45660 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Wed May 27 15:50:11 EDT 2015 ;; MSG SIZE rcvd: 108 ns2.dns.nic.accountant. 156.154.145.195 ; DiG 9.10.1 @156.154.145.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns2.dns.nic.accountant. 2610:a1:1072::c3 ; DiG 9.10.1 @2610:a1:1072::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8407 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 79 msec ;; SERVER: 2610:a1:1072::c3#53(2610:a1:1072::c3) ;; WHEN: Wed May 27 15:50:27 EDT 2015 ;; MSG SIZE rcvd: 108 ns3.dns.nic.accountant. 156.154.159.195 ; DiG 9.10.1 @156.154.159.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns3.dns.nic.accountant. 2610:a1:1073::c3 ; DiG 9.10.1 @2610:a1:1073::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46624 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1073::c3#53(2610:a1:1073::c3) ;; WHEN: Wed May 27 15:50:42 EDT 2015 ;; MSG SIZE rcvd: 108 ns4.dns.nic.accountant. 156.154.156.195 ; DiG 9.10.1 @156.154.156.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns4.dns.nic.accountant. 2610:a1:1074::c3 ; DiG 9.10.1 @2610:a1:1074::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21156 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1074::c3#53(2610:a1:1074::c3) ;; WHEN:
Re: [dns-operations] Lack of tlsa support
On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.com wrote: Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): Actually, I was wondering why those answers are NODATA rather than NXDOMAIN since presumably there aren't other record types at the name I queried. It looks like this is because this zone is in the controlled interruption mode (it has a wildcard at the apex for A, MX, etc). Shumon Huque. ___ 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] Lack of tlsa support
In message a5f5f06b-a4bd-4df5-9381-8f25b6677...@hopcount.ca, Joe Abley writ
es:
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db
| sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not
sure why; new gTLD operators are constrained by contract as to the
RRTypes they're allowed to publish, and TLSA isn't one of them. It's not
obvious that this is a problem for anybody, though; it's not like you'd
expect to see a TLSA RRSet in there.
genreport tests non meta types including a unknown type (below) and
checks the rcode returned. For a name that exists the rcode should
be NOERROR. You can also specify the type list on the command line
which is what I did for tlsa.
The next step for this will be to test subsets of Alexa zones so
we can get a more general picture of the state of type support.
Why one would treat CDS differently to CDNSKEY I don't know. It
doesn't make sense from a protocol perspective.
typelist=${typelist:-A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX
TXT RP AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS LOC NXT SRV NAPTR
KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM
TLSA HIP CDS CDNSKEY OPENPGPKEY SPF NID L32 L64 LP EUI48 EUI64 URI CAA DLV
TYPE666}
[marka@ednscomp ~/tld-report]$ grep accountant root.db | awk '$4 == NS {
print $1, $5}' | sh gentypereport
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1071::c3 (ns1.dns.nic.accountant.): all ok
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1072::c3 (ns2.dns.nic.accountant.): all ok
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1073::c3 (ns3.dns.nic.accountant.): all ok
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1074::c3 (ns4.dns.nic.accountant.): all ok
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1075::c3 (ns5.dns.nic.accountant.): all ok
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1076::c3 (ns6.dns.nic.accountant.): all ok
accountants. @2001:dcd:2::7 (demand.beta.aridns.net.au.): CDS=refused
accountants. @37.209.194.7 (demand.beta.aridns.net.au.): CDS=refused
accountants. @2001:dcd:1::7 (demand.alpha.aridns.net.au.): CDS=refused
accountants. @37.209.192.7 (demand.alpha.aridns.net.au.): CDS=refused
accountants. @2001:dcd:4::7 (demand.delta.aridns.net.au.): CDS=refused
accountants. @37.209.198.7 (demand.delta.aridns.net.au.): CDS=refused
accountants. @2001:dcd:3::7 (demand.gamma.aridns.net.au.): CDS=refused
accountants. @37.209.196.7 (demand.gamma.aridns.net.au.): CDS=refused
[marka@ednscomp ~/tld-report]$
What is the point you're making?
We have ICANN checking query rates and uptimes but not protocol
basics (like answering all non meta query types) prior to letting
new TLDs go live.
We have TLD operators all of whom have invested lots of money to
get to a TLD who have not done basic testing of the servers /
firewalls.
We have a attitude
Re: [dns-operations] Lack of tlsa support
On May 27, 2015, at 10:32 AM, Joe Abley jab...@hopcount.ca wrote: It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. Isn't this truly a problem because if my cache is cold (for the zone in question) my recursive name server could send it a query for _443._tcp.www.example.accountant. TLSA (to keep picking on them) which would then just timeout? DW smime.p7s Description: S/MIME cryptographic signature ___ 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] Lack of tlsa support
In message 0cff2137-a8b7-44bb-a2a7-6bd3cd0db...@verisign.com, Wessels, Duane writes: On May 27, 2015, at 10:32 AM, Joe Abley jab...@hopcount.ca wrote: It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. Isn't this truly a problem because if my cache is cold (for the zone in question) my recursive name server could send it a query for _443._tcp.www.example.accountant. TLSA (to keep picking on them) which would then just timeout? Yes and you never know when a resolver will go back to a TLD to get a referral. DW -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
