Closed jbertozzi closed 1 year ago
This is not due to the record, it's actually because dnspython seemingly doesn't allow you to put a DNS name in the host
variable, it requires an IP. If you put in an IP instead of ad.example.org does it error out? If so then that confirms it. The dns.inet.af_for_address is used to determine what address family it is, which obviously a DNS name cannot be used to determine if it's IPv4/IPv6 and therefore it errors.
Surprised dnspython doesn't allow that, per the doc for dns.query.xfr it expects an IPv4 or IPv6 address.
I don't see it being unreasonable to just detect if it's an IP or a DNS and do a quick query for the IP and feed that in. We could use dnspython to do it, but I suspect just using socket.gethostbyname
would be easier and not require us to specify a record type (A/CNAME/etc) like dnspython requires.
I do note our providers docs do show using a DNS name (which I created and I believe I did actually test against), so I'll just to test again just to confirm, it's been a bit so I can't actually be sure if I did. Starting to think I didn't though.
Addressing #10 may be a solution as well, if the functionality of that new function handles DNS names.
Gonna move this over into https://github.com/octodns/octodns-bind since the AxfrSource
lives there now
I confirm that using the ip address in the host variable fixed it.
Thank you for the hint.
@jbertozzi wonderful, thank you for checking. I'll take a look this weekend hopefully to add the functionality to handle if it's a DNS name. It's definitely desirable functionality
@jbertozzi This fix is now in v0.0.3 release of the provider
Hello,
I cannot dump my current Microsoft AD zones to octodns configuration file.
Dumping the zone:
I am able to correctly get an axfr using dig:
Adding some
print()
into the code, the problematic record seems to bec5d1c200-2ce8-42b3-bde4-72aea693b480._msdcs.example.org 600 IN CNAME ad.example.org.
although it seems valid to me.Did I do anything wrong?