In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0508131527270(_dot_)25210-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
On Sat, 13 Aug 2005, wayne wrote:
Don't most resolvers deal with this automatically and leave the
application no control over this?
Are you saying that SPF implementations need to bypass standard
resolvers and do special checking?
[...]
When the resolver API lets you query by name,class,type (e.g. "man resolver" -
resolv.h in Linux), then CNAME is just another query type, and you lookup
the next name yourself as needed if that's what you want.
But you aren't querying for a CNAME, you are querying for another
qtype. When you query for, example, an A record that is found via a
bunch of CNAME lookups, you still get the A record from the resolver.
You also get the CNAMEs, but that's kind of beside the point.
So, for example:
(wayne(_at_)footbone) $ dig cname13.midwestcs.com a
; <<>> DiG 9.3.1 <<>> cname13.midwestcs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63829
;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;cname13.midwestcs.com. IN A
;; ANSWER SECTION:
cname13.midwestcs.com. 50 IN CNAME cname12.midwestcs.com.
cname12.midwestcs.com. 50 IN CNAME cname11.midwestcs.com.
cname11.midwestcs.com. 50 IN CNAME cname10.midwestcs.com.
cname10.midwestcs.com. 50 IN CNAME cname09.midwestcs.com.
cname09.midwestcs.com. 50 IN CNAME cname08.midwestcs.com.
cname08.midwestcs.com. 50 IN CNAME cname07.midwestcs.com.
cname07.midwestcs.com. 50 IN CNAME cname06.midwestcs.com.
cname06.midwestcs.com. 50 IN CNAME cname05.midwestcs.com.
cname05.midwestcs.com. 50 IN CNAME cname04.midwestcs.com.
cname04.midwestcs.com. 50 IN CNAME cname03.midwestcs.com.
cname03.midwestcs.com. 50 IN CNAME cname02.midwestcs.com.
cname02.midwestcs.com. 50 IN CNAME cname01.midwestcs.com.
cname01.midwestcs.com. 50 IN CNAME cname00.midwestcs.com.
cname00.midwestcs.com. 50 IN A 127.1.2.3
;; AUTHORITY SECTION:
midwestcs.com. 204025 IN NS ns1.twisted4life.com.
midwestcs.com. 204025 IN NS dns1.unpythonic.net.
midwestcs.com. 204025 IN NS dns.midwestcs.com.
;; ADDITIONAL SECTION:
dns1.unpythonic.net. 117626 IN A 206.222.212.218
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Aug 13 20:40:26 2005
;; MSG SIZE rcvd: 439
(wayne(_at_)footbone) $
This creates a chain of 14 CNAMEs. We find in the Answer Section the
A record we are looking for, but also the CNAMEs that were needed to
get there. To the best of my knowledge, the authoratative server
provided all of this information in a single packet since it
understands the complete CNAME chain.
Similarly:
(wayne(_at_)footbone) $ dig io-mehnle.midwestcs.com a
; <<>> DiG 9.3.1 <<>> io-mehnle.midwestcs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5629
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;io-mehnle.midwestcs.com. IN A
;; ANSWER SECTION:
io-mehnle.midwestcs.com. 600 IN CNAME io.mehnle.net.
io.mehnle.net. 86037 IN CNAME mehnle.net.
mehnle.net. 86289 IN A 195.30.85.225
;; AUTHORITY SECTION:
mehnle.net. 86023 IN NS io.link-m.de.
mehnle.net. 86023 IN NS ns.link-m.de.
mehnle.net. 86023 IN NS ns3.knipp.de.
;; ADDITIONAL SECTION:
io.link-m.de. 86022 IN A 195.30.85.225
ns.link-m.de. 86022 IN A 195.30.85.251
ns3.knipp.de. 86022 IN A 194.64.105.66
;; Query time: 30 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Aug 13 20:27:12 2005
;; MSG SIZE rcvd: 213
(wayne(_at_)footbone) $
Note that this CNAME chain crosses two different name servers since
midwestcs.com and mehnle.net use completely seperate name servers.
Still, the resolver tracked down all the answers and provided them in
the Answer Section.
So, yes SPF implementations need to bypass the simplified
gethostbyaddr() family API, and use the resolver API - in which
CNAME is just another type of record.
But, you aren't looking for a CNAME, and there is special processing
(see RFC1035) for CNAMEs.
Pyspf uses the DNS package which is equivalent to resolv.h, but implemented
in Python (instead of wrapping the C API).
Maybe the Python resolver is broken and doesn't correctly implement
RFC1035.
-wayne