[dns-operations] need someone else to look at these servers

[Mark Andrews]

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 <543D9ED7.3020303 at lcrcomputer.net>, 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
> dns-operations at lists.dns-oarc.net
> 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: marka at isc.org