Re: Resolver problems

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 4 Dec 2009 08:10:36 -0600 (CST)
    From:        "Jeremy C. Reed" <reed%reedmedia.net@localhost>
    Message-ID:  
<alpine.NEB.2.01.0912040732430.12658%t1.m.reedmedia.net@localhost>

The various points in this message seem to be being missed everywhere...

  | On Thu, 3 Dec 2009, Ingolf Steinbach wrote:
  | 
  | > >> 2) Re-writing the source port number of the faulty UDP packets.

Yes, you probably could do that, but I have no idea how to make
PF (or ipf) do it (never needed that).

  | > > I am curious how any DNS client would use a response from it. It
  | > > should not be trusted.

I believe whoever it was who asked that question was asking how the
bogus replies are ever being successfully used by anyone - and I suspect
that the answer is, that they aren't - but that only AAAA responses are
being sent from the bogus port (for some weird reason - perhaps the router
has a small set of DNS types that it knows how to handle in its main
loop - I'd guess it might be doing NAT translation of DNS replies or
something odd like that - and for other types it doesn't know it punts the
query to some other internal process to handle, and that one sends the
reply from a bogus port.)

It would be interesting to do a query for some other "strange" RR type
(perhaps one of the DNSSEC type - it shouldn't matter if data will be
returned or not, as long as the name queried is valid so it isn't an
error response) and see if similar broken behaviour is observed.

  | > The DNS client would not be able to detect that the source port was
  | > "corrected", would it?

No, it wouldn't be able to tell if the rewriting was done correctly.

  | It should detect it. It is a sign of spoofed data. For example, dig (as 
  | a client) would complain, like:
  | 
  |  ;; reply from unexpected source: 10.10.2.6#10028, expected 10.10.2.7#53

That's when you receive a reply from a bad port - that is being detected now,
and that's what was causing the problem, the question related to what would
happen if something modified the incoming packet, before it reached the
resolver, to change the source port back to 53.   If that could be done,
then it would not be detectable as fake, and should be correctly received.

Of course, I believe that now an alternative solution (avoiding using the 
broken router as a DNS cache) has been implemented, so there's little point 
attempting to find a way to deal with this weirdness (though, Ingolf, you
could tell us what the broken router is, so everyone else can at least know
to avoid the thing should it ever be a candidate to be installed).

For the rest of this, the more general philosophical discussion, that's
all happening on tech-net (and cc'd to netbsd-users, though that should stop)
under the seeming guise of a discussion of PR 42405 (though none of it
is going to gnats any more.)

kre