Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/17/2012 09:35 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2012 01:02 PM, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza In the end, I choose a more liberal approach and instead of defining a more stricter validator for IPv4 only I rather used approach already implemented in the installers, i.e. default length of network prefix is 24 for IPv4 and 64 for IPv6. Updated patch attached. Martin Works for me. I wonder if this is a candidate for some more unit tests... rob One more test should not hurt. Updated patch attached. Martin From 8e9908b4c4d22921227ed4a10adb780a88821043 Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Wed, 5 Sep 2012 09:56:27 +0200 Subject: [PATCH] Use default reverse zone consistently When a new reverse zone is to be generated based on an IP address without a network prefix length, we need to use some default value. While netaddr library default ones (32b for IPv4 and 128b for IPv6) are not very sensible we should use the defaults already applied in installers. That is 24b for IPv6 and 64 for IPv6. Test case has been added to cover the new default. https://fedorahosted.org/freeipa/ticket/2461 --- install/tools/ipa-dns-install| 2 +- install/tools/ipa-replica-install| 2 +- install/tools/ipa-server-install | 2 +- ipalib/plugins/dns.py| 11 +++- ipalib/util.py | 18 ipaserver/install/bindinstance.py| 20 ++--- tests/test_xmlrpc/test_dns_plugin.py | 54 ++-- 7 files changed, 78 insertions(+), 31 deletions(-) diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install index d4795f72e03eed1b460a3751fc5596ac6da70900..84d1bdc2eb5729896ecb62f65feb11122aacf77d 100755 --- a/install/tools/ipa-dns-install +++ b/install/tools/ipa-dns-install @@ -213,7 +213,7 @@ def main(): else: reverse_zone = bindinstance.find_reverse_zone(ip) if reverse_zone is None and not options.no_reverse: -reverse_zone = bindinstance.get_reverse_zone_default(ip) +reverse_zone = util.get_reverse_zone_default(ip) if not options.unattended and bindinstance.create_reverse(): reverse_zone = bindinstance.read_reverse_zone(reverse_zone, ip) diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index 267a70d8b60d96de9a9bde83b15c81ae59da1a96..57a8de16344821ad142a820d7c84a4b31a1fe274 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -222,7 +222,7 @@ def install_bind(config, options): else: reverse_zone = bindinstance.find_reverse_zone(config.ip)
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
Martin Kosek wrote: On 09/17/2012 09:35 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2012 01:02 PM, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza In the end, I choose a more liberal approach and instead of defining a more stricter validator for IPv4 only I rather used approach already implemented in the installers, i.e. default length of network prefix is 24 for IPv4 and 64 for IPv6. Updated patch attached. Martin Works for me. I wonder if this is a candidate for some more unit tests... rob One more test should not hurt. Updated patch attached. Martin ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/19/2012 05:30 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/17/2012 09:35 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2012 01:02 PM, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza In the end, I choose a more liberal approach and instead of defining a more stricter validator for IPv4 only I rather used approach already implemented in the installers, i.e. default length of network prefix is 24 for IPv4 and 64 for IPv6. Updated patch attached. Martin Works for me. I wonder if this is a candidate for some more unit tests... rob One more test should not hurt. Updated patch attached. Martin ACK Pushed to master, ipa-3-0. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
Martin Kosek wrote: On 09/05/2012 01:02 PM, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza In the end, I choose a more liberal approach and instead of defining a more stricter validator for IPv4 only I rather used approach already implemented in the installers, i.e. default length of network prefix is 24 for IPv4 and 64 for IPv6. Updated patch attached. Martin Works for me. I wonder if this is a candidate for some more unit tests... rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/05/2012 01:02 PM, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza In the end, I choose a more liberal approach and instead of defining a more stricter validator for IPv4 only I rather used approach already implemented in the installers, i.e. default length of network prefix is 24 for IPv4 and 64 for IPv6. Updated patch attached. Martin From 0a12edd4b3ef6763ffdb10fe996ba667b528df6d Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Wed, 5 Sep 2012 09:56:27 +0200 Subject: [PATCH] Use default reverse zone consistently When a new reverse zone is to be generated based on an IP address without a network prefix length, we need to use some default value. While netaddr library default ones (32b for IPv4 and 128b for IPv6) are not very sensible we should use the defaults already applied in installers. That is 24b for IPv6 and 64 for IPv6. https://fedorahosted.org/freeipa/ticket/2461 --- install/tools/ipa-dns-install | 2 +- install/tools/ipa-replica-install | 2 +- install/tools/ipa-server-install | 2 +- ipalib/plugins/dns.py | 11 ++- ipalib/util.py| 18 ++ ipaserver/install/bindinstance.py | 20 ++-- 6 files changed, 33 insertions(+), 22 deletions(-) diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install index d4795f72e03eed1b460a3751fc5596ac6da70900..84d1bdc2eb5729896ecb62f65feb11122aacf77d 100755 --- a/install/tools/ipa-dns-install +++ b/install/tools/ipa-dns-install @@ -213,7 +213,7 @@ def main(): else: reverse_zone = bindinstance.find_reverse_zone(ip) if reverse_zone is None and not options.no_reverse: -reverse_zone = bindinstance.get_reverse_zone_default(ip) +reverse_zone = util.get_reverse_zone_default(ip) if not options.unattended and bindinstance.create_reverse(): reverse_zone = bindinstance.read_reverse_zone(reverse_zone, ip) diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index 267a70d8b60d96de9a9bde83b15c81ae59da1a96..57a8de16344821ad142a820d7c84a4b31a1fe274 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -222,7 +222,7 @@ def install_bind(config, options): else: reverse_zone = bindinstance.find_reverse_zone(config.ip) if reverse_zone is None and not options.no_reverse: -reverse_zone = bindinstance.get_reverse_zone_default(config.ip) +reverse_zone = util.get_reverse_zone_default(config.ip) if not options.unattended and bindinstance.create_reverse(): reverse_zone = bindinstance.read_reverse_zone(reverse_zone,
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On Wed, Sep 05, 2012 at 01:02:35PM +0200, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. You are right, IPv6 networks could have default /64 prefix. However as I wrote in different mail, I don't recommend to use default IPv4 prefix at all because FreeIPA targets for company environments where /24 is not so common, not for home environments. The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/05/2012 01:06 PM, Adam Tkac wrote: On Wed, Sep 05, 2012 at 01:02:35PM +0200, Jan Cholasta wrote: Dne 5.9.2012 12:48, Martin Kosek napsal(a): On 09/05/2012 12:36 PM, Jan Cholasta wrote: Dne 5.9.2012 12:22, Petr Spacek napsal(a): On 09/05/2012 11:30 AM, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Hello, I don't like automatic netmask guessing. I have met class-based guessing in Windows (XP?) and I was forced to overwrite default mask all the time ... If there was no guessing, you would have to write the netmask anyway, so I don't see any harm in guessing here. IMHO there is no sensible default prefix in real world. I sitting on network with /23 prefix right now. Also, I have never seen 10.x network with /8 prefix. While this might be true for IPv4 in some cases, /64 is perfectly sensible for IPv6. Also, I have never seen 192.168.x.x network with non-/24 prefix. Honza While this may be true for 192.168.x.x, it does not apply for 10.x.x.x networks as Petr already pointed out. I don't think that there will be many people expecting that a reverse zone of 10.0.0.0/24 would be created. And they would be correct, because the default prefix length for a class A network is /8, not /24. And since FreeIPA is mainly deployed to internal networks, I assume this will be the case of most users. Martin OK, but what about IPv6? Correct me if I'm wrong, but the prefix length is going to be /64 99% of the time for IPv6. You are right, IPv6 networks could have default /64 prefix. However as I wrote in different mail, I don't recommend to use default IPv4 prefix at all because FreeIPA targets for company environments where /24 is not so common, not for home environments. I think now most of us agree on that automatic prefixes does not make much sense for IPv4. But do we really want to introduce different behavior in this case for IPv4+IPv6 network validation and allow automatic prefix only for IPv6 only? The installer uses /24 for IPv4 addresses and /64 for IPv6 addresses, maybe this should be used as a default here as well. Yeah, it would make sense to do this change also for installer to make them consistent. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On 09/05/2012 01:18 PM, Martin Kosek wrote: You are right, IPv6 networks could have default /64 prefix. However as I wrote in different mail, I don't recommend to use default IPv4 prefix at all because FreeIPA targets for company environments where /24 is not so common, not for home environments. +1 I think now most of us agree on that automatic prefixes does not make much sense for IPv4. But do we really want to introduce different behavior in this case for IPv4+IPv6 network validation and allow automatic prefix only for IPv6 only? +1 Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 302 Stricter IP network validator in dnszone-add command
On Wed, 2012-09-05 at 11:30 +0200, Jan Cholasta wrote: Dne 5.9.2012 10:04, Martin Kosek napsal(a): We allowed IP addresses without network specification which lead to unexpected results when the zone was being created. We should rather strictly require the prefix/netmask specifying the IP network that the reverse zone should be created for. This is already done in Web UI. A unit test exercising this new validation was added. https://fedorahosted.org/freeipa/ticket/2461 I don't like this much. I would suggest using CheckedIPAddress and not forcing the user to enter the prefix length instead. CheckedIPAddress uses a sensible default prefix length if one is not specified (class-based for IPv4, /64 for IPv6) IPv4 classes were already dead and not relevant last century Jan, so class-based netmask is really useless, if we want to use a default for ipv4 I would use /24 for any address, that's the simplest guess you can make ,a nd will still be often wrongt, but certainly less wrong than using the outdated 'class' concept. Simo. as opposed to IPNetwork (/32 for IPv4, /128 for IPv6 - this causes the erroneous reverse zones to be created as described in the ticket). Honza -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
