...

It could just be a nameserver querying your nameserver while the source port to use has been configured to 53. This isn't usually the case, but some admin just might have thought that it is a good idea. I wouldn't do it because it obfuscates the logs.

O.K., if I'm on the right trip, udp requests are not bad and its no real hole if i allow them.

Caution: Some buffer overflows happened in the past when reading data from a udp socket. The protocol doesn't really matter when it comes to dealing with data from an untrusted source. The fact that the attack may or may not be more difficult doesn't change anything about the fact that it is indeed an attack. Even if you make sure that you only see packets from source port 53 _and_ from your nameserver, this isn't reason enough to trust them - somebody else might have sent them, disguising himself behind the ip address of the nameserver. The bare purpose of dns cache poisoning might be sufficient in a weak setup.

...

If it's tcp and not udp, then someone might have tried to get zone files from you. Then it is interesting, _who_ did that, with which reason.

whats so bad about other people can accessing my zone files? I thought the should do this in order to resolve the Hostname...

Distinguish between a single dns request (of a single record) and a request to transfer the complete zone. Zone transfers are usually done using port 53 TCP, not udp, so that makes them easier to filter. It's better though to enable xfers for the slave nameservers only.

Or is there only a risk when you have 'internal' zone files on this NS (that's not the case...)?

The information contained therein. Depends on the content on whether to worry about or not.

Thanks for help.

You're welcome.

Max

Thanks, Roman. -- - - | Roman Drahtmüller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -