The servers (or the firewalls in front of them) are not RFC 103[45] compliant. DNS is a query/response protocol. If you don't get a response the server is broken. It shouldn't matter what is in the packet including complete garbage as long as it is 12 bytes or bigger and the qr bit is set to zero. If you can't parse the packet, you *construct* a response which is just the DNS header with the rcode set to FORMERR, the id set to that of the query and qr set to 1, aa set to 0, aa set to 0, ad set to 0, rd copied, ra set as appropriate (not that it really matters), cd copied if you support DNSSEC otherwise set to 0, z set to 0. This isn't rocket science. It is not hard to do this.
Report the problem to them. If they do not fix the problem in a reasonable amount of time followup with the rest of the steps listed in RFC 1033. Yes, I do mean excommunicate zones that can't handle getting a EDNS query, or can't handle AD being set to 1 in the query. If the firewall doesn't like a query it should be generating a reply on behalf of the server. That said there is no valid reason to block well formed EDNS queries or queries with reserved bits set or to block EDNS queries with version set to a value other than zero or to block EDNS options especially 15 years after EDNS was first deployed. None of these things should cause a problem to a nameserver and while there are plenty of servers returning bad responses to these sorts of queries (FORMERR or BADVERS incorrectly) they stay up and continue running. If they do then the block should be temporary while the problem is addressed. The blocks definitely should not be on by default. RFC 1033 COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain. Mark In message <[email protected]>, Lyle Giese writes: > A customer is trying to send email to a customer that is using > secureserver.net for email. > > Their MX record points to presmtp.ex3.secureserver.net. > > This is where things get screwy. > > Dig(+trace) shows that presemtp.ex3.secureserver.net has the following > auth servers: > > gns1.secureserver.net > gns2.secureserver.net > gns3.secureserver.net > > However when I query these servers directly using dig, I get back No > servers could be reached. > (dig @gns1.secureserver.net presmtp.ex3.secureserver.net) > > When I use +notcp option, I get back: > > Warning: EDNS query returned status FORMERR - retry with '+noedns'. > > If I use +notcp and +noedns, it works and I get the A record. > > If I use +noedns, it works and I get the A record. > > Am I doing something wrong or are their servers/load balancers screwed > up? I know something is wrong, but would like someone with a bit more > knowledge to look at this and give their opinion. > > Thanks, > Lyle Giese > LCR Computer Services, Inc. > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
