Re: Bind Configuration

      moin moin,
          Butash so:
            any sort of public dns - anything greater than 1500 bytes
            (ie most domain-keys//spf records), and also any
          True, if you're doing those things, you might have large dns
          payloads and
          need tcp. If you think they cause problems rather than fixing
          them, then
          ...
        "Normal" use of these yes, but imho better just to leave it be
        serviced anyways, especially if any sort of provider for others.
      Yeah, I suppose I pre-optimized and presumed this would be home,
      non 3rd
      party use for Keith.
    I just bring it up as I've had "security experts" say to block
    things like that and icmp in more of a service-provider or servicing
    capacity, and experience has just told me best to leave it be as a
    natural thing for dns and networking in general.  Often makes for
    more complication and problem than you're fixing ultimately if
    ramifications are not understood.
            that keep 400gb DDoS at bay) use that to
          What would anomaly mitigation gear be doing to cause large dns
          payloads?
          That's a serious question as I don't even know what anomaly
          mitigation
          gear is.
        It's not a large payload issue, it's a method of them validating
        who is a script opening a raw udp socket to spew junk, etc vs. a
        "real" RFC-compliant client by sending that truncate bit back to
        the client, making them request via tcp, and thus doing
        something more than legit aiming a cannon.
      Hmm, this isn't making sense to me. Are you saying a client makes
      a
      request to your dns service and you force the client over to tcp
      lookups?
      If so, does that cause the rest of the recursive lookup to other
      servers
      to be tcp as well?
    So if I remember the rfc process right, client requests record, that
    ends up being like a domain key over 512 bytes, server sends back a
    truncate message, basically "too large a reply, resend via tcp pls
    so I can fragment it".  Client then does, and normally gets their
    big dns record in a few chunks.
    Better yet, cut and paste from rfc:
    Old Cisco anomaly mitigation appliances did that, and later Arbor
    tms and most other software that auto-mitigate dns attacks, as it's
    one of the few ways you can "challenge" a client to interact back in
    such a way you can identify whether it's a real client request or a
    raw socket bit-blast at udp/53 pr other.  
    They have interesting ways of challenging other protocol behavior as
    well to verify who's real or not.
        It also broke some remote providers that blocked tcp/53 as well
        for some reason when our devices couldn't "validate" them,
        adding them to a drop list vs. whitelisting them as "valid"
        clients.
      Did those remote providers block tcp/53 for client or just for
      server (
      only incoming syn blocks )?
    Well, I remember one instance we had to reach out to road runner
    cable engineers because they were blocking tcp/53 requests for their
    customer dns resolvers, and suddenly a large swatch of their
    customer base couldn't resolve anything hosted by us when our ddos
    appliances blacklisted them as an attacker (2 addresses doing a
    _lot_ of requests interpreted as bad, which at the time we had some
    50mil domains under us, so it was felt).  They opened it, but we had
    to whitelist them specially until then.
    Pedantic things you learn over the years that stick with you.
      der.hans

This message is part of the following thread:
	the complete thread tree sorted by date
	Keith Smith at