The first time it is run, neat copies the current running config as the default profile in /etc/sysconfig/networking/ including resolv.conf file. However, this file may have been generated off of dhcp/bootp info, in which case it shouldn't be archived at all, let alone as a persistent default configuration. This is especially disconcerting when traveling between different networks, and foreign DNS servers suddenly start appearing in the currently running firewall rules!
you are right...
But no one can detect, if the current resolv.conf is a good one... Besides, you can reconfigure with neat the standard settings, which then will be saved over the first copied version.
Sure you could - the dhcp config scripts just need to add a line something like # generated by DHCP - don't touch this line or this file won't get updated anymore to /etc/resolv.conf. If this line exists, DHCP can muck with the file, if it doesn't, the admin edited the file and it should be considered static and left alone by DHCP and editable by neat.
Or how about this - add a new config element to each networking profile that allows specification of which device should be allowed to control resolv.conf via DHCP. set to device name (eth0, ppp0, etc) -> only DHCP responses from that device get reflected in resolv.conf set to 'any' -> DHCP responses from any interface get reflected in resolv.conf In either of these two cases, resolv.conf would be considered dynamically created data, and uncachable by neat. set to 'none' -> no DHCP responses touch resolv.conf. This file would now be considered a static config file, suitable for copying around into different profiles, and responsability for updating would lie with the system administrator.