From Newsgroup: comp.protocols.dns.bind

From a BIND point of view "in-addr.arpa" is a unique zone with no dependencies.

John

-----Original Message-----
From: bind-users [mailto:bind-users-bounces@lists.isc.org] On Behalf Of DeCaro, James John (Jim) CIV DISA FE (USA) via bind-users
Sent: Thursday, July 09, 2020 8:16 AM
To: Mark Andrews; @lbutlr
Cc: bind-users
Subject: RE: [Non-DoD Source] Re: Dumb Question is an A or AAAA record required?

Would the lack of A records affect pointer records? Seems like it would.


Jim

"If you always do what you always did you will always get what you always got."


--- Synchronet 3.18a-Linux NewsLink 1.113

From Newsgroup: comp.protocols.dns.bind



Am 09.07.20 um 15:31 schrieb John W. Blue:

From a BIND point of view "in-addr.arpa" is a unique zone with no dependencies.

and typically you have no control over PTR records at all given that
they have nothing to do with your domain

while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

-----Original Message-----
From: bind-users [mailto:bind-users-bounces@lists.isc.org] On Behalf Of DeCaro, James John (Jim) CIV DISA FE (USA) via bind-users
Sent: Thursday, July 09, 2020 8:16 AM
To: Mark Andrews; @lbutlr
Cc: bind-users
Subject: RE: [Non-DoD Source] Re: Dumb Question is an A or AAAA record required?

Would the lack of A records affect pointer records? Seems like it would

--- Synchronet 3.18a-Linux NewsLink 1.113

From Newsgroup: comp.protocols.dns.bind

You do have control over that.. kind of. As far as I'm aware hosting
providers generally offer control over PTR records in their admin
panels. However delegation of them to your own authoritative name
servers is.. complicated. A lot more so than delegation of forward
lookups would be anyway (A, AAAA, MX, yada yada). Apparently the hosting provider would have to delegate (as far as I understand it's like
sharing?) control over just that/those IP(s), and remember to revoke it
after you leave their hosting services too. See https://www.arin.net/resources/manage/reverse or https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns for more information... But I don't understand this part very well myself.

On my own hosting provider it appears that I can adjust the PTR records
on their admin interface, however I can't delegate it to my own name
servers.. since it's apparently a rather manual process. And I'm
probably not paying my hosting provider enough for that.

Whichever methods are available, for email in particular it's advisable
to publish a PTR record of some kind. IRC networks may also ask to do
this before they apply your domain as your vhost (and A and PTR have to match). On Freenode at least they do.

On 7/9/20 3:36 PM, Reindl Harald wrote:

and typically you have no control over PTR records at all given that
they have nothing to do with your domain

while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

--
Met vriendelijke groet / Best regards,
Michael De Roover
--- Synchronet 3.18a-Linux NewsLink 1.113

From Newsgroup: comp.protocols.dns.bind



Am 09.07.20 um 16:57 schrieb Michael De Roover:

You do have control over that..

i have, but not everybody has

kind of. As far as I'm aware hosting
providers generally offer control over PTR records in their admin
panels.

but it still has nothing to do with your domain by definition, the PTR
could be anything

However delegation of them to your own authoritative name
servers is.. complicated. A lot more so than delegation of forward
lookups would be anyway (A, AAAA, MX, yada yada). Apparently the hosting provider would have to delegate (as far as I understand it's like
sharing?) control over just that/those IP(s), and remember to revoke it
after you leave their hosting services too. See https://www.arin.net/resources/manage/reverse or https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns for more information... But I don't understand this part very well myself.

the ptr-zone of our /24 rnage is delegated to my nameserver for many
years, you just need to talk to the guys far after "customer support"

Whichever methods are available, for email in particular it's advisable
to publish a PTR record of some kind. IRC networks may also ask to do
this before they apply your domain as your vhost (and A and PTR have to match). On Freenode at least they do.

i know that all, thanks

but how does that change anything in the simple fact that "Would the
lack of A records affect pointer records? Seems like it would" given
that the PTR zone is a dns zone like anything else

On 7/9/20 3:36 PM, Reindl Harald wrote:

and typically you have no control over PTR records at all given that
they have nothing to do with your domain

while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

--- Synchronet 3.18a-Linux NewsLink 1.113

From Newsgroup: comp.protocols.dns.bind

On 7/9/20 5:03 PM, Reindl Harald wrote:

but it still has nothing to do with your domain by definition, the PTR
could be anything

Of course it can be, they're completely separate name spaces. However
would it make any sense in practice to point it somewhere else entirely?
You'd probably be better off not setting it at all then. I'd argue that they're meant to match each other.

but how does that change anything in the simple fact that "Would the
lack of A records affect pointer records? Seems like it would" given
that the PTR zone is a dns zone like anything else
while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

My thoughts exactly. They can technically be different and the DNS
itself indeed couldn't care less (but applications checking for that
might).. but would it make sense to? I mean yeah I suppose that they can
exist without the other. Not uncommon for A records to be without PTR
records, and I guess that a PTR record without an A record could work
too..? But again, aside from the theoretical possibility, why would you
want to set your PTR records to not match at least one of your A records?
--
Met vriendelijke groet / Best regards,
Michael De Roover
--- Synchronet 3.18a-Linux NewsLink 1.113

From Newsgroup: comp.protocols.dns.bind


Am 09.07.20 um 17:20 schrieb Michael De Roover:

On 7/9/20 5:03 PM, Reindl Harald wrote:

but it still has nothing to do with your domain by definition, the PTR
could be anything

Of course it can be, they're completely separate name spaces. However
would it make any sense in practice to point it somewhere else entirely? You'd probably be better off not setting it at all then. I'd argue that they're meant to match each other.

but how does that change anything in the simple fact that "Would the
lack of A records affect pointer records? Seems like it would" given
that the PTR zone is a dns zone like anything else
while it's smart (at least when you want to send mails) that your IP has
a sane PTR and that the name maps back to the IP the dns system couldn't
care less

My thoughts exactly. They can technically be different and the DNS
itself indeed couldn't care less (but applications checking for that
might).. but would it make sense to? I mean yeah I suppose that they can exist without the other. Not uncommon for A records to be without PTR records, and I guess that a PTR record without an A record could work
too..? But again, aside from the theoretical possibility, why would you
want to set your PTR records to not match at least one of your A records?

they question was "Would the lack of A records affect pointer records?"
an dthe answer is clearly *no*

my first response was "while it's smart (at least when you want to send
mails) that your IP has a sane PTR and that the name maps back"

so it's not a matter of "would it make any sense in practice" and "why
would you want to" because nobody want's and that was not the question

case closed, period


--- Synchronet 3.18a-Linux NewsLink 1.113