Why doesn't the octoblox provider support NS record types?

[woodycox]

I have been looking at using this provider to automate DNS changes into a test Infoblox instance that I have, and in doing so I've discovered that it doesn't support NS record types.

I was wondering if you could clarify why this is?

I do know that Infoblox treats NS record types differently from most of the other DNS server products out there. It's API essentially makes you create a delegation object where you have to provide the NS record along with the corresponding A records that are the authoritative name servers for the delegation.

Kind of like this:

{
  "fqdn": "test.example.com",
  "delegate_to": [
    { "name": "ns1.test.example.com", "address": "1.1.1.1" },
    { "name": "ns2.test.example.com", "address": "8.8.8.8" }
  ]
}

From what I can tell most of the other DNS server products out there, just treat each record type individually, and so they don't enforce associations between individual record types. It looks like OctoDNS was built around this understanding and is why it also treats each record/record type individually and is why you can define a delegation within an octoDNS zone yaml config file like this:

config\example.com.yaml

test:
  ttl: 300
  type: NS
  values:
  - ns1.test.example.com.
  - ns2.test.example.com.
myhost1:
  ttl: 300
  type: A
  value: 1.2.3.4
ns1.test:
  ttl: 300
  type: A
  value: 1.1.1.1
myhost2:
  ttl: 300
  type: A
  value: 1.2.3.5
ns2.test:
  ttl: 300
  type: A
  value: 8.8.8.8

Notice how in the octoDNS yaml above, I've defined the myhost1 and the myhost2 A records inbetween the NS record and the two A record entries for the ns1.test and ns2.test name servers. OctoDNS doesn't care that the NS record is in one location within the yaml file and the A records for ns1.test and ns2.test are scattered elsewhere throughout the yaml. Again, this is because octocDNS is expecting the target DNS service to treat all records seperately.

Given the above, is the reason why the octoblox provider doesn't support NS record types, because Infoblox forces you to assoociate NS records with A records and that this is fundametally incompatible with the way OctoDNS works?

Any insight you could provide on this would be very much apprreciated.

[asyncon]

Why your NS and glue Records do not work is usually specific to the configuration of your InfoBlox instance.

The expected behaviour is to not specify NS records but to reference an NS group to allow administration tasks to be separate from record management.

OctoBlox did not support the creation of zone_delegated object types however there is now a pre-release version that makes this configurable.

Here is an example of how to use this feature:

pip install --pre octoblox
# -or-
pip install octoblox==0.5.0rc1

config.yaml

providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./config
    default_ttl: 3600
    enforce_order: True
  infoblox:
    class: octoblox.InfoBloxProvider
    endpoint: infoblox.example.com
    username: admin
    password: env/INFOBLOX_PASSWORD
    create_zones: true
    new_zone_fields:
      grid_primary:
        - name: infoblox.example.com
      ns_group: default
      restart_if_needed: true
      soa_default_ttl: 3600
      view: default
      use_grid_zone_timer: true
  infoblox_delegated:
    class: octoblox.InfoBloxProvider
    endpoint: infoblox.example.com
    username: admin
    password: env/INFOBLOX_PASSWORD
    create_zones: true
    zone_type: zone_delegated
    new_zone_fields:
      delegated_to:
        - name: ns1.test.example.com
          address: 1.1.1.1
        - name: ns2.test.example.com
          address: 8.8.8.8
      restart_if_needed: true

zones:
  example.com.:
    sources:
      - config
    targets:
      - infoblox
  test.example.com.:
    sources:
      - config
    targets:
      - infoblox_delegated

config/example.com.yaml

myhost1:
  ttl: 300
  type: A
  value: 1.2.3.4
myhost2:
  ttl: 300
  type: A
  value: 1.2.3.5

config/test.example.com.yaml

{}

[asyncon]

There has been a subsequent update to handle the issues raised in #2 that changes how delegated zones are configured. Check #2 (comment) for an example.

[asyncon]

Version 0.5.0 will be released and this issue closed at the end of next week unless anymore issues are reported.