[dns-operations] Lack of tlsa support

Wed May 27 23:21:38 UTC 2015

In message <A5F5F06B-A4BD-4DF5-9381-8F25B66774C1 at 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 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.

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 AAAA 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 at 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 at 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 that you can just deploy whatever garbage you
like as a DNS server or in front of it and its ok.  If you don't
want to play by the rules then stay out of the game.

ICANN and the TLDs should be showing leadership in this area.

In the end I'll end up fielding questions like "why does the TLSA
lookup fail" on bind-users.  I've already fielded question on failed
lookups due to servers/firewalls blocking queries with EDNS options
in them.

> 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 
> :-)

No.  You just have IPv6 available.

> Joe
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org