[dns-operations] Lack of tlsa support

Warren Kumari warren at kumari.net
Wed May 27 18:14:00 UTC 2015


On Wed, May 27, 2015 at 1:32 PM, Joe Abley <jabley at 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 at 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 at 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



More information about the dns-operations mailing list