[dns-operations] Lack of tlsa support

[Mark Andrews]

In message <CF32BA1B-1119-465A-AEE1-6EFCE967BA7E at hopcount.ca>, "Joe Abley" writ
es:
> 
> 
> On 28 May 2015, at 0:21, Mark Andrews wrote:
> 
> > In message <A5F5F06B-A4BD-4DF5-9381-8F25B66774C1 at 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: marka at isc.org