Re: automatic reverse and forwarding zones
"Garbage" records... On Mon, 7 Nov 2022, Matus UHLAR - fantomas wrote: On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? The only reason you get records in cache is because you requested them. From my vantage most PTR records are demonstrably garbage. Caching exists because if you requested it once you might request it again. Who knows, maybe you didn't believe it the first time. In any case, that's why the aphorism "garbage in garbage out" is a thing. -- Fred Morris -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 11/7/22 9:08 AM, Matus UHLAR - fantomas wrote: I'm afraid that this problem can become really huge when someone creates huge amount of generated records, e.g. using proposed module. Even if BIND's cache is simply FIFO -- which I'm fairly certain that it's smarter than that -- and flushes a less garbage record in favor of a more garbage record, then BIND will do what it's designed to do the next time someone queries for the less garbage record, namely it will go fetch it and cache it. It will effectively be the same as if it never had the less garbage record in cache like if it is from a cold start. It will be a small delay. But it won't negatively impact the stability or operation of BIND. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote: while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. On 07.11.22 16:28, Ondřej Surý wrote: That's not any different than wildcard record in a forward zone. The resolvers already have to deal with garbage in the cache and cache eviction algorithms. I'm afraid that this problem can become really huge when someone creates huge amount of generated records, e.g. using proposed module. The DNS server doesn't live among rainbows and unicorns, so we prepare for the worst to come from network, not the best. Let's hope such problem won't appear. I was only curious if it may happen, if there's need to consider it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
> On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote: > > while it's doable, and with using BIND plugin at generating server it won't > need much of memory, any server that will be repeatedly asked to resolve IPs > from that range will fill its cache with generated records. That's not any different than wildcard record in a forward zone. The resolvers already have to deal with garbage in the cache and cache eviction algorithms. The DNS server doesn't live among rainbows and unicorns, so we prepare for the worst to come from network, not the best. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote: sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? On 07.11.22 16:07, Ondřej Surý wrote: How do you know it's a garbage? One woman's trash is another woman's treasure... That is the point. If anyone generates generic DNS records for /64 (16Ei addresses) as the OP asked for: https://lists.isc.org/pipermail/bind-users/2022-October/106846.html ...it will most probably be just garbage. while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. Won't this cause troubles on any server? I don't know - it might. if it does, do we have anything against it? Won't this cause even more problem on server generating those records? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
> On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote: > > > sooner or later, but filling up cache with garbage could result in other > non-garbage records being flushed out. > Are there any mechanisms that would wipe this garbage before other records, > used more often even if not very recently? How do you know it's a garbage? One woman's trash is another woman's treasure... Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote: what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote: On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
I recommend anyone who wants to deploy wildards to go read
https://slack.engineering/what-happened-during-slacks-dnssec-rollout/
There are lots of learning points there. You can skip to the "Solving
the mystery" section if you are familiar with the cover of the
Hitchhiker's guide to the Galaxy.
Yes, wildcards exist and can be signed. But there are some non-obvious
failure modes you might miss. Using wildcards is not trivial. Yet
often (always?) sold in as a simple workaround for something. There is
nothing simple about wildcards. It's one of the most complex things
people have put into the DNS. There's a reason they got their own
section in RFC1912. Which predates DNSSEC and is only a couple of months
younger than the type, but still explains the mystery if you read
it carefully with that in mind.
I understand that a wildcard PTR record might look like a simple way to
replace a large number of records with a single one. But anyone
actually *using* a PTR record will want to validate that PTR by doing a
forward lookup. Now, what does that mean? Right...
Having
*.e.d.0.c.d.a.b.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR whatevername.example.com.
you'll also need
whatevername.example.com. 2001:db8:bad:c0de::
2001:db8:bad:c0de::1
2001:db8:bad:c0de::2
; ...
2001:db8:bad:c0de::::fffe
2001:db8:bad:c0de::::
Totalling 2^64 records. Which you don't "just" have to somehow
host on your DNS server. You'll also have to reply with all of those
records to anyone asking for whatevername.example.com.
Good luck with that.
In case there is any doubt: A one-way PTR entry is worse than no PTR
entry. It's actual proof that you are attempting to use a name you
don't control.
Bjørn
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
> Do wildcard records work with multiple labels? I was thinking that they
> didn't, but it's that wildcards in PKIX do not work with multple labels,
> alas.
As far as I understand, yes, wildcard "works with multiple labels", at
least in the meaning that a wildcard can expand more than one label in
the hierarchy. Example:
If you have
*.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa. IN PTR whatevername.your-domain.
in your DNSSEC-signed zone file and get a query for
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa.
you will get a signed reply with a PTR with the name
1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa.
and the value of the PTR record as given above in the zone file.
However, in the RRSIG record supplied with the answer, the "labels"
field will indicate 16+2 = 18 for the 16 nibble labels + ip6.arpa in
the original PTR record in the zone, not the 32 + 2 labels in the
query and the response, so that a validator can see that it's only
that part of the name which is signed. ("number-of-labels field in
RRSIG is smaller than number-of-labels in answer, so must be the
result of a wildcard expansion.")
This is pretty clearly spelled out in the approximate half-page
"The Labels field" section on
https://www.rfc-editor.org/rfc/rfc4034.html#page-8
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: Edit the corresponding REVERSE zone & add following line in the end $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. Dont forget to Reload bind config & you are done. On 27.10.22 07:58, Marco wrote: How is the syntax for IPv6? Is it possible to do it for an entire /64? On 27. 10. 2022, at 10:12, Matus UHLAR - fantomas wrote: this would create HUGE amount of records, they wouldn't fit into memory. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.* -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 The BIND 9 team just have been busy with other items with more priority. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 27. 10. 2022, at 10:12, Matus UHLAR - fantomas wrote: > > >> >>> Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: >>> Edit the corresponding REVERSE zone & add following line in the end >>> >>> $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. >>> >>> Dont forget to Reload bind config & you are done. > >> On 27.10.22 07:58, Marco wrote: >> How is the syntax for IPv6? > > the syntax for $GENERATE is the same, just the records are different. > >> Is it possible to do it for an entire /64? > > this would create HUGE amount of records, they wouldn't fit into memory. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Micro random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Marco writes: > At least for IPv4, there are servers that reject connections from IPs > that don't have a reverse zone with PTR record. Yes. But but no one in their right mind do that for IPv6. A missing PTR is not indicating anything at all. You might as well reject connections based on rand(10) < 9 or similar. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
I tried back in 2013 to get the IETF to standardise delegating the reverse tree when prefix delegations happen. https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt named already supports updating PTR records based on the IP address of the TCP connection making the UPDATE request. SLACC hosts can update their own PTR records if you configure the nameserver to allow it. See update-policy tcp-self. Mark > On 28 Oct 2022, at 14:42, Paul Ebersman wrote: > > grant> I'd be interested in learning what other things /require/ or are > grant> at least predicated on having PTR records for IPs. > > Been a few years since I last delved but was appalled at some of the > pointless uses of rev-ptrs. NYT used to require it to let you connect to > their website, as one such totally pointless use. > > Reality is that the only way to find out is see if users scream or do > PTRs for all your addrs. For v6, on the fly generation is less broken > than trying to depend on DHCPv6 server dynamic DNS updates (doesn't help > for SLAAC). Someone has already mentioned that knot supports this. > > On the plus side, most idiots checking for rev-ptr only care if they get > an answer. Unlike SMTP, where MTAs might check if forward and reverse > match, as long as they get an answer, they go away fat, dumb and happy. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
grant> I'd be interested in learning what other things /require/ or are grant> at least predicated on having PTR records for IPs. Been a few years since I last delved but was appalled at some of the pointless uses of rev-ptrs. NYT used to require it to let you connect to their website, as one such totally pointless use. Reality is that the only way to find out is see if users scream or do PTRs for all your addrs. For v6, on the fly generation is less broken than trying to depend on DHCPv6 server dynamic DNS updates (doesn't help for SLAAC). Someone has already mentioned that knot supports this. On the plus side, most idiots checking for rev-ptr only care if they get an answer. Unlike SMTP, where MTAs might check if forward and reverse match, as long as they get an answer, they go away fat, dumb and happy. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 10/27/22 4:18 PM, Andrew Latham wrote: IRC for example will check for PTR and gate login. I know there are others but that came to mind quickly. In some regions having PTRs was a requirement. It has been years but I recall LACNIC required/desired PTRs be set. I wasn't aware of IRC's requirement for PTRs. I'll have to ask some others for background. I'd be interested in learning what other things /require/ or are at least predicated on having PTR records for IPs. I absolutely agree that having PTR records, especially records that are of some value, are a worth while thing to have. That being said, I think expecting DNS servers to have fully populated ip6.arpa zones is a non-starter. I don't even thing it makes it as far as untenable as I think a fully populated zone will cause most things to simply fall over flat on their face. Perhaps this will end up being one of those unplanned differences between IPv4 and IPv6. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
IRC for example will check for PTR and gate login. I know there are others but that came to mind quickly. In some regions having PTRs was a requirement. It has been years but I recall LACNIC required/desired PTRs be set. On Thu, Oct 27, 2022 at 2:47 PM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 10/27/22 1:24 PM, Marco wrote: > > At least for IPv4, there are servers that reject connections from > > IPs that don't have a reverse zone with PTR record. > > Please elaborate. > > I've not heard of (unspecified type of) servers rejecting connections > because of the lack of a PTR record. > > I have heard of mail servers /accepting/ a /TCP/ /transport/ connection > layer but /rejecting/ email at the /SMTP/ /application/ layer for the > lack of a PTR record. > > IMHO mail servers are not in scope for a $GENERATE style flood filling > of a zone. Rather they are in scope for very specifically generated > records. > > > That is the only reason that I see for that. > > Most ISPs do it. > > I'd say that /many/ ISPs populate in-addr.arpa zone(s) for IPv4. -- I > still run across IPv4 addresses that don't have PTR records way more > often than I think is reasonable. > > I've seen no evidence that ISPs also populate ip6.arpa zone(s) for IPv6 > in a similar way. Not the least of which are some of the reasons called > out in this thread. > > > > -- > Grant. . . . > unix || die > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- - Andrew "lathama" Latham - -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 10/27/22 1:24 PM, Marco wrote: At least for IPv4, there are servers that reject connections from IPs that don't have a reverse zone with PTR record. Please elaborate. I've not heard of (unspecified type of) servers rejecting connections because of the lack of a PTR record. I have heard of mail servers /accepting/ a /TCP/ /transport/ connection layer but /rejecting/ email at the /SMTP/ /application/ layer for the lack of a PTR record. IMHO mail servers are not in scope for a $GENERATE style flood filling of a zone. Rather they are in scope for very specifically generated records. That is the only reason that I see for that. Most ISPs do it. I'd say that /many/ ISPs populate in-addr.arpa zone(s) for IPv4. -- I still run across IPv4 addresses that don't have PTR records way more often than I think is reasonable. I've seen no evidence that ISPs also populate ip6.arpa zone(s) for IPv6 in a similar way. Not the least of which are some of the reasons called out in this thread. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Am 27.10.2022 um 13:08:40 Uhr schrieb Grant Taylor via bind-users: > Aside: I do question what you would populate the /48 ~ /56 ip6.arpa > zone with. What hypothetical data would you put in it? If it's PD > to an end user, what information would the ISP put in there that > wouldn't be confidential or potentially reveal that any and all IPs > in that prefix belong to a customer w/o also identifying the customer? At least for IPv4, there are servers that reject connections from IPs that don't have a reverse zone with PTR record. That is the only reason that I see for that. Most ISPs do it. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 10/27/22 11:23 AM, Marco wrote: It isn't, because a customer gets /48 or /56 in most cases. "For example one of their clients has the IP 2001:db::3." is a singular IP. The customer's router can use various methods to assign addresses, auto configuration and DHCPv6. Agreed. However that's contrary to the example in your original message. If the ISP wants to provide reverse zone for all possible addresses (ISP doesn't know which one of the assigned are used by the customer), it must have all reverse zones on their zone file or dynamically create them when a DNS server receives a request. As others have indicated, populating reverse zone file(s) with 2^(128-48) records is a non-starter and tantamount to a DoS. The ISP could delegate the /48 if it was to another provider that ran their own DNS server. But that's not likely the scenario with Prefix Delegation. /If/ I needed to populate any significant portion of an ip6.arpa zone I would probably look at seeing if I could leverage Dynamically Loadable Zones [1] & [2] to pull content from an external ""database on an as-needed basis. I've glanced at DLZ a handfull of times but have never used it. Every time that I do, I gravitate towards the Stub (sample) [3] and wonder if I can (ab)use it to create something that will allow me to run a command (program / script / etc.) that will create synthetic records w/o needing to populate them in a database. N.B. I consider DLZ to be for BIND to be much like the Milter API is for Sendmail / Postfix; e.g. a way to call out to something else to do something with the request. Aside: I do question what you would populate the /48 ~ /56 ip6.arpa zone with. What hypothetical data would you put in it? If it's PD to an end user, what information would the ISP put in there that wouldn't be confidential or potentially reveal that any and all IPs in that prefix belong to a customer w/o also identifying the customer? [1] https://kb.isc.org/docs/aa-00995 [2] https://bind-dlz.sourceforge.net/ [3] https://bind-dlz.sourceforge.net/stub_driver.html -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Hi Marco Probably Knot could help here (https://www.knot-dns.cz/docs/3.2/html/modules.html#synthrecord-automatic-forward-reverse-records) where Knot is able to generate IPv6-PTR and IPv6- based on a pattern "on-the-fly". Do you want to achieve something like this? # Reverse-Lookup $ dig @resolver +short -x 2a02:1368:6000::cafe static-2a02-1368-6000--cafe.cust.swissbackbone.net. # Forward-Lookup () $ dig @resolver +short static-2a02-1368-6000--cafe.cust.swissbackbone.net. 2a02:1368:6000::cafe Best regards, Tom On 10/27/22 19:23, Marco wrote: Am 27.10.2022 um 09:52:55 Uhr schrieb Grant Taylor via bind-users: This is a singular IP (presumably link-net) for a customer. So there would be exactly one forward and one reverse PTR record. It isn't, because a customer gets /48 or /56 in most cases. The customer's router can use various methods to assign addresses, auto configuration and DHCPv6. If the ISP wants to provide reverse zone for all possible addresses (ISP doesn't know which one of the assigned are used by the customer), it must have all reverse zones on their zone file or dynamically create them when a DNS server receives a request. I remember years ago that DHCP servers could be configured to dynamically update the forward and / or reverse zone when providing a lease to a client. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Am 27.10.2022 um 09:52:55 Uhr schrieb Grant Taylor via bind-users: > This is a singular IP (presumably link-net) for a customer. So there > would be exactly one forward and one reverse PTR record. It isn't, because a customer gets /48 or /56 in most cases. The customer's router can use various methods to assign addresses, auto configuration and DHCPv6. If the ISP wants to provide reverse zone for all possible addresses (ISP doesn't know which one of the assigned are used by the customer), it must have all reverse zones on their zone file or dynamically create them when a DNS server receives a request. > I remember years ago that DHCP servers could be configured to > dynamically update the forward and / or reverse zone when providing a > lease to a client. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
On 10/27/22 1:16 AM, Marco Moock wrote: Hello, Hi, how do ISPs automatically create the reverse and forwaring zones for their customers IP pools? I think it might be out of scope for what you were asking about, but I believe the following is an alternative approach. For example one of their clients has the IP 2001:db::3. So for clarity, we're talking about 2001:db:0:0:0:0:0:3. (I think. I'm on my first cup of coffee.) This is a singular IP (presumably link-net) for a customer. So there would be exactly one forward and one reverse PTR record. I remember years ago that DHCP servers could be configured to dynamically update the forward and / or reverse zone when providing a lease to a client. With this in mind, the forward and reverse zones would be roughly the size of the number of customers thus not blossoming ~> exploding into something that is tantamount to a DoS. Its reverse zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.ip6.arpa includes a PTR pointing to 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.isp.example.org This has an record of 2001:db::3. Is it possible to let bind create that automatically for certain zones? Aside from $GENERATE, which others have talked about exploding the zone, I'm not aware of any way to have BIND /initiate/ the change to zone content / data (for this). -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Marco writes: > Did it create any problems if you don't have Reverse DNS for the IPv6 > addresses for normal customer traffic? Not to my knowledge. I've had support for semi-automatic delegation to customers on my todo-list for ~10 years but never gotten around to actually doing it. I'm sure a few users would love it, but not enough to jusify the work.. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
> > It probably does not play well with DNSSEC, although I was thinking > > about whether some amount of wildcards in the signed reverse could > > help, but I don't think so. > > Well, what if the reverse is an NSEC3 does that let the server > make up stuff with having to sign it all? I don't think so, but > I'm thinking out loud here. Not sure what you're thinking of here. "A reverse" is, I think, most often thought to be a PTR record, so it can't be an NSEC3 record. A DNS reply which includes the NSEC3 records is typically given as part of an "authenticated denial of existence" response, i.e. the server expresses "there is no name in the zone matching the queried- for name, and there is no name between those names with these hashes in the zone", and the status code in the reply is then NXDOMAIN. This also means that no wildcard record in the zone matched the queried-for name. The publishing name server then has no way to "make up stuff", and there's no need to sign anything on the fly -- the NSEC3 records and their signatures can be pre-computed when the zone contents is known (typically when it is loaded). Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
> >To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616 > > records (yes, that's about 18 x 10^18 if my math isn't off). I predict > > you do not posess a machine capable of running BIND with that many > > records loaded -- I know we don't. > > It sure would be nice to be able to set some kind of default > (static) answer for reverse zones. While it has limited > useability for IPv4, it would actually be nice, and it seems a > win for IPv6 reverse. That's what you get with a wildcard PTR record, e.g. *.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa. IN PTR whatevername.your-domain. would return "whatevername.your-domain." as a PTR record whenever an otherwise-nonexistent PTR record in the 0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa. zone was queried for. > It probably does not play well with DNSSEC [...] Oh, it does. This is what the "labels" field in the RRSIG record is for, ref. https://www.rfc-editor.org/rfc/rfc4034.html#page-8 Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Havard Eidnes via bind-users wrote: >To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616 > records (yes, that's about 18 x 10^18 if my math isn't off). I predict > you do not posess a machine capable of running BIND with that many > records loaded -- I know we don't. It sure would be nice to be able to set some kind of default (static) answer for reverse zones. While it has limited useability for IPv4, it would actually be nice, and it seems a win for IPv6 reverse. It probably does not play well with DNSSEC, although I was thinking about whether some amount of wildcards in the signed reverse could help, but I don't think so. signature.asc Description: PGP signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
>> Edit the corresponding REVERSE zone & add following line in the end
>>
>> $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com.
>>
>> Dont forget to Reload bind config & you are done.
>
> Thanks.
> How is the syntax for IPv6?
> Is it possible to do it for an entire /64?
The full syntax of the $GENERATE zone file directive as
implemented by BIND can be found at
https://bind9.readthedocs.io/en/latest/chapter3.html#bind-primary-file-extension-the-generate-directive
Apparently, you can generate entries for 0-f with
$GENERATE 0-15
${0,0,x}0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa.
IN PTR $.whatevername.your-domain-sequence.
However, a couple of points:
1) I don't think you can "nest" $GENERATE directives, so the
above only enters 16 PTR records in the DNS, and you probably need
to enter "umpteen" such $GENERATE entries if you want to insist on
unique names in the zone file.
2) Think about what you are trying to do here... To "fill" an
in-addr.arpa zone for a /24 you require 256 records, and that's
eminently feasible.
To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616
records (yes, that's about 18 x 10^18 if my math isn't off). I
predict you do not posess a machine capable of running BIND with
that many records loaded -- I know we don't.
The $GENERATE directive actually creates all the individual records
you ask it to do before the zone is loaded "properly" -- think of it
as a "macro expansion" for the zone file, and that the zone file is
"pre-processed" before it's loaded.
The reasons above are probably the reason that ISPs either can be
tempted to do ip6.arpa for "anonymous clients" with wildcard records
if they do anything about it at all. Either that, or they generate
the zone file from other "external" provisioning data. The approach
of using wildcard records can from a technological perspective be
combined with "custom" entries in the same zone -- remember that
wildcard records only match if the queried-for name otherwise doesn't
exist in the zone file.
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Am 27.10.2022 um 10:58:18 Uhr schrieb Bjørn Mork: > Possible, but only for very small pools. Note that $GENERATE only is > a short form for easier hand editing of zone files on the primary > server. The zone is expanded on load and zone transfers etc will > contain the expanded data set. It doesn't save any resources. Only > editing. Ok thanks. Did it create any problems if you don't have Reverse DNS for the IPv6 addresses for normal customer traffic? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Marco Moock writes: > Hello, > > how do ISPs automatically create the reverse and forwaring zones for > their customers IP pools? > > For example one of their clients has the IP 2001:db::3. We mostly don't do this for IPv6. It's a pointless exercise, IMHO. We give every customer/site a /48. Statically defining 2^80 forward and reverse entries per customer is obviously impossible. It can in theory be scripted, and I believe some ISPs do that. But there is no way you can encode 80 bits more compact and readable than most of those addresses, so you end up with names that are long and unreadable compared to the address they point to. That's not why we do DNS. There is one exception in our network: We do DNS for a few small pools only used for IA_NA addresses. The addreses are used on CPE WAN interfaces and will show up in traceroutes. Some customers asked for a name, like they're used to with IPv4. So I added that since these pools are small enough to allow static entries. The pool is locked to a specific BNG and the size is fixed. We can therefore make unique and readable names using only a small part of the 128 bit address. We copy those bits directly as hex digits into the name. No need to complicate things by translating the variable part. A couple of examples: 2001:4610:a:60::430 2001:4610:a:60::2 2001:4610:a:60::f00 We don't use $GENERATE for this since the data is generated by scripts anyway. And I don't think $GENERATE handles hex digits very well anyway? > Is it possible to let bind create that automatically for certain zones? Possible, but only for very small pools. Note that $GENERATE only is a short form for easier hand editing of zone files on the primary server. The zone is expanded on load and zone transfers etc will contain the expanded data set. It doesn't save any resources. Only editing. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: Edit the corresponding REVERSE zone & add following line in the end $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. Dont forget to Reload bind config & you are done. On 27.10.22 07:58, Marco wrote: How is the syntax for IPv6? the syntax for $GENERATE is the same, just the records are different. Is it possible to do it for an entire /64? this would create HUGE amount of records, they wouldn't fit into memory. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: > Edit the corresponding REVERSE zone & add following line in the end > > $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. > > Dont forget to Reload bind config & you are done. Thanks. How is the syntax for IPv6? Is it possible to do it for an entire /64? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: automatic reverse and forwarding zones
It can be done on a need/manual basis, or if you have large ip block & you want to reply automatically created response for your ip's , you can use $GENERATE statement. Basic example of adding auto PTR/REVERSE ipv4 Record generation Edit the corresponding REVERSE zone & add following line in the end $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. Dont forget to Reload bind config & you are done. Regards, SYED JAHANZAIB From: bind-users on behalf of Marco Moock Sent: Thursday, October 27, 2022 12:16 PM To: comp-protocols-dns-b...@moderators.isc.org Subject: automatic reverse and forwarding zones Hello, how do ISPs automatically create the reverse and forwaring zones for their customers IP pools? For example one of their clients has the IP 2001:db::3. Its reverse zone 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.ip6.arpa includes a PTR pointing to 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.isp.example.org This has an record of 2001:db::3. Is it possible to let bind create that automatically for certain zones? -- kind regards Marco -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
