Strange DNS resolving behavior

[Kerry Liles]

ouch!  Good catch in the end!!


"John Manly" <jwmanly at amherst.edu> wrote in message
news:c66p2v$ti3$1 at sf1.isc.org...
> OK, we figured it out.  But it was such a nasty problem that I thought
> this list might appreciate what happened.  Way back when Blaster and
> Nachi came out we took Cisco's advice and set up something called a
> route-map statement to block packets that the Nachi virus was using to
> help find new targets.  The statement in essence said "if an inbound
> packet is an icmp echo or icmp echo-reply, and it's length is exactly 92
> bytes, drop it".  This statement had been enabled for months with no
> problem.
>
> But then, a few days ago, we made a typo in the course of some other
> work that Cisco's IOS didn't complain about, and as a result, we were
> dropping ALL packets of length 92 (the clause "must be an icmp packet"
> had been turned into a noop by the typo.)  And yes, it just so happened
> that DNS queries from both Dig and NSLOOKUP for
> "amherst.publishingconcepts.com" resulted in responses from certain
> nameservers that were exactly 92 bytes long, so these responses never
> made it through to us.
>
> You can see why this was so frustrating to debug: only responses to
> queries for certain names (amherst.publishingconcepts.com being one of
> them) from certain DNS resolvers (in particular the listed servers for
> publishingconcepts.com itself) had this precise size.  But queries for
> other names to the same servers, or for the same name but to other
> resolvers, didn't hit the magic size and thus worked fine.  And things
> were further complicated because I didn't realize that Genuity's servers
> that provide secondary DNS service for us are "authoritative only" and
> nonrecursive, so some of my testing made it look like their resolvers
> were having the same problem, which is what made me think it wasn't just
> a local problem to my campus.
>

///snip