On Fri, Nov 06, 2015 at 10:54:02AM +1100, Mark Andrews wrote:
> I keep getting told the IETF can't tell people what to do
> but that is *exactly* what we do do when we issue a BCP.
> We tell people what best current practice is and ask them
> to follow it.
>
> Today we have TLDs that do perform all sorts of checks on
> servers they delegate zones to and some do inform the
> operators of those zones that they have errors. Those
> checks cover in part tests described in
> draft-andrews-dns-no-response-issue.
>
> So do we adopt this or do we continue to lie to ourselves
> about what BCP actually do?
If this is about:
https://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue/
then I for one strongly support its adoption. I've been doing DANE
SMTP adoption surveys for over a year now, and have run into quite
a few nameserver operators with a number of DNSSEC issues. I've
found especially the SIDN (.nl) registry very helpful in interfacing
with DNS hosting providers to address the reported issues, but have
also had some help from .cz, .se and .gov. Today I reached out to
norid.no, they'll likely be helpful too.
It would be great if I did not have to nag each operator or hosting
provider I happened to find, and instead registries would make
periodic efforts to validate the correctness of all delegations.
Recommending this as a best practice seems quite reasonable.
As to what makes a delegation valid, it is not too difficult to
construct a sensible list of tests. The dnsviz.net site seems to
have no trouble testing for a reasonably comphensive set of warnings
and errors.
In addition to all the obvious tests of the consistency of delegation
records with data at the zone apex, no lame delegations, DS records
having matching DNSKEY records, ... Based in part on:
https://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue/
I'd also check for:
* Not dropping queries for unexpected RRtypes (which are
misguidedly droppped as a "security feature" by some systems).
Especially TLSA RRs, which are starting to get used with SMTP.
* Correct processing of denial of existence in signed zones:
; Check for valid NXDOMAIN or NODATA (if wildcard applies)
;
made-up-label2.made-up-label1.<zone-apex>. IN A ?
made-up-label2.made-up-label1.<zone-apex>. IN AAAA ?
made-up-label2.made-up-label1.<zone-apex>. IN TLSA ?
; Check for valid NXDOMAIN or NODATA (if wildcard applies)
; if in bailiwick known names exist below the zone apex.
; Names of MX hosts are often a good source of such names.
;
made-up-label2.made-up-label1.known-name.<zone-apex>. IN A ?
made-up-label2.made-up-label1.known-name.<zone-apex>. IN AAAA ?
made-up-label2.made-up-label1.known-name.<zone-apex>. IN TLSA ?
For example, papaki.gr returns NSEC RRsets with no RRSIG for multiple
domains:
@dns1.papaki.gr
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24618
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;_25._tcp.mail.3814.eu. IN TLSA
3814.eu. SOA dns1.papaki.gr. hostmaster.papaki.gr.
2015101800 10800 3600 1209600 3600
3814.eu. RRSIG SOA 5 2 86400 20160218062849 20151018062849
12273 3814.eu.
mail.3814.eu. NSEC webmail.3814.eu. A RRSIG NSEC
3814.eu. NSEC mail.3814.eu. A NS SOA MX RRSIG NSEC DNSKEY
I notified them, whether action will be take is not yet clear.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
