DNS RR prematured end

[FelixZY]

Brief description

We are running DNS queries using Scapy. The queries are run against more well known DNS providers - i.e. the error count should be very low. Lately we have noticed many log prints from scapy.runtime containing multiple warnings about "DNS RR prematured end". We also see a much larger number of DNS queries failing than expected, usually directly following these log prints.

A possible explanation seems to be packet fragmentation (does the sr function handle packet fragmentation?). Could this be it or are there any other possible explanations?

Environment

• Scapy version: 2.4.2, 2.4.3rc1, master (2019-04-26)
• Python version: 3.7.1
• Operating System: Ubuntu 18.04.2 LTS

How to reproduce

As an example, we have seen the issue occur for a DNS query against 198.206.14.241 for the A record of netflix.com.

ans, unans = sr(
    IP(
        dst="198.206.14.241"
    )
    / UDP()
    / DNS(
        id=RandShort(),
        rd=1,
        qd=DNSQR(
            qname="netflix.com",
            qtype="A"
        )
    ),
    retry=0,
    timeout=5,
    verbose=False
)

try:
    query = ans[0][0]  # type: IP
    answer = ans[0][1]  # type: IP
except IndexError:
    raise TimeoutError(f"No response was received for job ({job})") from None

Actual result

2019-04-26 11:18:26 +0200 [WARNING](scapy.runtime): DNS RR prematured end (ofs=1494, len=1460)
2019-04-26 11:18:26 +0200 [WARNING](scapy.runtime): DNS RR prematured end (ofs=1630, len=1460)
2019-04-26 11:18:26 +0200 [WARNING](scapy.runtime): more DNS RR prematured end (ofs=1680, len=1460)
2019-04-26 11:18:27 +0200 [WARNING](worker#19181): Job (HoardJob(dns_server='198.206.14.241', host='netflix.com', record='A', timeout=datetime.timedelta(seconds=5))) failed
Traceback (most recent call last):
  File "/home/felix/school/kandidat/DNSHoarder/src/hoarder.py", line 150, in __perform_hoard
    raise TimeoutError(f"No response was received for job ({job})") from None
TimeoutError: No response was received for job (HoardJob(dns_server='198.206.14.241', host='netflix.com', record='A', timeout=datetime.timedelta(seconds=5)))

Expected result

No error

Related resources

#1846 #1849 discusses DNS RR prematured end errors. However, using the merged code from the master branch does not yield any different results.

#1952 (in particular this and this comment) contains the code used by our program.

[gpotter2]

Thanks for the report.

It would be amazing if you could provide a pcap file that contains a DNS packet that reproduces this issue, so that we can work on it :/ (Scapy/Wireshark will do)

[FelixZY]

Attached are files for the aforementioned example of netflix.com@198.206.14.241: 198.206.14.241--netflix.zip

I expanded the code in the following way to output pcap files, please let me know if this is incorrect:

try:
    query = ans[0][0]  # type: IP
    answer = ans[0][1]  # type: IP
except IndexError:
    from scapy.all import wrpcap
    a = Path(f"../debug/{job.dns_server}--{job.host}--ans.pcap")
    b = Path(f"../debug/{job.dns_server}--{job.host}--uans.pcap")
    logger.error(a.resolve())
    a.touch()
    b.touch()
    wrpcap(str(a), ans)
    wrpcap(str(b), unans)
    raise TimeoutError(f"No response was received for job ({job})") from None

Please note
The warnings from scapy manifested themselves for the first time this thursday (after a long period of no program runs(!)) and occurred consistently for different scapy versions through friday.
New runs today (sunday) DOES still produce an unexpected number of TimeoutErrors for certain DNS servers as before. They DO NOT however seem to produce the scapy.runtime warning prints anymore. No code changes have been applied between then and now. Today's run was on scapy 2.4.2.

[gpotter2]

You've only provided a request packet, on which I can't reproduce :/

>>> a = rdpcap("./198.206.14.241--netflix.com--uans.pcap")[0]                                                      
>>> a.src = a.chksum = a[UDP].chksum = None                                                                        
>>> sr1(a, timeout=1)                                                                                              
Begin emission:
Finished sending 1 packets.
....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Received 484 packets, got 0 answers, remaining 1 packets
>>> a.dst="8.8.8.8"                                                                                                
>>> sr1(a, timeout=1)                                                                                              
Begin emission:
Finished sending 1 packets.
.....*
Received 6 packets, got 1 answers, remaining 0 packets
<IP  version=4 ihl=5 tos=0x0 len=185 id=12966 flags= frag=0 ttl=124 proto=udp
[...]

Although the DNS server seems down.

Could you:

• start wireshark & capture
• make a DNS query with Scapy that result in a warning/error
• stop wireshark capture and share the pcap. If possible cropped to the concerned packets.

That way we could actually replicate just the dissecting part

[FelixZY]

I'm back looking at this and still cannot reproduce the previous scapy.runtime warning prints. Running some manual DNS lookups for failing requests using nslookup seem to produce intermittent failing results as well (i.e. not a scapy or code error...).

I think we need to do some more investigation on our end - I will get back to you within the week. If the scapy.runtime warning prints manifest again I will make sure to capture them.

[FelixZY]

Sorry about the late reply

We have been unable to reproduce the scapy.runtime warning prints but from some general online reading we believe these to arise in some cases related to IP fragmenting (the number 1460 turned up as a maximum packet length under certain conditions - I am sorry that I cannot provide a specific reference link at this time).

The reason for servers producing intermittent results for queries is most likely due to network conditions etc. and not related to scapy.

With regards to the abnormally high number of failed DNS queries we have been unable to ascertain any relation with the scapy.runtime warning prints. However, we have been able to see that only about 7-15% of all dns queries sent seem to fail in any way which at least appears more plausible.

[gpotter2]

Thanks for the update.

Feel free to reopen whenever you have more informations leading to think this is a bug :)

