On 28 May 2015, at 0:21, Mark Andrews wrote:
In message <[email protected]>, "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
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
