------- Forwarded Message
To: Michael Richardson <mcr@xxxxxxxxxxxx>
From: Mark Andrews <marka@xxxxxxx>
References: <20130819222037.GA55876@xxxxxxxxxxxxxxx> <20130822184610.2640.qmail@xxxxxxxxx> <CAMm+Lwj5nTOqTA8ZL7smzW2Q28ARw9NTcbHpxKY-RXZ40-7ZLA@xxxxxxxxxxxxxx> <20130822212337.B37A838CBDA2@xxxxxxxxxxxxxxxx> <5559.1377478600@xxxxxxxxxxxx>
Subject: Re: [dnsext] Deprecating SPF
In-reply-to: Your message of "Sun, 25 Aug 2013 20:56:40 -0400."
<5559.1377478600@xxxxxxxxxxxx>
Date: Tue, 27 Aug 2013 07:56:55 +1000
In message <5559.1377478600@xxxxxxxxxxxx>, Michael Richardson writes:
>
> Mark, I think that the ietf@xxxxxxxx readers (myself included) might be
> confused by how your message about lame ccTLD delegations relates to
> "Deprecating SPF"
Part of the reason the spf wg wants to deprecate SPF is that there
are nameservers or nameserver/loadbalancer or nameserver/firewall
combinations that drop SPF queries. The failure to respond causes
more timeouts in processing than there are with TXT records.
These are not traditional lame delegations. The servers still
respond the A queries. They sometimes respond to other queries.
These two queries were done straight after each other.
; <<>> DiG 9.10.0pre-alpha <<>> cnrs-orleans.fr @admin.cnrs-orleans.fr spf +norec
;; global options: +cmd
;; connection timed out; no servers could be reached
; <<>> DiG 9.10.0pre-alpha <<>> cnrs-orleans.fr @admin.cnrs-orleans.fr a +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64936
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnrs-orleans.fr. IN A
;; AUTHORITY SECTION:
cnrs-orleans.fr. 7200 IN SOA admin.cnrs-orleans.fr. Postmaster.cnrs-orleans.fr. 2013082001 21600 3600 3600000 7200
;; Query time: 413 msec
;; SERVER: 163.9.1.2#53(163.9.1.2)
;; WHEN: Tue Aug 27 07:55:08 EST 2013
;; MSG SIZE rcvd: 97
Then there are the servers that don't return the correct NS RRset
and/or don't return the correct SOA record with negative answers.
Testing for NS keeps one withing the RFC 103[45] set of types.
Note the correst SOA record should be for 2957.com. I have in the
past received email proporting to be from 2957.com which is why it
is in my test set.
; <<>> DiG 9.10.0pre-alpha <<>> 2957.com spf @ns1.dsredirection.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5484
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;2957.com. IN SPF
;; AUTHORITY SECTION:
com. 3600 IN SOA ns1.dsredirection.com. hostmaster.oversee.net. 2013060601 43200 7200 1209600 3600
;; Query time: 238 msec
;; SERVER: 204.13.160.143#53(204.13.160.143)
;; WHEN: Tue Aug 27 07:29:55 EST 2013
;; MSG SIZE rcvd: 113
they do actually respon to the NS query though the record come from a
wildcard delegation. Note the lack for "aa".
; <<>> DiG 9.10.0pre-alpha <<>> +norec 2957.com ns @ns1.dsredirection.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31997
;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;2957.com. IN NS
;; ANSWER SECTION:
2957.com. 3600 IN NS ns1.dsredirection.com.
2957.com. 3600 IN NS ns2.dsredirection.com.
;; ADDITIONAL SECTION:
ns2.dsredirection.com. 7200 IN A 204.13.161.145
ns1.dsredirection.com. 7200 IN A 204.13.160.143
;; Query time: 183 msec
;; SERVER: 204.13.160.143#53(204.13.160.143)
;; WHEN: Tue Aug 27 07:34:51 EST 2013
;; MSG SIZE rcvd: 119
Mark
> Mark Andrews <marka@xxxxxxx> wrote:
> > Part of the question is whether the IETF is going to work with ICANN,
> > IANA and the ccTLD to audit delegations for servers that are not RFC
> > 103[45] compliant and suspend delegations where the servers are not
> > compliant.
>
> > * no responding to queries based on query type
> > * not having a NS rrset at the delegation point
>
> > Enforcing that ccTLD and ICANN TLD regularly audit delegations and have
> > mismatches corrected. This is REQUIRED by RFC 1034 in part to stop the
> > sorts of problems we are seeing today.
>
> > We don't have to put up people putting up misconfigured / broken
> > servers.
>
> > For the non responding servers I have written
> > draft-andrews-dns-no-response-issue to try to capture the issues. It
> > was on the dnsop agenda for Berlin but didn't get covered as time ran
> > out. I would like everyone to read it and comment on it.
>
> > Mark
> > --
> > Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
- --
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
------- End of Forwarded Message