[amchoukir]

Hello @gpotter2, @FelixZY,

I do not know if the issue is the same but sharing here to see if I need to open another issue.

I am trying to edit an mDNS pcap but when re-writing it to pcap format it leads to a malformed packet in wireshark.

When reading it back into scapy I see

>>> p2 = rdpcap("/Users/amchouki/multiple_4a_new.pcap")
WARNING: DNS RR prematured end (ofs=290, len=276)

I am sharing the corresponding the pcaps if that helps:

Archive.zip

[amchoukir]

If that can help here are more information

>>> p[0][DNS]
<DNS  id=0 qr=1 opcode=QUERY aa=1 tc=0 rd=0 ra=0 z=0 ad=0 cd=0 rcode=ok qdcount=0 ancount=4 nscount=0 arcount=6 qd=None an=<DNSRRSRV  rrname='airplay._airplay._tcp.local.' type=SRV rclass=32769 ttl=120 rdlen=None priority=0 weight=0 port=5000 target='DESKTOP-FCI78BJ.local.' |<DNSRR  rrname='airplay._airplay._tcp.local.' type=TXT rclass=32769 ttl=4500 rdlen=None rdata=[b'service1'] |<DNSRR  rrname='_services._dns-sd._udp.local.' type=PTR rclass=IN ttl=4500 rdlen=None rdata='_airplay._tcp.local.' |<DNSRR  rrname='_airplay._tcp.local.' type=PTR rclass=IN ttl=4500 rdlen=None rdata='airplay._airplay._tcp.local.' |>>>> ns=None ar=<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=A rclass=32769 ttl=120 rdlen=None rdata=9.8.67.252 |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fd09:9:8:67:a9e0:9c1d:e6c9:2911 |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fd09:9:8:67:8095:a84f:1412:fced |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fe80::a9e0:9c1d:e6c9:2911 |<DNSRRNSEC  rrname='DESKTOP-FCI78BJ.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='DESKTOP-FCI78BJ.local.' typebitmaps=['A', 'AAAA'] |<DNSRRNSEC  rrname='airplay._airplay._tcp.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='airplay._airplay._tcp.local.' typebitmaps=['TXT', 'SRV'] |>>>>>> |>
>>> len(p[0])
330

This matches what wireshark gives me for the original packet.

>>> p[0].ar[1]
<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fd09:9:8:67:a9e0:9c1d:e6c9:2911 |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fd09:9:8:67:8095:a84f:1412:fced |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fe80::a9e0:9c1d:e6c9:2911 |<DNSRRNSEC  rrname='DESKTOP-FCI78BJ.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='DESKTOP-FCI78BJ.local.' typebitmaps=['A', 'AAAA'] |<DNSRRNSEC  rrname='airplay._airplay._tcp.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='airplay._airplay._tcp.local.' typebitmaps=['TXT', 'SRV'] |>>>>>

Now if I edit the ttl field of ar[1] I get the following

>>> p[0].ar[1].ttl = 4500
>>> len(p[0])
612

I guess the length should not change based on the ttl change. The ar field seems to be updated correctly though

>>> p[0].ar
<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=A rclass=32769 ttl=120 rdlen=None rdata=9.8.67.252 |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=4500 rdlen=None rdata=fd09:9:8:67:a9e0:9c1d:e6c9:2911 |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fd09:9:8:67:8095:a84f:1412:fced |<DNSRR  rrname='DESKTOP-FCI78BJ.local.' type=AAAA rclass=32769 ttl=120 rdlen=None rdata=fe80::a9e0:9c1d:e6c9:2911 |<DNSRRNSEC  rrname='DESKTOP-FCI78BJ.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='DESKTOP-FCI78BJ.local.' typebitmaps=['A', 'AAAA'] |<DNSRRNSEC  rrname='airplay._airplay._tcp.local.' type=NSEC rclass=32769 ttl=120 rdlen=None nextname='airplay._airplay._tcp.local.' typebitmaps=['TXT', 'SRV'] |>>>>>>

[gpotter2]

Make sure you're using 2.4.4. Please open a new issue

[amchoukir]

Make sure you're using 2.4.4. Please open a new issue

Yes I am on 2.4.4 . Created #2938 to track this issue