Generate IPv6 reverse PTR records for /64 subnet
I use SixXS and delegated the reverse PTR ip6.arpa zone to my own NS servers, so I am able to set up forward-confirmed hostnames within my subnet. This is great. A particular /64 subnet I designated is primarily used by hosts those configure themselves with SLAAC + Privacy Extensions. This means, these hosts pick random addresses and keep changing them as they expire. To be compliant with Internet etiquette, all these addresses should have a forward-confirmed reverse hostname at all the times.
E.g.: 2a01:xxxx:xxxx:xxxx:5374:6172:6761:7465 should have a reverse PTR like:
5.6.4.7.1.6.7.6.2.7.1.6.4.7.3.5.x.x.x.x.x.x.x.x.x.x.x.x.1.0.a.2.ip6.arpa. IN PTR host-5374617267617465.ip6pool.mydomain.tld.
And all the 2 ^ 64 addresses in the /64 subnet should have reverse records like this, except for some unique hosts. E.g. reverse records for 2a01:xxxx:xxxx:xxxx::88 and 2a01:xxxx:xxxx:xxxx::99 should point to server1.mydomain.tld and server2.mydomain.tld respectively.
Corresponding forward records should also be set up to point to the respective IPs.
Is there already an efficient way to do this?
I've seen generators but those would actually generate all the 2 ^ 64 records for me, which I don't think would be efficient. There is no point to cache and store that much data when only a very small fraction of it is being used by once. So I need a DNS server that generates records on-the-fly (request comes for particular reverse record, the server generates and sends response as host-${IP6-SUFFIX}.ip6pool.mydomain.tld scheme). I'm not sure if BIND could do that.
Alternatively, but this would be a very inconvenient solution, I could watch for new addresses on the network, and add them to the reverse zone as I see them. Then, only those addresses would have a reverse PTR which are actually used on the network. But this could be very cumbersome to implement.
Any ideas for a smooth implementation?
ipv6 bind
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I use SixXS and delegated the reverse PTR ip6.arpa zone to my own NS servers, so I am able to set up forward-confirmed hostnames within my subnet. This is great. A particular /64 subnet I designated is primarily used by hosts those configure themselves with SLAAC + Privacy Extensions. This means, these hosts pick random addresses and keep changing them as they expire. To be compliant with Internet etiquette, all these addresses should have a forward-confirmed reverse hostname at all the times.
E.g.: 2a01:xxxx:xxxx:xxxx:5374:6172:6761:7465 should have a reverse PTR like:
5.6.4.7.1.6.7.6.2.7.1.6.4.7.3.5.x.x.x.x.x.x.x.x.x.x.x.x.1.0.a.2.ip6.arpa. IN PTR host-5374617267617465.ip6pool.mydomain.tld.
And all the 2 ^ 64 addresses in the /64 subnet should have reverse records like this, except for some unique hosts. E.g. reverse records for 2a01:xxxx:xxxx:xxxx::88 and 2a01:xxxx:xxxx:xxxx::99 should point to server1.mydomain.tld and server2.mydomain.tld respectively.
Corresponding forward records should also be set up to point to the respective IPs.
Is there already an efficient way to do this?
I've seen generators but those would actually generate all the 2 ^ 64 records for me, which I don't think would be efficient. There is no point to cache and store that much data when only a very small fraction of it is being used by once. So I need a DNS server that generates records on-the-fly (request comes for particular reverse record, the server generates and sends response as host-${IP6-SUFFIX}.ip6pool.mydomain.tld scheme). I'm not sure if BIND could do that.
Alternatively, but this would be a very inconvenient solution, I could watch for new addresses on the network, and add them to the reverse zone as I see them. Then, only those addresses would have a reverse PTR which are actually used on the network. But this could be very cumbersome to implement.
Any ideas for a smooth implementation?
ipv6 bind
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08
add a comment |
I use SixXS and delegated the reverse PTR ip6.arpa zone to my own NS servers, so I am able to set up forward-confirmed hostnames within my subnet. This is great. A particular /64 subnet I designated is primarily used by hosts those configure themselves with SLAAC + Privacy Extensions. This means, these hosts pick random addresses and keep changing them as they expire. To be compliant with Internet etiquette, all these addresses should have a forward-confirmed reverse hostname at all the times.
E.g.: 2a01:xxxx:xxxx:xxxx:5374:6172:6761:7465 should have a reverse PTR like:
5.6.4.7.1.6.7.6.2.7.1.6.4.7.3.5.x.x.x.x.x.x.x.x.x.x.x.x.1.0.a.2.ip6.arpa. IN PTR host-5374617267617465.ip6pool.mydomain.tld.
And all the 2 ^ 64 addresses in the /64 subnet should have reverse records like this, except for some unique hosts. E.g. reverse records for 2a01:xxxx:xxxx:xxxx::88 and 2a01:xxxx:xxxx:xxxx::99 should point to server1.mydomain.tld and server2.mydomain.tld respectively.
Corresponding forward records should also be set up to point to the respective IPs.
Is there already an efficient way to do this?
I've seen generators but those would actually generate all the 2 ^ 64 records for me, which I don't think would be efficient. There is no point to cache and store that much data when only a very small fraction of it is being used by once. So I need a DNS server that generates records on-the-fly (request comes for particular reverse record, the server generates and sends response as host-${IP6-SUFFIX}.ip6pool.mydomain.tld scheme). I'm not sure if BIND could do that.
Alternatively, but this would be a very inconvenient solution, I could watch for new addresses on the network, and add them to the reverse zone as I see them. Then, only those addresses would have a reverse PTR which are actually used on the network. But this could be very cumbersome to implement.
Any ideas for a smooth implementation?
ipv6 bind
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
I use SixXS and delegated the reverse PTR ip6.arpa zone to my own NS servers, so I am able to set up forward-confirmed hostnames within my subnet. This is great. A particular /64 subnet I designated is primarily used by hosts those configure themselves with SLAAC + Privacy Extensions. This means, these hosts pick random addresses and keep changing them as they expire. To be compliant with Internet etiquette, all these addresses should have a forward-confirmed reverse hostname at all the times.
E.g.: 2a01:xxxx:xxxx:xxxx:5374:6172:6761:7465 should have a reverse PTR like:
5.6.4.7.1.6.7.6.2.7.1.6.4.7.3.5.x.x.x.x.x.x.x.x.x.x.x.x.1.0.a.2.ip6.arpa. IN PTR host-5374617267617465.ip6pool.mydomain.tld.
And all the 2 ^ 64 addresses in the /64 subnet should have reverse records like this, except for some unique hosts. E.g. reverse records for 2a01:xxxx:xxxx:xxxx::88 and 2a01:xxxx:xxxx:xxxx::99 should point to server1.mydomain.tld and server2.mydomain.tld respectively.
Corresponding forward records should also be set up to point to the respective IPs.
Is there already an efficient way to do this?
I've seen generators but those would actually generate all the 2 ^ 64 records for me, which I don't think would be efficient. There is no point to cache and store that much data when only a very small fraction of it is being used by once. So I need a DNS server that generates records on-the-fly (request comes for particular reverse record, the server generates and sends response as host-${IP6-SUFFIX}.ip6pool.mydomain.tld scheme). I'm not sure if BIND could do that.
Alternatively, but this would be a very inconvenient solution, I could watch for new addresses on the network, and add them to the reverse zone as I see them. Then, only those addresses would have a reverse PTR which are actually used on the network. But this could be very cumbersome to implement.
Any ideas for a smooth implementation?
ipv6 bind
ipv6 bind
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
asked May 14 '16 at 14:08
MegaBrutalMegaBrutal
1011
1011
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 1 hour ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08
add a comment |
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08
add a comment |
1 Answer
1
active
oldest
votes
Actually, this is weird. If you are serving things from your network, your servers should be in fixed addresses. So easy to have PTR as well.
Opposite, using random privacy addresses, you should not provide them PTR, as it, sort of, breaks anonymity.
(This may be up to discussion and I am waiting for the comments).
Out of this concern, the simple use of Dnsmasq as DNS authoritive and dhcp+radvd makes great (as long as you don't use privacy ipv6).
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f283137%2fgenerate-ipv6-reverse-ptr-records-for-64-subnet%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Actually, this is weird. If you are serving things from your network, your servers should be in fixed addresses. So easy to have PTR as well.
Opposite, using random privacy addresses, you should not provide them PTR, as it, sort of, breaks anonymity.
(This may be up to discussion and I am waiting for the comments).
Out of this concern, the simple use of Dnsmasq as DNS authoritive and dhcp+radvd makes great (as long as you don't use privacy ipv6).
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
add a comment |
Actually, this is weird. If you are serving things from your network, your servers should be in fixed addresses. So easy to have PTR as well.
Opposite, using random privacy addresses, you should not provide them PTR, as it, sort of, breaks anonymity.
(This may be up to discussion and I am waiting for the comments).
Out of this concern, the simple use of Dnsmasq as DNS authoritive and dhcp+radvd makes great (as long as you don't use privacy ipv6).
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
add a comment |
Actually, this is weird. If you are serving things from your network, your servers should be in fixed addresses. So easy to have PTR as well.
Opposite, using random privacy addresses, you should not provide them PTR, as it, sort of, breaks anonymity.
(This may be up to discussion and I am waiting for the comments).
Out of this concern, the simple use of Dnsmasq as DNS authoritive and dhcp+radvd makes great (as long as you don't use privacy ipv6).
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
Actually, this is weird. If you are serving things from your network, your servers should be in fixed addresses. So easy to have PTR as well.
Opposite, using random privacy addresses, you should not provide them PTR, as it, sort of, breaks anonymity.
(This may be up to discussion and I am waiting for the comments).
Out of this concern, the simple use of Dnsmasq as DNS authoritive and dhcp+radvd makes great (as long as you don't use privacy ipv6).
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
answered Jul 28 '16 at 20:23
22decembre22decembre
86118
86118
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f283137%2fgenerate-ipv6-reverse-ptr-records-for-64-subnet%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
With IPv6 it is common to not provide reverse DNS for privacy addresses, only for fixed/static addresses for servers, network equipment etc.
– Sander Steffann
May 14 '16 at 14:33
@MegaBrutal from a Spam avoidance standpoint this is a bad practice. One common and quite effective spam avoidance technique is to check rDNS validation. Relatively few non-SMTP hosts pass rDNS. It is common to have PTR records that don't pass rDNS for hosts that don't have static IP addresses.
– BillThor
May 15 '16 at 0:08