How to handle class B nets

[ITler]

Hy,

I don't get it to use your module to manage DNS for class B network. (No problem with class C)
Imagine, I've got this network in 10.22.0.0/16 with multiple hosts, i.e. 10.22.0.4, 10.22.2.33 and 10.22.177.218

dns::record::a {
    'host177218':
        zone => 'my-domain.com',
        data => ['10.22.177.218']
        ptr => true,
}

dns::zone { 'my-domain.com':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

# Reverse Zone
dns::zone { '22.10.IN-ADDR.ARPA':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

All easy. When puppet runs, error is raised when concat module tries to assemble reverse zone config:

Invalid relationship: File[/opt/puppetlabs/puppet/cache/concat/_etc_bind_zones_db.0.22.10.IN-ADDR.ARPA.stage/fragments/9_db.0.22.10.IN-ADDR.ARPA.11.0.22.10.IN-ADDR.ARPA,PTR,0.22.10.IN-ADDR.ARPA.record] { notify => Exec[concat_/etc/bind/zones/db.0.22.10.IN-ADDR.ARPA.stage] }, because Exec[concat_/etc/bind/zones/db.0.22.10.IN-ADDR.ARPA.stage] doesn't seem to be in the catalog

(I create the A-record on the DNS-client as puppet exported resource and realize it on DNS server)

When changing reverse zone definition to dns::zone { '0.22.10.IN-ADDR.ARPA': [...] } it is working, but this is not what I want to do.

What is missing here?

Kind regards
ITler

[solarkennedy]

Yea it is currently hardcoded to class C:

puppet-dns/manifests/record/a.pp

Line 24 in bef2b91

$reverse_zone = inline_template('<%= @ip.split(".")[0..-2].reverse.join(".") %>.IN-ADDR.ARPA')

I would say you have two options:

1. Use dns::record::ptr instead of the ptr=>true shortcut
2. Fix the bug and PR? :)

It is hard though because the A record type doesn't "know" the scope of the reverse zone at the time the A record is created. Could be a parameter though?

[ITler]

Thanks for fast replying.

Defining an explicit ptr would be ok for me. Maybe you would be so nice and confirm correct definition?

dns::record::ptr { 'host177218':
  zone => 'my-domain.com',
  data => ['177.218'] # or the other way around?
}

Thank you!

[solarkennedy]

Zone should be 22.10.IN-ADDR.ARPA no?

[solarkennedy]

Also @jearls can you comment on this thread? I could be just plain wrong re: comments in #138

[ghost]

All DNS reverse zones are, by definition, class C reverse zones.

When a system does a look-up of the IPv4 address A.B.C.D, that look-up is issued as: D.C.B.A.IN-ADDR.ARPA - in other words, it looks up "D" in the A.B.C reverse zone, no matter what network size A.B.C.D is.

So in this case, the reverse zones should be defined as:

# Reverse Zone
dns::zone { '0.22.10.IN-ADDR.ARPA':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

# Reverse Zone
dns::zone { '2.22.10.IN-ADDR.ARPA':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

# Reverse Zone
dns::zone { '177.22.10.IN-ADDR.ARPA':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

[solarkennedy]

I swore I could remember doing CIDR reverse delegations at a previous job. Here is a SO answer: http://serverfault.com/questions/22743/reverse-dns-in-a-cidr-world
And here is the RFC:
http://tools.ietf.org/html/rfc2317

So I'm not sure if they are still "by definition". However in this case I agree that it will be easier for @ITler to bite the bullet and split up the class B into C.

However dig +trace -x 4.2.2.2 shows an example of someone hosting a the "whole" /16 in revsere form.

[ITler]

See section 4.1

I'm not sure, but this at least looks to like reverse zones can be defined as class B, too. A colleague of mine says same. I've got no testing environment ready to prove.
I just give it a try with

# Reverse Zone
dns::zone { '22.10.IN-ADDR.ARPA':
  soa         => 'ns1.my-domain.com',
  soa_email   => 'admin.my-domain.com',
  nameservers => ['ns1']
}

dns::record::ptr { 'host177218':
  zone => 'my-domain.com',
  data => ['177.218']
}

I'll report back next week.

[ghost]

Yes, if you're managing your own DNS zones, you can do a class B reverse zone by properly crafting the names within that zone:

$ORIGIN 22.10.IN-ADDR.ARPA.
@               IN SOA ns1.my-domain.com. admin.my-domain.com. {
                    2016051900 ; serial
                    7200       ; refresh
                    3600       ; retry
                    86400      ; expire (1 day)
                    3600       ; negative ttl
                )
                IN NS ns1.my-domain.com.

218.177         IN PTR host177218.my-domain.com.

However, to my knowledge, this module has no way to automatically create the 218.177 style reverse name in your class B reverse zone.

Your example is close to working:

dns::record::ptr { 'host177218':
    host => '218.177',
    zone => '22.10.IN-ADDR.ARPA',
    data => 'host177218.my-domain.com',
}

This would work. You just can't use the ptr => true option to dns::record::a with this setup.

I might actually have a way to make the ptr => true code work with this style of reverse zone, but I'll have to think about it before submitting a PR for that.

-- Johnson

[ghost]

FYI - this can only be done for the original network classes (class A, class B, class C), since those are the network classes that are split up on octet boundaries. In my previous example, IP address A.B.C.D could be split up as follows:

• class A: host D.C.B in A.IN-ADDR.ARPA
• class B: host D.C in B.A.IN-ADDR.ARPA
• class C: host D in C.B.A.IN-ADDR.ARPA

Edit: Corrected order of host components in class A and class B example

[solarkennedy]

@ITler does that answer your question? Also I've just now merged #138 which gives some fancier options for non class C ptrs by ip.

[ITler]

Guys, that's awesome. Little question leading to nice improvement of the library.
I'll give that a try as soon as I can and I'm pretty sure, that the new feature will allow the kind of configuration I need.

Many thanks for your support.