named[1095]: error (unexpected RCODE REFUSED)

[Mark Andrews]

In message <CAEKtLiQnYWet6BxzhzpDXUBvg6Ujx==TF5FZ+G=BG2wupZoNJQ at mail.gmail.com>
, Casey Deccio writes:
> On Mon, May 4, 2015 at 9:38 AM, Chris <cpollock at 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: marka at isc.org