[dns-operations] mail.protection.outlook.com FORMERR responses when querying with EDNS

[Mark Andrews]

Well the correct response when you don’t support EDNS is FORMERR. 

That said there is no reason for any nameserver  to not support EDNS.  Its been well over 20 years since EDNS was introduced and it only takes a couple of extra lines of code to have a conforming implementation. You don’t need to understand any options or EDNS flags. Ignoring unknown options is correct behaviour as is setting all the flags to zero in replies (if you don’t understand DNSSEC then DO is mot copied). You don’t have to use a bigger UDP buffer. You do need to check the version field but that is about all.  Sending back FORMERR rather than an EDNS response just doubles you traffic levels.
-- 
Mark Andrews

> On 6 Oct 2021, at 23:30, Martin George <Martin.George at nominet.uk> wrote:
> 
> 
> Hiya all,
>  
> I’m investigating an issue that is affecting a client of ours, they are seeing a high number of SERVFAILs for queries send to various children zones of .mail.protection.outlook.com. I’ve noticed that when querying for mail.protection.outlook.com, and any child zones, directly against the authoritative nameservers listed in the nameserver records for that zone, I see a FORMERR response code and a warning that requests the disabling of EDNS when querying.
>  
> To provide an example, I query the internet for the nameserver records of mail.protection.outlook.com, I’ve used Cloudflare to ensure that our corporate resolvers had no impact on the result.
>  
> ❯ dig mail.protection.outlook.com NS @1.1.1.1
>  
> ; <<>> DiG 9.17.9 <<>> mail.protection.outlook.com NS @1.1.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25269
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>  
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;mail.protection.outlook.com.   IN           NS
>  
> ;; ANSWER SECTION:
> mail.protection.outlook.com. 10               IN           NS          ns1-proddns.glbdns.o365filtering.com.
> mail.protection.outlook.com. 10               IN           NS          ns2-proddns.glbdns.o365filtering.com.
>  
> ;; Query time: 56 msec
> ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
> ;; WHEN: Wed Oct 06 11:39:15 BST 2021
> ;; MSG SIZE  rcvd: 129
>  
> Then querying mail.protection.outlook.com against ns1-proddns.glbdns.o365filtering.com, I expect to see an SOA, but instead I see a FORMERR
>  
> ❯ dig mail.protection.outlook.com soa @ns1-proddns.glbdns.o365filtering.com.
>  
> ; <<>> DiG 9.17.9 <<>> mail.protection.outlook.com soa @ns1-proddns.glbdns.o365filtering.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 10885
> ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>  
> ;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'
>  
> ;; Query time: 26 msec
> ;; SERVER: 104.47.72.81#53(104.47.72.81) (UDP)
> ;; WHEN: Wed Oct 06 11:41:06 BST 2021
> ;; MSG SIZE  rcvd: 12
>  
> I was wondering if anyone else has noticed this behaviour previously, and could provide any reasoning behind it? Is anyone else seeing failures with queries for mail.protection.outlook.com and any child zones of the aforementioned?
>  
> Many thanks!
>  
> --
> Martin George
> DNS Engineer
> Nominet UK
>  
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211007/cb880e0d/attachment.html>