Two separate replies for one query to some domains

[Mark Andrews]

In message <201005030503.49752.jzb2 at aexorsyst.com>, "John Z. Bohach" writes:
> Hello,
> 
> I'm trying to run a local caching-only nameserver (bind-9.3.3) on Linux 
> in order to bypass my ISP's name-servers, and most things work fine, 
> except some domains behave strangely.
> 
> For example, forecast.weather.gov has a TTL of 5 seconds.
> 
> My initial look-up works correctly, and the response is in fact cached 
> for 5 seconds.  After 5 seconds, another look-up sequence is initiated, 
> but this time, the look-up fails.
> 
> I ran ethereal to get a packet trace, and what I find is that the first 
> query's response is fine, as expected.  Further lookups within the 5 
> second TTL don't generate any external traffic, as expected.
> 
> However, after 5 seconds, another look-up sequence is initiated, but 
> this time the response is as follows:
> 
> First response is an OPT RR, with some fairly useless information, as 
> far as I can tell.  Socket is then closed, likely from my end.
> 
> Second response (without any further queries from my end), about 300 - 
> 500 milliseconds after the first response, contains the correct 
> response sequence to get further towards the resolution (next resolver, 
> etc.).  Problem is, by this point, the socket was closed, and 
> bind-9.3.3 went away with the OPT RR which is not really an answer, and 
> thus ignores the second response, which would get to the correct 
> answer, had it been received, instead of hitting a closed socket.  So I 
> get a failed look-up error.  Trace shows second response was dropped.
> 
> To overcome this, I've forced all outgoing queries to originate from 
> port 53 as well, but even though that seems to receive the second 
> response (server listens on 53), it seems to get discarded as only the 
> first response (OPT RR) seems to get processed, which still results in 
> a failed look-up.
> 
> And now, the icing on all of this is that after 100 seconds of failure, 
> the forecast.weather.gov site responds correctly, without any 
> intermeditate OPT RR, and resolution succeeds.  This caches the 
> response for the TTL of 5 seconds, and this whole thing starts over, 
> with 100 seconds of OPT RR + correct (but ignored by bind) RR, then 
> correct RR only (and success), and repeats.
> 
> Is this something in my configuration?  Is this a *.weather.gov problem?  
> Or is it just that my ISP is messing with my packets?  Or is this just 
> my tax-dollars at work?  A few other sites have similar problems, all 
> with extremely short TTL's (but the vast majority of domains work 
> correctly), was just wondering how I could get around this.  If I set 
> my resolver to my ISP's, the *.weather.gov sites initially respond with 
> a TTL of 5 seconds, but afterwards, all have TTL's in 90's for 
> subsequent look-ups.
> 
> Could someone else comment on any experience with the *.weather.gov 
> domains?
> 
> Thank You,
> John Z. Bohach
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

I don't see any additional packets though one of the servers is not
reachable (ssmc.gslb.weather.gov).  The servers that are reachable
incorrectly set "rd" in the response when "rd" is not set in the
query. "rd" is supposed to be copied from the query to the response.
I don't know how load balancee vendors get this sort of thing wrong
unless they have never read the RFC's.  It doesn't matter how fast
you are when the answer is wrong.

; <<>> DiG 9.7.0 <<>> forecast.weather.gov @boulder.gslb.weather.gov +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47607
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;forecast.weather.gov.		IN	A

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47607
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;forecast.weather.gov.		IN	A

;; ANSWER SECTION:
forecast.weather.gov.	5	IN	A	216.38.80.20

;; Query time: 200 msec
;; SERVER: 140.172.7.194#53(140.172.7.194)
;; WHEN: Tue May  4 08:17:44 2010
;; MSG SIZE  rcvd: 54

I suspect your extra packet problem is closer to home.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org