Re: Deprecating SPF

Hi Jay,

below are my findings from a test I did in May 2008. I'm redoing the
same test next week with the latest Windows 2012R2 and will post the
results here. The zone-transfer issue mentioned in the text below has
been reported to Microsoft and has been fixed soon after.

Jay Daley <[email protected]> writes:

>
> I'm now really confused about what Microsoft DNS does and doesn't
> support.  Does anyone have any up to date, genuine evidence to answer
> the following questions:
>

---- ( Text from May 2008 ) -----

I did some testing with the Windows 2008 DNS Server and if the DNS
Server can work when receiving RRs unknown to this DNS Server from an
other DNS Server by AXFR.

The Windows 2009 DNS Server supports these RRs natively from the GUI or
the Commandline tool (dnscmd.exe):

AFSDB
CNAME
ATMA
A
AAAA
HINFO
ISDN
MX
MG
MB
MINFO
NXT
PTR
KEY
MR
RP
RT
SRV
SIG
TXT
WKS
X25
WINS (link to WINS Forward lookup, non-standard)
WINS-R (link to WINS Reverse lookup, non-standard)
DNAME (only via dnscmd.exe)


Test setup:

Master-DNS: BIND 9.4.3b1
Slave-DNS: Windows 2008 Enterprise Server GA, Windows DNS Server Version
6.0.6001.18000
Queries tested with DIG 9.4.2 WINDOWS

I've only done tests with a few RRs, namely with NAPTR, DNAME, SPF, DS
and DLV.

The results vary between a normal zone refresh and a newly create slave
zone.

When creating the slave zone fresh, all unknown RRs are transferred and
stored:

- -----------
SPF:
Master (BIND):
@               IN SPF "v=spf1 +mx a:mail.strotmann.de/32 -all"

Slave (Windows 2008):
@                       86400        #99        26 76 3d 73 70 66 31 20
2b 6d 78 20 61
3a 6d 61 69 6c 2e 73 74 72 6f 74 6d 61 6e 6e 2e 64 65 2f 33 32 20 2d 61
6c
6c

- -----------

NAPTR:
Master (BIND):
_test           IN NAPTR        100 10 "u" "E2U+sip"
"!^.*$!sip:[email protected]!" .

Slave (Windows 2008):
_test                   86400        NAPTR        100 10 "u" "E2U+sip"
"!^.*$!sip:[email protected]!" .

- -----------


DNAME:
Master (BIND):
dname           IN DNAME        example.com.

Slave (Windows 2008):
dname                   86400        DNAME        example.com.


- -----------

DS:

Master (BIND):
dskey           IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )
Slave (Windows 2008):
dskey                   86400        43        ffffffec 45 05 01 2b
ffffffb1 ffffff83
ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f ffffffad 1a
29 21 18

- -----------

DLV:

Master (BIND):
dlv             IN DLV 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )

Slave (Windows 2008):
dlv                     86400        #32769        ffffffec 45 05 01 2b
ffffffb1
ffffff83 ffffffaf 5f 22 58 ffffff81 79 ffffffa5 3b 0a ffffff98 63 1f
ffffffad 1a 29 21 18


However, the situation is different when doing a incremental (AXFR style
IXFR) zone refresh from the Slave to the master (non-initial update):

NAPTR - shown as "Unknown" in GUI, but shown in correct format in the
zone file on disk. Queries from DIG for these RR are answered correct.

DNAME - shown as "Unknown" in GUI, but shown in correct format in the
zone file on disk.  Queries from DIG for these RR are answered correct.

SPF/DS/DLV - when there is an SPF/DS/DLV record (and probably any other
record unknown to the DNS Server engine) in the zone on the master, the
Windows 2008 DNS Server only stores the new SOA record and does not load
any other RR from the zone. There is no error message in the message log
on this failed attempt to transfer the zone, instead there is an log
message of type "INFORMATION" saying that the zone has been successful
transferred ans written to disk. Queries against the zone are answered
with NOERROR/NODATA except for the SOA record, which is returned as an
answer. Attempts to do an AXFR against the slave zone on the Windows
2008 server are failing.

So initially, when the zone is created, the zonetransfer including
unknown RRs works. Windows 2008 is using a standard AXFR here. However
when at a later time the zone changes, the zonetransfer fails silently
and the slave zone becomes unusable. Windows 2008 DNS Server is using an
"AXFR style IXFR" here.

BIND log entry of initial AXFR from Windows 2008 DNS Server:
25-May-2008 22:42:29.671 client 217.255.147.5#35580: transfer of
'example.com/IN': AXFR started
25-May-2008 22:42:29.673 client 217.255.147.5#35580: transfer of
'example.com/IN': AXFR ended

BIND log entry of refresh AXFR from Windows 2008 DNS Server:
25-May-2008 22:52:30.308 client 217.255.147.5#41923: transfer of
'example.com/IN': AXFR-style IXFR started
25-May-2008 22:52:30.309 client 217.255.147.5#41923: transfer of
'example.com/IN': AXFR-style IXFR ended

-----( End text from May 2008 ) ------

Carsten Strotmann
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext