dnspython and CNAME answers

[lrhazi-cua]

Sorry this is not really an issue.. just a question. Looking at the code that perform dns queries, am not seeing how a CNAME response is detected and handled! Could someone explain please?

Looking at the code of DNSLookup_dnspython() function, the call to dns.resolver.query() does not include raise_on_no_answer=False, without which a CNAME response would come as NoAnswer exception, no?

So how does this code catch the CNAME responses?

[sdgathman]

I don't personally test the dnspython support, but apparently CNAME is returned along with other RR types as it is in pydns. The CNAMES are followed in SPF.query.dns(). Additional records from the resolver are cached in the session cache, which likely include results needed for resolving CNAME. The offline test cases include CNAME records.

Do you have an online test case to see if dnspython support is actually broken?

[sdgathman]

So I installed python2-dns (Fedora dnspython package). I ran a simple policy lookup via CNAME from command line: python spf.py -v imap.gathman.org

With pydns, CNAME records are returned:

result= ('imap.gathman.org', 'CNAME') mail.gathman.org
addcache= ('imap.gathman.org', 'CNAME') mail.gathman.org
result= ('mail.gathman.org', 'TXT') ['v=spf1 a a:h.mail.gathman.org -all']
addcache= ('mail.gathman.org', 'TXT') ['v=spf1 a a:h.mail.gathman.org -all']
result= ('ns1.gathman.org', 'A') 70.184.247.44
result= ('ns1.gathman.org', 'AAAA')  p
result= ('ns2.he.net', 'A') 216.218.131.2
result= ('ns2.he.net', 'AAAA')  p
result= ('ns3.he.net', 'A') 216.218.132.2
result= ('ns3.he.net', 'AAAA')  p
result= ('ns4.he.net', 'A') 216.66.1.2
result= ('ns4.he.net', 'AAAA')  p
result= ('ns5.he.net', 'A') 216.66.80.18
result= ('ns5.he.net', 'AAAA')  p
v=spf1 a a:h.mail.gathman.org -all

Notice that pydns return CNAME and additional records. dnspython seems to handle the CNAME internally:

result= ('imap.gathman.org', 'TXT') ['v=spf1 a a:h.mail.gathman.org -all']
addcache= ('imap.gathman.org', 'TXT') ['v=spf1 a a:h.mail.gathman.org -all']
v=spf1 a a:h.mail.gathman.org -all

[lrhazi-cua]

That's what am seeing, dnspython follows CNAMEs automatically and returns nothing the client could use to track CNAMEs.. so the code for cname tracking is not really in use, right? Thanks for confirming.. I would just confused.

[lrhazi-cua]

In [13]: import dns.resolver                                                                                        

In [14]: a=dns.resolver.query('c.cuaemail.org','a')                                                                 

In [15]: [x for x in a]                                                                                             
Out[15]: [<DNS IN A rdata: 136.242.2.110>]

In [16]:

scriptmgmt-2 :: ~ » dig +noall +answer c.cuaemail.org
c.cuaemail.org.         9       IN      CNAME   www.cua.edu.
www.cua.edu.            300     IN      CNAME   toptier.catholic.edu.
toptier.catholic.edu.   23      IN      A       136.242.2.110
scriptmgmt-2 :: ~ »

[sdgathman]

There is no need to track CNAMES if the library does it correctly. The lack of additional records is more of a problem, as caching these is key to efficiency. If dnspython has its own internal cache, it is not clear when it is flushed.

[lrhazi-cua]

Not sure if there is an issue that needs to be tracked here, but feel free to close if appropriate. Thank you!

[kitterma]

On February 18, 2020 7:29:01 PM UTC, "Stuart D. Gathman" notifications@github.com wrote:

There is no need to track CNAMES if the library does it correctly.

Assuming I remember correctly, the CNAME tracking code in pyspf is for pydns, not dnspython.

Scott K