[dns-operations] NXDOMAIN plus CNAME answer - works sometimes!?

[Roy Arends]

> On 22 Mar 2018, at 13:49, Matthew Richardson <matthew-l at itconsult.co.uk> wrote:
> 
> I have been troubleshooting an issue, the initial symptoms were two Windows
> 2008 R2 DNS servers (using root hints) caching and returning NX domains for
> www.cgma.org & portal.cgma.org.  Running Wireshark on one of these with a
> cleared cache, clearly shows ns7.markmonitor.com providing returning a
> packet containing NXDOMAIN flags but with a CNAME answer.
> 
> Then using dig, one sees very similar:-
> 
>> ; <<>> DiG 9.11.2-P1 <<>> @ns7.markmonitor.com portal.cgma.org +norec
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20219
>> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1680
>> ;; QUESTION SECTION:
>> ;portal.cgma.org.               IN      A
>> 
>> ;; ANSWER SECTION:
>> portal.cgma.org.        86400   IN      CNAME   portal-cgma-332539813.us-east-1.elb.amazonaws.com.
>> 
>> ;; AUTHORITY SECTION:
>> com.                    86400   IN      SOA     ns1.markmonitor.com. hostmaster.markmonitor.com. 2018012501 86400 3600 2592000 172800
>> 
>> ;; Query time: 30 msec
>> ;; SERVER: 162.88.61.19#53(162.88.61.19)
>> ;; WHEN: Thu Mar 22 13:42:04 GMT 2018
>> ;; MSG SIZE  rcvd: 170
> 
> albeit with a somewhat weird-looking authority section.
> 
> However, when capturing packets on a recursive Bind server, one also sees
> the same response (NXDOMAIN flag with CNAME answer) but Bind goes on to
> resolve the CNAME and return the answer.
> 
> If anything, its working on Bind is more puzzling than its not working on
> Windows.
> 
> Just to ensure that I am not being an idiot (I am doubting myself), is
> there any way that that answer could be correct/valid?

The ns7.markmonitor.com server has been configured to respond authoritatively for the com zone and for the cgma.org zone. 

Since it is able to resolve the cname RDATA (portal-cgma-332539813.us-east-1.elb.amazonaws.com)  internally (since it is configured to be authoritative for com) it can state authoritatively (AA bit set) that the domain portal-cgma-332539813.us-east-1.elb.amazonaws.com. does not exist (NXDOMAIN).

Your BIND resolver is smart enough to not accept that NXDOMAIN + AA bit set response and will do a query-restart internally for portal-cgma-332539813.us-east-1.elb.amazonaws.com. This way, it will be able to resolve this properly.

Windows might not be that smart and simply trust that the right hand side of the CNAME doesn’t exist.

 
>  Also, does anyone
> have any clues as to what might cause such answers?

See above.

Roy

>  Is anyone from
> MarkMonitor here who might shed some light?
> 
> Best wishes,
> Matthew
> 
> (a long-time lurker on this list)
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations