In message <4F564AC2.1040502@xxxxxxx>, Alessandro Vesely writes:
> On 06/Mar/12 16:00, John R. Levine wrote:
> >
> >>> We seem to believe that the "D" part is deployed so that adding new
> >>> "unknown" RRTypes is not an issue.
> >>
> >> I think this is correct, but OTOH someone recently asked about
> >> possible issues in this area, and if I remember correctly,
> >> received no response.
> >
> > Last month I ran into a guy on the dmarc list who complained that his
> > server returns NOTIMP in response to queries for SPF records ("because
> > it doesn't implement them") and clients were doing odd things. But
> > it's been a long time since I've run into anyone else like that, so I
> > agree, it's not an issue.
>
> Hm... I have no idea how such response gets cached. RFC 2136 says
> that "an appropriate error will be returned to the requestor's caller"
> when RCODE is SERVFAIL or NOTIMP.
>
> Is that the same case that Scott noticed when he wrote:
>
> Particularly when querying for SPF records of type SPF, persistent
> 2 ServFail results are /not rare/.
>
> http://www.ietf.org/mail-archive/web/spfbis/current/msg00259.html
> (emphasis added)
> ?
>
> IIRC there was also a mirroring issue...
>
> At least, I think these issues will gradually vanish as the software
> at the relevant servers gets upgraded.
A RFC 1035 recursive server should be able to handle SPF. It's
just a opaque data blob to it with a name, type, class and ttl
attributes. To serve SPF a RFC 1035 needed to be upgraded as it had
no way to store / load the record.
DNS software developers should read Section 3.6. "Defining new types,
classes, and special namespaces", especially the sentence:
New definitions should be expected.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf