This feature moved to f15. Will revisit for that.

reopening for the 2010-09-07 meeting.

+1

(Note: I won't be able to make it for the meeting tonight, so I vote here)

We have some questions on the feature talk page.

Also, would like to know the status of coordination with NM owner about this. He's planning on using dnsmasq. Will this work?

Any news here from feature owners?
It would be good to move this forward...

This should be taken up with others, because it seems dnsmasq is becoming the default resolver, and it does not support DNSSEC.

Personally, I'd like to see dnsmasq limited to the KVM/qemu setups, and having the system resolver be fully DNSSEC aware with either bind or unbound.

All the support with root and dlv keys are in both the bind and unbound packages.

ok, so ways forward:

a) just drop the feature.

b) convince NM and libvirt folks to use something instead of dnsmasq.

c) Add dnssec support to dnsmasq

Thoughts? Would feature owners care to persue any of those?

Replying to [comment:7 kevin]:

ok, so ways forward:

a) just drop the feature.

I'd rather not...

b) convince NM and libvirt folks to use something instead of dnsmasq.

They need dns+dhcp, so its prob significant to have them move to bind/unbound+dhcpd

c) Add dnssec support to dnsmasq

That's not trivial. I am not sure what the dnsmasq authors have planned. the smart way would be to use ldns or better libunbound. Still, a lot of work.

Thoughts? Would feature owners care to persue any of those?

d) See if NM/libvirtd can stay away from the system resolver

I believe they are mostly using it because they want a dns+dhcp server for the VM. They should do so on one of their own interfaces/IP addresses (virbrX) and perhaps configure dnsmasq to use the system resolver as a forwarder (so they enjoy dnssec protection too from the system resolver)

Also, I know unbound can be told about a new resolver dynamically (via unbound-control remote) so NM obtaining a new DNS server via DHCP can be communicated to unbound. But I am not sure if Fedora is ready to make unbound the stock system dnssec resolver over bind. I don't think bind can dynamically update the forwarders.

I'd still be interested in an irc/voip meeting with the people involved and do some brain storming on this.

NM 0.8.2+ (which will ship for F15) has support for local caching nameserver, using either bind or dnsmasq. Unfortunately the bind plugin doesn't quite work yet, because I haven't had a chance to sit down and figure out the absolutely byzantine bind config syntax for a simple caching nameserver use-case. But if the bind plugin got fixed up, I"m sure it would be trivial to add support for local caching nameserver. I'd prefer not to add a UI checkbox for this, since in talking to our bind maintainer DNSSEC is not for everyday consumption yet, so for now it would simply be a global config-file option. But I'm happy to do that much if I can get somebody to help me out with the NM bind caching nameserver config.

We should look at it also getting an unbound plugin....

I don't know much about NM, but I could try and help you out on fixing the bind plugin.

As for DNSSEC, I don't agree if that's what Adam said. Now that the root is signed and deployed, and about 20 TLD's are signed, I think we're pretty much in "everyday consumption".

Ping me on irc (letoams) if you want to work on this.

Whats the status of this feature?

Any news here?

No news from my end. How about we try and schedule a irc/voip meeting with the people involved. Eg Adam Atrak (bind), me (unbound) and the NM people ?

Adding dcbw here for comment. He would be the one to meet with you guys from NM. ;)

I updated the feature page.

Some time ago I discussed BIND and NetworkManager integration with Dan Williams and we decided to improve the BIND plugin, I will handle this task before beta freeze.

As Paul pointed above (11/16/10 22:09:20 changed by pwouters) BIND won't conflict with libvirtd's dnsmasq setup.

This feature was approved at the 2011-01-26 meeting.