In message <CAEKtLiQnYWet6BxzhzpDXUBvg6Ujx==TF5FZ+G=bg2wupzo...@mail.gmail.com> , Casey Deccio writes: > On Mon, May 4, 2015 at 9:38 AM, Chris <cpoll...@embarqmail.com> wrote: > > > I've just finished setting up Bind as a local caching name server to > > work in conjunction with my Spamassassin setup. I did this because > > queries to uribl.com were getting blocked probably due to my ISPs > > reputation for spam. It seems to be working great, no more of the > > blocked queries to uribl.com however I am seeing a lot of this: > > > > error (unexpected RCODE REFUSED) resolving > > 'b4d44f4bcc9ddf0e61605920116ce915.ctyme.ixhash.net/A/IN': > > 62.75.209.50#53 > > error (unexpected RCODE REFUSED) resolving 'getcreations.com/AAAA/IN': > > 192.185.149.195#53 > > error (connection refused) resolving > > '185.130.201.205.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 > > error (connection refused) resolving > > '185.130.201.205.dnsbl.sorbs.net/A/IN': 174.36.235.174#53 > > > > > > this is a query to a domain I own > > > > error (unexpected RCODE REFUSED) resolving 'toadnet.com/AAAA/IN': > > 207.218.247.135#53 > > > > Do I have something in my setup incorrect? > > > > Hi Chris, > > The problem is not with your resolver, but with the zones/servers it is > contacting. Take toadnet.com, for example. The delegation records in the > .com zone are these: > > $ dig +noall +authority @a.gtld-servers.net toadnet.com ns > toadnet.com. 172800 IN NS ns2.ev1servers.net. > toadnet.com. 172800 IN NS ns1.ev1servers.net. > toadnet.com. 172800 IN NS ns1.ecdiscounts.com. > > and the authoritative records in the toadnet.com zone are these: > > $ dig +noall +answer @ns1.ecdiscounts.com toadnet.com ns > toadnet.com. 86400 IN NS ns2.usdcservers.net. > toadnet.com. 86400 IN NS ns1.usdcservers.net. > > But the ev1servers.net servers are not properly set up to respond for the > toadnet.com zone: > > $ dig +noall +comments @ns1.ev1servers.net toadnet.com ns > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43670 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > > In your case, looks like you probably need to clean up the delegation > records in the parent zone through your registrar to match the ones in your > child zone. Others would need to do similarly, depending on their > situation. > > Cheers, > Casey
This is also the sort of things that parent zone operators are *supposed* to be checking for (this includes TLD operators) and arranging for the delegation to be fixed. Note the key word "both" in the instructions below. None of the TLD operators started managing zones before RFC 1034 was published thus they ALL should be doing this. RFC 1034 4.2.2. Administrative considerations As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. Being "lazy" is not a good reason for not following the should. Not being able to directly contact the registrant is not a good reason to not ensure the checking is being performed. Getting complaints because you reported inconsistencies is not a good reason to not do the checking. Yes, I've heard a number of lame excuses why TLDs are not doing this checking. In the end because the TLD did not do this checking everybodies time on this list got wasted dealing with the fallout of not doing the checks and following up. If you want to get the money do the job you are being paid to do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
