"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
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
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,
> 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
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
> 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
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 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:
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:
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:
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.
> 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
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
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
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
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
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
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
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 <
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
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
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
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
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
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
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
> > 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
> >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
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
>> 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
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
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.
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
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
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
35 matches
Mail list logo
