| elvsp1n | Hi Gents | 00:14 |
|---|---|---|
| elvsp1n | I am looking at the documentation for reverse dns using designate | 00:17 |
| elvsp1n | https://docs.openstack.org/designate/latest/user/manage-ptr-records.html | 00:17 |
| eandersson | If you want to integrate it with Neutron you can look at this guide too https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html#config-dns-int-ext-serv | 00:20 |
| eandersson | https://docs.openstack.org/neutron/latest/admin/config-dns-int.html | 00:20 |
| elvsp1n | I have it integrated with neuntron already | 00:21 |
| elvsp1n | here is the problem | 00:21 |
| elvsp1n | it seems like designate was not created to work with subnet smaller than /24, meaning that if I get a public subnet delegated of /25 using 98.91.186.0/25, designate won't allow me to create a zone with / on its name | 00:21 |
| elvsp1n | for example, trying to create this zone: 0/25.186.91.98.in-addr.arpa. it says that the name is invalid | 00:22 |
| johnsom | That is a setting in the neutron extension | 00:24 |
| elvsp1n | after att delegated my static block of ip to my dns, doing a reverse dns it returns 93.186.91.98.in-addr.arpa. 86400 INCNAME93.0/25.186.91.98.in-addr.arpa. | 00:25 |
| elvsp1n | johnsom, I saw that as well but here is what the description says: | 00:25 |
| elvsp1n | ipv4-ptr-zone-prefix-size: default: 24 description: | The size in bits of the prefix for the IPv4 reverse lookup (PTR) zones. Valid size has to be multiple of 8, with maximum value of 24 and minimum value of 8. . NOTE: Use only when "reverse-dns-lookup" option is set to "True". source: default type: int value: 24 | 00:27 |
| elvsp1n | juju config neutron-api | 00:27 |
| elvsp1n | default: 24 | 00:27 |
| elvsp1n | description: | | 00:28 |
| elvsp1n | The size in bits of the prefix for the IPv4 reverse lookup (PTR) zones. Valid size has to be multiple of 8, with maximum value of 24 and minimum value of 8. . NOTE: Use only when "reverse-dns-lookup" option is set to "True". | 00:28 |
| elvsp1n | Valid size has to be multiple of 8, with a maximum value of 24...... | 00:28 |
| elvsp1n | neutron-api won't allow me to use 25 | 00:28 |
| elvsp1n | designate allow me to create a zone with - on it, for example: 0-127.186.91.98.in-addr.arpa. | 00:32 |
| elvsp1n | but when att return the CNAME 93.0/25.186.91.98.in-addr.arpa. , designate do not respond to the query | 00:32 |
| elvsp1n | I have designate integrated with designate-bind | 00:33 |
| elvsp1n | I was able to deploy another server with bind9 only and was able to create a zone with the name 0/25.186.91.98.in-addr.arpa. which return the ptr record defined | 00:34 |
| elvsp1n | which mean that bind9 support it without problems, my question is, why designate doesn't? or if there is a way to make it accept it, how I might be able to do it? | 00:35 |
| johnsom | Smaller values in neutron means it makes more granular zones in designate | 00:45 |
| elvsp1n | johnsom, are you sure about it? My understanding is that the configuration for neutron-api ipv4-ptr-zone-prefix-size is related to the Netmask Length (also called a prefix) which mean that 24 = 0-255 (or 256 ips), 16 = 65,536 ips and 8 = 16,777,216 ips...... | 00:53 |
| elvsp1n | I currently have assigned a block of 128 ips (/25), can you share an example of what you mean by your statement: "Smaller values in neutron means it makes more granular zones in designate" ? | 00:55 |
| johnsom | I am not 100% sure as I have not used that extension much. But it should be able to handle small subnets. We do in designate | 00:57 |
| elvsp1n | I undestand, do you have a public ip with a subnet smaller than 256 ip (/24) that I can query to see if the reverse dns is actually working having the subnet delegated from an ISP by returning a CNAME with the information about the subnet delegation? | 01:05 |
| elvsp1n | btw johnsom, I am currently able to define my external subnet (/25) in neutron, I am able to get a floating ip and it works as expected and also, designate creates the ptr record for reverse dns without problems. The issue comes when the subnet is delegated from the ISP, as they are only able to allocate /25 subnets, having them delegate my /25 subnet to my dns (designate-bind), in order to make it work with all public dns, I need to create a zone as | 01:06 |
| elvsp1n | 0/25.186.91.98.in-addr.arpa. | 01:06 |
| elvsp1n | here is an example that you can take a look at | 01:07 |
| elvsp1n | in your computer (terminal), having it connected to the internet, run the following: | 01:07 |
| elvsp1n | dig mail.development.us-east.os.neosllc.org | 01:09 |
| elvsp1n | notice that it respond with the public ip allocated through openstack (neutron/designate) | 01:09 |
| elvsp1n | now try testing the reverse dns for that ip | 01:10 |
| elvsp1n | by running the following command: | 01:10 |
| elvsp1n | dig -x 99.92.187.93 | 01:10 |
| elvsp1n | notice that it return the proper record | 01:11 |
| elvsp1n | ;; ANSWER SECTION: | 01:11 |
| elvsp1n | 93.187.92.99.in-addr.arpa. 86400 INCNAME93.0/25.187.92.99.in-addr.arpa. | 01:11 |
| elvsp1n | 93.0/25.187.92.99.in-addr.arpa.3600 INPTRmail.development.us-east.os.neosllc.org. | 01:11 |
| elvsp1n | thats working as expected because I am currently using a server with just bind9 properly configured with the zone that att is returning when performing the query | 01:12 |
| elvsp1n | now if you do the same test using my designate server | 01:15 |
| elvsp1n | dig -x 99.92.187.93 @designate.neosllc.org | 01:15 |
| elvsp1n | it answer as well with the following: | 01:15 |
| elvsp1n | 93.187.92.99.in-addr.arpa. 3600INPTRmail.development.us-east.os.neosllc.org. | 01:16 |
| elvsp1n | notice that it does not include the subnet information or 93.0/25.187.92.99.in-addr.arpa. | 01:16 |
| elvsp1n | so when I use it through the public dns, it does not reply with the PTR record as the zone created by neutron/designate is 187.92.99.in-addr.arpa. instead of 0/25.187.92.99.in-addr.arpa. | 01:17 |
| elvsp1n | looking at the source code for designate, I see that there is a zone validation done before it gets created here https://opendev.org/openstack/designate/src/commit/002005a440e87198e05719d17c3d39a980a552e3/designate/api/v2/controllers/zones/__init__.py#L96 | 01:20 |
| elvsp1n | I will dig through the code to have a better understanding of why it does not allow the use of / in zone names and/or why creating zones with - (ie 0-127.187.92.99.in-addr.arpa. ) does not respond to queries like 0/25.187.92.99.in-addr.arpa. | 01:21 |
| johnsom | I can help you tomorrow, I am on mobile tonight | 01:36 |
| johnsom | My talk from the last summit might help you as well | 01:38 |
| elvsp1n | sounds good | 01:54 |
| elvsp1n | this is the error that I am hitting: https://opendev.org/openstack/designate/src/commit/002005a440e87198e05719d17c3d39a980a552e3/designate/objects/adapters/base.py#L202 | 02:07 |
| elvsp1n | openstack zone create --email sample@email.com 0/25.187.92.99.in-addr.arpa. | 02:08 |
| elvsp1n | Provided object is not valid. Got a ValueError error with message Domain 0/25.187.92.99.in-addr.arpa. is invalid | 02:08 |
| elvsp1n | I can see that the field definition limit it to 255 here https://opendev.org/openstack/designate/src/commit/002005a440e87198e05719d17c3d39a980a552e3/designate/objects/zone.py#L32 | 02:19 |
| johnsom | That is the RFC requirement | 02:20 |
| johnsom | It is required by the standards documents | 02:21 |
| elvsp1n | understand | 02:21 |
| elvsp1n | But allowing us to create zone names with / is also part of the rfc standard as seen in the examples shared on rfc2317: https://tools.ietf.org/html/rfc2317 | 02:26 |
| elvsp1n | and I suspect that is also the reason why bind9 allow us to create zones with / as well | 02:26 |
| elvsp1n | for some reason, in designate code, the zone.validate does not seems to be causing the exception that I am hitting as I don't see it checking for that here: https://opendev.org/openstack/designate/src/commit/002005a440e87198e05719d17c3d39a980a552e3/designate/objects/zone.py#L95 | 02:28 |
| johnsom | Actually, it is not recommended if you follow all of the RFCs in this space. | 02:34 |
| johnsom | elvsp1n https://youtu.be/zdhvNezU1w4?feature=shared&t=364 | 02:34 |
| johnsom | I presented on this at the last summit | 02:34 |
| elvsp1n | let me check it out | 02:35 |
| johnsom | To quote the RFC you linked: | 02:35 |
| johnsom | https://www.irccloud.com/pastebin/WSOsPxxb/ | 02:36 |
| elvsp1n | correct | 02:36 |
| elvsp1n | but big ISP like att just know how to do things their way or no way | 02:36 |
| elvsp1n | I kindly asked them to delegate it as 0-127.187.92.99.in-addr.arpa. citing that precisely paragraph but they responded: | 02:37 |
| elvsp1n | Hello We configure our Delegations following RFC2317 I have provided the link for your reference as well as attached a PDF. https://tools.ietf.org/html/rfc2317 Thanks Michael AT&T Prov-DNS Team | 02:37 |
| elvsp1n | Hello Unfortunately no, this is the standard AT&T uses and not able to modify. Thanks Michael AT&T Prov-DNS Team | 02:38 |
| elvsp1n | let me check your video | 02:38 |
| elvsp1n | thats precisely what I am dealing with, but instead of being able to have a /24 subnet delegated to my dns, all what they can do is assign a /25 then configure a CNAME that limit my delegation to the subnet that I have assigned | 02:42 |
| elvsp1n | in your slide: What is the IPv4 IN-ADDR.ARPA challenge? You have: IN-ADDR.ARPA zones are delegated on octet boundaries, so the smallest reverse lookup zone you could delegate would be using 24-bit prefixes, or 254 host addresses... In my case, att is only able to delegate /25 or 128 ipv4 addresses to my account | 02:43 |
| elvsp1n | I am assuming that att is facing that challenge which is why they delegated it setting a CNAME in their DNS which reply with 0/25.187.92.99.in-addr.arpa. instead of just my ip as it would normally or 93.187.92.99.in-addr.arpa. which is how designate is currently working | 02:46 |
| elvsp1n | Mr. Johnsom, even if its not recommended, the RFCs do not forbid it, which again, is why I am assuming, bind9 allow us to create zones with / instead of only limit us to use -. | 02:49 |
| elvsp1n | if the rfc2317 show examples with /. why forbid it on designate? | 02:51 |
| elvsp1n | what you are covering in your video is precisely the problem that I am facing but the solution proposed (using - instead of /) is why I started my inquiries about it (again, forced by att as they will not delegate it using -) | 02:54 |
| elvsp1n | In your future development opportunity, you showed this: Neutron could be enhanced to create classless IN-ADDR.ARPA. zones when projects are allocated subnets from a routable subnet pool. The command that you showed is this: | 02:55 |
| elvsp1n | openstackn subnet pool create --share --pool-prefix 203.0.113.0/24 --default-prefix-length 26 demo-subnetpool4 | 02:56 |
| elvsp1n | then in the next bullet you wrote: A Neutron DNS extension could be created that creates shared PTR zones for floating IPs. This would allow the project to have direct management of their PTR records. | 02:57 |
| elvsp1n | it sounds like that extention is something that could be created in the future | 02:57 |
| elvsp1n | openstack subnet pool create a bunch of subnets inside a bigger subnet | 03:00 |
| elvsp1n | but in my case, I have my /25 subnet defined, creating a pool of subnet with that particular command would require me to create subnets smaller than /25 (or /26, /27, /28, /29, /30), smaller than 30 would not allow customers to have an ip available for their vms as you need 1 for a router and the broadcast | 03:04 |
| elvsp1n | still, that won't solve the problem of having my main subnet /25 returning a CNAME with 93.0/25.187.92.99.in-addr.arpa. if designate is not able to create a 0/25.187.92.99.in-addr.arpa. | 03:05 |
| elvsp1n | I might as well just get a /24 or bigger block from arin to get over att bs | 03:19 |
| eandersson | Can you provide us with the exact cli commands and steps you use and I can look and see if it is designate preventing this or not. | 10:28 |
| frickler | iirc we said that we don't support "/" in a zone name since people can switch to "-" instead. but if $bigcorp refuses to do that in their zone delegation, it might be sensible to weaken that limitation | 10:55 |
| frickler | that still won't solve the issue of teaching neutron about it, though, but that's a neutron issue, not designate | 10:56 |
| eandersson | We would probably need to change the regex to something like this I assume for that to work | 12:32 |
| eandersson | > RE_ZONENAME = re.compile(r'^(?!.{255,})(?:(?!\-)[A-Za-z0-9_\-\/]{1,63}(?<!\-)\.)+\Z') # noqa | 12:32 |
| elvsp1n | hi eandersson, try with this command: | 13:43 |
| elvsp1n | openstack zone create --email sample@email.com 0/25.187.92.99.in-addr.arpa. | 13:43 |
| elvsp1n | frickler I tried to manually create the zone directly in designate (service_domain, services project) as thats where by default, it create the PTR records | 13:45 |
| elvsp1n | ideally, working with neutron to make sure that it knows how to handle subnets with sufix greater than 25 would be ideal as that will allow us to automatically assign floating ip and reverse dns (PTR records) | 13:46 |
| elvsp1n | but I tried manually in designate and my inquiry started basically because bind9 allow it but designate don't | 13:47 |
| elvsp1n | here is the error that I am getting: https://opendev.org/openstack/designate/src/commit/6067d6d1996edfc061d9fe9d5cc3e3a4e878b2a6/designate/objects/fields.py#L184 | 13:55 |
| frickler | elvsp1n: yes, this is intentional and has been discussed before, see https://bugs.launchpad.net/designate/+bug/1880583 | 13:57 |
| elvsp1n | thanks frickler for pointing that out, I just updated the ticket with my suggestion. | 14:16 |
| elvsp1n | At the end of the day, designate should allow us to manage our DNS servers through its api, if DNS servers allow us to create zones with / on its name, I think that designate should also allow us to define zones with / on its name. | 14:17 |
| elvsp1n | but thats just the suggestion of a simple mortal :) | 14:18 |
| frickler | elvsp1n: I'm not completely opposed to that, but designate supports multiple backends and it would also make sense to ensure that data in designate are compatible with all of them | 14:43 |
| elvsp1n | frickler is there a designate backend (dns server) that don't support / on its zone name? ie. Dynect, Bind9, Infoblox, Nsd4, Fake, PowerDNS 4 | 14:48 |
| elvsp1n | Looking at Dynect's documentation in this page: https://help.dyn.com/finding-your-reverse-dns-zone-name/ | 14:52 |
| elvsp1n | it seems like they are instructing users to replace the / for a - as follows: | 14:52 |
| elvsp1n | Classless Address Block Example: | 14:52 |
| elvsp1n | 1. Take your network IP address.192.168.15.224/27 | 14:52 |
| elvsp1n | 2. Remove the netmask portion of the address, that’s the number after the slash (/) in the prior example.192.168.15.224 | 14:52 |
| elvsp1n | 3. Reverse the order of the remaining octets.224.15.168.192 | 14:53 |
| elvsp1n | 4. Add ‘in-addr.arpa’ to the end.224.15.168.192.in-addr.arpa | 14:53 |
| elvsp1n | 5. Add the netmask back into the address.224-27.15.168.192.in-addr.arpa* | 14:53 |
| elvsp1n | They are basically instructing users to create the zone with hyphen instead of /, the problem is that creating the zone in designate with hyphen does not respond to queries with / | 14:54 |
| elvsp1n | thats why, in my suggestion on the desginate bug/1880583 I also suggested that designate (or designate-bind) reply to queries with / using the zone defined with - | 14:55 |
| frickler | yes, that's different zones, so it certainly does not solve your use case. I also don't know most of these backends, I was just mentioning this as a possible counter argument | 14:55 |
| elvsp1n | let me give you an example | 14:55 |
| frickler | well you certainly cannot respond to a different zone than the one that is configured | 14:56 |
| elvsp1n | thats correct | 15:00 |
| elvsp1n | according to Dynect, I should create 0-25.187.92.99.in-addr.arpa. | 15:00 |
| elvsp1n | openstack zone create --email support@neosmail.com 0-25.187.92.99.in-addr.arpa. | 15:01 |
| elvsp1n | testing it, it seems to respond properly | 15:02 |
| elvsp1n | dig NS 0-25.187.92.99.in-addr.arpa. @designate.neosllc.org | 15:02 |
| elvsp1n | ;; ANSWER SECTION: | 15:02 |
| elvsp1n | 0-25.187.92.99.in-addr.arpa. 3600 INNSdesignate.neosllc.org. | 15:02 |
| elvsp1n | but trying to get the information using the way att created the delegation | 15:03 |
| elvsp1n | dig NS 0/25.187.92.99.in-addr.arpa. @designate.neosllc.org | 15:03 |
| elvsp1n | it does not respond with the same record... | 15:03 |
| elvsp1n | now reading this documenation from Dynect brings another question for me, apparently the designate documentation say that we can share specific number of ip in a zone with another project by defining (in the example that they described, they are allowing a project to manage 3 ip in a zone) | 15:08 |
| elvsp1n | https://docs.openstack.org/designate/latest/user/manage-ptr-records.html | 15:08 |
| elvsp1n | in the documentation, the zone is created with: openstack zone create --email me@example.com 2.0.192.in-addr.arpa. | 15:08 |
| elvsp1n | then the delegated zone is created as follows: openstack zone create --email me@example.com 1-3.2.0.192.in-addr.arpa. | 15:08 |
| elvsp1n | then the zone is shared with another project with the following: openstack zone share create 1-3.2.0.192.in-addr.arpa. 9284a20339184a9bb299386c380211c7 | 15:09 |
| elvsp1n | then, they go ahead and start creating a CNAME for each of the ip delegated as follows: openstack recordset create --record 1.1-3.2.0.192.in-addr.arpa. --type CNAME 2.0.192.in-addr.arpa. 1.2.0.192.in-addr.arpa. | 15:10 |
| elvsp1n | now the question is, if the hyphen replace the /, aren't we supposed to specify a subnet sufix after the hypen as described in Dynect's documentation? In designate's documentation this 1.1-3.2.0.192.in-addr.arpa. seems to be like specifying a range of ip (from 1 to 3) instead of specifying a subnet 1/3 | 15:11 |
| elvsp1n | I tested creating a zone assuming that the hyphen specify a range of ip that describe a subnet or: 0-127.187.92.99.in-addr.arpa. | 15:13 |
| elvsp1n | And I also tested creating a zone assuming that the hyphen was a direct replacement of the / or: 0-25.187.92.99.in-addr.arpa. | 15:13 |
| elvsp1n | still, designate-bind does not respond to queries with / or: dig NS 0/25.187.92.99.in-addr.arpa. @designate.neosllc.org | 15:14 |
| frickler | yes, unless you get your provider to change the delegation, all of this is useless in your scenario | 15:21 |
| elvsp1n | thats correct... | 15:22 |
| elvsp1n | att is chargin about 40bucks/month for a /25 subnet, I will try to request a /24 subnet with arin for 250/yr to avoid dealign with this ISP | 16:09 |
| johnsom | Just to add some context, Azure also does not allow the invalid '/' | 17:32 |
| johnsom | "When you're creating classless reverse DNS lookup zones in Azure DNS, you must use a hyphen (-) instead of a forward slash (/) in the zone name." | 17:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!