Greg Choules via bind-users writes:
> What's a "primary master" as opposed to (presumably?) a "secondary master"?
Some servers will be both masters and slaves when using hierarchical
replication. It is useful to define the root of the tree as "primary
master" and refer to any upstream from a "s
Ondřej Surý writes:
> Nobody is preventing from doing the work yourself, or paying somebody for
> doing
> the work for you. That's where the open-source model shines.
Or simply trigger the curiousity of some innocent victim who will then
do the work for free :-)
I don't necessarily believe thi
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.
Y
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(
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
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. S
Petr Špaček writes:
> named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC
> signatures (and other metadata) without validating them.
>
> named.conf statement 'dnssec-validation auto;' then enables DNSSEC
> validation itself.
>
> In other words, it is possible to allow DNSSEC to wo
Sandro writes:
> On 24-09-2022 11:20, Bjørn Mork wrote:
>> Philip Prindeville writes:
>>
>>> How many ISP's squelch DNSSEC like that? I hope it's not a common
>>> practice!
>> More common than you'd like to think. See Geoff's ex
Philip Prindeville writes:
> How many ISP's squelch DNSSEC like that? I hope it's not a common practice!
More common than you'd like to think. See Geoff's excellent world map
at https://stats.labs.apnic.net/dnssec
Note that no validation implies no signatures for downstream resolvers.
Which m
Mark Andrews writes:
> What records in paypal.com do you or your customers actually depend upon
> being signed? Paypal’s web servers depend on CAs not the DNS to provide
> trust anchors. It's not their SMTP servers as paypalcorp.com is not signed.
OK, let's just hope no CA runs Redhat then.
Petr Menšík writes:
> It is suitable for all other algorithms so I disagree that
> without algorithms 5 and 7 it is not usable at all. Majority of
> secured domains use stronger algorithms already.
Would it be the same if it worked for a majority of TLDs? Say "nz" as
an arbitrary example. Woul
Mark Andrews writes:
> We don’t log rsamd5 is disabled now ec or ed curves when they are not
> supported by the crypto provider. Why should rsasha1 based algs be
> special?
Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is
not.
I don't know if disabled EC curves is a real
www.ssa.gov is a separate zone according to the ssa.gov NS:
bjorn@idefix:~$ dig ns www.ssa.gov @dns1.ssa.gov
; <<>> DiG 9.16.27-Debian <<>> ns www.ssa.gov @dns1.ssa.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002
;; flags: qr rd; QUERY: 1, ANSW
Mirsad Goran Todorovac writes:
> Apparently, APPARMOR denied opening of the journal file in
> /etc/bind/zones even when the directory hand bind group write
> permissions.
Looking at the default policy in /etc/apparmor.d/usr.sbin.named in the
Debian bind9 package, I see that /etc/bind/ only have
Sandro writes:
> The bit from the first semicolon to the end of the line was missing.
>
> Is that expected behavior? I couldn't find any documentation regarding
> the usage of parentheses.
The master file format is mostly defined by RFC1035. See
https://datatracker.ietf.org/doc/html/rfc1035#sec
Mirsad Goran Todorovac writes:
> Dear All,
>
> In the past three days I have just made our domain DNSSEC
> signed. However, I seem to be missing something.
>
> When I query other DNS servers, like CloudFlare 1.0.0.1, I get the
> "ad" flag.
>
> But in my own domain, and my own domain servers, the
Alex K writes:
> On Mon, May 9, 2022 at 1:51 PM Matus UHLAR - fantomas
> wrote:
>
>> maybe someone uses VPN over DNS...
>> in such case, rate limiting of client comes to mind...
>>
> That would mean that the clients have access to their own dns servers,
> which the firewall does not allow.
No, y
Michael Richardson via bind-users writes:
> I have moved from dnssec-tools to having bind9 do all the management itself.
> There are a couple of things that I don't understand, and I find that the
> FAQs and howtos I've read are rather too introductory for me.
> I have been signing my zones since
Mark Andrews writes:
> It’s a long known issue with so called “Transparent” DNS
> proxies/accelerators/firewalls. Iterative resolvers expect to talk to
> authoritative servers. They ask questions differently to the way they
> do when they talk to a recursive server. Answers from different
> le
Matthijs Mekking writes:
> What can you do to get it to "omnipresent"? Tell BIND that the DS is
> in the parent (only do so if it is true of course). You can run
>
> rndc dnssec -checkds published your.zone
>
> And it should update the keyfile. You should then see a "DsPublish"
> line in
Matthijs Mekking writes:
> To be precise, BIND updates the key files each keymgr run. But If the
> keymgr waits for an event (rather than a duration), it will retry
> every refresh key interval, which defaults to an hour.
>
> You can check the logs for "next key event" to see when the keymgr is
>
Hello,
I recently moved a few zones from "auto-dnssec maintain" to
"dnssec-policy ..." to prepare for simpler/automatic key rotation in the
future.
For the time being I have configured my policy with separate KSK and ZSK
and unlimited key life times to replicate the old setup as closely as
possib
Dan Mahoney writes:
> We've seen a number of messages reported to us as having an isc.org "from"
> address, and as having our dkim signatures, but the signatures failing to
> verify, perhaps because a forwarder may have added a subject tag or
> rewritten some other header. Of course, SPF also
Timothe Litt writes:
> Anyhow, it's not clear exactly what problem you're asking LOC (or
> anything) to solve.
Which problems do LOC solve?
I remember adding LOC records for fun?() in the previous millennium when
RFC 1876 was fresh out of the press. But even back then paranoia
finally took ove
"@lbutlr" writes:
> On 2022 Apr 10, at 05:37, Bjørn Mork wrote:
>> "@lbutlr" writes:
>>
>>> # dnssec-keygen -a 13 example,com
>>> # dnssec-keygen -f KSK -a 13 example,com
>>>
>>> Add $INLCUDE to the zone file for each o
"@lbutlr" writes:
> # dnssec-keygen -a 13 example,com
> # dnssec-keygen -f KSK -a 13 example,com
>
> Add $INLCUDE to the zone file for each of these 4 keys.
4? You've generated 2 key pairs. There should be only 2 public keys
included in the zone.
> dnssec-signzone: warning: keys/Kexample.com.
Anand Buddhdev writes:
> The zone is correctly signed, but with RSASHA1, which is not
> recommended. You may be on a Linux distro whose openssl disables old
> algorithms like RSASHA1, and so BIND will not be able to validate this zone.
Doesn't that violate a MUST in RFC 8624?
Mostly curious -
Mark Tinka writes:
> DNS queries won't be sent to name servers that aren't listed as
> authoritative for the zone.
You'll normally get a few update queries to the SOA MNAME if you leave
the real master there.
Whether you should change the MNAME or not is another question...
Bjørn
--
Visit ht
28 matches
Mail list logo
