Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)
Valid base64 includes spaces and new lines. Poorly written record parsers reject valid records. -- Mark AndrewsOn 30 Dec 2022, at 10:38, Eric Germann via bind-users wrote: On Dec 29, 2022, at 16:34, Timothe Litt wrote:Yup, Eric's case was a classic example. He tried to do the right thing, put in the wrong record, and the system didn't produce the expected results. To his credit, he persisted. Most people don't. A while ago there was a study (cloudflare/APNIC) that showed that about only about 40% of people who enabled DNSSEC for their accounts successfully served DS records in their registry.The really annoying part is it isn’t obvious that they want the public key and not the result of dnssec-dsfromkey; they do it themselves. The annoying part is they throw an error if the key isn’t valid Base64 (think spaces or newlines), but gladly accept the DS output from dnssec-dsfromkey. Somehow or another they are getting the key tag from the incorrect DS record, because they encode again the already encoded string.I looked in the docs for boto3 (the official API for AWS) and there appears no way to add a public key so you can’t do it programmatically.I’ll have to pass that on to my AWS contacts. Doubt they’ll do anything but it is worth throwing it over the fence.Again, thanks for all the help!Eric-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: Binary data -- 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: Email migration and MX records
Just a reason to not use them for your email. Not everybody is in a position to repair stuff on a 7/24/365 basis. Notify that the mail is delayed by don’t bounce. -- Mark Andrews > On 7 Jan 2023, at 06:11, Brown, William wrote: > > Last I saw, both M365 and Google only retry for 24 hours before returning as > undeliverable. > > > -- > William Brown > WNYRIC/Erie 1 BOCES > > -Original Message- > From: bind-users On Behalf Of Marcus Kool > Sent: Wednesday, January 4, 2023 7:17 AM > To: bind-users@lists.isc.org > Subject: Re: Email migration and MX records > > This email originated from outside of the organization. Use caution > when replying, opening attachment(s), and/or clicking on URL's. > > > SMTP is a wonderful protocol that queues messages and retries delivery for 5 > days so a non-responsive email server is no issue. > Just do not have a temporary solution that bounces emails since those will > never arrive (the sender is notified about the bounce). > > Confidentiality Notice: This electronic message and any attachments may > contain confidential or privileged information, and is intended only for the > individual or entity identified above as the addressee. If you are not the > addressee (or the employee or agent responsible to deliver it to the > addressee), or if this message has been addressed to you in error, you are > hereby notified that you may not copy, forward, disclose or use any part of > this message or any attachments. Please notify the sender immediately by > return e-mail or telephone and delete this message from your system. > -- > 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: DNS Cookies Causing FORMERR
Really there are very few servers that are broken and the numbers are
decreasing. They are well under 1%. Just contact the few remaining server
operators and inform them that they are broken. It should just be an upgrade
to the current version to fix.
The behavior for unknown EDNS options was tightened nearly 10 years ago (April
2013). It was unspecified in the original EDNS RFC and made ignored in in the
updated RFC which every vendor should have picked up. At the time some vendors
ignored unknown options and others returned FORMERR or NOTIMP or REFUSED.
Others just dropped the request. Some returned BADVER. It was a mess.
There are also implementations that don’t know how to return FORMERR properly.
You don’t echo back the request with rcode set to FORMERR and QR to 1 as that
produces broken responses but some implementations do that. Why would you send
a message that you don’t understand? Nowhere is there any instructions to do
this.
To send a FORMER you send a DNS message header with rcode set to FORMERR. If
you can parse the question section for QUERY copy that into the response. If
you understand EDNS you can add an OPT record. Similarly TSIG if appropriate
and you support it Yes you can sign a FORMERR.
--
Mark Andrews
> On 7 Jan 2023, at 06:50, Justin Krejci wrote:
>
>
> DNS Servers that do not properly support or properly ignore DNS cookies and
> instead return FORMERR is annoying. This is not new. However I have been
> seeing more or perhaps just have more users that are finding more domains
> that are hosted on authoritative servers with this unfortunate behavior.
>
> Example progrowth.com name severs.
>
> Individual work arounds on caching BIND servers are not difficult to
> implement, like this
>
> server 47.206.74.18 {
> send-cookie no;
> };
> server 209.131.228.178 {
> send-cookie no;
> };
>
>
> However this workaround is problematic in terms of ongoing upkeep of this
> list and the increasing need to add new entries to the list. I'd like to be
> able to start sending cookies again if the servers begin to operate compliant
> to the EDNS RFC and I would like to not have to write any tools to remove
> entries from this list or schedule some regular calendar reminder to check or
> add to Nagios or whatever. I'd also rather not just globally disable sending
> of DNS cookies but it is something being considered.
>
> In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom
>
> "Nevertheless, mishandling of the COOKIE option has been known to cause
> errors that are fatal to name resolution when the resolver is validating
> responses coming from a signed zone, and the authoritative server returns
> either FORMERR or BADVERS, or fails to respond to the query. named treats
> these answers as if the server does not support EDNS (which it doesn't) so it
> stops sending any EDNS queries at all, which makes it impossible to get a
> DNSSEC response back."
>
> This statement indicates this fall-back method is only applicable to signed
> domains. Is there a knob in BIND to apply this behavior to all domains?
> Basically, if the authoritative server is behaving incorrectly in this way
> then enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries
> to continue to be answered for the end users.
>
> My caching servers are running the BIND 9.18 branch
>
> Thanks for any pointers or suggestions.
>
> -Justin
> --
> 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: parental-agent, emtpy DS response ?
I suspect the problem is that the request does not have RD=1 and you are
talking to
recursive servers. The following should work except where the authoritative
server
does not implement DNS properly and rejects recursive queries rather than just
treating
the request as not recursive.
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index eab42bf8c0e..5b62fa8dc95 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -20704,6 +20704,7 @@ checkds_createmessage(dns_zone_t *zone, dns_message_t
**messagep) {
message->opcode = dns_opcode_query;
message->rdclass = zone->rdclass;
+ message->flags |= DNS_MESSAGEFLAG_RD;
dns_message_gettempname(message, &tempname);
> On 8 Jan 2023, at 07:11, Anders Löwinger wrote:
>
> Hi
>
> I have some trouble with the parental-agents. Anyone seen this before/can
> give me a clue to get this working?
>
> Tried with my two recursive resolvers first, then localhost. No difference.
>
> From the log
>
> named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS response from
> 2a00:f680:100:1501::32#53
> named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS response from
> 2a00:f680:10:1501::33#53
> named[3428351]: zone lowinger.se/IN (signed): checkds: empty DS response from
> 127.0.0.1#53
>
> zone "lowinger.se" {
>
> type primary;
> file "lowinger.se";
> dnssec-policy lowinger-policy;
> inline-signing yes;
> // parental-agents {
> // 2a00:f680:100:1501::32;
> // 2a00:f680:100:1501::33;
> // };
>
> parental-agents { 127.0.0.1; };
> };
>
> BIND 9.18.10-1+ubuntu22.04.1+isc+1-Ubuntu (Stable Release)
>
>
> dig has no problem resolving the DS record.
>
> # dig @127.0.0.1 lowinger.se ds +short
> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>
> # dig @2a00:f680:100:1501::32 lowinger.se ds +short
> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>
> # dig @2a00:f680:100:1501::33 lowinger.se ds +short
> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>
>
>
>
> --
> Regards / Med vänlig hälsning
> Anders Löwinger, CEO, Abundo AB, +46 72 206 0322
>
> --
> 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: General DNS / SPF question
Please don’t hijack an existing thread by replying to an existing message for a
unrelated subject. It is bad form. Just create a new message and send it to
bind-us...@isc.org.
--
Mark Andrews
> On 8 Jan 2023, at 09:07, Michael Muller via bind-users
> wrote:
>
>
> Hello everyone,
>
> This is my first time posting here, and I'm not sure if it's the right place
> or not to ask my question. This is a general DNS question, specifically, I
> think, SPF.
>
> (Btw, I do use Bind in my system, so that's why I'm here.)
>
> I host email using SmarterMail, and all 400+ customers either use a regular
> email client (desktop app/mobile device) or the webmail interface.
>
> One particular customer wants to use Gmail as their email client for sending
> email from their domain. I helped set up the settings at gmail for the SMTP
> server, and did the google-siteverification and added include:gmail.com to
> the SPF TXT record, as well as DKIM and DMARC configured. I get green lights
> for the domain from Dmarcian (well, they said I had a duplicate SPF value,
> which I have removed).
>
> The emails that get sent *do* arrive for other users on my email server, but
> *not* to email addresses off-server, ie; @live.com
>
> I can see the traffic from gmail in my logs, and it appears the emails are
> sent, but they do not arrive.
>
> Stumped. Any spare brain cells available out there would be appreciated.
>
> Thanks,
>
> Mik
>
> Mik Muller, president
> Montague WebWorks
> 20 River Street, Greenfield, MA
> 413-320-5336
> http://MontagueWebWorks.com
> Powered by ROCKETFUSION
> On 1/7/2023 3:11 PM, Anders Löwinger wrote:
>> Hi
>>
>> I have some trouble with the parental-agents. Anyone seen this before/can
>> give me a clue to get this working?
>>
>> Tried with my two recursive resolvers first, then localhost. No difference.
>>
>> From the log
>>
>> named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS response
>> from 2a00:f680:100:1501::32#53
>> named[3420650]: zone lowinger.se/IN (signed): checkds: empty DS response
>> from 2a00:f680:10:1501::33#53
>> named[3428351]: zone lowinger.se/IN (signed): checkds: empty DS response
>> from 127.0.0.1#53
>>
>> zone "lowinger.se" {
>>
>> type primary;
>> file "lowinger.se";
>> dnssec-policy lowinger-policy;
>> inline-signing yes;
>> // parental-agents {
>> // 2a00:f680:100:1501::32;
>> // 2a00:f680:100:1501::33;
>> // };
>>
>> parental-agents { 127.0.0.1; };
>> };
>>
>> BIND 9.18.10-1+ubuntu22.04.1+isc+1-Ubuntu (Stable Release)
>>
>>
>> dig has no problem resolving the DS record.
>>
>> # dig @127.0.0.1 lowinger.se ds +short
>> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>>
>> # dig @2a00:f680:100:1501::32 lowinger.se ds +short
>> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>>
>> # dig @2a00:f680:100:1501::33 lowinger.se ds +short
>> 59647 14 2 825E888C2FAA4F70241467A257C02C66AD5DAFDB818253B7FEB52DA4 BEB071CA
>>
>>
>>
>>
>> --
>> Regards / Med vänlig hälsning
>> Anders Löwinger, CEO, Abundo AB, +46 72 206 0322
>>
>>
> --
> 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: Can not query localhost
Now you went from Oracle Linux 6 to Oracle linux 9.16 (b.t.w. no one keeps track of which BIND version ships which which random Linux distro, it is much better to report the BIND versions as well). In that time there has been a lot of change. Did you copy over just the local configuration changes or did you copy over everything? By local configuration changes I mean just the zone you added and any acls. Distros expect you to put local changes in isolated files so they can update defaults configurations without overwriting local config. Copying everything means that you are missing all those changes. > On 14 Jan 2023, at 03:48, David Carvalho via bind-users > wrote: > > > Ok, so apparently everything seems to be running fine. > > > I am not using dnsssec (dnssec-validation is auto ?!) and "dnssec-enable > yes" was considered obsolete by named-checkconfg, so it is also commented. > I had to comment > > bindkeys-file "/etc/named.iscdlv.key"; Well what was in "/etc/named.iscdlv.key” ? I suspect it was grossly out of date. Anything that mentions DLV is out of date as that has been shutdown for years and is just returning a response that says there is no content here anymore. Also the Root’s DNSSEC keys rolled in 2017 and if it hasn’t been updated since before then the key is out of date. There should be nothing in there but public keys which are safe to publish. Commenting it out meant that you are now using the built in trust anchors. Defaults for DNSSEC have changed over time (validation is on by default) and using out of date trust anchors with newer versions of BIND will cause DNSSEC validation failures. > managed-keys-directory "/var/named/dynamic"; > > and everything worked. Still don't understand exactly why, I will continue > to investigate, but any feedback is welcome. Named logs why thing fail. Examine the logs. > Thanks > Regards > David > > > > -Original Message- > From: bind-users On Behalf Of David > Carvalho via bind-users > Sent: 13 January 2023 14:11 > To: 'Marco' ; bind-users@lists.isc.org > Subject: RE: Can not query localhost > > Thanks for the reply. > Yes > > ACL active. Exact same configuration as in old server named.conf, with a > different listening IP, of course, which belongs to my LAN ACL. > > Performing "dig @localhost any my.domain" works perfectly. If querying just > "dig @localhost" or "dig @my.ip", tcpdump shows it trying to connect to top > level IPs And I keep getting SERVFAIL. > > > Regards. > David > > > -Original Message- > From: Marco > Sent: 13 January 2023 11:33 > To: bind-users@lists.isc.org > Cc: David Carvalho > Subject: Re: Can not query localhost > > Am 13.01.2023 schrieb David Carvalho via bind-users > : > >> I get SERVFAIL when querying outside my domain. > > Have you enabled an ACL that allows any IP address to query your public > zones? > > You can only restrict recursive requests to your own IP addresses. > > -- > 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 -- 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: DNSSEC With Primary Hidden - Clarifying Question from Documentation
> On 18 Jan 2023, at 10:55, Grant Taylor via bind-users > wrote: > > On 1/17/23 4:45 PM, Michael Richardson wrote: >> Many people do exactly that. > > Sorry, I don't see that as an answer to -- my understanding of -- the OP's > question of "Does the primary server that handles the DNSSEC duties need to > be not hidden / publicly accessible?" > > Specifically what many people do, or not, doesn't translate to a requirement. > >> In my opinion, this is the best way to do things, and the in-place signing is >> just a total pain. > > Your opinions, such as they are, are independent of the OP's question. > > I've got an ancient version of BIND managing all of the DNSSEC wherein the > master is sort of hidden in that it's listed in the SOA's MNAME, but is not > listed as an NS. The MNAME is globally accessible. > > I'm sure that I'm overlooking something at the end of a long day, but I can't > see anything that prevents the OP from having the primary perform DNSSEC > functions while also functioning as a hidden primary role. DNSSEC was designed with the primary doing the signing and the secondaries just serving the signed content. DNSSEC works fine with a hidden primary signing the zone. As with everything DNSSEC every server involved needs to support DNSSEC. Now how you manage that signing is a completely seperate topic and there are different ways to do it. > -- > 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 -- 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: "not exact" error message
The consistency checks are not new. The message indicates that the IXFR contained a delete request for a record that doesn’t exist or an add for a record that exists. Named recovers be performing an AXFR of the zone. -- Mark Andrews > On 22 Jan 2023, at 04:31, Havard Eidnes via bind-users > wrote: > > Hi, > > I tried using BIND 9.18.10 as a downstream name server of an > OpenDNSSEC 2.1.8 installation, but after sorting out the ACL > issues on the OpenDNSSEC side, zone transfers failed with > messages such as these: > > Jan 21 17:15:34 new-ns named[22056]: transfer of '4.38.158.in-addr.arpa/IN' > from 158.38.x.yy#53: failed while receiving responses: not exact > Jan 21 17:16:42 new-ns named[22056]: transfer of 'ufisa.no/IN' from > 158.38.x.yy#53: failed while receiving responses: not exact > > Downgrading BIND to 9.16.36 made this work, so this appears to be > a new consistency check introduced with the newer version which > isn't being done by 9.16.36. > > Any idea what this new check consists of, and what I should hint > to the OpenDNSSEC developers to fix? > > I did a "dig axfr -y " of one of the zones from the > OpenDNSSEC host, and I found the TSIG record used to support the > zone transfer embedded in the result (twice!), and when I fed the > resulting file to named-checkzone, it didn't want to validate the > zone before I removed the two TSIG records. This, however, may > be unrelated; I do not know. > > Best 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 -- 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: signing for a hidden primary
In-line signing is the concept you are looking for and yes named supports it. -- Mark Andrews > On 22 Jan 2023, at 07:42, Randy Bush wrote: > > hidden primary can not sign. can the public primary which fetches from > it, and happens to be primary for the parent zone, do bitw signing? > > randy > -- > 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: "not exact" error message
> On 22 Jan 2023, at 09:54, Havard Eidnes wrote: > >> The consistency checks are not new. The message indicates that >> the IXFR contained a delete request for a record that doesn't >> exist or an add for a record that exists. Named recovers be >> performing an AXFR of the zone. > > Interesting. > > BIND 9.16.36 does not produce this log message, so it was easy to > be misled to conclude that this was a new consistency check. > Does 9.16.36 and 9.18.10 behave differently in terms of their > usage of IXFR? > > The log message BIND 9.18.10 produces does not mention IXFR or > that it's going to fallback to AXFR. I mis-interpreted it as a > fatal error message, and downgraded to BIND 9.16.36 without > verifying whether 9.18.10 actually worked as intended anyway (it > does, I just re-instaled 9.18.10 and re-signed a zone and > verified that it makes it through). The log message can only be produced when an IXFR stream is being processed. The consistency checks have been there as long as IXFR has existed. There are too many ways that zone content can be changed by administrators incorrectly. Then there are other behaviours that lead to inconsistencies. Transferring from multiple Microsoft Windows Active Directory servers can produce this, the LDAP synchronisation doesn’t ensure that a given serial number matches the same content on each server. Transferring from multiple servers each doing their own inline-signing can produce this (RRSIGs will differ between servers as the RRsets are changed at different times and zone serial numbers may also differ). There are a whole heap of reasons for IXFR to fail, this being one of them, and named will fall back to AXFR on any of them. > Regards, > > - Håvard -- 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: Finding dnssec validation failures in the logs
I would be looking for packet loss and / or a bad firewall that is dropping fragmented packets which is triggering fallback to non EDNS requests If you are forwarding ensure that the entire forwarding chain is validating. -- Mark Andrews > On 25 Jan 2023, at 04:53, John Thurston wrote: > > > It sounds like I'm correct that lines of the sort: > > validating com/SOA: got insecure response; parent indicates it should be > secure > > are my indication that dnssec is doing its job. (Whether I should be reacting > to messages like the above remains to be seen.) > > Let me rephrase my original question (which remains unanswered): Are there > other strings in the log which similarly indicate dnssec is doing its job and > logging responses which can not be validated? > > Of the lines like the above (for a sample day), 92% of them indicate failure > to validate SOA-records. Only 4% are for A-records. Of those same lines, the > most prevalent entris are the SOA-records for: > > 2%io > 2%us > 2%ip6.arpa > 2%pure.cloud > 2%org > 4%impervadns.net > 6%net > 7%cloudflare.net > 9%. > 33% com > > It concerns me the SOA records I'm requesting are so often being rejected as > invalid. > > I have my suspicions of what's happening, but not enough information to form > a solid hypothesis or perform tests. I want higher confidence that I'm > recognizing the important lines in the logs before I start casting stones. > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > On 1/24/2023 5:26 AM, Michael Richardson wrote: >> John Thurston wrote: >> > On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" >> I am >> > writing "category dnssec" to a log file at "severity info;" When I >> look in >> > the resulting log file, I'm guessing that lines like this: >> >> > validating com/SOA: got insecure response; parent indicates it should >> be >> > secure >> >> > Are an indication I have a problem I should investigate. >> >> Maybe. >> It could be that DNSSEC is simply defending you against attackers who are >> trying to race insecure answers to your queries in the belief that "nobody >> validates" >> >> If it were systematic (every query, every query to some servers...) then you >> should suspect that there is a on-path attacker modifying the responses. >> That's unlikely in general, but it's why we have DNSSEC. >> It could also be the result of corrupted packets that survive the UDP >> checksum, or which go through a middle box that "fixes" that. Some satellite >> systems do that. I imagine that Alaska might have at least one satellite >> link. >> >> It doesn't sound like it's systematic, so I think they are off-path >> attackers, and it looks like it's queries on .com? >> >> Most likely, there is little you can do. > -- > 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: Converting between zone file formats
Named-checkzone and named-compilezone are the same executable. Named-checkzone looks up remote records to more completely detect configuration errors. See the man page for details. -- Mark Andrews > On 30 Jan 2023, at 19:33, Havard Eidnes via bind-users > wrote: > > Hi, > > by default, the files written by BIND when acting as a slave is > not in "text" format, but is some binary file format, I beleive > what is referred to as "raw" format. > > Once in a while it's desireable to be able to see the contents of > the slave zone file as plain text. To that end I have previously > used named-compilezone to do this with > > named-compilezone \ >-q -j -f raw -F text -o - \ >$z \ >$directory/$z > > However... This does not appear to work anymore. > > Earlier I ran BIND 9.16 on this host, but it has been upgraded to > 9.18 (built and installed from local source). It seems that a > while back (probably in the 9.16 era), named-compilezone was > changed to a symlink to named-checkzone, and it also looks like > BIND 9.18 no longer installs named-checkzone, so what I have as > named-checkzone appears to come from BIND 9.16. > > Trying to use the procedure as above results in a named-checkzone > which hangs in select(), which is a bit strange when it's only > supposed to act on local files?!? > > What should I now use instead of the above to convert the binary > zone file to back to the textual master zone file format? Please > don't say "that's not possible"... > > (This might be important to be able to do if an upstream suffers > a catastrophe of some sort, as a step along the path to convert > this name server to be a master for the zone in question. Being > a master implies being able to modify the zone, and doing that > with a binary file is ... slightly inconvenient.) > > 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 -- 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: filter-a and dns64 in a ipv6-only network
Do you want a correctly operating DNS64 server or do you want to filter
all A records? They are mutually exclusive requirements. Please read
RFC 6147 to understand why they are mutually exclusive.
IPv6-only means that the IP packets being sent and received are only IPv6
packets for the thing (node, network) that is being described as IPv6-only.
You seem to have this strange notion that to run an IPv6-only node or
network that you need to filter out A records. Could you tell me who or
what told you this was required?
Mark
> On 31 Jan 2023, at 06:01, Thomas Schäfer wrote:
>
> Hi,
>
> I use tumbleweed for testing, since compiling bind is hard(at least for me).
>
> bind version: 9.18.11
>
> options {
>
>dns64 64:ff9b::/96 {
>clients { any; };
>recursive-only yes;
>mapped { !10/8; any; };
>};
>
> };
>
>plugin query "filter-a.so" {
> filter-a-on-v6 break-dnssec;
> filter-a-on-v4 break-dnssec;
> filter-a { ::/0 ; };
>};
>
> My test setup is intended to be ipv6-only. Please don't try to convince me,
> that clat would be better.
> (https://lists.isc.org/mailman/htdig/bind-users/2022-March/105826.html) I
> don't want IPv4 at all.
>
> The first line of the man page says:
> "filter-a - filter A in DNS responses when is present"
>
> and here starts my problem: dns64 generates an -Record, but the plugin
> filter-a expects an real -response. In the end a isn't filtered.
>
>
> Example with real -record
> host ct.de ::1
> Using domain server:
> Name: ::1
> Address: ::1#53
> Aliases:
>
> ct.de has IPv6 address 2a02:2e0:3fe:1001:302::
> ct.de mail is handled by 50 secondarymx.heise.de.
> ct.de mail is handled by 10 relay.heise.de.
>
> Example with synthesized -record
>
> host sz.de ::1
> Using domain server:
> Name: ::1
> Address: ::1#53
> Aliases:
>
> sz.de has address 195.50.177.61
> sz.de has IPv6 address 64:ff9b::c332:b13d
> sz.de has IPv6 address 64:ff9b::c332:b13d
> sz.de mail is handled by 50 sz-de.mail.protection.outlook.com.
>
>
> How can I achieve to remove a-records at any time?
>
>
> Regards,
> Thomas
>
>
>
>
> --
> 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: filter-a and dns64 in a ipv6-only network
> On 1 Feb 2023, at 05:52, Thomas Schäfer wrote: > > Am Montag, 30. Januar 2023, 23:12:53 CET schrieb Mark Andrews: >> Do you want a correctly operating DNS64 server or do you want to filter >> all A records? They are mutually exclusive requirements. Please read >> RFC 6147 to understand why they are mutually exclusive. > > That's simply not true. RFC 6147 is about synthesizing records based on > A > records. It says nothing about blocking A records afterwards. Then pray tell how does section 5.5. "DNSSEC Processing: DNS64 in Validating Resolver Mode” work if the server does not return A records? As I said DNS64 and filtering A records are mutually exclusive. There is down stream stuff that needs to see the records to make their own records. B.T.W. That section is not really compatible with DNSSEC. It works in some circumstances but will fail in other as a validating DNSSEC client needs to ask both CD=0 and CD=1 questions. I tried hard to point out that DNS64 was incompatible with DNSSEC while it was still in draft form. >> You seem to have this strange notion that to run an IPv6-only node or >> network that you need to filter out A records. > > It isn't more strange than filtering records in old IPv4 only networks. > That filter is ironically implemented by the isc - despite there is no > serious > RFC for that. > The purpose of the A record filter is to correct the behavior of apps which > don't respect IPv6 RFCs regarding the preference of IPv6 over IPv4. >> Could you tell me who or >> what told you this was required? > > Thank you for the personal attack within the first contact. Firstly I wanted to correct the source of the misinformation. I’m sorry if you perceived it as an attack. > I am old (enough) > - I can speak for myself. > I am an experienced user of different IPv6 only networks. > e.g > daily at eduroam-IPv6only, a big Wifi network administrated by the Leibniz > Supercomputinger Centre in Munich, > daily at the IPv6-only mobile network(4g/5g) by Deutsche Telekom, > once a year at the RIPE conference WiFi > I am the admin of my home/test lab with: tayga, jool, unbound (filters a, > does > dns64) , dnsmasq (can filter a, but can't do dns64 ) Just because something does something doesn’t make it a good thing. > I know that clat is a solution for *some* very old apps, usually on > smartphones and recently also on macs. > Nevertheless Windows doesn't use clat in wireless/wired LANs. > I want to get rid of clat - aka 464xlat. ( clat was not invented for eternity) > Even linux has no default clat installation on many distributions. On Windows you can manually configure an IPv4 in IPv6 tunnel and use it to talk to a DS-Lite AFTR element (RFC 6333) if it doesn’t do it automatically. I don’t use Windows normally so I don’t know whether it has support to look for the IPv6 DHCPv6 option to automatically configure the tunnel. You can do the same with a Mac and Linux boxes. > My experience until now: the a record filter doesn't break anything, but it > make some apps working without clat - so at least some windows and linux > apps. Well now you have learnt that it does break DNS64. > Now I am testing the usefulness of bind. In the recent state it isn't useful. > > Regards > Thomas Schäfer -- 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: Requesting Update-Policy Statements Sanity Check, Please
> On 3 Feb 2023, at 21:47, Darren Ankney wrote:
>
> You would probably need to attach your entire named.conf file (with
> sensitive bits (keys and the like) redacted and perhaps subnets
> obscured to examples such as 192.0.2.0/24, for example) before anyone
> would be able to help you.
>
> That being said, your update policy statements don't look correct to
> me. Have you tried to load them with BIND? Do they pass syntax check?
> The reason they don't look right is that they seem to follow this
> format correctly:
>
> # (grant | deny ) identity ruletype name types
>
> but include the word "name" which I think is meant to be replaced
> with your actual domain name (ie: I don't think the word "name" should
> be in the policy).
No, “name” there is the rule type.
> I have not previously used update-policy but I'd think it should be like this:
>
> update-policy {grant A ;};
This leaves out rule type.
>
> from reading:
> https://bind9.readthedocs.io/en/v9_18_11/reference.html#namedconf-statement-update-policy
--
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: Requesting Update-Policy Statements Sanity Check, Please
You need to replace the rule type with something more appropriate for the type
of update being preformed. For the updates made by the DHCP server I would use
“zonesub”. “name” is fine for LetsEncrypt.
update-policy {grant update-key zonesub A ;};
update-policy {grant update-key zonesub PTR;};
``zonesub``
This rule is similar to subdomain, except that it matches when the name
being updated is a subdomain of the zone in which the :any:`update-policy`
statement appears. This obviates the need to type the zone name twice, and
enables the use of a standard :any:`update-policy` statement in multiple zones
without modification. When this rule is used, the ``name`` field is omitted.
> On 3 Feb 2023, at 18:04, duluxoz wrote:
>
> Hi All,
>
> I'm pretty new to configuring Bind and so it would be great if someone(s)
> could just check my code re: the update-policy zone command(s) below - thanks
> in advance.
>
> For the first zone (a regular internal forward-lookup zone) I'd like to be
> able to update (from Kea via ddns) the zone when a new host is assigned/etc a
> DHCP lease:
>
> update-policy {grant update-key name internal-forward-lookup.local A ;};
>
> For the second zone (a regular internal reverse-lookup zone for the
> 192.168.1.0/24 network) I'd like to be able to update (from Kea via ddns) the
> zone when a new host is assigned a DHCP lease (obviously I've got an
> equivalent IPv6 reverse-lookup zone :-) ):
>
> update-policy {grant update-key name 1.168.192.IN-ADDR.ARPA PTR;};
>
> For the third zone (a regular external forward-lookup zone) I'd like to be
> able to update (via acme.sh/LetsEncrypt) the _acme-challenge.example.com TXT
> record when a Certificate is requested/renewed:
>
> update-policy {grant update-key name _acme-challenge.example.com TXT;};
>
> I've got the update-key configured and available on all the necessary boxes,
> etc, and dns (for fixed IP addresses) and dhcp are working - I just need to
> get these update-policy statements correct.
>
>
> Any help is greatly appreciated - and again, thanks in advance
>
> Cheers
>
> Dulux-Oz
--
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: Requesting Update-Policy Statements Sanity Check, Please
Add DHCID to the list of record types permitted to be updated by the DHCP
server.
--
Mark Andrews
> On 4 Feb 2023, at 21:15, duluxoz wrote:
>
> Thanks Mark (& Darren & Jan-Piet),
>
> So I made those changes you suggested (Mark), but I'm still having issues (ie
> DHCP leases are not being added to the DNS zones), so I've included my Bind9
> config:
>
> ~~~
>
> acl "bogusnets" {
> !"internal_hosts";
> 0.0.0.0/8;
> 10.0.0.0/8;
> 172.16.0.0/12;
> 192.0.2.0/24;
> 192.168.0.0/16;
> 224.0.0.0/3;
> };
> acl "internal_hosts" {
> 192.168.1.0/24;
> 192.168.2.0/24;
> };
> acl "secondary_external_servers" {
> 192.168.1.1/32;
> 192.168.1.2/32;
> };
> acl "secondary_internal_servers" {
> 192.168.2.1/32;
> 192.168.2.2/32;
> };
> acl "servers_ddns" {
> "localhost";
> 192.168.2.3/32;
> };
> acl "servers_rndc" {
> "localhost";
> 192.168.2.3/32;
> };
> acl "stats_hosts" {
> 192.168.2.0/24;
> };
> controls {
> inet 0.0.0.0 port 953 allow {
> "servers_rndc";
> } keys {
> "rndc.key";
> };
> };
> logging {
> channel "auth_servers_log" {
> file "/var/log/named/auth_servers.log" versions 3 size 512000 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "client_security_log" {
> file "/var/log/named/client_security.log" versions 3 size 512000
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "default_log" {
> file "/var/log/named/default.log" versions 3 size 512000 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "default_debug_log" {
> file "/var/log/named/default_debug.log" versions 3 size 512000 suffix
> timestamp;
> severity dynamic;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "ddns_log" {
> file "/var/log/named/ddns.log" versions 3 size 512000 suffix
> timestamp;
> severity debug 1;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "dnssec_log" {
> file "/var/log/named/dnssec.log" versions 3 size 512000 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "queries_log" {
> file "/var/log/named/queries.log" versions 3 size 512000 suffix
> timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "query_errors_log" {
> file "/var/log/named/query_errors.log" versions 3 size 512000 suffix
> timestamp;
> severity dynamic;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> channel "zone_transfers_log" {
> file "/var/log/named/zone_transfers.log" versions 3 size 512000
> suffix timestamp;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
> category "client" {
> "client_security_log";
> "default_debug";
> };
> category "dnssec" {
> "dnssec_log";
> "default_debug";
> };
> category "default" {
> "default_syslog";
> "default_debug";
> "default_log";
> };
> category "delegation-only" {
> "auth_servers_log";
> "default_debug";
> };
> category "edns-disabled" {
> "auth_servers_log";
> "default_debug";
> };
> category "lame-servers" {
> "auth_servers_log";
> "default_debug";
> };
> category "notify" {
> "zone_transfers_log";
> "default_debug";
>
Re: [KASP] Key rollover
You configure parental agents and named will check which DS’s are published. Named won’t complete the roll until it knows the new DS is published. > On 9 Feb 2023, at 19:49, Nick Tait via bind-users > wrote: > > On 9/02/23 05:17, adrien sipasseuth wrote: >> so it works BUT I need to know more than 48h in advance that the rollover is >> starting to submit the new KSK to my registar. >> >> How can I set this up if it's not with "public-safety"? > If it was me, I'd set the KSK to not roll-over automatically, and instead > create a recurring reminder for yourself to initiate the KSK roll-over > manually? That way you'd never get caught out with a KSK roll-over happening > when you weren't prepared for 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 -- 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: Restrict dynamic updates to one domain - disallow subdomains
Step back and tell us what you are attempting to achieve.
e.g. I want my hosts to be able to update their address records.
grant admin-key subzone ANY;
grant * self . A ;
and use SIG(0) to sign the updates. The admin adds the public KEY record for
the machine
using ‘admin-key’.
You generate a KEY record on the machine
% dnssec-keygen -T KEY -a RSASHA256 -n host -L 3600 ns1.example.com
Generating key
pair+*.+*..+.+...+...+...++.+.+..+
...+...+.+.+...+..++...+.+.+*.+.+..+.+.+..+..+.+...+.+..+...+++...++...+.+..+..+*.+.+.+.+.+.+...+..+.+..+.+.+..+..+.+...+..++..+...++.+.++.+.+...+..+.+.+.+..+..++..++.+...+
Kns1.example.com.+008+18976
%
which produces the public key
% cat Kns1.example.com.+008+18976.key
ns1.example.com. 3600 IN KEY 512 3 8
AwEAAaxeX1NDwHGxgBKNb/D9+JrwbRnoM+OIe/Y/f5X7gmXdiZ9xOjWM
alGauUtKzx1VvX2QyDUMs8zimoK4L+MM+ghEsvPjUBAnBN+p3Urq+Ae/
mxCmNMzwm3At18MS4TwmzJFFOOZCyQ2eIp0DiW8G+JZTr/3tYmZmPvTO
l4OSAZ3DRPQlwro2QH2gp2r3nIEdPbY4x5//H++5NSns6N2mAGo3fkA2
b6EpINrQJ40NPIOq8fvWGs+oiGFl83xsCWpbbezjMebdvMFDTaEZBqPS
vtqQCBfT7RRqIUebT6fKU3ZQh55Bah/5LJDIK3VDy05iAVVby/lCZ2YU IgGQm6NU1bM=
%
and you add to the zone like this
% awk '{print “update add", $0 } END { print "send" }’
Kns1.example.com.+008+18976.key | nsupdate -k admin-key.key
%
Add ‘BEGIN { print “zone ” }’ to the awk command if you are
updating glue address records this way.
Then the host it updates its address records using the private part of the key
pair
% nsupdate -k Kns1.example.com.+008+18976.private
update add ns1.example.com 3600 IN A 10.0.0.1
update add ns1.example.com 3600 IN 2001::1
send
%
You can do similar with TSIG by giving the key the same name as the machine but
you also need to add key clauses for all the TSIG keys to named.conf.
> On 14 Feb 2023, at 07:55, André Steden via bind-users
> wrote:
>
> But i don't want to specify all possible hostnames in the update-policy
> settings .
>
> there are more than 350 hosts in the example.de domain.
>
>
> Am 13.02.2023 um 20:06 schrieb Jan-Piet Mens:
>>> is it possible to restrict dynamic dns updates to one domain?
>>
>> I think 'name' is what you're after:
>>
>> grant key-name name host1.example.de. A;
>>
>> You will be aware that the type list can take multiple space-separated
>> values.
>>
>> -JP
> --
> 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: Restrict dynamic updates to one domain - disallow subdomains
Use external. You can create any rule you can think of with that.
> On 14 Feb 2023, at 20:29, André Steden wrote:
>
> I want an external server to be able to update all the hosts (A) records
> inside the example.de domain.
> But i don't want that the external server can create subdomain entries inside
> the example.de domain.
>
> Is this possible? What grant/deny rule must i use?
>
> -André
>
> Am 13.02.2023 um 23:33 schrieb Mark Andrews:
>> Step back and tell us what you are attempting to achieve.
>>
>> e.g. I want my hosts to be able to update their address records.
>>
>> grant admin-key subzone ANY;
>> grant * self . A ;
>>
>> and use SIG(0) to sign the updates. The admin adds the public KEY record for
>> the machine
>> using ‘admin-key’.
>>
>> You generate a KEY record on the machine
>>
>> % dnssec-keygen -T KEY -a RSASHA256 -n host -L 3600 ns1.example.com
>> Generating key
>> pair+*.+*..+.+...+...+...++.+.+..+
>>
>> ...+...+.+.+...+..++...+.+.+*.+.+..+.+.+..+..+.+...+.+..+...+++...++...+.+..+..+*.+.+.+.+.+.+...+..+.+..+.+.+..+..+.+...+..++..+...++.+.++.+.+...+..+.+.+.+..+..++..++.+...+
>> Kns1.example.com.+008+18976
>> %
>>
>> which produces the public key
>>
>> % cat Kns1.example.com.+008+18976.key
>> ns1.example.com. 3600 IN KEY 512 3 8
>> AwEAAaxeX1NDwHGxgBKNb/D9+JrwbRnoM+OIe/Y/f5X7gmXdiZ9xOjWM
>> alGauUtKzx1VvX2QyDUMs8zimoK4L+MM+ghEsvPjUBAnBN+p3Urq+Ae/
>> mxCmNMzwm3At18MS4TwmzJFFOOZCyQ2eIp0DiW8G+JZTr/3tYmZmPvTO
>> l4OSAZ3DRPQlwro2QH2gp2r3nIEdPbY4x5//H++5NSns6N2mAGo3fkA2
>> b6EpINrQJ40NPIOq8fvWGs+oiGFl83xsCWpbbezjMebdvMFDTaEZBqPS
>> vtqQCBfT7RRqIUebT6fKU3ZQh55Bah/5LJDIK3VDy05iAVVby/lCZ2YU IgGQm6NU1bM=
>> %
>>
>> and you add to the zone like this
>>
>> % awk '{print “update add", $0 } END { print "send" }’
>> Kns1.example.com.+008+18976.key | nsupdate -k admin-key.key
>> %
>>
>> Add ‘BEGIN { print “zone ” }’ to the awk command if you
>> are updating glue address records this way.
>>
>> Then the host it updates its address records using the private part of the
>> key pair
>>
>> % nsupdate -k Kns1.example.com.+008+18976.private
>> update add ns1.example.com 3600 IN A 10.0.0.1
>> update add ns1.example.com 3600 IN 2001::1
>> send
>> %
>>
>> You can do similar with TSIG by giving the key the same name as the machine
>> but you also need to add key clauses for all the TSIG keys to named.conf.
>>
>>> On 14 Feb 2023, at 07:55, André Steden via bind-users
>>> wrote:
>>>
>>> But i don't want to specify all possible hostnames in the update-policy
>>> settings .
>>>
>>> there are more than 350 hosts in the example.de domain.
>>>
>>>
>>> Am 13.02.2023 um 20:06 schrieb Jan-Piet Mens:
>>>>> is it possible to restrict dynamic dns updates to one domain?
>>>> I think 'name' is what you're after:
>>>>
>>>> grant key-name name host1.example.de. A;
>>>>
>>>> You will be aware that the type list can take multiple space-separated
>>>> values.
>>>>
>>>> -JP
>>> --
>>> 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: limit the number of invalid domain queries
It sounds like you are subject of a DoS attack or are being used in a DoS attack against someone else. Often the IP addresses are forged. In other cases they come from recursive servers that are also being abused. You can configure response rate limiting. https://bind9.readthedocs.io/en/v9_16_9/reference.html?highlight=Response%20rate%20limiting#response-rate-limiting You can also sign the zone using NSEC which will allow recursive servers that support DNSSEC synthesis to return responses for names that don’t exist without contacting your server as often. They need to contact you enough to build up the NSEC chain to be able to synthesis the NXDOMAIN response. > On 22 Feb 2023, at 13:32, Chinhlk wrote: > > Hi , > > I have a DNS server using BIND 9.16 software. > I have a phenomenon where there are many queries from different IPs to the > subdomains of cosy.vn (these subdomains do not exist; the domain name cosy.vn > is the main domain I am using). These queries cause an overload for my > system. I have used IP blocking solution, but these IPs are many and > constantly changing. > I would like to ask is there a way to configure blocking of queries from > those strange IPs to my subdomains? > > Thanks and looking forward to your support. > > Chinhlk > -- > 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: Correlation between NOTIFY-Source and AXFR-Source
Named just uses the notify to trigger an early refresh process. It then just asks the primaries in configured order. There is no real point in trying the notifier first. -- Mark Andrews > On 10 Mar 2023, at 06:00, Jan-Piet Mens wrote: > > >> >> I always was quite sure that Bind will request XFR from the Primary that >> sent the NOTIFY. > > my understanding has always been that the primaries are tried in configured > order. > > Looking forward to hear which is actually correct. :) > >-JP > -- > 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: DNSSEC error resolving gpo.gov ?
Why are you trying to query this address? The IPv4 servers are 162.140.15.100 and 162.140.254.200. > On 15 Mar 2023, at 07:53, Darren Ankney wrote: > > This is failing for me regularly: > > $ dig ns3.gpo.gov +dnssec +norecurse @162.140.15.200 > ;; communications error to 162.140.15.200#53: timed out > ;; communications error to 162.140.15.200#53: timed out > ;; communications error to 162.140.15.200#53: timed out > > ; <<>> DiG 9.18.11 <<>> ns3.gpo.gov +dnssec +norecurse @162.140.15.200 > ;; global options: +cmd > ;; no servers could be reached > > but all other combos of ns3.gpo.gov or ns4.gpo.gov and 162.140.15.100 > and 162.140.15.200 work fine. > > On Tue, Mar 14, 2023 at 12:03 PM Tim Maestas wrote: >> >> I've been having problems resolving www.federalregister.gov which is served >> by ns3.gpo.gov and ns4.gpo.gov, using BIND 9.16.27. Haven't been able to >> quite figure out why so I've stuck an NTA in for the time being. >> >> On Tue, Mar 14, 2023 at 8:52 AM Stephane Bortzmeyer >> wrote: >>> >>> On Tue, Mar 14, 2023 at 11:35:38AM -0400, >>> Alexandra Yang wrote >>> a message of 183 lines which said: >>> >>>> I wonder if any of your nameserver resolve it just fine, like 8.8.8.8 >>>> works >>> >>> Among RIPE Atlas probes, most succeed: >>> >>> % blaeu-resolve --displayvalidation -r 100 --type A gpo.gov >>> [ (Authentic Data flag) 162.140.14.82] : 46 occurrences >>> [162.140.14.82] : 52 occurrences >>> [ERROR: SERVFAIL] : 2 occurrences >>> Test #50935448 done at 2023-03-14T15:46:50Z >>> >>> The two whose resolvers servfail may have stricter/paranoid resolvers. -- 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: DNSSEC error resolving gpo.gov ?
> On 15 Mar 2023, at 02:08, Alexandra Yang wrote: > > Hi Group, > > I wonder if anyone can shed some light on this, our nameserver(BIND 9.16.37 > )keeps giving error on resolving gpo.gov and ns3.gpo.gov, here are the errors: > > Mar 14 10:23:32 ipam-dns-in-1 named[3713]: validating gpo.gov/SOA: got > insecure response; parent indicates it should be secure For some reason you are not getting signed responses. Are you using a forwarder? > Mar 14 10:23:32 ipam-dns-in-1 named[3713]: no valid RRSIG resolving > 'ns3.gpo.gov/DS/IN': 162.140.254.200#53 > Mar 14 10:23:32 ipam-dns-in-1 named[3713]: broken trust chain resolving > 'ns3.gpo.gov/A/IN': 162.140.15.100#53 > > While I checked the DNSSEC of this domain I can't seem to find any problem > could cause above error, anyone else see issue with resolving gpo.gov ? > > Thanks!! > > Sandra > -- > 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: DNSSEC error resolving gpo.gov ?
> On 15 Mar 2023, at 11:14, Tim Maestas wrote: > > > > On Tue, Mar 14, 2023 at 4:34 PM Mark Andrews wrote: > > > > On 15 Mar 2023, at 02:08, Alexandra Yang wrote: > > > > Hi Group, > > > > I wonder if anyone can shed some light on this, our nameserver(BIND 9.16.37 > > )keeps giving error on resolving gpo.gov and ns3.gpo.gov, here are the > > errors: > > > > Mar 14 10:23:32 ipam-dns-in-1 named[3713]: validating gpo.gov/SOA: got > > insecure response; parent indicates it should be secure > > For some reason you are not getting signed responses. Are you using a > forwarder? > > For what it's worth, I keep getting: > Mar 14 23:59:56 cl-dns1 named[19640]: view Caching: validating > federalregister.gov/SOA: got insecure response; parent indicates it should be > secure > Mar 14 23:59:56 cl-dns1 named[19640]: no valid RRSIG resolving > 'www.federalregister.gov/DS/IN': 162.140.254.200#53 > Mar 14 23:59:56 cl-dns1 named[19640]: view Caching: validating > federalregister.gov/SOA: got insecure response; parent indicates it should be > secure > Mar 14 23:59:56 cl-dns1 named[19640]: no valid RRSIG resolving > 'www.federalregister.gov/DS/IN': 162.140.15.100#53 > Mar 14 23:59:56 cl-dns1 named[19640]: broken trust chain resolving > 'www.federalregister.gov/A/IN': 162.140.15.100#53 > > ..no forwarders in use. At some point the domain starts to validate as my > NTAs drop out unless I use -force, but then it starts to fail again. Named should be sending queries with DO=1 and it should be getting back signed responses. I suspect that you will need to run packet captures of the traffic to and from 162.140.15.100 and 162.140.254.200 port 53 from the nameserver. Either signed responses will cease or DNSSEC requests will cease. In either case having the traffic around the transition should help to determine what is happening. e.g. tcpdump -G 100 -w %Y%m%d%H%M%S.pcap port 53 and \( host 162.140.15.100 or host 162.140.254.200 \) % tcpdump -r 20230315150938.pcap -n -vv reading from file 20230315150938.pcap, link-type EN10MB (Ethernet), snapshot length 262144 15:10:12.496870 IP (tos 0x0, ttl 64, id 17293, offset 0, flags [none], proto UDP (17), length 88) 172.30.42.109.55290 > 162.140.254.200.53: [udp sum ok] 1494% [1au] A? federalregister.gov. ar: . OPT UDPsize=1232 DO [COOKIE 1a42be4f8b283640] (60) 15:10:12.845984 IP (tos 0x0, ttl 229, id 53065, offset 0, flags [DF], proto UDP (17), length 506) 162.140.254.200.53 > 172.30.42.109.55290: [udp sum ok] 1494*- q: A? federalregister.gov. 3/3/1 federalregister.gov. A 75.2.36.59, federalregister.gov. A 99.83.174.136, federalregister.gov. RRSIG ns: federalregister.gov. NS ns4.gpo.gov., federalregister.gov. NS ns3.gpo.gov., federalregister.gov. RRSIG ar: . OPT UDPsize=4096 DO (478) 15:10:12.851518 IP (tos 0x0, ttl 64, id 27024, offset 0, flags [none], proto UDP (17), length 88) 172.30.42.109.58808 > 162.140.15.100.53: [udp sum ok] 32328% [1au] DNSKEY? federalregister.gov. ar: . OPT UDPsize=1232 DO [COOKIE a8086401dd8eae30] (60) 15:10:13.107025 IP (tos 0x0, ttl 230, id 37446, offset 0, flags [DF], proto UDP (17), length 1134) 162.140.15.100.53 > 172.30.42.109.58808: [udp sum ok] 32328*- q: DNSKEY? federalregister.gov. 5/0/1 federalregister.gov. DNSKEY, federalregister.gov. DNSKEY, federalregister.gov. DNSKEY, federalregister.gov. RRSIG, federalregister.gov. RRSIG ar: . OPT UDPsize=4096 DO (1106) % -- 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: DNSSEC error resolving gpo.gov ?
> On 15 Mar 2023, at 15:42, Tim Maestas wrote: > > Named should be sending queries with DO=1 and it should be getting back > signed responses. I suspect that you will need to run packet captures of the > traffic to and from 162.140.15.100 and 162.140.254.200 port 53 from the > nameserver. Either signed responses will cease or DNSSEC requests will > cease. In either case having the traffic around the transition should help > to determine what is happening. > > I've found that, after a fresh restart of named, if I query for > "federalregister.gov A" I get a good AD response, and then subsequent queries > for "www.federalregister.gov" are successful as well. If however after a > restart of named I begin with a query for www.federalregister.gov A then I > get servfail, and subsequent queries for federealregister.gov servfail as > well. Here is the tcpdump from the 2nd (failed) case of an initial query for > www.federalregister.gov: > > > reading from file dns.cap, link-type EN10MB (Ethernet), snapshot length 262144 > 04:30:01.114458 IP (tos 0x0, ttl 64, id 35832, offset 0, flags [none], proto > UDP (17), length 92) > 10.0.0.159.43263 > 162.140.254.200.53: [udp sum ok] 15013 [1au] A? > www.federalregister.gov. ar: . OPT UDPsize=512 DO [COOKIE 352538a87bde87a5] > (64) > 04:30:01.204863 IP (tos 0x0, ttl 229, id 4936, offset 0, flags [DF], proto > UDP (17), length 80) > 162.140.254.200.53 > 10.0.0.159.43263: [udp sum ok] 15013*-| q: A? > www.federalregister.gov. 3/0/1 . OPT UDPsize=4096 DO [|domain] This is a malformed DNS response. It looks like the server tried to send a truncated response with an OPT record but failed to correctly update the answer count field to zero. % dig www.federalregister.gov @162.140.15.100 +dnssec +bufsize=512 +ignore +qr +norec ; <<>> DiG 9.19.11-dev <<>> www. @162.140.15.100 +dnssec +bufsize=512 +ignore +qr +norec ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ; COOKIE: 4a67cc813cfe03eb ;; QUESTION SECTION: ;www.federalregister.gov. IN A ;; QUERY SIZE: 64 ;; Warning: Message parser reports malformed message packet. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 ;; flags: qr aa tc; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.federalregister.gov. IN A ;; ANSWER SECTION: . 32768 CLASS4096 OPT ;; Query time: 271 msec ;; SERVER: 162.140.15.100#53(162.140.15.100) (UDP) ;; WHEN: Wed Mar 15 16:30:22 AEDT 2023 ;; MSG SIZE rcvd: 52 -- 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: DNSSEC error resolving gpo.gov ?
> On 15 Mar 2023, at 16:49, Mark Andrews wrote: > > > >> On 15 Mar 2023, at 15:42, Tim Maestas wrote: >> >> Named should be sending queries with DO=1 and it should be getting back >> signed responses. I suspect that you will need to run packet captures of >> the traffic to and from 162.140.15.100 and 162.140.254.200 port 53 from the >> nameserver. Either signed responses will cease or DNSSEC requests will >> cease. In either case having the traffic around the transition should help >> to determine what is happening. >> >> I've found that, after a fresh restart of named, if I query for >> "federalregister.gov A" I get a good AD response, and then subsequent >> queries for "www.federalregister.gov" are successful as well. If however >> after a restart of named I begin with a query for www.federalregister.gov A >> then I get servfail, and subsequent queries for federealregister.gov >> servfail as well. Here is the tcpdump from the 2nd (failed) case of an >> initial query for www.federalregister.gov: >> >> >> reading from file dns.cap, link-type EN10MB (Ethernet), snapshot length >> 262144 >> 04:30:01.114458 IP (tos 0x0, ttl 64, id 35832, offset 0, flags [none], proto >> UDP (17), length 92) >>10.0.0.159.43263 > 162.140.254.200.53: [udp sum ok] 15013 [1au] A? >> www.federalregister.gov. ar: . OPT UDPsize=512 DO [COOKIE 352538a87bde87a5] >> (64) >> 04:30:01.204863 IP (tos 0x0, ttl 229, id 4936, offset 0, flags [DF], proto >> UDP (17), length 80) >>162.140.254.200.53 > 10.0.0.159.43263: [udp sum ok] 15013*-| q: A? >> www.federalregister.gov. 3/0/1 . OPT UDPsize=4096 DO [|domain] > > This is a malformed DNS response. It looks like the server tried to send a > truncated response with an OPT record but failed to correctly update the > answer count field to zero. > > % dig www.federalregister.gov @162.140.15.100 +dnssec +bufsize=512 +ignore > +qr +norec > > ; <<>> DiG 9.19.11-dev <<>> www. @162.140.15.100 +dnssec +bufsize=512 +ignore > +qr +norec > ;; global options: +cmd > ;; Sending: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 > ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ; COOKIE: 4a67cc813cfe03eb > ;; QUESTION SECTION: > ;www.federalregister.gov. IN A > > ;; QUERY SIZE: 64 > > ;; Warning: Message parser reports malformed message packet. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 > ;; flags: qr aa tc; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;www.federalregister.gov. IN A > > ;; ANSWER SECTION: > . 32768 CLASS4096 OPT > ;; Query time: 271 msec > ;; SERVER: 162.140.15.100#53(162.140.15.100) (UDP) > ;; WHEN: Wed Mar 15 16:30:22 AEDT 2023 > ;; MSG SIZE rcvd: 52 What I should have said about this is that this tells named that the server DOES NOT SUPPORT EDNS and hence DNSSEC as there is no OPT record in the ADDITIONAL section in a response where the port, query id and question match the request. Now I have reported this via the web site but whether they take it seriously or not only time will tell. It’s very hit and miss trying to report broken DNS servers. The automated response is below. Mark Your request (42885) has been received and is being reviewed by our support staff. Thank you for contacting the Office of the Federal Register (OFR). The OFR publishes on behalf of more than 300 Federal entities and can only accept documents from Federal agencies. We have no involvement with, or control over, their policies or programs. The OFR is responsible for the accuracy of the content of the Federal Register and CFR, which must reflect what the agency submitted for publication in the Federal Register. Federal regulations do not permit OFR staff to provide assistance for requests asking the OFR to: - evaluate or interpret material published in the Federal Register; - provide legal analysis of material published in the Federal Register; - explain or provide compliance guidance of material published in the Federal Register. In addition, we are not permitted to perform research or make detailed suggestions to locate material published on specific topics. We will not respond to those emails. If you have a question about our office or one of our publications, we will respond within 10 business days. Otherwise, use the information below to find an appropriate contact. 1. For problems with ecfr.gov: - use this help system - to correct a content error that was incorrect in the Federal Register rul
Re: RPZ answer me NXDOMAIN for some domain
'break-dnssec no' looks at the DO flag and whether the data to be returned is signed. If DO is 1 and the data is signed then the answer is not modified. If DO is 0 then it is modified as the client cannot be performing DNSSEC validation on the response and be expecting it to succeed for responses from signed zones. ‘break-dnssec yes’ ignores the DO flag and whether the data is signed. This is designed to allow forwarded requests to get DNSSEC protection as you can have the policy on multiple servers in the chain to server plain clients. > On 23 Mar 2023, at 00:28, Ondřej Surý wrote: > > >> On 22. 3. 2023, at 14:26, BONIN Nathanael wrote: >> >> If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted >> to !!! Thanks. > > +1 > >> But what I don’t understand is why, when I use directly SrvA (server that >> have RPZ zone), it works ? > > That's something that's impossible to answer without seeing the full > configuration (named-checkconf -px). > > 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 -- 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: bind with qname min. fails to continue recursing on one specific query
00 8000 000c 000a 0008 5971 94c0 Yq.. > 0050: 9932 9282.2.. > > 10:01:39.945218 172.16.20.30.58268 > 170.141.167.222.53: [bad udp cksum e2f9! > -> 7f9c] 15558% [1au] A? www.extglb.tn.gov. ar: . OPT UDPsize=512 DO(58) (ttl > 64, id 46842, len 86) > : 4500 0056 b6fa 4011 ca0d 6005 471e E..V@...`.G. > 0010: aa8d a7de e39c 0035 0042 f9e2 3cc6 0010 ...5.B..<... > 0020: 0001 0001 0377 0665 7874 .www.ext > 0030: 676c 6202 746e 0367 6f76 0100 0100 glb.tn.gov.. > 0040: 0029 0200 8000 000c 000a 0008 5971 .)Yq > 0050: 94c0 9932 9282 ...2.. > > 10:01:39.992119 170.141.167.222.53 > 172.16.20.30.58268: 15558- q: A? > www.extglb.tn.gov. 0/6/1 ns: extglb.tn.gov. [5m] NS ndcgtm01.tn.gov., > extglb.tn.gov.[|domain] (DF) (ttl 43, id 35970, len 448) > : 4500 01c0 8c82 4000 2b11 c81b aa8d a7de E.@.+... > 0010: 6005 471e 0035 e39c 01ac aa2f 3cc6 8010 `.G..5./<... > 0020: 0001 0006 0001 0377 0665 7874 .www.ext > 0030: 676c 6202 746e 0367 6f76 0100 01c0 glb.tn.gov.. > 0040: 1000 0200 0100 0001 2c00 1108 6e64 6367 ,...ndcg > 0050: 746d 3031 0274 6e03 676f 7600 c010 0002 tm01.tn.gov. > 0060: 0001 012c ., > > -- > 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 -- 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: DNSSEC error resolving gpo.gov ?
Please tell them to forward my dig output to the DNS vendor. The header content does NOT match the rest of the packet. Just because some resolvers “work” with malformed packets it doesn’t mean that the servers are not broken. The headers say that there are 3 records in the answer section and 1 in the additional section when there is only 1 record present. That is the definition of a malformed response. Mark > On 4 Apr 2023, at 12:41, Alexandra Yang wrote: > > Hi Mark, > > We just heard back from the gpo.gov nameserver, see below. Looks like they > think the cause of the problem is BIND not resend query using TCP which is > required since DNS Flag day 2020 ? Thanks again for your help! > > " > • We also analyzed DNSSEC for federalregister.gov against the following > major DNS Servers and they have come back as fully validated. > • Google (8.8.8.8) > • Cloudflare (1.1.1.1) > • OpenDNS (208.67.220.220) > • During our extensive testing, we were able to reproduce the issue and > found out that DNS requests could fail if remote DNS Servers ( forwarders ) > are not compliant with the requirements for the DNS environments since DNS > Flag Day 2020 ( https://www.dnsflagday.net/2020/ ) > • Most importantly: Resolvers MUST resend queries over TCP if they > receive a truncated UDP response (with TC=1 set)! > Our recommendation is please review the requirements for the DNS > environments since DNS Flag Day 2020 ( https://www.dnsflagday.net/2020/ ) and > make sure the local forwarders are compliant. > " > > > On Wed, Mar 15, 2023 at 6:01 PM Mark Andrews wrote: > > > > On 15 Mar 2023, at 16:49, Mark Andrews wrote: > > > > > > > >> On 15 Mar 2023, at 15:42, Tim Maestas wrote: > >> > >> Named should be sending queries with DO=1 and it should be getting back > >> signed responses. I suspect that you will need to run packet captures of > >> the traffic to and from 162.140.15.100 and 162.140.254.200 port 53 from > >> the nameserver. Either signed responses will cease or DNSSEC requests > >> will cease. In either case having the traffic around the transition > >> should help to determine what is happening. > >> > >> I've found that, after a fresh restart of named, if I query for > >> "federalregister.gov A" I get a good AD response, and then subsequent > >> queries for "www.federalregister.gov" are successful as well. If however > >> after a restart of named I begin with a query for www.federalregister.gov > >> A then I get servfail, and subsequent queries for federealregister.gov > >> servfail as well. Here is the tcpdump from the 2nd (failed) case of an > >> initial query for www.federalregister.gov: > >> > >> > >> reading from file dns.cap, link-type EN10MB (Ethernet), snapshot length > >> 262144 > >> 04:30:01.114458 IP (tos 0x0, ttl 64, id 35832, offset 0, flags [none], > >> proto UDP (17), length 92) > >>10.0.0.159.43263 > 162.140.254.200.53: [udp sum ok] 15013 [1au] A? > >> www.federalregister.gov. ar: . OPT UDPsize=512 DO [COOKIE > >> 352538a87bde87a5] (64) > >> 04:30:01.204863 IP (tos 0x0, ttl 229, id 4936, offset 0, flags [DF], proto > >> UDP (17), length 80) > >>162.140.254.200.53 > 10.0.0.159.43263: [udp sum ok] 15013*-| q: A? > >> www.federalregister.gov. 3/0/1 . OPT UDPsize=4096 DO [|domain] > > > > This is a malformed DNS response. It looks like the server tried to send a > > truncated response with an OPT record but failed to correctly update the > > answer count field to zero. > > > > % dig www.federalregister.gov @162.140.15.100 +dnssec +bufsize=512 +ignore > > +qr +norec > > > > ; <<>> DiG 9.19.11-dev <<>> www. @162.140.15.100 +dnssec +bufsize=512 > > +ignore +qr +norec > > ;; global options: +cmd > > ;; Sending: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 > > ;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 512 > > ; COOKIE: 4a67cc813cfe03eb > > ;; QUESTION SECTION: > > ;www.federalregister.gov. IN A > > > > ;; QUERY SIZE: 64 > > > > ;; Warning: Message parser reports malformed message packet. > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57919 > > ;; flags: qr aa tc; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; QUE
Re: DNSSEC error resolving gpo.gov ?
Also it does no harm. SHA1 DS are still secure. If there are both SHA1 and SHA256 DS records present the SHA1 records are ignored by SHA256 capable validators and no you can’t just remove the SHA256 DS record and have the DS RRset validate. > On 4 Apr 2023, at 20:27, Petr Menšík wrote: > > No, unfortunately there is no way to disable it. It just creates both digests > and there is no way to disable creation of SHA-1 in bind 9.11. > dnssec-dsfromkey -2 can be used to output only SHA256 digest. > > I think automated process using dsset files does not offer switches to not > generate them. With manual signing process it should be possible to delete > SHA1 digest from dsset file before signing it with dnssec-signzone. I doubt > it would work smoothly with inline signing directly from named. At least not > in our RHEL8 version. > > Petr > > On 24. 03. 23 14:35, John W. Blue via bind-users wrote: >> Petr, >> >> Thanks for sharing that tidbit of info. Off the top of your head do you >> know if that can be disabled? >> >> John >> >> -Original Message- >> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Petr >> Menšík >> Sent: Friday, March 24, 2023 8:32 AM >> To: bind-users@lists.isc.org >> Subject: Re: DNSSEC error resolving gpo.gov ? >> >> That is done also by bind 9.11, not only infoblox. It creates both digests >> on common operations. >> >> On 3/14/23 16:23, John W. Blue via bind-users wrote: >>> Keep in mind that SHA1 may not have been included by choice. >>> >>> If gpo.gov is using Infoblox there is a, what I like to call, Infoblox-ism >>> in play regarding DNSSEC where even if you choose RSA256 or RSA512 or >>> whatever it will create a SHA1. >>> >>> John >>> >>> -Original Message- >>> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf >>> Of Stephane Bortzmeyer >>> Sent: Tuesday, March 14, 2023 10:17 AM >>> To: Alexandra Yang >>> Cc: bind-users@lists.isc.org >>> Subject: Re: DNSSEC error resolving gpo.gov ? >>> >>> On Tue, Mar 14, 2023 at 11:08:28AM -0400, Alexandra Yang >>> wrote a message of 154 lines which said: >>> >>>> I wonder if anyone can shed some light on this, our nameserver(BIND >>>> 9.16.37 )keeps giving error on resolving gpo.gov and ns3.gpo.gov, >>>> here are the >>>> errors: >>> "DS record for zone gpo.gov with keytag 18496 was created by digest >>> algorithm 1 (SHA-1) which is deprecated." >>> https://zonemaster.fr/en/result/9161c8485223705c >>> >>> -- >>> 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 >> -- >> Petr Menšík >> Software Engineer, RHEL >> Red Hat, https://www.redhat.com/ >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >> >> -- >> 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 > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, http://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > -- > 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: Does DNSSEC increased packet size reach end computers?
There are some applications that will do DNSSEC. You should assume that any application may ask for DNSSEC records and that is normal. DNSSEC was designed from the very beginning to be validated in the application and only works fully when that is done. The recursive server still needs to validate the responses to prevent the cache being poisoned by spoofed responses. The clients will switch between UDP and TCP to get the responses they need. The AD bit is only to be trusted if there is channel security and you trust the recursive server. Mark > On 12 Apr 2023, at 05:11, Bob Harold wrote: > > I was in the process of setting up a test server with DNSSEC signed domains, > and asking users to point at the test server to see if the larger packets > affected their application, when I realized I might be wrong. > DNS Resolvers will get bigger responses from DNS Authoritative servers > because of DNSSEC signatures. But clients, running stub resolvers, will > likely set the +AD flag and expect the DNS Resolver to validate, but the > client will get a response that does not include any DNSSEC records. Is that > correct? > > So I only need to worry about increased packet sizes between DNS Resolvers > and DNS Authoritative servers? > > (Granted, the actual answer size to the client could be large enough to cause > fall-back to TCP, but that is not because of DNSSEC.) > > -- > Bob Harold > -- > 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: Delegation NS-records when zones share an authority server
> On 13 Apr 2023, at 03:19, Fred Morris wrote: > > TLDR: NS records occur above and below zone cuts. > > On Wed, 12 Apr 2023, John Thurston wrote: >> >> We have authority over state.ak.us, which we publish as a public zone. We >> also publish challenge.state.ak.us as a public zone. >> >> The public NS records for state.ak.us are: ns4.state.ak.us and >> ns3.state.ak.us The NS records for challenge.state.ak.us are the same. >> >> I recently noticed there were no NS records _in the state.ak.us zone_ for >> challenge.state.ak.us. > > So nothing above the zone cut == there is no zone cut. (IMO) > >> This had me scratching my head . . "how can this be working?", until I >> remembered the same instances of BIND were serving out both zones. There >> _were_ NS records in the challenge.state.ak.us zone, BIND had them, was >> authoritative, so would answer with them; BIND didn't need to look in the >> state.ak.us zone to find them. > > Yup. > >> Some experimentation shows that even if I insert NS records into state.ak.us >> (for challenge.state.ak.us), BIND does not add them to its answer when asked >> "dig NS challenge.state.ak.us". I interpret this to mean that while this >> instance of BIND is authoritative for both zones, it answers with >> information from the most specific zone it has, and ignores values in the >> delegating zone. And that makes sense to me. > > Yup. > >> Now the question is, should I insert NS records into state.ak.us (for >> challenge.state.ak.us) anyway? >> [...] >> >> Unknown: >> >> * Does the answer change if we want to start signing either zone? > > I suspect you don't need the NS records in challenge.state.ak.us and if you > remove them then the records in challenge.state.ak.us are simply part of the > state.ak.us zone since they're served off of the same server. Glue records > (above the cut) are essentially the same NS record(s) published on > nameservers above the zone cut as within the zone on the nameservers for the > zone proper (below the cut). > > On the other hand maybe whatever software you're using to manage / serve DNS > does something with those records (or requires them since / if the two > namespaces are loaded as separate zones). > > In terms of NXDOMAIN and SOA queries, both state.ak.us and > challenge.state.ak.us seem to do the right thing in terms of pretending to be > separate zones, e.g. in the first case returning the correct domain in the > AUTHORITY and in the second case returning the relevant SOA records directly > in the ANSWER. You need NS records in the parent domain to give correct answers to DS queries (DATA or NODATA NOERROR vs NXDOMAIN) and to generate valid NSEC and NSEC3 chains. Additionally if the parent zone is ever transferred to server without the child zone clients will see a Schrödinger zone. Always add delegating NS RRset and keep it consistent with the child zone. > -- > > Fred Morris, internet plumber > > > -- > 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: Delegation NS-records when zones share an authority server
> On 13 Apr 2023, at 06:44, Mark Andrews wrote: > > > >> On 13 Apr 2023, at 03:19, Fred Morris wrote: >> >> TLDR: NS records occur above and below zone cuts. >> >> On Wed, 12 Apr 2023, John Thurston wrote: >>> >>> We have authority over state.ak.us, which we publish as a public zone. We >>> also publish challenge.state.ak.us as a public zone. >>> >>> The public NS records for state.ak.us are: ns4.state.ak.us and >>> ns3.state.ak.us The NS records for challenge.state.ak.us are the same. >>> >>> I recently noticed there were no NS records _in the state.ak.us zone_ for >>> challenge.state.ak.us. >> >> So nothing above the zone cut == there is no zone cut. (IMO) >> >>> This had me scratching my head . . "how can this be working?", until I >>> remembered the same instances of BIND were serving out both zones. There >>> _were_ NS records in the challenge.state.ak.us zone, BIND had them, was >>> authoritative, so would answer with them; BIND didn't need to look in the >>> state.ak.us zone to find them. >> >> Yup. >> >>> Some experimentation shows that even if I insert NS records into >>> state.ak.us (for challenge.state.ak.us), BIND does not add them to its >>> answer when asked "dig NS challenge.state.ak.us". I interpret this to mean >>> that while this instance of BIND is authoritative for both zones, it >>> answers with information from the most specific zone it has, and ignores >>> values in the delegating zone. And that makes sense to me. >> >> Yup. >> >>> Now the question is, should I insert NS records into state.ak.us (for >>> challenge.state.ak.us) anyway? >>> [...] >>> >>> Unknown: >>> >>> * Does the answer change if we want to start signing either zone? >> >> I suspect you don't need the NS records in challenge.state.ak.us and if you >> remove them then the records in challenge.state.ak.us are simply part of the >> state.ak.us zone since they're served off of the same server. Glue records >> (above the cut) are essentially the same NS record(s) published on >> nameservers above the zone cut as within the zone on the nameservers for the >> zone proper (below the cut). >> >> On the other hand maybe whatever software you're using to manage / serve DNS >> does something with those records (or requires them since / if the two >> namespaces are loaded as separate zones). >> >> In terms of NXDOMAIN and SOA queries, both state.ak.us and >> challenge.state.ak.us seem to do the right thing in terms of pretending to >> be separate zones, e.g. in the first case returning the correct domain in >> the AUTHORITY and in the second case returning the relevant SOA records >> directly in the ANSWER. > > You need NS records in the parent domain to give correct answers to DS > queries (DATA or NODATA NOERROR vs NXDOMAIN) and to generate valid NSEC and > NSEC3 chains. Additionally if the parent zone is ever transferred to server > without the child zone clients will see a Schrödinger zone. Always add > delegating NS RRset and keep it consistent with the child zone. To demonstrate what I mean about DS. While named has code to handle this inconsistency other recursive servers may not as it is NOT a RFC requirement. % dig ds challenge.state.ak.us ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> ds challenge.state.ak.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 13281432cf7c77c8010064371a0bdc1c24b7a7f4aaf4 (good) ;; QUESTION SECTION: ;challenge.state.ak.us. IN DS ;; AUTHORITY SECTION: state.ak.us. 3600 IN SOA ns3.state.ak.us. hostmaster.state.ak.us. 1681251385 3600 900 7776000 3600 ;; Query time: 1484 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Apr 13 06:52:27 AEST 2023 ;; MSG SIZE rcvd: 129 % dig soa challenge.state.ak.us ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> soa challenge.state.ak.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9228 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5babd4f25d912557010064371a19b455b75c97d45a2c (good) ;; QUESTION SECTION: ;challenge.state.ak.us. IN SOA ;; ANSWER SECTION: challenge.state.ak.us. 21600 IN SOA ns3.state.a
Re: Reverse Policy Zone to make MS Azure stuff work?
Create a catalog zone and use that to distribute the zone configuration to all your recursive servers. As for using a zone that is not delegated to you. Microsoft own appserviceenvironment.net and are telling you to use it this way. This is no different to the IETF saying you can have your own 10.in-addra.arpa for RFC 1918 addresses. Mark > On 14 Apr 2023, at 08:28, John Thurston wrote: > > Due to a requirement to use something Microsoft crafted, we are being asked > to assert (internally) authority over 3rd-level names under ç > I've pushed back on this, because I don't think it's nice to publish > "authoritative" answers in domains we have not been delegated. But I'm told > it's all ok, because Microsoft says its ok* Having accepted that the ship has > sailed, it's now a question of how to deliver such answers. > One obvious way is to define a zone for each 3rd level under > appserviceenvironment.net, and publish them in a way our resolvers can find > them. In the absence of catalog-zones, this could be a lot of additional work > (for me). > Then I wondered if adding these 'hijacked' names to our RPZ would meet the > need. I first thought, "Yeah. It'll work.", but then I re-read the statement > from MS saying each 3rd level was going to need to have a 4th level zone > defined. A zone definition requires at least an SOA and NS record . . and > last time I checked, an RPZ would not deliver an NS record. So it seems that > idea may be squashed. > Who else has need to publish locally-defined appserviceenvironment.net names? > Were you able to do it with your RPZ? > * > https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase > > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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: dnssec-validation?
; trust anchor, which is built in to BIND and doesn't need to be > configured by hand). > > The default is "auto". When it's set to that, your server will query the > root name servers in order to confirm that the automatically-configured > trust anchor is correct. You said it was "trying to" reach the root, which > suggests it wasn't succeeding? If so, that would explain why everything > that wasn't locally authoritative would return SERVFAIL. > > Note that this is related to *recursive* queries, that is, queries for zones > that are not served by your secondary server. It should have nothing to do > with whether your own domain is signed, or whether there's a DS record for > it in the parent zone. My guess is, you had the authoritative configuration > working fine (otherwise presumably dnssec-analyzer would've complained), but > recursive isn't working. > > Unfortunately, since you haven't provided any configuration info or even the > name of the domain you were trying to set up, I can't make any more educated > guesses than that. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > -- > 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: Best practice MultiView
You use keys as well when sending notify to select which view processes the
notify
> On 17 Apr 2023, at 18:44, Jiaming Zhang wrote:
>
> Dear community,
>
> I was wondering if notifying and updating zones in different view (say
> "internal" and "external") between bind servers via different key is a good
> practice. I got a sample zone/config like below:
> ```
> view "internal" { zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key key1; };
> notify yes;
> };
> # some more zone
> }
> view "external" {
> zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key key2; };
> notify yes;
> };
> }
> ```
> where both zones have the same name server (e.g. `ns1.example.com` and
> `ns2.example.com`). What I'm trying to archive is that and update on zones in
> "internal" view does not contaminate zones in "external" view, or vice versa.
> I was wondering if using different key to limit update is a good practice,
> since I'm expecting "external" view on slave server will also receive notify
> upon update on "internal" zone at master, but just unable to query update due
> to incorrect key.
>
> Kind Regards,
> Jiaming Zhang
>
> Yixi Meta
> Tel: +31 (6) 12 98 08 07
> Email: j.zh...@yiximeta.com
> Website: yiximeta.com
>
> De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde.
> Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u
> deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
> afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze
> e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
> bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
>
> The content of this message is intended solely for the addressee. No rights
> can be derived from this message or its attachments. If you are not the
> intended recipient, we kindly request you to delete the message and inform
> the sender. It is strictly prohibited to disclose, copy or distribute this
> email or the information inside it, without a written consent from the
> sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade
> register with number 85744115.
> --
> 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: help with notify
The additional problem is that you also choose to hide the domain and the IP addresses which doesn’t help others test stuff for you. Why do you think named asked for the addresses of the servers? What does named have and what does it need to send out notify messages? Is the server properly configured so it can get what it needs? Can it talk to all the servers it needs too? Is everything properly delegated? Are firewalls stopping it getting what it needs. The address queries are just the first step in sending NOTIFY messages. The NOTIFY process starts with names but these need to be turned into addresses. Named includes a full iterative resolver. It uses that to get what it needs. This should be enough for you to solve what is going wrong. -- Mark Andrews > On 18 Apr 2023, at 03:31, Matt Zagrabelny via bind-users > wrote: > > > Hello Ondřej, > >> On Mon, Apr 17, 2023 at 9:26 AM Ondřej Surý wrote: >> >> > On 17. 4. 2023, at 15:59, Matt Zagrabelny via bind-users >> > wrote: >> > >> > Greetings bind-users, >> > >> > I'm running a little older Debian bind: >> > >> > bind9 1:9.9.5.dfsg-9 >> >> A little older? > > Sure. I was trying to offer full disclosure while not bringing a lot of > attention to how behind I am at work. > > >> Debian Jessie reached EOL in June 2018, Debian Jessie LTS reached EOL in >> June 2020 > > ELTS is still going. I just enabled that repo. Thanks for the encouragement. > >> So, you are running software that hasn't received any update in 3-5 years. >> >> Upgrade to current Debian stable, it has a fully-maintained up-to-date BIND >> 9.16 version >> in security (1:9.16.37-1~deb11u1) and almost up-to-date BIND 9.18 in >> backports (the update >> is currently blocked by the Debian being frozen for the next stable release). > > I've been a happy Debian user since 3.0 Woody. Thanks for your contributions > to it. I very much appreciate your time and effort. > > Not sure if anyone is willing to look at my questions until I upgrade to a > more recent BIND release. If so, I'd be grateful. > > Thanks, > > -m > -- > 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: one authoritative name server and each domain requires ns1.thisdomain.com
Please name the TLDs that have this stupid policy. The whole point of having NS records that are names rather than addresses in to allow one to change the address of a name server by updating a single record and perhaps a couple of glue records in the parent domains of that name. Requiring that all zones have servers that live within the zone defeats that. I suspect you have misunderstood something. Forcing people to update millions of records to change an address is nonsensical. -- Mark Andrews > On 5 May 2023, at 07:06, Jim Peters wrote: > > > I am looking for a way to run the existing name servers I use as the > authoritative name server for all the zones I am authoritative for that I > currently have a problem with. > > For most domains that I have, it is sufficient to list ns1.example.net and > ns2.example.net in each zone and publish those names with the registrars as > the host record. > > For a few top-level domains that I deal with, the requirements of the TLD > require that the name of the name server be a subdomain name of the zone. > What I mean is that for the zone anotherdomain.TLD, I have to create NS > records called DNS1.anotherdomain.TLD and DNS2.anotherdomain.TLD. Then I end > up their A and records for ns1.anotherdomain.TLD and > ns2.anotherdomain.TLD. > > All of my zones currently live in a view named external. > > I'm not having any operational issues with BIND/named. The problem is with > the management software.When it finds the new name server names, it > consumes all zones on these servers again as if NS1.anotherdomain.TLD and > NS2.anotherdomain.TLD are their servers.Other than anotherdomain.TLD, > none of them are. > > Is there some approach in BIND / named.conf I can get to so that > "ns1.anotherdomain.TLD and ns2.anotherdomain.TLD" are only seen as the name > servers for zones in TLD? > > Maybe a view for zones in TLD ... or possibly a separate view for each zone > from TLD that needs this treatment of name servers? > > Thanks, > > Jim Peters > jpet...@dovetailinternet.com > -- > 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: Problem with subdomain delegation - NS RR ignored?
Don’t use host for diagnostics. It really is the wrong tool. If you want to
see the
delegation make non-recursive queries.
dig a ns1.fish.hub @localhost +norec
dig ns fish.hub @localhost +norec
When you make recursive queries, named follows the records in the zone and
returns the
answers from the referenced servers. Compare the above with the recursive
queries below.
dig a ns1.fish.hub @localhost
dig ns fish.hub @localhost
Mark
> On 10 May 2023, at 14:07, bindu...@thegeezer.net wrote:
>
> Howdy
>
> I'm struggling with subdomain creation, for some reason the delegation glue
> records are being ignored - and i was wondering if someone could help me
> identify what I've done wrong please. I know i need to setup another server
> for the subdomain, but I've been trying to get this going at work and getting
> the same issue, so thought to try on my test bed. Can't even get the NS
> record returned for the subdomain
>
> Given the domain ".hub" I can verify the domain level NS
> # host -t NS hub localhost
> > hub name server localhost.
>
> I can create an A record for "salmon.hub." and this resolves as expected:
> # host -t a salmon.hub localhost
> > salmon.hub has address 8.8.8.8
>
> I want to delegate to a different domain server the subdomain "fish.hub" and
> have created glue records as below in the config snippet, but get NXDOMAIN
> for both the A record and the NS record
> # host -t a ns1.fish.hub localhost
> > Host ns1.fish.hub not found: 3(NXDOMAIN)
>
> # host -t NS fish.hub localhost
> > Host fish.hub not found: 3(NXDOMAIN)
>
> Any suggestions gratefully received. Pertinent parts of named.conf and zone
> file are shown below, if you need more info please don't hesitate to ask
>
> thanks in advance!
>
> TG
>
> /etc/bind/named.conf
> acl "trusted" {
> 10.0.0.0/8;
> 192.168.0.0/16;
> 127.0.0.0/8;
> ::1/128;
> };
> allow-recursion {
> trusted;
>};
> forwarders {
> 208.67.220.220;
> 208.67.222.222;
> };
> zone "hub" IN {
>type master;
>file "pri/hub.zone";
>notify no;
> };
>
> /etc/bind/pri/hub.zone
> $TTL 1W
> @ IN SOA hub. root.hub. (
> 2008122601 ; Serial
> 28800 ; Refresh
> 14400 ; Retry
> 604800 ; Expire - 1 week
> 86400 ); Minimum
> @ IN NS localhost.
> @ IN A 127.0.0.1
>
> @ IN ::1
>
> salmon.hub. IN A 8.8.8.8
> fish.hub. IN NS ns1.fish.hub.
> ns1.fish.hub. IN A 4.4.4.4
>
>
>
> --
> 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: migration to new isp - now private addresses showing up publicly?
Use different TSIG keys rather than IP address to select which view matches for
notify and zone transfers.
acl all-keys {key internal; key external;};
match-clients {key internal; !all-keys; …};
The !all-keys is to prevent matching by IP for the listed keys.
Do similar for all views.
Then add keys to primary definitions and server clauses with keys at the view
level for notify.
I’m pretty sure there is a knowledge base article with full details.
--
Mark Andrews
> On 24 May 2023, at 05:40, Kaya Saman wrote:
>
>
>
>
>> On 5/23/23 20:18, Sten Carlsen wrote:
>>
>>
>>> On 23 May 2023, at 19.46, Kaya Saman wrote:
>>>
>>>
>>>
>>> On 5/23/23 18:07, Sten Carlsen wrote:
>>>>>> On 23 May 2023, at 19.00, Kaya Saman wrote:
>>>>>>
>>>>>>
>>>>>>> On 5/23/23 12:47, Matus UHLAR - fantomas wrote:
>>>>>>>> On 23.05.23 12:22, Kaya Saman wrote:
>>>>>>>> I've got a very strange problem that has emerged somehow after
>>>>>>>> migrating my isp.
>>>>>>>>
>>>>>>>>
>>>>>>>> My setup previously used 2x servers in master/slave configuration for
>>>>>>>> my public "view" and then had 3x servers for the "internal" view. This
>>>>>>>> was working fine for years and I have been regularly testing using
>>>>>>>> online dns healthcheck sites such as mxtoolbox etc...
>>>>>>>>
>>>>>>>>
>>>>>>>> Now when I try to run any type of check from mxtoolbox or other site
>>>>>>>> eg. https://dnschecker.org/ I am getting my private IP's showing
>>>>>>>> instead of the public ones?
>>>>>>>>
>>>>>>>>
>>>>>>>> Initially it started off by my external zone files not transferring
>>>>>>>> which I managed to see that the information was trying to traverse my
>>>>>>>> NAT (I know, not the best practice to have all dns servers on the same
>>>>>>>> network).
>>>>>>>>
>>>>>>>>
>>>>>>>> As a result external emails from my mail server are not working too
>>>>>>>> well with a hit and miss type thing going on right now.
>>>>>>>>
>>>>>>>>
>>>>>>>> Just to go over, my zone files are fine as the 'external' ones only
>>>>>>>> have public ip addresses in them and do not include any type of
>>>>>>>> internal addressing whatsoever.
>>>>>>>>
>>>>>>>>
>>>>>>>> Here's an example of the config in named.conf for the master:
>>>>>>> view "external" {
>>>>>>> match-clients { !internals; any; };
>>>>>> [...]
>>>>>>> view "external" {
>>>>>>> match-clients { !internals; any; };
>>>>>> I don't see your definition of "internals".
>>>>>> Also, I don't see your definition of internal view.
>>>>>> if internal IP addresses are visible on the internet, obviously the
>>>>>> internet sources fall into your internal view, not into this one.
>>>>>>
>>>>>>
>>>>> Finally, I understand what is going on and things get stranger
>>>>>
>>>>>
>>>>> The internal IP addressing is being served up by the slave servers. They
>>>>> seem to have pulled the file domain.db and renamed it to
>>>>> domain-external.db???
>>>>>
>>>>>
>>>>> Of course the 'master' machine is already serving up domain-external.db
>>>>> to the public domain. This has the correct IP addressing with everything
>>>>> else such as dkim and dmarc.
>>>>>
>>>>>
>>>>> So, currently I think the whole problem is stemming from the fact that
>>>>> the zone transfers are not working correctly for my external view between
>>>>> 'master' and 'slave' servers.
>>>>>
>>>>>
>>>>> How can I do that without needing to traverse my NAT?
>>>>>
>>>
Re: migration to new isp - now private addresses showing up publicly?
Follow example 4 on <https://kb.isc.org/docs/aa-0085>. You haven’t got named to
read the keys into named.conf nor told named to use the keys for notify and zone
transfers. Also just use TSIG in your allow-transfer acls.
include “external.key”;
include “internal.key”;
masters { 10.0.0.1 key external; };
masters { 10.0.0.1 key internal; };
also-notify { 10.0.0.2 key external; };
also-notify { 10.0.0.2 key internal; };
allow-transfer { key external; };
allow-transfer { key internal; };
Mark
> On 24 May 2023, at 08:13, Kaya Saman wrote:
>
> Not sure if I did something wrong? Unfortunately the same thing has happened,
> the internal zone file got transferred as the external zone file?
>
> I followed your suggestion and this article here:
> https://bind9.readthedocs.io/en/v9_18_4/chapter6.html
> which I think you mentioned at the bottom?
>
> I created keys called internal. and external. from the example in the docs:
> $ tsig-keygen host1-host2. > host1-host2.key
>
> they got stored in files called external.key and internal.key within the
> namedb directory
>
> So my named.conf file now contains:
>
> acl internals {
> 127.0.0.0/8;
> 192.168.0.0/16;
> 172.16.0.0/12;
> 10.0.0.0/8;
> };
>
> acl all-keys {key internal.; key external.;};
>
> I then referenced the keys like so on the master for both internal and
> external views (I'm only showing external in this example):
>
> view "external" {
> match-clients { key external.; !all-keys; !internals; any; };
> allow-recursion {
> 127.0.0.1;
> };
>
>
> zone "domain.com" {
> type master;
> file "/var/named/var/named/domain-external.db";
> notify explicit;
> also-notify { int_dns2; int_dns3; };
> allow-transfer { int_dns2; int_dns3; };
> allow-query { ext_dns2; ext_dns3; !internals; any; };
> allow-update { key external. ;};
> };
> };
>
> and on the slave:
>
> view "external" {
> match-clients { key external.; !all-keys; !internals; any; };
> allow-recursion {
> 127.0.0.1;
> };
>
>
> zone "domain.com" {
>type slave;
>file "/var/named/var/named/domain-external.db";
> masters { int_dns1; };
> // allow-notify { ext_dns1; };
>allow-query { int_dns1; !internals; any; };
> };
> };
>
> I'm sure there are extra steps needed which I have omitted somewhere??
>
> On 5/23/23 22:03, Mark Andrews wrote:
>> Use different TSIG keys rather than IP address to select which view matches
>> for notify and zone transfers.
>>
>> acl all-keys {key internal; key external;};
>>
>> match-clients {key internal; !all-keys; …};
>>
>> The !all-keys is to prevent matching by IP for the listed keys.
>>
>> Do similar for all views.
>>
>> Then add keys to primary definitions and server clauses with keys at the
>> view level for notify.
>>
>> I’m pretty sure there is a knowledge base article with full details.
>>
>> --
>> Mark Andrews
>>
>>> On 24 May 2023, at 05:40, Kaya Saman wrote:
>>>
>>>
>>> On 5/23/23 20:18, Sten Carlsen wrote:
>>>>
>>>>
>>>>> On 23 May 2023, at 19.46, Kaya Saman wrote:
>>>>>
>>>>>
>>>>> On 5/23/23 18:07, Sten Carlsen wrote:
>>>>>>> On 23 May 2023, at 19.00, Kaya Saman wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 5/23/23 12:47, Matus UHLAR - fantomas wrote:
>>>>>>>>
>>>>>>>>> On 23.05.23 12:22, Kaya Saman wrote:
>>>>>>>>> I've got a very strange problem that has emerged somehow after
>>>>>>>>> migrating my isp.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My setup previously used 2x servers in master/slave configuration for
>>>>>>>>> my public "view" and then had 3x servers for the "internal" view.
>>>>>>>>> This was working fine for years and I have been regularly testing
>>>>>>>>> using online dns healthcheck sites such as mxtoolbox etc...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now when I try to run any type of check from mxtoolbox or other site
>>>&g
Re: Can update-policy accept IP addresses ?
> On 24 May 2023, at 13:59, Patrick Rynhart wrote:
>
> Currently we have (for our Master zone) a list of IPs that can update
> our DNS master using the allow-update statement:
>
> zone "redacted.ac.nz" {
> type master;
> allow-update {
> ::1;
> 127.0.0.1;
> 131.123.103.2;
> 131.123.88.3;
> ...
> }
>
> We are wanting to transition to the more modern update-policy
> statement (because we want to make use of keys), but as a transition
> step we would like our existing whitelisted IPs to be included. We
> have tried the following:
>
> zone "redacted.ac.nz" {
> type master;
> update-policy {
> grant ::1 zonesub ANY;
> grant 127.0.0.1 zonesub ANY;
> grant 131.123.103.2 zonesub ANY;
> grant 131.123.88.3 zonesub ANY;
> ...
> }
> }
>
> But all operations from the whitelisted IPs result in the following:
>
> update 'assey.ac.nz/IN' denied
>
> If we roll back to the "allow-update" statement block, everything
> starts working again.
>
> Could someone please advise whether update-policy allows IPs (there
> are some sources on the net that suggest it should be able to accept
> IPs and/or FQDN addresses - for example
> http://pig.made-it.com/ddns.html) ?
No. They are not accepted. tcp-self and 6to4-self are the closest to
using IP addresses and allow for updating of only individual reverse names
with requests sent over TCP. They are intend to allow hosts to add PTR
records for themselves without having to establish a prior trust relationship.
Just add keys to the allow-update acl as you transition services over then
once everything is working using TSIG or SIG(0) move to update-policy. Unless
you need the finer grain controls allow-update is equally as secure as
update-policy.
allow-update {
key key1;
key key2;
127.0.0.2;
…
};
> If the statement does allow it, how can we go about troubleshooting ?
> We have already tried starting named in the foreground with -d 10, but
> don't get anything useful (just update 'assey.ac.nz/IN' denied)
>
> With Thanks in Advance
>
> Patrick
> --
> 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: Blocked by spamassassin?
Spamassassin looks for domain names of sites that are known to be dangerous in the body of the email. Many of those sites are known be served from non RFC compliant servers or have broken delegation both of which can cause log messages. Those log messages containing those domain names that cause the email to be rejected. > On 1 Jun 2023, at 11:11, Alex wrote: > > Hi, > I tried to submit a message earlier today about some error messages I was > receiving related to query errors and it was immediately rejected, apparently > by spamassassin, but did not provide any further info. > > There was clearly nothing in my message that was spam. Do you have any > suggestions on how I should proceed? > > Thanks, > Alex > > -- > 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
Yep, some people just don’t take care with delegations. Complain to Huawei. Complain to the other companies you list in your followup email. All it takes to fix this is to change the name of the zone on the child servers (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com” to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone if they are fully qualified. If there are other delegations from huawei.com for other sub zones to these servers they will also need to be instantiated. It’s maybe 10 minute work for each subdomain to fix. It just requires someone to do the work. This is a very old (last millennia) mis configuration method used by people who want to avoid doing delegations. Domain name speculators used to do this using “com” or even “.” as the zone name and wildcard A records to provide A answers for the zones delegated to the server. It “works” if all you return is positive answers but that hasn’t been true since IPv6 came into existence. e.g. "*. A ” When people come to you and say that it works with Google, et al. point them at https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say “Here is a DNS configuration testing site and it reports the zone as broken, you need to take it up with the company." Mark > On 2 Jun 2023, at 00:58, Jesus Cea wrote: > > I am getting errors "Name huawei.com (SOA) not subdomain of zone > cloud.huawei.com". The problem raises when requesting on > oauth-login.cloud.huawei.com . The problem was described in the mailing list: > > https://lists.isc.org/pipermail/bind-users/2021-January/104064.html > > BIND is replying with a SERVFAIL. This is correct and appropriate. > Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) other > are not doing that SOA verification, so for users we are the guilty, not > Huawey, because "using Google it works!". In fact, we have a big customer > phone app failing because of this (yes, this seems to be a bug with that app > but, again, "with google it works!"). > > What can we do? Is possible to disable that check in bind? > > We are using 9.16. We could upgrade to 9.18, if needed. > > Thanks. > > -- > Jesús Cea Avión _/_/ _/_/_/_/_/_/ > j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/ > Twitter: @jcea_/_/_/_/ _/_/_/_/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -- > 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: Understanding query failed errors
205.251.194.123 ns3.acoustic-adm.com. 60 IN 2600:9000:5302:7b00::1 ns4.acoustic-adm.com. 60 IN A 205.251.192.237 ns4.acoustic-adm.com. 60 IN 2600:9000:5300:ed00::1 ;; Query time: 246 msec ;; SERVER: 2600:9000:5306:4e00::1#53(ns2.acoustic-adm.com) (UDP) ;; WHEN: Sat Jun 03 09:48:05 AEST 2023 ;; MSG SIZE rcvd: 461 > 31-May-2023 17:12:22.921 query-errors: client @0x7f53d91aeb68 > 68.195.111.45#54508 (mail8140.bwnews.bestwestern.com): query failed > (SERVFAIL) for mail8140.bwnews.bestwestern.com/IN/TXT at > ../../../lib/ns/query.c:7060 > 31-May-2023 17:12:22.928 query-errors: client @0x7f53da5deb68 > 68.195.111.45#53653 (bounce.bwnews.bestwestern.com): query failed (SERVFAIL) > for bounce.bwnews.bestwestern.com/IN/TXT at ../../../lib/ns/query.c:7060 > > Is Best Western actually having such DNS problems? Even just a simple "host" > command shows something is wrong: > > $ host mail8140.bwnews.bestwestern.com > mail8140.bwnews.bestwestern.com has address 129.41.76.129 > Host mail8140.bwnews.bestwestern.com not found: 2(SERVFAIL) > mail8140.bwnews.bestwestern.com mail is handled by 5 > mail8140.bwnews.bestwestern.com. Yes. They need to get someone that can configure a server with the correct name for the zone being delegated to it. This is simply a matter of putting the correct name into the configuration. If you are delegating “bwnews.bestwestern.com” then you add a zone called “bwnews.bestwestern.com”. Simple. > On another server, I'm receiving a bit more information: > 31-May-2023 17:13:28.845 lame-servers: FORMERR resolving > 'mail8140.bwnews.bestwestern.com//IN': 205.251.194.123#53 > 31-May-2023 17:13:28.845 query-errors: client @0x7f655c820168 127.0.0.1#50563 > (mail8140.bwnews.bestwestern.com): query failed (failure) for > mail8140.bwnews.bestwestern.com/IN/ at ../../../lib/ns/query.c:7779 > > What is the impact of these messages? > > I'm also receiving many timeout problems. > > 31-May-2023 17:00:51.990 query-errors: info: client @0x7f8d00a1b968 > 127.0.0.1#56239 (_dmarc.zoominfo.com): query failed (timed out) for > _dmarc.zoominfo.com/IN/TXT at ../../../lib/ns/query.c:7779 > 31-May-2023 17:00:52.172 query-errors: info: client @0x7f8d00de5168 > 127.0.0.1#30280 (travel-assets.com.fresh30.spameatingmonkey.net): query > failed (timed out) for travel-assets.com.fresh30.spameatingmonkey.net/IN/A at > ../../../lib/ns/query.c:7779 > 31-May-2023 17:03:52.542 query-errors: client @0x7f53da961d68 > 68.195.111.45#50747 (31.57.89.167.bb.barracudacentral.org): query failed > (timed out) for 31.57.89.167.bb.barracudacentral.org/IN/A at > ../../../lib/ns/query.c:7779 > > I think the last two occur on multiple servers, leading me to believe they > actually have a problem? Barracuda requires that you register your IP with > them, and I've done that, but other queries with them work just fine, even > from servers that aren't registered. > > Could this be a bind tuning problem? Neither server where I ran these tests > are having resource issues that I know of. > > Any ideas on how to troubleshoot these to confirm it's not a problem with my > own server would be greatly appreciated. > > Thanks, > Alex > -- > 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: Workaround needed for TSIG Zone Transfer
There is no workaround that I can think of.
As an aside I’d be specifying the key in the primaries clause rather than
server clause.
--
Mark Andrews
> On 10 Jun 2023, at 07:52, Frey, Rick E via bind-users
> wrote:
>
>
> I’ve got a case where using BIND (v9.16.41) as a secondary to a third party
> (commercial) primary nameserver. Using TSIG for the zone transfers. Have
> verified zone transfers and TSIG key using dig between hosts. BIND is
> configured to use TSIG for the primary server using server x.x.x.x { keys
> “somekey”; } directive.
>
> Problem is that the primary server does not sign the response with TSIG for
> the SOA query sent by BIND to determine if update is needed. Since response
> to SOA query is not signed, BIND considers response invalid:
>
> Sample log message when SOA not signed:
> zone some-domain.com/IN: refresh: failure trying master x.x.x.x#53 (source
> 0.0.0.0#0): expected a TSIG or SIG(0)
>
> I know that BIND is not at fault and the primary server is breaking RFC8945
> as any query with TSIG is required to return a TSIG RR in the response.
> Working w/ vendor of the primary nameserver to resolve. The vendor is a
> pretty widely used provider so I’m a bit surprised issue has not occurred
> before now.
>
> Mainly wondering if there is any workaround available to allow BIND to either
> not send TSIG in SOA query to the primary server (but still use TSIG for zone
> transfer) or accept the SOA response w/o TSIG RR. I was unable to find any
> means to configure this behavior in reading through BIND documentation.
>
> Rick
>
> This email message and any attachments are for the sole use of the intended
> recipient(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original message and any
> attachments.
> Sensitivity: Internal
>
> --
> 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: Best way to handle multiple retries from BIND?
> On 26 Jun 2023, at 11:05, Fred Morris wrote: > > I have an authoritative server which performs a resource intensive operation > to determine an answer; sometimes it takes long enough that BIND asks again > (and again!). Firing off multiple attempts to determine the answer just digs > the hole deeper. Well what do you expect when the server doesn’t answer? Silence means nothing. Packet loss is a thing. > What's the best approach, assuming the same client asks repeatedly: > • Discard later queries, answer the first one? > • Discard earlier queries, answer the last one? > • Send same the response (when we get it) in response to all queries (I > don't like this one)? If you have a true duplicate you only need to answer it once otherwise you have different clients and you need to answer all of them. Note there can be multiple clients on the same address. > And does anyone know can the recommended mitigation be presumed to be the > best option regardless of the recursive server (BIND, Unbound, etc.)? Fix whatever is causing the server to take a long time to respond. DNS isn’t designed with servers that take a lot of time to respond in mind. Resolution takes long enough without spurious delays. Clients give up in a couple of seconds and the resolver often needs to make 20+ queries to validate a answer. The time budget per query is small and the planet has about a 200ms RTT. > Thanks in advance... > -- > 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 -- 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: Best way to handle multiple retries from BIND?
> On 26 Jun 2023, at 14:25, Ondřej Surý wrote: > > >> On 26. 6. 2023, at 6:04, Randy Bush wrote: >> >> so, for address foux, how do i know if there is one client or more than >> one? > > I think you only know that for an established TCP connection. Everything else > could be port reuse. Which doesn’t matter as there can only be one client at any point in time behind the tuple sans a broken NAT implementation. > Ondřej > -- > 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. > -- 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: Master file permission denied
The *exact* same error, word for word, or a different permission denied? > On 29 Jun 2023, at 06:35, Daniel Armando Rodriguez via bind-users > wrote: > > However, as soon as I added this > > dnssec-policy "default"; > inline-signing yes; > > Error came up again :-( > -- > 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: Master file permission denied
Show us the current permissions now that you have fixed them including every directory from the root. The permissions you had originally where wrong and wouldn’t normally be that way. Something or someone changed them. It may have happened again. We can’t see what you see so you have to show more details. If you you still have an error message cut-and-paste the new one including time stamps. > On 29 Jun 2023, at 09:03, Daniel A. Rodriguez via bind-users > wrote: > > Exactly the same > > > El 28 de junio de 2023 6:50:26 p. m. GMT-03:00, Mark Andrews > escribió: > The *exact* same error, word for word, or a different permission denied? > > On 29 Jun 2023, at 06:35, Daniel Armando Rodriguez via bind-users > wrote: > > However, as soon as I added this > > dnssec-policy "default"; > inline-signing yes; > > Error came up again :-( > -- > 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 -- 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: identifying DNSKEY by label
Firstly use dnssec-settime to manage the removal of the keys from the zone. Named periodically scans the key directory to see if a key has been marked to change state. Note a key should not be remove from a zone while there are still RRSIGs that where generated from it in the zone or in caches. From the dnssec-settime man page -I date/offset This option sets the date on which the key is to be retired. After that date, the key is still included in the zone, but it is not used to sign it. -D date/offset This option sets the date on which the key is to be deleted. After that date, the key is no longer included in the zone. (However, it may remain in the key repository.) The algorithm and key id are encoded into the file name. The key files record the various dates in the key files with the times recorded in UTC in ISO format. e.g. This key was created published and activated Tue Mar 22 14:17:34 2022. It has not been inactivated (-I) or been marked for deletion from the zone (-D). K.+005+12816.key: ; This is a zone-signing key, keyid 12816, for . ; Created: 20220322031734 (Tue Mar 22 14:17:34 2022) ; Publish: 20220322031734 (Tue Mar 22 14:17:34 2022) ; Activate: 20220322031734 (Tue Mar 22 14:17:34 2022) . IN DNSKEY 256 3 5 AwEAAfOwUKzeKqoZ98OnL3Gr6bbgkRYP7C/e2pj1VRxwnkh+Uy/KJ+l4 n5wcJVe6wQubIdNrwsPuhOOUjvJZwFfoEZAA5XkAs8/u9iWO2zNRswAN S3twZtaLK/3wMDwagBNW3ELw8UvQiaoDvqNkTVYSUOMVEmmmJYLUCZwb rncN/nSEJswwgna+s0wrj8QByq/R/y9WN4F46BbgvANirFQZm3izhYLd HjZVWrVBaynBUnjMrU8JI88KPzz5PhhhCOX/7Keh3Xqj7dWOZn4cYD/3 Yx8qz+x3siJUtXQHp4SViKGIQX8FmEATDFRyL0nWAe+GfahdwaUYOE5x oF9AIKAUJsc= K.+005+12816.private: Private-key-format: v1.3 Algorithm: 5 (RSASHA1) Modulus: 87BQrN4qqhn3w6cvcavptuCRFg/sL97amPVVHHCeSH5TL8on6XifnBwlV7rBC5sh02vCw+6E45SO8lnAV+gRkADleQCzz+72JY7bM1GzAA1Le3Bm1osr/fAwPBqAE1bcQvDxS9CJqgO+o2RNVhJQ4xUSaaYlgtQJnBuudw3+dIQmzDCCdr6zTCuPxAHKr9H/L1Y3gXjoFuC8A2KsVBmbeLOFgt0eNlVatUFrKcFSeMytTwkjzwo/PPk+GGEI5f/sp6HdeqPt1Y5mfhxgP/djHyrP7HeyIlS1dAenhJWIoYhBfwWYQBMMVHIvSdYB74Z9qF3BpRg4TnGgX0AgoBQmxw== PublicExponent: AQAB PrivateExponent: UEQShqYU8ntkLyc5yty/uhNk5pnvB2OFqB0i4B++Gw2088hH9jBbjk19BVUHsf1ymlNjzyqYzedIYE4suye+5SpOa1lOYN6KaBuSWuh9p7Y5VxrSXLdxkY6ULK/j4LrbCReYuwqg1YWvPN1UVdXpm6p8qpzlvR5/XdKGWEOdPR4HqTt22DpxStckrZ52g5vMZ+7/xurfrrw79h5rqauk03haQ0+WHMqoVTrvEXO7Ao2juFnX4gB/c7Qsx8tJvfk74w7H1r/AuaBYHkqMOce0Obpjq3fwqyS0tPElj702pCvdfDtZI2rY1PiUEjPEVtnlbrAw111vOyYwaAPy8RVw2Q== Prime1: +mzLu2MYzX7U0dfwSu1J+VMYEeLIk5LDO5sBIdOTcR+i1MpF5gvqTu5/89weNYdSjgInZfgyntc0nZsj2jXCkWyPTKOtngx5KP67rLNtxdY+bD5HE7Ze985JVKwUaahnn6nTzf12lyDjbegVKyW/FL2IuYbZdiQ5Y9PKpYMWFI8= Prime2: +R0g5/pd2jZV6Vj//L5rHB4OjyUEUnsdc6qs+vrrfzemTFAKjTjGyayXTYS82R3k5luxej5GNvji/J/Ly6eQnbFKI7dhPbOX2W1wSkhCOLgXPPSoBzQIeu/0XD1XJwhrf3IZt6HPw5NUBBY9yCP+2Tk58qDlOEnCpTNJeMC8Fkk= Exponent1: nNeDCgvYvuuOsxbBosvXJtaKHrmg0fx7VluQa/UtRQ6BVzCQcrJHv8PUU5ErQm9MnzBuKIk4ew9iHsvJuqMtBxOs9F0XIgPB5pEUTefa+qtiUTz4Gzp/ZEjI2MUly77zl6Yvx7XVjnXEu1M93tY3RPAoL7prfHjXkNRW+S6Op7U= Exponent2: iOibVyLgRbcrDC3fslYso61ZLw6XC4WiMBmTK/SPTMGW4cXzpp2XkusJ1I6pA2JMlNW7+oUTLc8nYNOpu2mCL0hqiKqWBMUZJWPiHNENpAJ4swV6+0p7hqUt1SvZJBiai9Z3j9acSs5DlGNs3Pv7agLreA85KvBOy2AedwDl3hE= Coefficient: GCuVIunQ0WTXrXbug5L0Fn16fc28dBe+uHfLoNRix4p33ZPhAjahT6VLA5F7o9suwA98Ppc9IBh82qfJPqlk3v3nBV5GY5K+ivq4Huy4US9t19TqWog+tzmbVTYFzueXnJPzCPHtG7x5ps5PaxD17GDQWaSHK8idOijAPmbSOY4= Created: 20220322031734 Publish: 20220322031734 Activate: 20220322031734 > On 29 Jul 2023, at 20:13, Axel Rau wrote: > > Hi all, > > I have several ZSKs in one zone, but only one is being > used for signing. > The others seem to be relicts from earlier rollovers. > I would like to delete the unused DNSKEY RRs via nsupdate, > but how can I identify a DNSKEY by label ? > > The zone has not yet been converted to dnssec-policy but > uses still auto-dnssec maintain. > > Axel > --- > PGP-Key: CDE74120 ☀ mobile: +49 160 7568212 > computing @ chaos claudius > > -- > 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: dnssec-policy syntax error in options but not in view
You can’t define a policy there. You can tell named to use the policy. Move the
definition outside of options.
--
Mark Andrews
> On 4 Aug 2023, at 08:26, E R wrote:
>
>
> My understanding from the ARM is that the dnssec-policy can be in the
> "options", "view" or "zone". I have mine in "view" and when I try to move
> into "options" I get a syntax error that I cannot seem to understand what is
> wrong. I stripped out all other statements and reduced the dnssec-policy to
> just a handful of items to KISS and I still do not see why why I get the
> error from named-checkconf. I can move the block from under "options" to the
> "view" and it just works so I am not sure why named-checkconf thinks there is
> a missing semicolon? Bind 9.16.23-RH.
>
> # named-checkconf 1.conf
> 1.conf:3: missing ';' before '{'
> 1.conf:3: '}' expected near '{'
>
> # cat 1.conf
> options {
>dnssec-policy "mydefault" {
> keys {
> csk key-directory lifetime unlimited algorithm ecdsa256;
> };
>};
> };
>
>
> --
> 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: Facing issues while resolving only one record
.168.1.133.33517 > 192.36.148.17.53: 18768 >> [1au] DNSKEY? incometax.gov.in. (57) >> 18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53: 28883 >> [1au] DNSKEY? incometax.gov.in. (57) >> 18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53: 46716 >> [1au] DNSKEY? incometax.gov.in. (57) >> 18:47:25.597312 ens18 In IP 192.168.1.162.53963 > 192.168.1.133.53: 23+ >> ? eportal.incometax.gov.in. (42) >> 18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 125.16.225.122.53: 12762 >> [1au] DNSKEY? incometax.gov.in. (57) >> I feel this is something related to DNS RRKEY Record size? >> Plus then I dumbdb on my server and went through cache using command >> #rndc dumpdb -all >> And here is the output >> incometax.gov.in. 3422NS ns01.incometax.gov.in. >> 3422NS ns02.incometax.gov.in. >> ns01.incometax.gov.in. 131 \- ;-$NXRRSET >> ; ns01.incometax.gov.in. RRSIG NSEC ... >> ; ns01.incometax.gov.in. NSEC ns02.incometax.gov.in. A RRSIG NSEC >> ; incometax.gov.in. SOA ns01.incometax.gov.in. >> ns-admin.cpc.incometax.gov.in. 2023060970 7200 3600 1209600 3600 >> ; incometax.gov.in. RRSIG SOA ... >> ns02.incometax.gov.in. 120 \- ;-$NXRRSET >> ; ns02.incometax.gov.in. RRSIG NSEC ... >> ; ns02.incometax.gov.in. NSEC ns03.incometax.gov.in. A RRSIG NSEC >> ; incometax.gov.in. SOA ns02.incometax.gov.in. >> ns-admin.cpc.incometax.gov.in. 2023071447 7200 3600 1209600 3600 >> ; incometax.gov.in. RRSIG SOA ... >> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 130] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 119] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 125] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 114] [v4 unexpected] [v6 nxrrset] >> ; ns01.incometax.gov.in [v6 TTL 124] [v4 unexpected] [v6 nxrrset] >> ; ns02.incometax.gov.in [v6 TTL 113] [v4 unexpected] [v6 nxrrset] >> Any idea what could be an issue? >> -- >> 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/conta
Re: BIND 9.18 unable to successfully transfer zone from axfrdns primary
Set debug level 3 on the xfrin channel. There are some debug level messages that really should be set to error level in lib/dns/xfrin.c on FORMERR. Also make sure you are running dig from the same version as later versions are more strict in parsing responses from the wire. > On 1 Sep 2023, at 09:23, Ian Bobbitt wrote: > > I have a system running BIND 9.18.17 that needs to transfer a zone from > djbdns/axfrdns. I receive FORMERRs, and haven't been able to get any log > messages indicating the problem. > > xfer-in: info: zone example.net/IN: Transfer started. > xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: connected > using192.0.2.1 #53 > xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: failed > while receiving responses: FORMERR > xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer > status: FORMERR > xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: Transfer > completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 bytes/sec) (serial 0) > > This replaced a long obsolete system running 9.8.2 that was able to > successfully transfer the zone. I can also successfully transfer the zone > with `dig -t axfr ...` from the new system, which gives no errors. > named-checkzone on the resulting data also gives no errors, and BIND is able > to successfully load it as a primary. > > How do I go about finding the cause of the FORMERR and resolve it? > > -- Ian > -- > 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: Local network IPv6 addresses
Just use dynamic DNS to add the addresses to the DNS. RFC 2136 with
RFC 2931 (SIG(0)) or RFC 2845 (TSIG).
zone example.com {
type primary;
update-policy {
grant * self * ANY; // For the node to update it’s
own records.
grant admin-key subzone * ANY; // For adding the initial KEY
records.
};
};
Add public key using KEY record at the node’s name for SIG(0) or use
a TSIG key with the node’s name.
For reverse zone use TCP as the authenticator by forcing the update to
come from the address that matches the PTR record to be updated.
zone 0.0.0.0.0.0.0.0.8.b.8.0.1.0.0.2.ip6.arpa {
type primary;
update-policy {
grant * tcp-self . PTR(1).
};
...
};
> On 4 Sep 2023, at 04:30, Marco wrote:
>
> Am 03.09.2023 um 18:36:53 Uhr schrieb Alessandro Vesely:
>
>> DHCP server has options to insert leased addresses in a dynamic zone.
>> That works for IPv4. PCs connected to the LAN somehow discover the
>> gateway has a routable IPv6 address and self-assign an address in
>> that range, besides the fe80:: thing, without talking to a DHCP
>> server.
>>
>> Is there a method to get those addresses into the DNS?
>
> This is the SLAAC - it doesn't use DHCPv6.
> No domain name will be assigned by this method, so I see no reason for
> DNS.
Why do you think you need to use DHCP to assign a domain name? Doing that
with the DHCPv4 server was just a matter of convenience rather than setting
the domain name when the machine was commissioned as you only had to read
the ethernet address on the side of the box and add a entry in the DHCP server
for it. Doing the DNS updates from the DHCP server also has the convenience
that you only had to deal with authentication between 2 entities rather than
hundreds or thousands.
A lot of this also comes from not having enough address to give every machine
its own public addresses. If you are behind a NAT you don’t have a public
address so you don’t have the ability to have a presence in the public DNS.
IPv6 corrects this.
> You can configure your router to advertise the prefix without the A
> flag, so no SLAAC happens.
> YOu need then to configure a DHCPv6. Then it should me possible to pass
> the lease information into a dynamic DNS zone.
> --
> 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: resolver: DNS format errors
Spamhaus’s servers are sending back responses that do not answer the question.
Named is doing QNAME minimisation using NS queries and rather than the servers
sending back a NODATA response for the empty non-terminal names they are
sending back the NS records for the top of the zone.
I suggest that you ask them to fix their DNS servers to correctly answer NS
queries. They appear to need to look at the query name as well as the query
type.
This is what often happens when you write custom DNS servers. You fail to
handle some query you weren’t planning for.
Mark
--
Mark Andrews
> On 8 Sep 2023, at 04:41, Alex wrote:
>
>
> Hi,
>
> I have a fedora38 server with bind-9.18.17 and receiving the following log
> entries for virtually every query (where "mykey" is my registered spamhaus
> DQS key):
> 07-Sep-2023 14:30:13.608 lame-servers: FORMERR resolving
> 'mykey.hbl.dq.spamhaus.net/NS/IN': 66.42.94.100#53
> 07-Sep-2023 14:30:13.625 resolver: DNS format error from 143.215.143.8#53
> resolving mykey.hbl.dq.spamhaus.net/NS for : reply has no answer
> 07-Sep-2023 14:30:13.625 lame-servers: FORMERR resolving
> 'mykey.hbl.dq.spamhaus.net/NS/IN': 143.215.143.8#53
> 07-Sep-2023 14:30:13.628 lame-servers: success resolving
> 'psnobcays3v2r52vapfv5fgvr6pgd6znvuzyhe5ktid3ty3oai4q._file.mykey.hbl.dq.spamhaus.net/A'
> after disabling qname minimization due to 'failure'
>
> 07-Sep-2023 14:39:30.214 lame-servers: success resolving
> '22.10.223.192.bl.spamcop.net/A' after disabling qname minimization due to
> 'ncache nxdomain'
>
> For some reason my config isn't ignoring lame-servers, but it does look
> relevant and related to the resolver errors.
>
> I've tried to experiment with including "minimal responses yes;" in my
> config, based on some reading about a similar issue years ago, but it doesn't
> change anything. This nameserver provides DNS across a VPN link to a remote
> system on a cable modem because having the server (also fedora38) query DNS
> directly on a cable modem was resulting in some other weird errors.
>
> Any ideas greatly appreciated.
>
> acl "trusted" {
> { 127/8; };
> { 68.195.44.40/29; };
> { 147.135.111.126; };
> };
> options {
> listen-on port 53 { 127.0.0.1; 147.135.111.126; };
> listen-on-v6 port 53 { none; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> secroots-file "/var/named/data/named.secroots";
> recursing-file "/var/named/data/named.recursing";
> allow-query { trusted; };
> allow-query-cache { trusted; };
> minimal-responses yes;
> recursion yes;
> managed-keys-directory "/var/named/dynamic";
> geoip-directory "/usr/share/GeoIP";
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> include "/etc/crypto-policies/back-ends/bind.config";
> };
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> channel named_debug {
> severity dynamic;
> file "/var/log/named.debug.log" versions 2 size 100m;
> print-time yes;
> print-category yes;
> };
> category default { named_debug; };
> channel query_info {
>severity info;
>file "/var/log/named.query.log" versions 3 size 5m;
>print-time yes;
>print-category yes;
> };
> category queries { query_info; };
> };
> zone "." IN {
> type hint;
> file "named.ca";
> };
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
>
> --
> 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: consolidating in-addr.arpa data
Create a 10.in-addr.arpa zone with appropriate delegations and have all servers serve it. That way they can all find te sub zones. -- Mark Andrews > On 16 Sep 2023, at 10:16, John Thurston wrote: > > > A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and PTR > in whatever.10.in-addr.arpa. MS DNS is happy to publish those. > > But the DNS system running on BIND also has a whatever.10.in-addr.arpa zone. > > So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query both > DNS systems in turn. If I get NXDOMAIN from both, then I can say the PTR > doesn't exist. > > On each system, I'd like to be able to take the 10.in-addr.arpa data from the > other, compute the differences, and incorporate them locally. Then I'll be > able to query either system, and accept an NXDOMAIN with confidence. > > And since writing my earlier note, I have re-located the code I think I > stumbled across earlier > > Tony Finch's "nsdiff" > > > > https://dotat.at/prog/nsdiff/ > > > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > On 9/15/2023 2:21 PM, Greg Choules wrote: >> Hi John. >> Can you tell me a bit more please? >> - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? >> - Where are hosts auto registering to? I'd guess MS, but it would be good to >> confirm. >> - What does fragmentation look like? A few real examples would be useful. >> I'm trying to understand just what is the problem. >> - How much of 10 do you use? >> - What do you mean by "...can be published from two different DNS >> services."? Could you expand on that please? >> - Is there any zone transfer between BIND and MS DNS? >> >> Thanks, Greg >> >> On Fri, 15 Sept 2023 at 21:00, John Thurston >> wrote: >>> This question involves making our BIND system work with Microsoft's DNS >>> software. If this makes it off-topic, let me know and I'll be quiet about >>> it. >>> >>> We use ISC BIND to hold and host most of our zone data. Internally, we have >>> delegated some zones, and they are held in Microsoft DNS. These zones are >>> used for MS Active Directory 'Domains', and accept auto-registration of DNS >>> records from authorized hosts. Because we are using 10-dot addresses >>> internally, the auto-registration by hosts causes fragmentation of the >>> 10.in-addr.arpa zone data. >>> >>> I recall someone once offered a bit of code to mash this zone data back >>> together, so the same information can be published from two different DNS >>> services. I've hunted through this list's archive and have not found the >>> reference. Before I go roll my own, can anyone point me at an existing >>> solution? >>> >>> -- >>> -- >>> Do things because you should, not just because you can. >>> >>> John Thurston907-465-8591 >>> john.thurs...@alaska.gov >>> Department of Administration >>> State of Alaska >>> > -- > 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: resolver: DNS format errors
> On 19 Sep 2023, at 02:14, Alex wrote: > > > > On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews wrote: > Spamhaus’s servers are sending back responses that do not answer the > question. Named is doing QNAME minimisation using NS queries and rather than > the servers sending back a NODATA response for the empty non-terminal names > they are sending back the NS records for the top of the zone. > > I suggest that you ask them to fix their DNS servers to correctly answer NS > queries. They appear to need to look at the query name as well as the query > type. > > This is what often happens when you write custom DNS servers. You fail to > handle some query you weren’t planning for. > > They have just recommended disabling qname-minimization altogether. Is that > the right solution? No. The correct solution is for them to fix their broken servers. Their servers give correct answers for DS, A, TXT, SOA, A and others but not for NS (a referral back to the same servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they do for DS, A, TXT, SOA, A and others). This is behaviour that is specified in RFC 1034 that is wrong. QNAME minimisation (RFC 7816) is a security fix designed to prevent leaking of query names and types to servers closer to the root that don’t need this information and it works with all servers that are DNS protocol compliant. They are recommending that you turn off a security fix. RFC 1034, 4.3.2. Algorithm ... 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn’t match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. ... 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. Step 2 gives zrd.dq.spamhaus.net. Step 3a matches pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net and as there isn’t NS records at that name the answer section should be empty. Adding referral records is done in step 3b which is skipped. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4. % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ds @a.gns.spamhaus.net ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ds @a.gns.spamhaus.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26823 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 2048 ;; QUESTION SECTION: ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN DS ;; AUTHORITY SECTION: zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 2309182309 3600 600 432000 1 ;; Query time: 194 msec ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) ;; WHEN: Tue Sep 19 09:11:44 AEST 2023 ;; MSG SIZE rcvd: 151 % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' txt @a.gns.spamhaus.net ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net txt @a.gns.spamhaus.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65222 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 2048 ;; QUESTION SECTION: ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN TXT ;; AUTHORITY SECTION: zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 2309182309 3600 600 432000 1 ;; Query time: 188 msec ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) ;; WHEN: Tue Sep 19 09:12:05 AEST 2023 ;; MSG SIZE rcvd: 151 % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' soa @a.gns.spamhaus.net ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2g
Re: resolver: DNS format errors
Correction, they incorrectly answer the SOA query. > On 19 Sep 2023, at 09:53, Mark Andrews wrote: > > > >> On 19 Sep 2023, at 02:14, Alex wrote: >> >> >> >> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews wrote: >> Spamhaus’s servers are sending back responses that do not answer the >> question. Named is doing QNAME minimisation using NS queries and rather than >> the servers sending back a NODATA response for the empty non-terminal names >> they are sending back the NS records for the top of the zone. >> >> I suggest that you ask them to fix their DNS servers to correctly answer NS >> queries. They appear to need to look at the query name as well as the query >> type. >> >> This is what often happens when you write custom DNS servers. You fail to >> handle some query you weren’t planning for. >> >> They have just recommended disabling qname-minimization altogether. Is that >> the right solution? > > No. The correct solution is for them to fix their broken servers. Their > servers give correct > answers for DS, A, TXT, SOA, A and others but not for NS (a referral back > to the same > servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they > do for DS, A, TXT, > SOA, A and others). This is behaviour that is specified in RFC 1034 that > is wrong. QNAME > minimisation (RFC 7816) is a security fix designed to prevent leaking of > query names and types > to servers closer to the root that don’t need this information and it works > with all servers > that are DNS protocol compliant. They are recommending that you turn off a > security fix. > > > RFC 1034, 4.3.2. Algorithm > > ... > > 2. Search the available zones for the zone which is the nearest > ancestor to QNAME. If such a zone is found, go to step 3, > otherwise step 4. > > 3. Start matching down, label by label, in the zone. The > matching process can terminate several ways: > > a. If the whole of QNAME is matched, we have found the > node. > > If the data at the node is a CNAME, and QTYPE doesn’t > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > Otherwise, copy all RRs which match QTYPE into the > answer section and go to step 6. > >... > >6. Using local data only, attempt to add other RRs which may be > useful to the additional section of the query. Exit. > > Step 2 gives zrd.dq.spamhaus.net. Step 3a matches > pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > and as there isn’t NS records at that name the answer section should be > empty. Adding referral > records is done in step 3b which is skipped. > > b. If a match would take us out of the authoritative data, > we have a referral. This happens when we encounter a > node with NS RRs marking cuts along the bottom of a > zone. > > Copy the NS RRs for the subzone into the authority > section of the reply. Put whatever addresses are > available into the additional section, using glue RRs > if the addresses are not available from authoritative > data or the cache. Go to step 4. > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ds @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ds > @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26823 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2048 > ;; QUESTION SECTION: > ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN DS > > ;; AUTHORITY SECTION: > zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. > 2309182309 3600 600 432000 1 > > ;; Query time: 194 msec > ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP) > ;; WHEN: Tue Sep 19 09:11:44 AEST 2023 > ;; MSG SIZE rcvd: 151 > > % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' txt @a.gns.spamhaus.net > > ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net > txt @a.gns.spamhaus.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65222 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
Re: Stop leaking queries for RFC 1918 zones
The option is enabled by default however if you forward all queries then the
automatic zones won’t be created and the forwarder is responsible for
filtering. This is done like this because lots of people use forwarding to get
to the internal servers that serve these zones.
Just create empty zones in named.conf. If the automatic creation doesn’t work
with the rest of your configuration.
The log messages are there to tell you that queries are still leaking.
Given your other questions about 10.in-addr.arpa I would really set it up and
delegate based on which address blocks are assigned to whom. Allow the zone to
be transferred to any 10.0.0.0/8 address by default. Add in other server
address or TSIG keys as different departments request access to it. Start with
an empty zone and delegations for the addresses you are using yourself and
build up from there. Turn off forwarding in this zone’s configuration by using
an empty forwarders clause ( forwarders { /* empty */ }; ).
I know you said this was a lost cause but it doesn’t have to be 100% perfect.
It can be built up over time.
--
Mark Andrews
> On 23 Sep 2023, at 02:45, John Thurston wrote:
>
>
> The global/view option
>
> empty-zones-enable yes;
>
> isn't behaving as I expected.
>
> I had expected that it would cause empty "RFC 1918" zones to be created for
> those zones for which there were not local zones defined. That is, if there
> were no local zones of this type defined, it would create all the required
> empty zones. But if 10.in-addr.arpa was defined locally, it would skip that
> but define the rest of them.
>
> After looking at my logs, and seeing that I'm leaking RFC 1918 queries, I see
> my expectations were wrong.
>
> Is explicitly defining the remaining empty zones the best way to correct this?
>
> Or maybe add the un-used RFC 1918 zones to our RPZ?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> --
> 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: resolver: DNS format errors
> On 4 Oct 2023, at 06:31, Petr Menšík wrote:
>
> Hi Mark,
>
> I have seen this error before and I admit it is quite annoying. Especially
> when the owners of failing implementations refuse to fix their bugs. Is there
> any possibility to tune this only for set of broken servers?
>
> server prefix {} block can set different features for selected server(s),
> disabling even EDNS0 extension. But qname-minimization cannot be changed
> selectively. Be it per address or (sub)domain, it would be useful until all
> implementations fix their behaviour.
Disabling EDNS is about constructing individual queries. QNAME minimisation is
about changing the series of queries made while iterating. Very different
things.
> Would it make sense to allow disabling qname minimization in server blocks
> also? Is there specific reason, why this can be changed only per view or
> globally? Is there other workaround possible? May stub zones help with this?
Stub zones don’t disable QNAME minimisations below them. The just short
circuit the iteration process above them.
Really I don’t want to be writing code to just deal with SpamHaus’s
mis-implementation. They should fix their broken servers.
> Cheers,
> Petr
>
> On 19. 09. 23 1:53, Mark Andrews wrote:
>>
>>> On 19 Sep 2023, at 02:14, Alex wrote:
>>>
>>>
>>>
>>> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews wrote:
>>> Spamhaus’s servers are sending back responses that do not answer the
>>> question. Named is doing QNAME minimisation using NS queries and rather
>>> than the servers sending back a NODATA response for the empty non-terminal
>>> names they are sending back the NS records for the top of the zone.
>>>
>>> I suggest that you ask them to fix their DNS servers to correctly answer NS
>>> queries. They appear to need to look at the query name as well as the
>>> query type.
>>>
>>> This is what often happens when you write custom DNS servers. You fail to
>>> handle some query you weren’t planning for.
>>>
>>> They have just recommended disabling qname-minimization altogether. Is that
>>> the right solution?
>> No. The correct solution is for them to fix their broken servers. Their
>> servers give correct
>> answers for DS, A, TXT, SOA, A and others but not for NS (a referral
>> back to the same
>> servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they
>> do for DS, A, TXT,
>> SOA, A and others). This is behaviour that is specified in RFC 1034
>> that is wrong. QNAME
>> minimisation (RFC 7816) is a security fix designed to prevent leaking of
>> query names and types
>> to servers closer to the root that don’t need this information and it works
>> with all servers
>> that are DNS protocol compliant. They are recommending that you turn off a
>> security fix.
>>
>>
>> RFC 1034, 4.3.2. Algorithm
>>
>>...
>>
>>2. Search the available zones for the zone which is the nearest
>> ancestor to QNAME. If such a zone is found, go to step 3,
>> otherwise step 4.
>>
>>3. Start matching down, label by label, in the zone. The
>> matching process can terminate several ways:
>>
>> a. If the whole of QNAME is matched, we have found the
>> node.
>>
>> If the data at the node is a CNAME, and QTYPE doesn’t
>> match CNAME, copy the CNAME RR into the answer section
>> of the response, change QNAME to the canonical name in
>> the CNAME RR, and go back to step 1.
>>
>> Otherwise, copy all RRs which match QTYPE into the
>> answer section and go to step 6.
>>
>> ...
>> 6. Using local data only, attempt to add other RRs which may be
>>useful to the additional section of the query. Exit.
>>
>> Step 2 gives zrd.dq.spamhaus.net. Step 3a matches
>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net
>> and as there isn’t NS records at that name the answer section should be
>> empty. Adding referral
>> records is done in step 3b which is skipped.
>>
>> b. If a match would take us out of the authoritative data,
>> we have a referral. This happens when we encounter a
>> node with NS RRs marking cuts along the bottom of a
>> zone.
>>
>> Copy the NS RRs for the subzone into the authority
>> section of the reply. Put whatever addresses are
>> available into the additional secti
Re: Bind forgets my changes with nsupdate
You need to figure out what is updating the zone. This isn’t named. -- Mark Andrews > On 6 Oct 2023, at 19:28, Paul van der Vlis via bind-users > wrote: > > Hello, > > I try to give a dynamic IP to a name, using nsupdate. This works fine, but > after some hours the IP is gone from the master (which I update). > > Something like this: > Host home.customer.nl not found: 3(NXDOMAIN) > > The IP is then still available from the slaves, what gets it from the master. > > I do something like this to give the IP, using a script: > > root@server:~# /usr/bin/nsupdate -k /etc/customer.key > > server ns1.vandervlis.nl > > zone customer.nl. > > update delete home.customer.nl. > > update add home.customer.nl. 3600 A 1.2.3.4 > > send > > quit > > I don't see anything about the removal in the logs. But I saw a "freeze" and > a "thaw" in the logs for the domain. > > Any idea why the IP removes after some time? > > With regards, > Paul van der Vlis > > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl/ > -- > 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: Bind forgets my changes with nsupdate
Just configure named to sign the zone. -- Mark Andrews > On 6 Oct 2023, at 22:30, Paul van der Vlis wrote: > > Op 06-10-2023 om 10:39 schreef Mark Andrews: >> You need to figure out what is updating the zone. This isn’t named. > > Thanks for your answer. > It makes me find the reason. See my other message. > > With regards, > Paul > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl/ -- 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: KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive Keys Disappear?)
pid";
> session-keyfile "/run/named/session.key";
> include "/etc/crypto-policies/back-ends/bind.config";
> };
>
> logging
> {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
>
> zone "." IN {
> type hint;
> file "/var/named/named.ca";
> };
>
> zone "dnssec.example" {
> type primary;
> file "dnssec.example.db";
> dnssec-policy default;
> inline-signing yes;
> key-directory "keys/dnssec.example";
> };
> -
> [root@localhost dnssec.example]# cat /var/named/dnssec.example.db
> $ORIGIN dnssec.example.
> $TTL 3h
>
> @ IN SOA ns01.dnssec.example. postmaster.dnssec.example. (
> 2023100601 ; Serial
> 3h; Refresh after 3 hours
> 1h; Retry after 1 hour
> 1w; Expire after 1 week
> 1h ) ; Negative caching TTL of 1 hour
>
> NS ns01.dnssec.example.
>
> ; Addresses - ORIGIN definition allows us to not have to type FQDN as well as
> the trailing .
>
> ns01A 10.1.2.3
> --
> 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: 9.18 BIND not iterated over all authoritative nameservers
Well if the bank is stupid enough to use NS records that point to nameservers that do not exist on the internet then lookups FAIL. % dig ns gtm.bankeasy.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.18-dev <<>> ns gtm.bankeasy.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: dbef45feadd7b3850100653c2cefd1f381fbb389e388 (good) ;; QUESTION SECTION: ;gtm.bankeasy.com. IN NS ;; ANSWER SECTION: gtm.bankeasy.com. 0 IN NS bkx-bigip1-out.ffc.local. ;; Query time: 992 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Sat Oct 28 08:34:39 AEDT 2023 ;; MSG SIZE rcvd: 111 % Named now uses NS lookups to perform QNAME minimisation. If one puts garbage in the NS records then they should expect lookups to fail. The NS records on both sides of a zone cut are supposed to be IDENTICAL. This is not a new requirement. It has been this way since the very beginning. The bank needs to fix what they publish. Mark > On 28 Oct 2023, at 02:36, Michael Martinell via bind-users > wrote: > > Hello, > At this point I am hoping that somebody might have a workaround so that we > can exclude domains from this behavior if they are broken on the far end. > Does anybody have a workaround for this? > We are a small ISP and run BIND compiled from source. We currently run 9.16.x > Every time we try to move forward with 9.18 customers start to complain that > they are unable to reach certain websites. This includes banks, > universities, and other organizations. > I understand the goal is to get all DNS to RFC 6891, but from a practical > standpoint, this isn’t working for customers, so we are prevented from > upgrading either. > Related website: > https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 > Our source code compile options: > ./configure --with-gnu-ld --with-libxml2 --with-json-c > --with-openssl=/usr/local/openssl && make && make install && ldconfig > When I do a dig against a server running 9.18 I get the following: > dig @dns1.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns1.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46906 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: d8ce8161641fbfdf0100653bcf9ad1fff99d24914278 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; Query time: 8 msec > ;; SERVER: > 2607:d600:1000:330:75:102:161:227#53(2607:d600:1000:330:75:102:161:227) > ;; WHEN: Fri Oct 27 09:56:26 CDT 2023 > ;; MSG SIZE rcvd: 74 > The same command resolves just fine when I run it against 9.16 > dig @dns2.itctel.com view.bankeasy.com > ; <<>> DiG 9.16.42 <<>> @dns2.itctel.com view.bankeasy.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30969 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: b0ec30c4ddfeacd30100653bcf9ff140c249344242e0 (good) > ;; QUESTION SECTION: > ;view.bankeasy.com. IN A > ;; ANSWER SECTION: > view.bankeasy.com. 3133 IN CNAME view.gtm.bankeasy.com. > view.gtm.bankeasy.com. 300 IN A 96.2.250.200 > ;; Query time: 11 msec > ;; SERVER: > 2607:d600:9000:330:75:102:160:227#53(2607:d600:9000:330:75:102:160:227) > ;; WHEN: Fri Oct 27 09:56:31 CDT 2023 > ;; MSG SIZE rcvd: 125 > [root@brkr-dns2 bind-9.18.12]# > Michael Martinell > Network/Broadband Technician > > Interstate Telecommunications Coop., Inc. > 312 4th Street West • Clear Lake, SD 57226 > Phone: (605) 874-8313 > michael.martin...@itccoop.com > www.itc-web.com > -- > 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: 9.18 BIND not resolving .gov.bd site
.net) (UDP) ;; WHEN: Tue Oct 31 12:04:53 AEDT 2023 ;; MSG SIZE rcvd: 725 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54270 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ns1.bcc.gov.bd. IN A ;; AUTHORITY SECTION: bcc.gov.bd. 86400 IN NS ns1.bcc.gov.bd. bcc.gov.bd. 86400 IN NS ns2.bcc.gov.bd. ;; ADDITIONAL SECTION: ns1.bcc.gov.bd. 86400 IN A 114.130.54.123 ns2.bcc.gov.bd. 86400 IN A 114.130.54.124 ;; Query time: 210 msec ;; SERVER: 123.49.12.112#53(dns.bd) (UDP) ;; WHEN: Tue Oct 31 12:04:54 AEDT 2023 ;; MSG SIZE rcvd: 107 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11259 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 69a562ec1c50e2280100654052b6abe0594cf8b9b688 (good) ;; QUESTION SECTION: ;ns1.bcc.gov.bd. IN A ;; ANSWER SECTION: ns1.bcc.gov.bd. 38400 IN A 114.130.54.123 ;; AUTHORITY SECTION: bcc.gov.bd. 38400 IN NS ns1.bcc.gov.bd. bcc.gov.bd. 38400 IN NS ns2.bcc.gov.bd. ;; ADDITIONAL SECTION: ns2.bcc.gov.bd. 38400 IN A 114.130.54.124 ;; Query time: 212 msec ;; SERVER: 114.130.54.123#53(ns1.bcc.gov.bd) (UDP) ;; WHEN: Tue Oct 31 12:04:54 AEDT 2023 ;; MSG SIZE rcvd: 135 % That succeeded but you will note that that address of both of the nameservers for bcc.gov.bd are in the same /24 which means there is a single point of failure at the routing level. At this point I’d test if you could reach the nameservers with direct queries as you have their addresses in the glue returned from the .bd nameservers assuming that if fails for you. % dig ns1.bcc.gov.bd @114.130.54.123 ; <<>> DiG 9.19.18-dev <<>> ns1.bcc.gov.bd @114.130.54.123 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2139 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 8a8e9d7bfc1abdb201006540536a724fdb04112462bb (good) ;; QUESTION SECTION: ;ns1.bcc.gov.bd. IN A ;; ANSWER SECTION: ns1.bcc.gov.bd. 38400 IN A 114.130.54.123 ;; Query time: 215 msec ;; SERVER: 114.130.54.123#53(114.130.54.123) (UDP) ;; WHEN: Tue Oct 31 12:07:54 AEDT 2023 ;; MSG SIZE rcvd: 87 % dig ns2.bcc.gov.bd @114.130.54.124 ; <<>> DiG 9.19.18-dev <<>> ns2.bcc.gov.bd @114.130.54.124 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44727 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 181d91ea2ecc46ce0100654054883752dba5d1912e6e (good) ;; QUESTION SECTION: ;ns2.bcc.gov.bd. IN A ;; ANSWER SECTION: ns2.bcc.gov.bd. 38400 IN A 114.130.54.124 ;; Query time: 212 msec ;; SERVER: 114.130.54.124#53(114.130.54.124) (UDP) ;; WHEN: Tue Oct 31 12:12:40 AEDT 2023 ;; MSG SIZE rcvd: 87 % -- 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: Question about URL being logged by resolver
People accidentally enter urls as domain names into tools. https://app-measurement.com/sdk-exp/A is a legal, but unusual, domain name consisting of 3 labels 'https://app-measurement’, 'com/sdk-exp/A’ and ‘.’. Mark > On 4 Nov 2023, at 13:29, Nick Tait via bind-users > wrote: > > Hi J. > > I'm not sure what the cause of the URLs is, but I can confirm I'm seeing the > same URLs in my own logs. The queries originate from multiple devices on my > internal network - all Apple devices I think. > > My advice: I wouldn't waste too much effort trying to solve this one, as it > is almost certainly something that you will have no control over. E.g. It > could be something bogus on a web page that these devices have all accessed? > > Nick. > > > On 4/11/23 11:30, J Doe wrote: >> Hello, >> >> On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see >> URL's being noted in the log files. >> >> One such example is: >> >> 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving >> 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization >> due to 'ncache nxdomain' >> >> This seems unusual to me because Bind usually notes the domain name it is >> attempting to resolve, not an URL. In this particular case, I would expect >> to see a notation about "app-measurement.com" and not "http://etc";. >> >> What is the significance of logging the URL and why does this happen in only >> some cases ? >> >> Thanks, >> >> - J > -- > 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: Catalog zone Notifies for child zones
> On 9 Nov 2023, at 01:25, G H via bind-users wrote: > > I have a master and a slave server setup with functional catalog zone > transfers. Upon initial daemon start, the slave will pull the catalog zone, > and then pull the domain zones contained within said catalog zone (let's > refer to these domains as child domains). > > If I modify the serial on the master's catalog zone file and restart, the > slave will successfully receive a NOTIFY and pull down the latest catalog > zone file contents. > > However, if I modify the serial of child domain zone, no NOTIFY is ever sent. > The only way I can get the slave server to pull down the latest contents of > the child domain zone is to delete the /var/cache/bind contents and restart > the slave daemon. What is the correct method of letting slave servers know > that the child domain zones are changed? I really want to avoid putting an > "also-notify" in the definition for child zone on the master. Well what NS records do you have in the child zone? Notify looks at NS records, looks up the address records (A and ), then sends NOTIFY messages to those addresses. > -- > 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: What does it mean "lame-servers: info: success resolving"?
It means that the servers for the zone doesn’t fully implement the DNS
protocol. NS queries for intermediate names are not getting the expected
answer.
--
Mark Andrews
> On 1 Dec 2023, at 21:10, Alessandro Vesely wrote:
>
> Hi all,
>
> I have this in BIND 9.18.19-1~deb12u1-Debian' logs:
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named-qu.log.0
> 30-Nov-2023 15:58:23.901 queries: info: client @0x7f281e72ff68
> 127.0.0.1#54827 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:28.909 queries: info: client @0x7f281e6add68
> 127.0.0.1#54827 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:30.357 queries: info: client @0x7f2817485f68
> 127.0.0.1#53802 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:31.621 queries: info: client @0x7f281f459f68
> 127.0.0.1#53122 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named.log.0
> 30-Nov-2023 15:58:35.689 lame-servers: info: success resolving
> '148.19.188.64.list.dnswl.org/A' after disabling qname minimization due to
> 'ncache nxdomain'
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named-dnssec.log.0
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: starting
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: attempting negative response validation from
> message
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: in validator_callback_nsec
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: resuming validate_nx
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: nonexistence proof(s) not found
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: checking existence of DS at 'org'
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: checking existence of DS at 'dnswl.org'
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: marking as answer (proveunsecure (4))
>
> The success arrived several seconds after. Does this mean that the (first)
> queries failed? The dnssec log seems to indicate that the IP was not listed.
>
> The queries in the first half of the 15:58 minute were part of an SPF
> evaluation. (The SPF record contains an exists:%{ir}.list.dnswl.org
> mechanism.). The SPF evaluation returned "error". I'm trying to understand
> whether the cause was a DNS hiccup.
>
> Is this a kind of error that could be orchestrated remotely?
>
>
> TIA
> Ale
> --
>
>
>
> --
> 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: Value of a DNSSEC validating resolver
A validating resolver is a prerequisite for validating clients to work. Clients don’t have direct access to the authoritative servers so the can’t retrieve good answers if the recursive servers don’t filter out the bad answers. Think of a recursive server as a town water treatment plant. You could filter and treat at every house and sometimes you still do like boiling water for baby formula but on the most part what you get out of it is good enough for consumption as is. -- Mark Andrews > On 2 Dec 2023, at 08:14, John Thurston wrote: > > > At first glance, the concept of a validating resolver seemed like a good > idea. But in practice, it is turning out to be a hassle. > > I'm starting to think, "If my clients want their answers validated, they > should do it." If they *really* care about the quality of the answers they > get, why should my clients be trusting *me* to validate them? > > Can someone make a good case to me for continuing to perform DNSSEC > validation on my central resolvers? > > -- > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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: Value of a DNSSEC validating resolver
Clients need to send both cd=0 and cd=1 queries. The two types of queries address different failure scenarios. I tried hard to prevent the stupid just send cd=1 advice before it was published. Years before there was a wish to reduce the amount of work a validating resolver does. There was bad advice from that and the WG chair refused to reopen the issue. CD=1 addresses bad clocks and trust anchors in resolvers. CD=0 addresses bad authoritative servers and spoofed responses. You can start with either and try the other when validation fails. -- Mark Andrews > On 3 Dec 2023, at 12:31, Crist Clark wrote: > > > Preface: Please don’t read any judgement of DNSSEC’s value into this > question. Just looking for the opportunity to understand DNSSEC better from > some world-class experts if any care to respond. > > When a client (or any DNS-speaker) is doing validation, doesn’t it set CD on > queries through a forwarder? In that sense, the intermediate servers do not > filter “bad answers.” Or is my understanding incorrect? Or do you mean the > data that the forwarder is using internally has been filtered of bad answers? > > >> On Fri, Dec 1, 2023 at 1:40 PM Mark Andrews wrote: >> A validating resolver is a prerequisite for validating clients to work. >> Clients don’t have direct access to the authoritative servers so the can’t >> retrieve good answers if the recursive servers don’t filter out the bad >> answers. >> >> Think of a recursive server as a town water treatment plant. You could >> filter and treat at every house and sometimes you still do like boiling >> water for baby formula but on the most part what you get out of it is good >> enough for consumption as is. >> >> >> -- >> Mark Andrews >> >>>> On 2 Dec 2023, at 08:14, John Thurston wrote: >>>> >>> >>> At first glance, the concept of a validating resolver seemed like a good >>> idea. But in practice, it is turning out to be a hassle. >>> >>> I'm starting to think, "If my clients want their answers validated, they >>> should do it." If they *really* care about the quality of the answers they >>> get, why should my clients be trusting *me* to validate them? >>> >>> Can someone make a good case to me for continuing to perform DNSSEC >>> validation on my central resolvers? >>> >>> -- >>> -- >>> Do things because you should, not just because you can. >>> >>> John Thurston907-465-8591 >>> john.thurs...@alaska.gov >>> Department of Administration >>> State of Alaska >>> -- >>> 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 -- 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: dnssec-delegation seems to be broken from .gov to bls.gov
More to the point why was the old KSK removed *before* checking that the DS record for the new KSK was published and had been for the TTL of the DS RRset? With proper procedures this should not happen. When something goes wrong / is delayed in a key rollover the process should stall until that step is complete, not proceed blindly ahead. > On 7 Dec 2023, at 07:35, Bhangui, Sandeep - BLS CTR via bind-users > wrote: > > The problem has been resolved. > The automatic KSK rollover on the dotgov.gov did not happen properly and > once we manually updated the DS record with the correct KSK keytags and keys > things were fixed. > All is good now. > Now to see if we can find out as to why the automatic KSK failover on the > dotgov.gov did not happen correctly. > Thanks > Sandeep > From: bind-users On Behalf Of Nick Tait > via bind-users > Sent: Wednesday, December 6, 2023 3:23 PM > To: bind-users@lists.isc.org > Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov > CAUTION: This email originated from outside of BLS. DO NOT click (select) > links or open attachments unless you recognize the sender and know the > content is safe. Please report suspicious emails through the “Phish Alert > Report” button on your email toolbar. On 7/12/2023 9:05 am, Nick Tait via > bind-users wrote: > I could be wrong, but based on the output above it looks like the current TTL > is 0, which means that doing this should provide immediate relief. > Sorry it looks like the DNS server on the Wi-Fi network I'm connected to has > done something weird with the TTL. > This is what I get when querying one of the "gov." authoritative servers > directly: > $ dig -t ds bls.gov @a.ns.gov +norecurse > > ; <<>> DiG 9.18.18-0ubuntu2-Ubuntu <<>> -t ds bls.gov @a.ns.gov +norecurse > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32241 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;bls.gov. IN DS > > ;; ANSWER SECTION: > bls.gov.3600IN DS 50951 8 2 > E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C > > ;; Query time: 16 msec > ;; SERVER: 2001:503:ff40::1#53(a.ns.gov) (UDP) > ;; WHEN: Thu Dec 07 09:19:24 NZDT 2023 > ;; MSG SIZE rcvd: 84 > This means when you remove the DS record, it will take 1 hour to fully take > effect (assuming no delay replicating between authoritative servers). > Nick. > -- > 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: DNSSec mess with SHA1
They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews > On 16 Dec 2023, at 01:09, Scott Morizot wrote: > > >> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: >> We do runtime detection at startup because it's configurable, build time >> would not work properly. > > Okay, that makes sense. However, if I understood the scenario correctly, it > seems like that configuration should then generate a runtime error or at > least report that DNSSEC validation has been disabled. The description > involved removing support for SHA1 entirely from the underlying system > configuration. If that's the case then I don't see how DNSSEC validation can > be reliably performed at all. It's not like introducing a new DNSSEC > algorithm or removing support for an older DNSSEC algorithm. SHA1 is used to > generate the hash label in NSEC3. I know that's been discussed on dnsops, but > it hasn't changed. And from algorithm 8 on, there haven't been separate > algorithms with and without NSEC3. Rather it's an option that can be > configured for signing on a zone by zone basis. So if SHA1 isn't available, I > don't see how any of the DNSSEC algorithms could truly be considered > supported on the system. > > That's making me curious enough that I might see if I can set up a system > where I could reproduce that scenario and see what happens. Unless it's > already part of your test suite and you know the answer, of course. > > Scott > -- > 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: zone not loaded in one of view
Read your logs and/or use named-checkzone and/or tell name-checkconf to load the zones. -- Mark Andrews > On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote: > > > Hi, I have a bind9 authoritative name server running, but I found a strange > problem. One of zone in a specific view not loaded when I view the > cache_dump.db after I execute `rndc dumpdb -all`. > > > The zone data file is almost the same for difference views execpted some few > domain resolution. > > > [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet > $TTL 86400 ; 1 day > @ IN SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. ( > 2023121601; serial number > 10800 ; Refresh interval, every 3 hours > 3600; Retry interval, every 30 minutes > 604800 ; Expire after 1 week > 86400 ) ;Minimum TTL of 1 day > > > $INCLUDE /etc/named.data/db.ynu.edu.cn.common > > > > > ; RR of type A > ; > vpn110800 IN A 113.55.110.251 > ; > lb-http-jz IN A 113.55.14.52 > ynucdn 600 IN A 202.203.208.4 > ; > vpn2IN A 202.203.208.9 > > > [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet > $TTL 86400 ; 1 day > @ IN SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. ( > 2023121601; serial number > 10800 ; Refresh interval, every 3 hours > 3600; Retry interval, every 30 minutes > 604800 ; Expire after 1 week > 86400 ) ;Minimum TTL of 1 day > > > $INCLUDE /etc/named.data/db.ynu.edu.cn.common > > > > > ; RR of type A > ; > lb-http-jz IN A 113.55.14.52 > ; > vpn110800 IN A 192.168.208.3 > ynucdn 600 IN A 202.203.208.4 > ; > vpn2IN A 202.203.208.9 > > > [root@pridns data]# > [root@pridns data]# named-checkconf /etc/named.conf > [root@pridns data]# echo $? > 0 > [root@pridns data]# > [root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET > name: ynu.edu.cn > type: primary > files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common > serial: 2023121601 > nodes: 576 > last loaded: Sat, 16 Dec 2023 08:00:49 GMT > secure: no > dynamic: no > reconfigurable via modzone: no > [root@pridns data]# > [root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET > rndc: 'zonestatus' failed: zone not loaded > [root@pridns data]# > [root@pridns data]# named-checkzone ynu.edu.cn > /etc/named.data/db.ynu.edu.cn.intranet > zone ynu.edu.cn/IN: loaded serial 2023121601 > OK > [root@pridns data]# > [root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet > /etc/named.data/db.ynu.edu.cn.intranet > -rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.cernet > -rw-r--r-- 1 root root 1.3K Dec 16 16:00 > /etc/named.data/db.ynu.edu.cn.intranet > [root@pridns data]# > > > And here is parts of content in /var/named/data/cache_dump.db > > > ; Zone dump of 'ynu.edu.cn/IN/INTRANET' > ; > ; zone not loaded > ; > ; Zone dump of 'rpz/IN/INTRANET' > > > > > -- > 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: NOTIFY and TSIG
You use TSIG when transferring a zone to ensure you are talking to a valid
primary.
Spoofed NOTIFY messages where accounted for when NOTIFY was developed. The
server
will protect itself from spurious NOTIFY messages by rate limiting. Now if you
are
using views you can use TSIG to select the correct view and hence zone
instance, to
deliver the NOTIFY to.
> On 9 Jan 2024, at 14:40, Nick Tait via bind-users
> wrote:
>
> Hi list.
> I've been trying to understand whether it is necessary for the NOTIFY request
> (i.e. sent from primary to secondary server) to use TSIG, in the case where
> the secondary server specifies a key in its zone's "primaries" option?
> For example, assume the following set-up:
> The primary server (192.0.2.1) specifies the following configuration:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type primary;
> file "/etc/bind/db.example.com";
> notify yes;
> allow-transfer { key "secret-key.example.com"; };
> };
>
> And the secondary server (192.0.2.2) specifies:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type secondary;
> file "db.example.com";
> primaries { 192.0.2.1 key "secret-key.example.com"; };
> notify no;
> };
>
> And if the zone file db.example.com (on the primary server) contained:
> $TTL 3600
> @ IN SOA server1 root.server1 1 86400 7200 2419200 1800
> @ IN NS server1
> @ IN NS server2
> server1 IN A 192.0.2.1
> server2 IN A 192.0.2.2
>
> In this case when the zone is changed on the primary server, it will send an
> unsigned NOTIFY to the secondary server. The question I was trying to answer
> was: With the configuration above, will the secondary server accept the
> unsigned notification?
> I was hoping to find an RFC that answered this question, but didn't have any
> luck Googling. However the BIND documentation for "allow-notify"
> (https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify)
> contains the following text:
> allow-notify
> ...
> Defines an address_match_list that is allowed to send NOTIFY messages for the
> zone, in addition to addresses defined in the primaries option for the zone.
> ...
> If not specified, the default is to process NOTIFY messages only from the
> configured primaries for the zone. allow-notify can be used to expand the
> list of permitted hosts, not to reduce it.
> My interpretation of the above was that if a key is specified in the
> "primaries" option, then the secondary would require the NOTIFY to be signed
> by the same key? However when I tested this theory, I found the secondary did
> accept (and process) the unsigned NOTIFY.
> While I understand (and agree) that this behaviour makes the most sense,
> given my confusion based on the documentation, I wonder if the documentation
> could be made clearer? E.g. Add the sentence: "In the case where the
> primaries option specifies a TSIG key, it is not necessary for the received
> NOTIFY to be signed by the same key."
> Thanks,
> Nick.
> --
> 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: dnssec-key 'unknown algorithm RSASHA512'
Firstly show what you are actually doing. It it too much for you to actually cut-and-paste what you are doing? Secondly BIND 9.18 is at 9.18.22. Version 9.18.8 is seriously out of date. > On 11 Jan 2024, at 15:21, pvs via bind-users wrote: > > Hello, > > I'm using ubuntu 22.04 server on which bind 9.18.8 service is running. > I'm trying to generate dnssec-key by using the command "dnssec-keygen -a > RSASHA512 -b 2048 -n zone example.com" > > After doing this, it is generating both public key and private key. When I > generate a file with aprivate key in /etc/bind directory, it is throwing > error 'unknown algorithm 'RSASHA512' > Same error is thrown when tried with other algorithms like ECDSAP256SHA256, > RSASHA1, RSASHA256 etc > Any help is greatly appreciated. > > -- > Regards, > > पं. विष्णु शंकर P. Vishnu Sankar > टीम लीडर Team Leader-Network Operations > सी-डॉट C-DOT > इलैक्ट्रॉनिक्स सिटी फेज़ I Electronics City Phase I > होसूर रोड बेंगलूरु Hosur Road Bengaluru – 560100 > फोन Ph 91 80 25119466 > -- > Disclaimer : > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you are not the intended recipient you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents of > this information is strictly prohibited. > The sender does not accept liability for any errors or omissions in the > contents of this message, which arise as a result. > -- > 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: Question about authoritative server and AA Authoritative Answer
> On 15 Jan 2024, at 09:04, Michel Diemer via bind-users > wrote: > > Ders bind users, > > I have already asked a similar question which was more about DNS in general , > this one is very specific about the AA bit. > > Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig > pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing > ? If possible, how to get AA answers for QNAME queries ? » The difference is because you have positive and negative answers. The authority section has information about how long the negative response can be cached for. See RFC 2308. As for AA ask the authoritative server rather than the recursive server. See RFC 1035. Also see the examples where AA is set in RFC 1034 and their descriptions. AA Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. Note that the contents of the answer section may have multiple owner names because of aliases. The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section. > I have set up two virtual machines on a virtual local network using Oracle > VirtualBox. One machine is a DNS authoritative-only server. The zone is named > "reseau1.lan" and defined only in bind9 zone files. If I really have to, I > will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan > inspired by RFC 6762 appendix G). The IP address of the DNS server is > 172.16.0.254 and the IP address of pc1 is 172.16.0.21. > dig soa reseau1.lan : the AA bit is set, which is what I am looking for > > <540085300119embeddedImage.png>͏ ͏ ͏ > > dig pc1.reseau1.lan ns : the AA bit is set > > <620630300119embeddedImage.png>͏ ͏ ͏ ͏ > > dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge > am I missing ? > > <8504625embeddedImage.png> > > Below my "named.conf.options" file > > <1311990100238embeddedImage.png>͏ > > > ͏ ͏ ͏ ͏ > -- > 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: Question about authoritative server and AA Authoritative Answer
> On 16 Jan 2024, at 02:32, pub.dieme...@laposte.net wrote: > > > > Dear Mark, > > I am sorry but I don'y understand you reply. > > > RFC 1034, § 6.2.2 the AA bit is set. > I have a non-recursive authoritative server and the AA bit is not set. My > example is similar to RFC 1034. Why, on the RFC the AA bit is set but not on > my example ? Because you were not querying the authoritative server, you where querying the recursive server in the screen shots. When you queried the authoritative server (see dns-authoritative-question.md) you got AA in the response. The answers from the recursive server: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 vs the answers from the authoritative server: ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > On my screenshots, where do you see negative answers ? The ones where the answer count was zero (look for "ANSWER: 0,”). > De : "Mark Andrews" > A : pub.dieme...@laposte.net,"bind users" > Envoyé: dimanche 14 Janvier 2024 23:54 > Objet : Re: Question about authoritative server and AA Authoritative Answer > > > > On 15 Jan 2024, at 09:04, Michel Diemer via bind-users wrote: > > > > Ders bind users, > > > > I have already asked a similar question which was more about DNS in general > > , this one is very specific about the AA bit. > > > > Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig > > pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I > > missing ? If possible, how to get AA answers for QNAME queries ? » > > The difference is because you have positive and negative answers. The > authority section has information about how long the negative response can be > cached for. See RFC 2308. > > As for AA ask the authoritative server rather than the recursive server. See > RFC 1035. Also see the examples where AA is set in RFC 1034 and their > descriptions. > > AA Authoritative Answer - this bit is valid in responses, > and specifies that the responding name server is an > authority for the domain name in question section. > > Note that the contents of the answer section may have > multiple owner names because of aliases. The AA bit > corresponds to the name which matches the query name, or > the first owner name in the answer section. > > > > I have set up two virtual machines on a virtual local network using Oracle > > VirtualBox. One machine is a DNS authoritative-only server. The zone is > > named "reseau1.lan" and defined only in bind9 zone files. If I really have > > to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan > > inspired by RFC 6762 appendix G). The IP address of the DNS server is > > 172.16.0.254 and the IP address of pc1 is 172.16.0.21. > > > > dig soa reseau1.lan : the AA bit is set, which is what I am looking for > > > > <540085300119embeddedImage.png>͏ ͏ ͏ > > > > dig pc1.reseau1.lan ns : the AA bit is set > > > > <620630300119embeddedImage.png>͏ ͏ ͏ ͏ > > > > dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or > > knowledge am I missing ? > > > > <8504625embeddedImage.png> > > > > Below my "named.conf.options" file > > > > <1311990100238embeddedImage.png>͏ > > > > > > ͏ ͏ ͏ ͏ > > -- > > 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 > -- 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: [Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
> On 22 Jan 2024, at 12:26, Ted Mittelstaedt wrote: > > Yes, this bug can be fixed. > > Just find a software developer and pay him some money. Or fix it yourself, > you have the code. > > I suppose ISC does not want you to buy a paid support subscription to fix > this one but maybe they do, you could try contacting them. > > Oh, wait. You must be wanting this fixed for FREE. Gotcha! > > Perhaps a review of what the point of Open Source software is might be in > order? > > Ted And it looks like the fix will be to replace the GetNetworkParams call with GetAdaptersAddresses in lib/irs/win32/resconf.c and go from there to get the DNS server addresses. Gentry you may also want to look in SYSTEM\\CurrentControlSet\\Services\\Tcpip6\\Parameters as well as SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters for the search list. https://learn.microsoft.com/en-au/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses Mark > On 1/8/2024 9:41 AM, Gentry Deng via bind-users wrote: >> Hello there, >> >> >> Due to an accident my local network is missing IPv4 DNS but has IPv6 DNS so >> it has little impact on accessing the internet. >> >> But I found that neither `dig `nor `nslookup` worked, and reported an error: >> >> >> ``` >> >> C:\Program Files\ISC BIND 9\bin\dig.exe: parse of C:\Program Files\ISC BIND >> 9\etc\resolv.conf failed >> >> ``` >> >> >> There is actually no "resolv.conf" there, they get the DNS from the system >> and if IPv4 DNS is missing it will throw an error. Creating "resolv.conf" >> manually also does not prevent the problem. >> >> I noticed that version 9.16 is about to be EOL. I wonder if this BUG can be >> fixed before EOL? After all, this is the only version of BIND 9 that still >> supports the Windows platform. >> >> >> Best regards, >> >> Gentry >> > -- > 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: FORMERR-Format error issue
The nameservers for members.nmar.com are broken. They are returning 2 CNAME records when only 1 is allowed. The are also returning a referral to the root servers. Referrals to the root servers after following CNAMEs are supposed to have gone the way of the dodo. Multiple CNAMEs have never been allowed. Just because Google accepts broken responses, it doesn’t make them correct. Mark % dig members.nmar.com +norec @ns2.hover.com ; <<>> DiG 9.19.20-dev <<>> members.nmar.com +norec @ns2.hover.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51358 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;members.nmar.com. IN A ;; ANSWER SECTION: members.nmar.com. 900 IN CNAME public.west.us.memberzone.org. members.nmar.com. 900 IN CNAME public.east.us.memberzone.org. ;; AUTHORITY SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ;; Query time: 219 msec ;; SERVER: 64.98.148.13#53(ns2.hover.com) (UDP) ;; WHEN: Thu Feb 01 16:35:45 AEDT 2024 ;; MSG SIZE rcvd: 314 % > On 1 Feb 2024, at 16:27, Scott Richardson wrote: > > Hello, > > -I have been troubleshooting a format error in BIND 9 for about a week at > this point. > > -The symptoms: > > -I am unable to resolve members.nmar.com. > > -The nslookup output from a client to OUR private recursive DNS server is as > follows: > >> members.nmar.com > Server: [100.101.0.10] > Address: 100.101.0.10 > > *** [100.101.0.10] can't find members.nmar.com: Server failed > > -Our DNS server log output follows: > > Jan 26 13:48:00 dns1 named[1609]: FORMERR resolving 'members.nmar.com/A/IN': > 216.40.47.26#53 > Jan 26 13:48:00 dns1 named[1609]: FORMERR resolving 'members.nmar.com/A/IN': > 64.98.148.13#53 > > -It works with Cloudfare and Goole however: > >> server 8.8.8.8 > Default Server: dns.google > Address: 8.8.8.8 > >> members.nmar.com > Server: dns.google > Address: 8.8.8.8 > > Non-authoritative answer: > Name:public.west.us.memberzone.org > Address: 172.170.249.2 > Aliases: members.nmar.com > > -If I dig this from one of our other server it fails as well unless I add the > +norec option which DOES work. > > -If I perform an nslookup to their authoritative DNS servers I get a referral > to the root name server list: > > Server: ns1.hover.com > Address: 216.40.47.26 > > Name:nmar.com > Address: 20.25.91.29 > >> members.nmar.com > Server: ns1.hover.com > Address: 216.40.47.26 > > Non-authoritative answer: > Non-authoritative answer: > Name:members.nmar.com > Served by: > - a.root-servers.net > > > - b.root-servers.net > > > - c.root-servers.net > > > - d.root-servers.net > > > - e.root-servers.net > > > - f.root-servers.net > > > - g.root-servers.net > > > - h.root-servers.net > > > - i.root-servers.net > > > - j.root-servers.net > > -I am not sure if this is an issue with us or them or I need to adjust my > configuration somehow to accommodate a problem on their server. I am not > sure why other DNS is working but ours is failing. > > -This is tested with our server firewall disabled. > > -I have disabled firewall rules within our network to confirm NO firewall > issues are causing this. > > -I have checked the DNS with our upstream and they are resolving this url > correctly; therefore I don't suspect firewall issues within their network. > > -We are not using IPV6 at all at this time. > > -This is occurring with both of our redundant DNS servers and I fired up a > test server with Bind 9.16 and it is giving me the same result. > > -Any thoughts or suggestions would be very helpful and much appreciated! > > Regards, > > > Scott > -- > 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: Non-improving referral
You have your answer. Update the parent zone.
--
Mark Andrews
> On 4 Feb 2024, at 18:27, Gabi Nakibly wrote:
>
>
> Hi,
> I would like to set up a new temporary nameserver for my zone (say
> 'example.com'), however for various reasons I prefer not to change the
> delegation of my parent zone ('.com'). So I need the current name server
> ('ns.example.com') to refer resolvers to my new temporary name server
> ('ns-temp.example.com'). However, when I tried to test this set-up with a
> BIND resolver, when the resolver got the delegation to the temporary name
> server it failed with 'non-improving referral'.
> How can I resolve this so the delegation will work for a BIND resolver having
> default config (or with any other resolver for that matter)? I know that I
> can simply update delegation at the parent zone to point directly to the new
> name server, but I prefer not to do this right now and I am looking for ways
> to do this without changing the parent delegation.
> --
> 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: Value of a DNSSEC validating resolver
Do the analysis where the resolver is under attack or the auth server with the best rtt is stale. -- Mark Andrews > On 9 Feb 2024, at 21:40, Petr Menšík wrote: > > Hello Mark, > > allow me here to correct your statement. We spent in Red Hat some time > thinking and testing validating clients. Validating resolver is *not* > necessary for validating clients to work. They are better and recommended, > but not always necessary. > > What is required is dnssec (security) awareness. Meaning that resolver will > fetch signatures for all queries with do=1 bit set. For example even dnsmasq > in default configuration will forward DNSSEC signatures to all DNSSEC enabled > queries. Also in cases dnssec validation is not enabled in it. It is not > strictly required fetching them for do=0 queries. > > For example our office resolvers do not have validation enabled. But they > allow any clients using dnssec-trigger to validate all queries themselves. > And that works for majority of existing DNS caches. > > What is required from bind9 is to have dnssec-enabled yes; That was default > even in 9.11 and this is the last version, where it is possible to change it > to dnssec-enabled no; Since 9.16 it is not possible to configure it that way. > In this case any validating client, be it end station or dns forwarder, will > fail all queries sent to it. Clients can validate regardless > dnssec-validation value is used, but they need do=1 answers to their do=1 > queries. > > Following chain of forwarders will still deliver non-bogus answers only. fwd > means forwarder only, not using root hints. > > [root-servers]---[non-validating iterative][non-validating > fwd]---[validating fwd]--->(secure or unsigned answers only) > > Validating client can refuse answer to dnssec-failed.org, even if the > recursive forwarder it is using did not check its validity. If it sends you > do=1 enabled answers, that is enough. You have to compute your own SERVFAIL > result, which validating upstream forwarder could have sent you straight > away. That that is the beauty of DNSSEC. Not everyone in the chain needs to > be doing crypto operations. But everyone in the chain can, as long as crypto > records are included. > > delv +vtrace or unbound-host -rvD commands work even on non-validating, but > security aware resolvers. > > And to answer original question. You store in cache only valuable records, > not bogus garbage. Having cache filled also with signatures makes validation > of your clients much faster, just RTT between you is used, even when they > validate. > > Regards, > Petr > >> On 12/1/23 22:40, Mark Andrews wrote: >> A validating resolver is a prerequisite for validating clients to work. >> Clients don’t have direct access to the authoritative servers so the can’t >> retrieve good answers if the recursive servers don’t filter out the bad >> answers. >> >> Think of a recursive server as a town water treatment plant. You could >> filter and treat at every house and sometimes you still do like boiling >> water for baby formula but on the most part what you get out of it is good >> enough for consumption as is. >> >> -- >> Mark Andrews >> >>>> On 2 Dec 2023, at 08:14, John Thurston wrote: >>> >>> >>> >>> At first glance, the concept of a validating resolver seemed like a good >>> idea. But in practice, it is turning out to be a hassle. >>> >>> I'm starting to think, "If my clients want their answers validated, they >>> should do it." If they *really* care about the quality of the answers they >>> get, why should my clients be trusting *me* to validate them? >>> >>> Can someone make a good case to me for continuing to perform DNSSEC >>> validation on my central resolvers? >>> >>> -- >>> -- >>> Do things because you should, not just because you can. >>> >>> John Thurston907-465-8591 >>> john.thurs...@alaska.gov >>> Department of Administration >>> State of Alaska > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > OpenPGP_0x4931CA5B6C9FC5CB.asc Description: Binary data > -- > 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 OpenPGP_signature.asc Description: Binary data -- 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: Value of a DNSSEC validating resolver
-- Mark Andrews > On 10 Feb 2024, at 04:18, Randy Bush wrote: > > >> >> I admit here we most often work with internal only forwarders, which >> are not accessible from outer internet. So those won't be under attack > > i am always impressed by security optiism > > randy -- 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: Value of a DNSSEC validating resolver
> On 9 Feb 2024, at 21:40, Petr Menšík wrote: > > Hello Mark, > > allow me here to correct your statement. We spent in Red Hat some time > thinking and testing validating clients. Validating resolver is *not* > necessary for validating clients to work. They are better and recommended, > but not always necessary. > > What is required is dnssec (security) awareness. Meaning that resolver will > fetch signatures for all queries with do=1 bit set. For example even dnsmasq > in default configuration will forward DNSSEC signatures to all DNSSEC enabled > queries. Also in cases dnssec validation is not enabled in it. It is not > strictly required fetching them for do=0 queries. > > For example our office resolvers do not have validation enabled. But they > allow any clients using dnssec-trigger to validate all queries themselves. > And that works for majority of existing DNS caches. > > What is required from bind9 is to have dnssec-enabled yes; That was default > even in 9.11 and this is the last version, where it is possible to change it > to dnssec-enabled no; Since 9.16 it is not possible to configure it that way. > In this case any validating client, be it end station or dns forwarder, will > fail all queries sent to it. Clients can validate regardless > dnssec-validation value is used, but they need do=1 answers to their do=1 > queries. > > Following chain of forwarders will still deliver non-bogus answers only. fwd > means forwarder only, not using root hints. > > [root-servers]---[non-validating iterative][non-validating > fwd]---[validating fwd]--->(secure or unsigned answers only) > > Validating client can refuse answer to dnssec-failed.org, even if the > recursive forwarder it is using did not check its validity. If it sends you > do=1 enabled answers, that is enough. You have to compute your own SERVFAIL > result, which validating upstream forwarder could have sent you straight > away. That that is the beauty of DNSSEC. Not everyone in the chain needs to > be doing crypto operations. But everyone in the chain can, as long as crypto > records are included. > > delv +vtrace or unbound-host -rvD commands work even on non-validating, but > security aware resolvers. > > And to answer original question. You store in cache only valuable records, > not bogus garbage. Having cache filled also with signatures makes validation > of your clients much faster, just RTT between you is used, even when they > validate. Your diagram has a "non-validating iterative”. How does that machine meet the requirement of "You store in cache only valuable records, not bogus garbage.” if it does not validate? Sure this chain will appear to work until it doesn’t. All it requires is 1 "bad answer" to be learnt by that first server and responses that should succeed, won’t. If you change the chain to [auth-servers]---[validating iterative][non-validating fwd]---[validating fwd]--->(secure or unsigned answers only) and have secure paths to the right of the "validating iterative” things will work. The "validating iterative” server is supposed to discard bogus responses which allows it to filter out the garbage. If you then say always set “CD=1” the validating intermediaries stop preforming that role which is why I objected to that being specified. Setup 3 auth servers with signature that have a validity interval of 2 weeks, one of which has up to date signatures and 2 that have out of date signatures. This is the sort of thing that happens out there by accident, e.g. unnoticed zone transfers failing and the zone has not yet expired. Try looking up multiple answers from that zone with your configuration and then with mine. > Regards, > Petr > > On 12/1/23 22:40, Mark Andrews wrote: >> A validating resolver is a prerequisite for validating clients to work. >> Clients don’t have direct access to the authoritative servers so the can’t >> retrieve good answers if the recursive servers don’t filter out the bad >> answers. >> >> Think of a recursive server as a town water treatment plant. You could >> filter and treat at every house and sometimes you still do like boiling >> water for baby formula but on the most part what you get out of it is good >> enough for consumption as is. >> >> -- >> Mark Andrews >> >>> On 2 Dec 2023, at 08:14, John Thurston wrote: >>> >>> >>> >>> At first glance, the concept of a validating resolver seemed like a good >>> idea. But in practice, it is turning out to be a hassle. >>> >>> I'm starting to think, "If my clients want their answers validated, they >>> should d
Re: Answers from subzone even when superzone has a delegation elsewhere
Additionally this behaviour is specified in RFC1034 so every nameserver should do this. -- Mark Andrews > On 14 Feb 2024, at 02:24, Friesen, Don CITZ:EX via bind-users > wrote: > > Andy, > The existence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa as an > authoritative zone on the server has higher relevance than the delegation > inside another zone. The answer comes from the authoritative zone, no need > to follow the delegation. > > Don Friesen > > -Original Message- > From: bind-users On Behalf Of Andy Smith > Sent: Tuesday, February 13, 2024 6:46 AM > To: bind-users@lists.isc.org > Subject: Re: Answers from subzone even when superzone has a delegation > elsewhere > > [You don't often get email from a...@strugglers.net. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > [EXTERNAL] This email came from an external source. Only open attachments or > links that you are expecting from a known sender. > > > Hi Don, > > Yes. > > If you want actual names to look at, these zones are both present on the same > servers: > >1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa > 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa > > However, the presence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is a > mistake and in the mean time someone has changed the delegation inside > 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa to be: > > 8.f.0.f NS ns-auto.bitfolk.com. > > A query for, say: > > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa. IN > PTR > > is answered NXDOMAIN because it does not exist inside the > 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa zone file, instead of following that > delegation to ns-auto.bitfolk.com. > > Thanks, > Andy > >> On Tue, Feb 13, 2024 at 02:31:32PM +, Friesen, Don CITZ:EX via >> bind-users wrote: >> Andy, You do also have the A record glue for elsewhere.example.com in the >> example.com zone, right? Just checking. >> >> Don Friesen > -- > 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 -- 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: dns_diff_apply / "del not exact" logging
Transfer from a single address. The IXFR transfer is detecting that a record is being asked to be deleted but it is not present in the zone. Named will fallback to an AXFR. The logs have been extended recently to provide more details. -- Mark Andrews > On 14 Feb 2024, at 18:41, Andreas S. Kerber via bind-users > wrote: > > Hi, > > since upgrading our secondary to 9.18.24 yesterday, I'm seeing the logging > messages below. > > 14-Feb-2024 07:52:24.850 general: error: dns_diff_apply: > wur1-ps003.ad01.geXXX/A/IN: del not exact > 14-Feb-2024 07:53:28.732 general: error: dns_diff_apply: > 1.0.e.4.1.1.0.0.2.ip6.arpa/SOA/IN: del not exact > 14-Feb-2024 07:54:03.827 general: error: dns_diff_apply: > ad01.idkXXX/RRSIG/IN: del not exact > 14-Feb-2024 08:05:18.363 general: error: dns_diff_apply: > HRO1-NB041.ad01.geXXX/A/IN: del not exact > 14-Feb-2024 08:07:25.346 general: error: dns_diff_apply: > lc7a5c2o2ur6umdqkvijckprpj74g6qr.ad01.idXXX/RRSIG/IN: del not exact > 14-Feb-2024 08:17:58.873 general: error: dns_diff_apply: > HRO1-NB002.ad01.geXXX/A/IN: del not exact > 14-Feb-2024 08:18:34.160 general: error: dns_diff_apply: > FUS1-MPC120.ad01.chXXX/A/IN: del not exact > > The zone names mentioned are anonymized by me. primary of each zone is some > kind of windows server. > Is this something to worry about? This kind of logging popped up since > upgrading the secondary to 9.18.24. > > -- > 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: KeyTrap fix breaks resolving semi-bogus paste.debian.net/snow-crash.org
Well if you are attacking the resolver by sending invalid RRSIGs ... > On 15 Feb 2024, at 11:15, Matt Nordhoff via bind-users > wrote: > > Hello, > > I'm not sure if this is a bug or a feature, but the recent CVE fixes > prevent resolving paste.debian.net with DNSSEC validation on. > > It is a CNAME: > > $ dig +short paste.debian.net > apu.snow-crash.org. > p.snow-crash.org. > 148.251.236.38 > > debian.net is fine, but snow-crash.org is misconfigured: It has an > algorithm 13 DS record, is correctly signed with algorithm 13, but is > also signed using algorithm 8 with signatures that expired a year > ago(!). > > <https://dnsviz.net/d/paste.debian.net/ZczXYw/dnssec/> > > Other resolvers, and older versions of BIND, ignore the bad/irrelevant > signatures and can still resolve the zone. > > With the recent CVE fixes, BIND sees the expired RRSIGs, decides it's > bogus, logs the below, and returns SERVFAIL. I imagine it hits > max-validation-failures-per-fetch or some internal limit. > > named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to > bad signature (keyid=41523): RRSIG has expired > named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found > named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': > 37.120.176.165#53 > named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to > bad signature (keyid=41523): RRSIG has expired > named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found > named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': > 148.251.236.38#53 > named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to > bad signature (keyid=41523): RRSIG has expired > named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found > named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': > 2a01:4f8:201:3437::2#53 > > snow-crash.org is clearly misconfigured, but resolvers usually succeed > when they encounter both valid and invalid DNSSEC signatures. And this > domain has no algorithm 8 DS records at all, so the signatures and > keys can be ignored entirely. > > Regarding DoS attacks, a resolver can ignore signatures that are > expired or use algorithms not included in the DS record without any > expensive cryptography. But that requires actually having the DS RRset at the time of the verification of the RRset/RRSIG. > I'm not necessarily saying this is a bug, but it might be an > interesting data point regarding the experimental new limits, and you > might want to consider changing the default or the accounting. > > I noticed the issue using Quad9's 9.9.9.11 DNS resolver, and then > reproduced it on an Ubuntu 23.10 (amd64) VM by installing Ubuntu's > bind9 1:9.18.18-0ubuntu2 package with the default configuration and > then upgrading it to 1:9.18.18-0ubuntu2.1. > > Some copy-and-pasted information at > <https://gist.github.com/mnordhoff/9286a264633fc12a262213a8d389f517>. > (Since I couldn't use <https://paste.debian.net/>...) > > (I also did/will tell Quad9 about it for their information.) > > Cheers, > -- > Matt Nordhoff > -- > 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: KeyTrap fix breaks resolving semi-bogus paste.debian.net/snow-crash.org
To put more detail on this the DS is *only* used to verify the DNSKEY RRset. As long as that returns trusted *every* DNSKEY in that RRset is valid for verifying the rest of the zone. There is NO requirement to look at the DS RRset when verifying anything other than the DNSKEY RRset. TA -> DNSKEY -> DS -> DNSKEY -> DS -> DNSKEY -> data Any of those RRsets can have expired from the cache when data is being verified. Only the final DNSKEY RRset is required to be present and to have been marked as trusted. Now DNS_R_SIGFUTURE and DNS_R_SIGEXPIRED are detected before any crypto is performed so it wouldn’t be too expensive to skip to the next RRSIG on those error codes but really you shouldn’t be publishing broken RRSIGs. Mark > On 15 Feb 2024, at 11:25, Mark Andrews wrote: > > Well if you are attacking the resolver by sending invalid RRSIGs ... > >> On 15 Feb 2024, at 11:15, Matt Nordhoff via bind-users >> wrote: >> >> Hello, >> >> I'm not sure if this is a bug or a feature, but the recent CVE fixes >> prevent resolving paste.debian.net with DNSSEC validation on. >> >> It is a CNAME: >> >> $ dig +short paste.debian.net >> apu.snow-crash.org. >> p.snow-crash.org. >> 148.251.236.38 >> >> debian.net is fine, but snow-crash.org is misconfigured: It has an >> algorithm 13 DS record, is correctly signed with algorithm 13, but is >> also signed using algorithm 8 with signatures that expired a year >> ago(!). >> >> <https://dnsviz.net/d/paste.debian.net/ZczXYw/dnssec/> >> >> Other resolvers, and older versions of BIND, ignore the bad/irrelevant >> signatures and can still resolve the zone. >> >> With the recent CVE fixes, BIND sees the expired RRSIGs, decides it's >> bogus, logs the below, and returns SERVFAIL. I imagine it hits >> max-validation-failures-per-fetch or some internal limit. >> >> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to >> bad signature (keyid=41523): RRSIG has expired >> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found >> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': >> 37.120.176.165#53 >> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to >> bad signature (keyid=41523): RRSIG has expired >> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found >> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': >> 148.251.236.38#53 >> named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to >> bad signature (keyid=41523): RRSIG has expired >> named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found >> named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN': >> 2a01:4f8:201:3437::2#53 >> >> snow-crash.org is clearly misconfigured, but resolvers usually succeed >> when they encounter both valid and invalid DNSSEC signatures. And this >> domain has no algorithm 8 DS records at all, so the signatures and >> keys can be ignored entirely. >> >> Regarding DoS attacks, a resolver can ignore signatures that are >> expired or use algorithms not included in the DS record without any >> expensive cryptography. > > But that requires actually having the DS RRset at the time of the > verification of the RRset/RRSIG. > >> I'm not necessarily saying this is a bug, but it might be an >> interesting data point regarding the experimental new limits, and you >> might want to consider changing the default or the accounting. >> >> I noticed the issue using Quad9's 9.9.9.11 DNS resolver, and then >> reproduced it on an Ubuntu 23.10 (amd64) VM by installing Ubuntu's >> bind9 1:9.18.18-0ubuntu2 package with the default configuration and >> then upgrading it to 1:9.18.18-0ubuntu2.1. >> >> Some copy-and-pasted information at >> <https://gist.github.com/mnordhoff/9286a264633fc12a262213a8d389f517>. >> (Since I couldn't use <https://paste.debian.net/>...) >> >> (I also did/will tell Quad9 about it for their information.) >> >> Cheers, >> -- >> Matt Nordhoff >> -- >> 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: opendnssec -> inline-signing
You DS and DNSKEY rrset are not matched. You need to publish the DS for the DNSKEY with key tag 3463. rg.net. 86256 IN DS 12391 8 2 0FB5F11E4FE4045D519A55915BD71D6DCFB1FA045B01BE891640C8EA 1C0792C9 rg.net. 3463 IN DNSKEY 256 3 8 ( AwEAAa4acpL+7ohA/vCtwkn4nWtiPxfnWlIpsvaJ8TdV OXZMetCE1l/iSlBHJT/QQQzC4UJxqendMOhM+8i2jMkd tkRqgZUGrEZNbAwVWbsLkP6zpbEvRNrPDW6CnGcIedXB KWqEYtYRb+iC2YhQxwHpd1mQygWwVbJglrujaj1zHcm2 y8jR9h/Y4a2dfImBMHt8kI1xl6phgncWv/GzpzgRUpid bdx35BGvK09Qa0AxZs35/hTaxgJZq0JW7tOH4jPip/B0 ZSYPXRjfqOorbn+HcIjTEtTRnLuo+RBa1MX25HYrH9Ad kErOCyWn71sx65L7rySB3iByz67VmA3kW0Qypp8= ) ; ZSK; alg = RSASHA256 ; key id = 43431 rg.net. 3463 IN DNSKEY 257 3 8 ( AwEAAeW0TsiLDw6VI9rcKCLnKFFVUAznLJEKR2OUExVa 4n8v5f2lysPYdz/JMl7mqZorSM9ncYRpUmaTzxt5n5XU dh5qTJcmDZvJRXdDBfBezcXM2Cs+bTxlK/KW/i3CCC0p g2a6VM4clWFSxw8ZlU2oNslsrw0XbxqIh96WP0jJsAko 26ACyYdsscZglGUgmyHFxPM2UmKAsk/ABgL8WTrYCg05 6FDmKT/hTWpZckJu5CekJEq5y+qNGCdqa+j4xY56f0ag 8cODW89yRPlMrw6Fr8nCLef1B6gRYN9MFU8RUY0hMy3b s62aB8A25ZRwYTH+3x/W4mNs0DLctSBZaEZnJGs= ) ; KSK; alg = RSASHA256 ; key id = 30790 rg.net. 3463 IN RRSIG DNSKEY 8 2 3600 ( 20240321203948 20240307193948 30790 rg.net. OYKcahhMUXRDMicqgFAQBGN6I6qNVwiEnWeMtWhn5t8l 8x8lSs29rJA9GTjfJurA8wt1IrxZftB9bO/11QL3zcd4 OyCWx6sgJUxsqgrV9HbLVYFIA7ZNLfrTHd3ZELv+WjFl LwpXwF8PLvguozEsggbO4+8yEnBMBB2H4yEovoZSJgmD ufApZJ2xwy/EaWUlOfSTUZiFpgKgUaSEkGJb96EbAKts kMKIpm4SWlrVobSCrbv/KF6/a8+8Wtj0tY7mgjPbREDd liaN92BRsQO0ykBep+HxH85CXPhqBMnl2Z43guX2t+QZ B36h61FrpFOt7RUnvJ8Pn3Rz+kx1VVOIsw== ) > On 8 Mar 2024, at 10:35, Randy Bush wrote: > > FreeBSD 13.2-RELEASE-p10 amd64 > bind 9.16.48 > softhsm-1.3.8 (yes, i know) > opendnssec 2.1.13 > moon in klutz > > been running opendnssec, and trying to move to bind inline-signing > > in the hope of making it more readable, the sad story is at > https://git.rg.net/randy/randy/src/master/scratch.md > > thanks for any clues > > randy > -- > 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: opendnssec -> inline-signing
> On 8 Mar 2024, at 10:54, Randy Bush wrote: > >> You DS and DNSKEY rrset are not matched. You >> need to publish the DS for the DNSKEY with key >> tag 3463. >> >> rg.net. 86256 IN DS 12391 8 2 >> 0FB5F11E4FE4045D519A55915BD71D6DCFB1FA045B01BE891640C8EA 1C0792C9 >> >> rg.net. 3463 IN DNSKEY 256 3 8 ( >> AwEAAa4acpL+7ohA/vCtwkn4nWtiPxfnWlIpsvaJ8TdV >> OXZMetCE1l/iSlBHJT/QQQzC4UJxqendMOhM+8i2jMkd >> tkRqgZUGrEZNbAwVWbsLkP6zpbEvRNrPDW6CnGcIedXB >> KWqEYtYRb+iC2YhQxwHpd1mQygWwVbJglrujaj1zHcm2 >> y8jR9h/Y4a2dfImBMHt8kI1xl6phgncWv/GzpzgRUpid >> bdx35BGvK09Qa0AxZs35/hTaxgJZq0JW7tOH4jPip/B0 >> ZSYPXRjfqOorbn+HcIjTEtTRnLuo+RBa1MX25HYrH9Ad >> kErOCyWn71sx65L7rySB3iByz67VmA3kW0Qypp8= >> ) ; ZSK; alg = RSASHA256 ; key id = 43431 >> rg.net. 3463 IN DNSKEY 257 3 8 ( >> AwEAAeW0TsiLDw6VI9rcKCLnKFFVUAznLJEKR2OUExVa >> 4n8v5f2lysPYdz/JMl7mqZorSM9ncYRpUmaTzxt5n5XU >> dh5qTJcmDZvJRXdDBfBezcXM2Cs+bTxlK/KW/i3CCC0p >> g2a6VM4clWFSxw8ZlU2oNslsrw0XbxqIh96WP0jJsAko >> 26ACyYdsscZglGUgmyHFxPM2UmKAsk/ABgL8WTrYCg05 >> 6FDmKT/hTWpZckJu5CekJEq5y+qNGCdqa+j4xY56f0ag >> 8cODW89yRPlMrw6Fr8nCLef1B6gRYN9MFU8RUY0hMy3b >> s62aB8A25ZRwYTH+3x/W4mNs0DLctSBZaEZnJGs= >> ) ; KSK; alg = RSASHA256 ; key id = 30790 >> rg.net. 3463 IN RRSIG DNSKEY 8 2 3600 ( >> 20240321203948 20240307193948 30790 rg.net. >> OYKcahhMUXRDMicqgFAQBGN6I6qNVwiEnWeMtWhn5t8l >> 8x8lSs29rJA9GTjfJurA8wt1IrxZftB9bO/11QL3zcd4 >> OyCWx6sgJUxsqgrV9HbLVYFIA7ZNLfrTHd3ZELv+WjFl >> LwpXwF8PLvguozEsggbO4+8yEnBMBB2H4yEovoZSJgmD >> ufApZJ2xwy/EaWUlOfSTUZiFpgKgUaSEkGJb96EbAKts >> kMKIpm4SWlrVobSCrbv/KF6/a8+8Wtj0tY7mgjPbREDd >> liaN92BRsQO0ykBep+HxH85CXPhqBMnl2Z43guX2t+QZ >> B36h61FrpFOt7RUnvJ8Pn3Rz+kx1VVOIsw== ) >> >>> https://git.rg.net/randy/randy/src/master/scratch.md > > yes, we can see that, as we noted. and yes we could rekey 42 zones at > the parents; great fun. > > but WHY NOT? same key sets with opendnssec and inline-signing, we > think. > > randy I can’t get to https://git.rg.net/randy/randy/src/master/scratch.md without installing a negative trust anchor or you fixing/removing the DS. -- 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: opendnssec -> inline-signing
Please read https://kb.isc.org/docs/dnssec-key-and-signing-policy especially the steps to do when migrating to using dnssec-policy with an existing signed zone. Start with "lifetime unlimited”. Tell named which keys have DS already published using rndc. You can also use dnssec-settime to do this. Once your existing keys are omnipresent you can update the lifetime to what you want to run with. On 8 Mar 2024, at 10:57, Mark Andrews wrote: > > > >> On 8 Mar 2024, at 10:54, Randy Bush wrote: >> >>> You DS and DNSKEY rrset are not matched. You >>> need to publish the DS for the DNSKEY with key >>> tag 3463. >>> >>> rg.net. 86256 IN DS 12391 8 2 >>> 0FB5F11E4FE4045D519A55915BD71D6DCFB1FA045B01BE891640C8EA 1C0792C9 >>> >>> rg.net. 3463 IN DNSKEY 256 3 8 ( >>> AwEAAa4acpL+7ohA/vCtwkn4nWtiPxfnWlIpsvaJ8TdV >>> OXZMetCE1l/iSlBHJT/QQQzC4UJxqendMOhM+8i2jMkd >>> tkRqgZUGrEZNbAwVWbsLkP6zpbEvRNrPDW6CnGcIedXB >>> KWqEYtYRb+iC2YhQxwHpd1mQygWwVbJglrujaj1zHcm2 >>> y8jR9h/Y4a2dfImBMHt8kI1xl6phgncWv/GzpzgRUpid >>> bdx35BGvK09Qa0AxZs35/hTaxgJZq0JW7tOH4jPip/B0 >>> ZSYPXRjfqOorbn+HcIjTEtTRnLuo+RBa1MX25HYrH9Ad >>> kErOCyWn71sx65L7rySB3iByz67VmA3kW0Qypp8= >>> ) ; ZSK; alg = RSASHA256 ; key id = 43431 >>> rg.net. 3463 IN DNSKEY 257 3 8 ( >>> AwEAAeW0TsiLDw6VI9rcKCLnKFFVUAznLJEKR2OUExVa >>> 4n8v5f2lysPYdz/JMl7mqZorSM9ncYRpUmaTzxt5n5XU >>> dh5qTJcmDZvJRXdDBfBezcXM2Cs+bTxlK/KW/i3CCC0p >>> g2a6VM4clWFSxw8ZlU2oNslsrw0XbxqIh96WP0jJsAko >>> 26ACyYdsscZglGUgmyHFxPM2UmKAsk/ABgL8WTrYCg05 >>> 6FDmKT/hTWpZckJu5CekJEq5y+qNGCdqa+j4xY56f0ag >>> 8cODW89yRPlMrw6Fr8nCLef1B6gRYN9MFU8RUY0hMy3b >>> s62aB8A25ZRwYTH+3x/W4mNs0DLctSBZaEZnJGs= >>> ) ; KSK; alg = RSASHA256 ; key id = 30790 >>> rg.net. 3463 IN RRSIG DNSKEY 8 2 3600 ( >>> 20240321203948 20240307193948 30790 rg.net. >>> OYKcahhMUXRDMicqgFAQBGN6I6qNVwiEnWeMtWhn5t8l >>> 8x8lSs29rJA9GTjfJurA8wt1IrxZftB9bO/11QL3zcd4 >>> OyCWx6sgJUxsqgrV9HbLVYFIA7ZNLfrTHd3ZELv+WjFl >>> LwpXwF8PLvguozEsggbO4+8yEnBMBB2H4yEovoZSJgmD >>> ufApZJ2xwy/EaWUlOfSTUZiFpgKgUaSEkGJb96EbAKts >>> kMKIpm4SWlrVobSCrbv/KF6/a8+8Wtj0tY7mgjPbREDd >>> liaN92BRsQO0ykBep+HxH85CXPhqBMnl2Z43guX2t+QZ >>> B36h61FrpFOt7RUnvJ8Pn3Rz+kx1VVOIsw== ) >>> >>>> https://git.rg.net/randy/randy/src/master/scratch.md >> >> yes, we can see that, as we noted. and yes we could rekey 42 zones at >> the parents; great fun. >> >> but WHY NOT? same key sets with opendnssec and inline-signing, we >> think. >> >> randy > > I can’t get to https://git.rg.net/randy/randy/src/master/scratch.md > without installing a negative trust anchor or you fixing/removing the DS. > > -- > 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 -- 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: Insecurity proof failed
Have you disabled EDNS to these servers in named.conf? DNSSEC responses are only returned if DO=1 is set in the request. Named can learn that a server doesn’t support EDNS if it doesn’t return EDNS responses consistently to EDNS requests. If that happens named will send plain DNS requests. Mark > On 12 Mar 2024, at 22:50, Borja Marcos wrote: > > Hi, > > This is driving me nuts. I have three BIND 9.18.24 running on FreeBSD. Two of > them on FreeBSD 14, one on FreeBSD 13.2. > > Just one of the servers is failing to resolve a single domain compared to the > other two: checkpoint.com <http://checkpoint.com/>. > > I get these errors: > > <142>1 2024-03-12T11:36:21.957013+00:00 dnsanycast named 86604 - - insecurity > proof failed resolving 'checkpoint.com/A/IN': 198.51.44.65#53 > <142>1 2024-03-12T11:36:21.941389+00:00 dnsanycast named 86604 - - insecurity > proof failed resolving 'checkpoint.com/A/IN': 198.51.45.1#53 > <142>1 2024-03-12T11:36:21.924666+00:00 dnsanycast named 86604 - - insecurity > proof failed resolving 'checkpoint.com/A/IN': 198.51.45.65#53 > <142>1 2024-03-12T11:36:21.907492+00:00 dnsanycast named 86604 - - insecurity > proof failed resolving 'checkpoint.com/A/IN': 198.51.44.1#53 > > and > these: validating checkpoint.com/A: got insecure response; parent indicates > it should be secure > > And ultimately my DNS servers returns a SERVFAIL. > > The puzzling thing is, the other two servers work (this is a check on a > different server from the same pool). > > ; <<>> DiG 9.18.24 <<>> @127.0.0.1 checkpoint.com. > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40171 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: aa16c8ceb3a9eee9010065f0416206a44938e6d8f2b4 (good) > ;; QUESTION SECTION: > ;checkpoint.com. IN A > > ;; ANSWER SECTION: > checkpoint.com. 18 IN A 54.230.112.31 > checkpoint.com. 18 IN A 54.230.112.106 > checkpoint.com. 18 IN A 54.230.112.68 > checkpoint.com. 18 IN A 54.230.112.55 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) > ;; WHEN: Tue Mar 12 11:49:54 UTC 2024 > ;; MSG SIZE rcvd: 135 > > > > I have the same configuration, using dnssec-validation set to auto. > > Any clue on what might be failing? I am really lost! > > Thanks, > > > > > > Borja. > > > -- > 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: transfert master slave
Allow-notify is additive. You can’t block notify from primaries.
--
Mark Andrews
> On 25 Mar 2024, at 22:34, sami.ra...@sofrecom.com wrote:
>
>
> Hello community,
> I'm trying to configure a DNS slave server (192.168.56.157) . I want to allow
> notifications only from the master (192.168.56.154). I added the directive
> "allow-notify {192.168.56.154;};" and it works. However, when I try to test
> the prohibition of notification by adding "allow-notify {none;};" at the
> slave, it still receives updates from the master. The transfer on the master
> is as follows:
> allow-transfer {192.168.56.157;};
> also-notify {192.168.56.157;};
> notify explicit;"
>
> PS. BIND version : 9.16.48
>
> Regards Sami
> Orange Restricted
>
> --
> 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: Some Authoritative-Only BCPs
Also authoritative servers lookup information. This includes addresses of
nameservers to send NOTIFY messages. DS queries as part of DNSSEC key
management. DNSKEY queries as part of DNSSEC trust anchor management. Plus
whatever else is required to resolve those queries.
--
Mark Andrews
> On 28 Mar 2024, at 19:04, Greg Choules via bind-users
> wrote:
>
>
> Hi cjc.
> My answers would be:
>
> - Leave `dnssec-validation` alone (auto) and ensure your server has a path to
> the Internet to make queries.
>
> - Don't mess with root hints. The only time anyone should need to do this is
> when running a completely captive server living in a custom namespace that is
> NOT the Internet.
>
> - I don't know if "none" and "!all" work out to be the same thing in code
> terms, but my preference would be "none" anyway because 1) that's what's in
> the documentation and would be the obvious choice, and 2) why deliberately
> create a negated expression that is harder to parse, mentally? Glancing
> through a config and seeing "...!all..." you may not notice the "!" and just
> see the "all". Even if you do see the pling, a statement containing it reads
> something like "I would like to permit not all", which requires some thinking
> about the intent. Whereas "I would like to permit none" (for me anyway) is
> clearer and less ambiguous.
>
> As for why authoritative servers need to make queries at all, please take a
> look at this article.
> https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries
>
> Hope that helps.
> Greg
>
>> On Thu, 28 Mar 2024 at 06:15, Crist Clark wrote:
>> I am upgrading and redeploying some authoritative-only BIND servers. Two
>> questions about some fine points:
>>
>> What to set 'dnssec-validation'? Just let it default to 'auto?' There is no
>> need or opportunity for an authoritative-only server to validate (right?).
>> Should we actively switch it off, set it to 'no?' For example, does setting
>> it to 'no' reduce any resource use or reduce the security vulnerability
>> space?
>>
>> This is bordering on aesthetic (maybe the first one is too), but what to do
>> about the compiled-in root hints? Even on my authoritative-only server with
>> "recursion no," every forty-five minutes or so, it's trying to go to the
>> root servers and retrieve the NS and DNSKEY RRs for the root. It's blocked
>> since there is no reason for this server to do outbound DNS, except to its
>> hidden masters, so it just keeps trying and cluttering the firewall logs.
>> What's the best way to stop this behavior? Is there a configuration option?
>> I did this,
>>
>> zone "." {
>> type primary;
>> file "primary/empty-zone.db";
>> allow-query { none; };
>> };
>>
>> Which seems to do the trick, but is that the cleanest way? Any problems with
>> that approach that I haven't considered?
>>
>> Oh, one final bonus question, is there any difference between specifying
>> 'none' and '!all' in a server list, ACL, etc.? I prefer 'none', but the old
>> configurations used '!all'. Can I change those without worrying?
>> --
>> 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
--
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: "bad cache-hit" or "bad-cache hit"
It a hold down cache on bad lookups. The timeout is 10 minutes. To prove whether a zone is secure or not DS records at delegations in the chain are looked up. Sometimes that fails. This cache records that failure. -- Mark Andrews > On 17 Apr 2024, at 07:03, John Thurston wrote: > > > Looking in my logs today, I found a confusing line: > > validating cran.rproject.org/SOA: bad cache hit (rproject.org/DS) > > I was trying to figure out what was wrong with my cache, and how BIND might > be able to determine that a cache hit is bad. To do that, it would need to > retrieve the current value and compare it to the value in cache . . and by > the time it has done that, why has it bothered to consult the cache? > > But now I think I may have mis-parsed the line. Maybe it isn't: > > bad cache-hit (i.e. Something was wrong with the cached value) > > but is instead: > > bad-cache hit (i.e. We found what we wanted in the cache of bad entries) > > Can anyone confirm my hypothesis? > > > > -- > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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: Answers for www.dnssec-failed.org with dnssec-validation auto;
Named will tell you which DNSSEC algorithms it supports. Depending upon the OS and its configuration this may differ. DNSSEC algorithms: RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 vs DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 % named -V BIND 9.19.23-dev (Development Release) running on Darwin arm64 22.6.0 Darwin Kernel Version 22.6.0: Mon Feb 19 19:43:41 PST 2024; root:xnu-8796.141.3.704.6~1/RELEASE_ARM64_T8103 built by make with '--enable-developer' '--prefix=/usr/local' '--sysconfdir=/etc' '--localstatedir=/var' '--with-gssapi=krb5-config' 'CFLAGS=-g -mmacosx-version-min=13.1' 'PKG_CONFIG_PATH=/Users/marka/userspace-rcu/lib/pkgconfig:' '--with-cachedb=rbt' compiled by CLANG Apple LLVM 15.0.0 (clang-1500.1.0.2.5) compiled with OpenSSL version: OpenSSL 3.2.1 30 Jan 2024 linked to OpenSSL version: OpenSSL 3.2.1 30 Jan 2024 compiled with libuv version: 1.44.2 linked to libuv version: 1.44.2 compiled with liburcu version: 0.15.0-pre compiled with jemalloc version: 5.3.0 compiled with libnghttp2 version: 1.59.0 linked to libnghttp2 version: 1.61.0 compiled with libxml2 version: 2.11.6 linked to libxml2 version: 21206 compiled with json-c version: 0.11 linked to json-c version: 0.11 compiled with zlib version: 1.3.1 linked to zlib version: 1.3.1 linked to maxminddb version: 1.8.0 threads support is enabled DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 DS algorithms: SHA-1 SHA-256 SHA-384 HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 TKEY mode 2 support (Diffie-Hellman): no TKEY mode 3 support (GSS-API): yes default paths: named configuration: /etc/named.conf rndc configuration: /etc/rndc.conf nsupdate session key: /var/run/named/session.key named PID file: /var/run/named/named.pid geoip-directory: /opt/local/share/GeoIP % > On 18 Apr 2024, at 11:44, Bob McDonald wrote: > > Would this be true for FreeBSD as well? I also have a bind 9.18.24 instance > running on freeBSD > and it seems to be ok. > > Bob > > > The crypto policy stuff ultimately creates and maintains files in > > /etc/crypto-policy/backends, which has a list of acceptable or > > not-acceptable crypto settings. > > > Whilst a "bind.config" is created, you aren't including it in your config > > (this is fine), which suggests that the issue is with some of openssl > > configurations (which will be system wide anyway). > > > You can use the update-crypto-policies to update only the openssl > > configuration to allow sha1, or you could manually recreate those files > > (instead of the usual symlinks) and edit them individually as you please. > > > Stuart > -- > 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: Broken DNS QNAME Recovery
> On 19 Apr 2024, at 16:12, Crist Clark wrote:
>
> First, yes, I know. Their DNS is broken. They should fix their DNS. We
> shouldn't need to make QNAME-minimization work around broken DNS.
>
> Name and shame a domain name in question,
>
> e1083.d.akamaiedge.akamai.csd.disa.mil
>
> The problem I see: akamai.csd.disa.mil is a delegated zone. All four name
> servers for the zone are in the zone. All four of the addresses in the
> parent's glue are unresponsive. It's actually the same for
> d.akamaiedge.akamai.csd.disa.mil too.
>
> That is breaking resolution for BIND 9.18 servers with default
> qname-minimization. If qname-minimization is set "off", it works. That's
> because the disa.mil NSes will respond with the answer for that full name. We
> never go farther up the name to try to find the non-responsive NS servers.
>
> (And yes, the DNS "authoritative" servers here are questionable too. The TTLs
> look like they are caching answers, but all of the responses have AA set.)
>
> Does that assessment look correct? I know BIND defaults to "relaxed" QNAME
> minimization. It works around certain cases of brokeness. I guess this is not
> one of them? Should it be? It's a case where things work without
> minimization. The brokeness is hidden for non-minimizing resolvers.
>
> Again, yeah, they are broken. They should fix it, but it broke someone's Very
> Important Work at our shop. And it used to work and it works from home and
> for other customers so it must be our DNS that's broken. So we end up setting
> "qname-minimization off" globally despite the fact they are really the broken
> ones. We'd rather keep minimization on, but it's the only reasonable work
> around we could find.
Just use a forward zone in forward only mode. When the parent servers give you
non working nameservers for child zones there isn’t a sensible automatic
solution.
zone disa.mil {
type forward;
forward only;
forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
};
> --
> 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: Broken DNS QNAME Recovery
No. “Forward zones” are not DNS zones. They are overrides to the DNS resolution
processes that just happened to be configured in named by overloading the zone
syntax element. Similarly stub and static stub are not zones. The are other
things.
--
Mark Andrews
> On 23 Apr 2024, at 01:24, John Thurston wrote:
>
> On 4/21/2024 10:05 PM, Mark Andrews wrote:
>> On 19 Apr 2024, at 16:12, Crist Clark wrote:
>>>
>>> First, yes, I know. Their DNS is broken. They should fix their DNS. We
>>> shouldn't need to make QNAME-minimization work around broken DNS.
>>>
>>> Name and shame a domain name in question,
>>>
>>> e1083.d.akamaiedge.akamai.csd.disa.mil
>>>
>>> The problem I see: akamai.csd.disa.mil is a delegated zone. All four name
>>> servers for the zone are in the zone. All four of the addresses in the
>>> parent's glue are unresponsive. It's actually the same for
>>> d.akamaiedge.akamai.csd.disa.mil too.
>>>
>>> That is breaking resolution for BIND 9.18 servers with default
>>> qname-minimization. If qname-minimization is set "off", it works. That's
>>> because the disa.mil NSes will respond with the answer for that full name.
>>> We never go farther up the name to try to find the non-responsive NS
>>> servers.
>>>
>>> (And yes, the DNS "authoritative" servers here are questionable too. The
>>> TTLs look like they are caching answers, but all of the responses have AA
>>> set.)
>>>
>>> Does that assessment look correct? I know BIND defaults to "relaxed" QNAME
>>> minimization. It works around certain cases of brokeness. I guess this is
>>> not one of them? Should it be? It's a case where things work without
>>> minimization. The brokeness is hidden for non-minimizing resolvers.
>>>
>>> Again, yeah, they are broken. They should fix it, but it broke someone's
>>> Very Important Work at our shop. And it used to work and it works from home
>>> and for other customers so it must be our DNS that's broken. So we end up
>>> setting "qname-minimization off" globally despite the fact they are really
>>> the broken ones. We'd rather keep minimization on, but it's the only
>>> reasonable work around we could find.
>> Just use a forward zone in forward only mode. When the parent servers give
>> you non working nameservers for child zones there isn’t a sensible automatic
>> solution.
>>
>> zone disa.mil {
>> type forward;
>> forward only;
>> forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
>> };
>
> Can such forward-zones be defined in catalog-zones?
>
>
>
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> --
> 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: Question about resolver
DS records live in the parent zone and the RFC 1034 rules for serving zone break down when a grandparent zone and child zone are served by the same server. This is corrected be the client by looking for intermediate NS records to find the hidden delegations then resuming the DS lookup. Named was looking up theses NS records I.e. chasing the DS servers. This can result in named finding delegation errors. QNAME minimisation also exposes these errors as it also does NS queries. Garbage in breakage out. -- Mark Andrews > On 27 Apr 2024, at 00:45, J Doe wrote: > > On 2024-04-25 08:55, Josh Kuo wrote: > >> DS = Delegation Signer, it is the record type that a signed child upload >> to the parent zone. It's difficult to say for sure without more >> information such as which domain name you are trying to resolve, but >> looks like it is probably due to a mis-matching DS record between the >> child and the parent (security lameness). >> >> You can use tools such as >> https://dnssec-analyzer.verisignlabs.com/online >> <https://dnssec-analyzer.verisignlabs.com/online> to help you analyze >> further. If you need to refresh your knowledge on how DNSSEC works, see >> the ISC DNSSEC Guide: >> https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html >> <https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html> >> >> -Josh > > Hi Josh, > > Thank you for your prompt reply! > > In this particular case, isn't the resolver attempting to do a reverse > lookup of the IP address that's listed ? > > Secondly, I'm still not entirely sure what the phrasing "chase DS > servers" means. I am aware of the DS RR type. > > As a side-note: I believe the "lame-servers" here is a function of me > configuring QNAME minimization to "relaxed". > > Thanks, > > - J > -- > 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
