Re: Referencing by cname from one authoritative zone to another authoritative zone
ntomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > How does cat play with mouse? cat /dev/mouse > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- > 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: Multi Master/Primary Authoritative DNSSEC DNS Nameserver With Synced/Replicated COMMON Dir/Vol For BIND
You need to remember multi-signer still has a lot of hand waving in its specification. All the coordination between operators is unspecified. Things like how you generate CDS automatically is undefined. A pre CDS (PCDS) record with an signer tag and signer count before the CDS data would work. The servers would then look for a full set of PCDS records and promote them to CDS records when that exists. This would be per algorithm. A full set is defined as having a record from each signer and the count of such signers matching the maximum signers of all PCDS records. Each signer needs to know its signer identifier and the total count of signers. When a new signer is added a new PCDS is generated by each signer for its keys. Similarly for when a signer is removed. Signers will log discrepancies between the configured signer count and the observed value in the PCDS records. All this needs to go through the IETF. -- Mark Andrews > On 28 Sep 2024, at 07:54, Terik Erik Ashfolk wrote: > > According to the page > https://blog.apnic.net/2021/08/25/multi-signer-dnssec-models/ > in MODEL 2. > I added an improved image as attachment. > > MULTI-ZSK-SIGNING IS ONE OF THE SOLUTION, and appears to be suitable for my > case. > > So, multi-signing with ZSKs from multiple nameservers would have worked, > when nameservers were using separate "zones" & "keys" folder, > > I needed to sign n1's zone file with n2's ZSK & with n3's ZSK. > I needed to sign n2's zone file with n1's ZSK & with n3's ZSK. > I needed to sign n3's zone file with n1's ZSK & with n2's ZSK. > > Because 3 nameservers are using SYNCED/REPLICATED shared directories & files, > so each ZSK & KSK are available to other nameservers. > > for "key-directory" > n1 using "/mnt/vol/v1/etc/bind/n1/keys" > n2 using "/mnt/vol/v1/etc/bind/n2/keys" > n3 using "/mnt/vol/v1/etc/bind/n3/keys" > > and shared common directory for BIND keys is > "/mnt/vol/v1/etc/bind/keys" > > and shared directory is > "/mnt/vol/v1" > > is there an option in BIND, that can monitor+enable additional ZSK signing > from new ZSK key from other namerservers for same domain ? > if not, please add this as new feature in BIND. > > if BIND itself cannot do the monitoring + multi-ZSK-signing now, then, HOW > can i monitor the ".../bind/n1/keys" (or ".../bind/n2/keys" or > ".../bind//n3/keys" or ".../bind/keys" ) sub-dirs under shared-directory and > find that BIND has began to use a new ZSK key ? > > or HOW can i get a signal from BIND in each nameserver ? that, BIND has began > to use a new ZSK key ? > > so-that, i can trigger/run another script in each nameserver (which added new > ZSK key) to begin signing my domain's zone file in other 2 nameservers with > the new ZSK. > > example : if n1 added a new ZSK for "example.com" domain, then a > "new-zsk-key-monitoring-script.sh" script will create 2 files > "signal-n2-ExampleCom-MZS-zskNUMBER.txt" > "signal-n3-ExampleCom-MZS-zskNUMBER.txt" > in the shared-bind-directory : "/mnt/vol/v1/etc/bind/keys". > Then "monitor-for-signal-file.sh" script running in n2 & n3, will get that > signal, & run "multi-ZSK-sign-script.sh" to mulit ZSK signing. > > > Thanks in advance. > > Erik. > > Erik T Ashfolk. > > > > >> On 9/26/24 7:26 PM, TErik Ashfolk wrote: >> Hello BIND Community. >> Looking forward to your suggestions, advises on setup DNSSEC enabled zones >> on multiple master/primary authoritative DNS server (Nameserver) with >> synced/replicated common shared directories/volume. >> Please skip the section(s) that you dont need to read/scan, >> & goto the QUESTIONS , the last section. >> OBJECTIVES (END-RESULT): >> Trying to achieve HA (High-Availability <https://en.wikipedia.org/ >> wiki/High_availability>), so-that, as long as 1 master/primary is >> up/running, then my domains are still available to world, and allowing users >> to obtain DNSSEC verified domain-name to IP-address resolving, etc from BIND >> DNS server services. >> RESOURCES: >> • Servers : rented 3 servers on 3 locations from different server providers. >> • Domain : I have multiple domains from domain providers (registrar) . Here >> i will use "example.com" >> • Each server has 1 IPv4-address, 1 IPv6-address. >> • Domain provider's "Use your own Nameserver" is pointed to 3 hostnames in 3 >> nameservers : n1.example.com ( 19
Re: Determining case of REFUSED queries
I think the reason for the REFUSED is pretty obvious % dig +norec google._domainkey.socialinnovation.ca @173.245.59.231 txt ; <<>> DiG 9.21.0-dev <<>> +norec google._domainkey.socialinnovation.ca @173.245.59.231 txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10815 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ; EDE: 20 (Not Authoritative) ;; QUESTION SECTION: ;google._domainkey.socialinnovation.ca. IN TXT ;; Query time: 14 msec ;; SERVER: 173.245.59.231#53(173.245.59.231) (UDP) ;; WHEN: Fri Sep 20 09:03:48 AEST 2024 ;; MSG SIZE rcvd: 72 % Now you just need to work out why you where asking 173.245.59.231 rather than the actual nameservers for socialinnovation.ca. socialinnovation.ca. 86400 IN NS dns.rebel.ca. socialinnovation.ca. 86400 IN NS dns2.rebel.ca. dns2.rebel.ca. 86400 IN A 52.10.144.165 dns.rebel.ca. 86400 IN A 52.3.166.104 > On 20 Sep 2024, at 08:48, J Doe wrote: > > Hi list, > > I have BIND 9.18.29 validating recursive resolver running on OpenBSD > 7.5. This resolver performs resolution for a mail server. > > Sometimes in my logs I will see the following: > >17-Sep-2024 16:21:41.562 lame-servers: info: REFUSED unexpected > RCODE resolving 'google._domainkey.socialinnovation.ca/TXT/IN': > 173.245.59.231#53 > > ... but if I manually resolve the address with: dig against the resolver > on the command line of the mail server, no errors are recorded. > > I'd like to determine why sometimes I receive this error. I currently > have logging for this category of errors set to: severity info. Should > I increase this or are there other ways to determine why resolution is > sometimes REFUSED ? > > 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: named-checkzone fail
> On 11 Sep 2024, at 16:06, Lee wrote:
>
> On Tue, Sep 10, 2024 at 10:52 PM Mark Andrews wrote:
>>
>>> On 11 Sep 2024, at 12:10, Lee wrote:
>>>
>>> On Tue, Sep 10, 2024 at 6:17 PM Mark Andrews wrote:
>>>>
>>>> Comma is legal in a domain name. It isn’t legal in a host name which are
>>>> a subset of domain names. Named-checkzone is working exactly as it should.
>>>
>>> Except this isn't really a domain name - it's a whatever-it's-called
>>> in a response policy zone. As far as I know there's only 4 valid
>>> tokens that can come after CNAME in an RPZ:
>>> ; . RPZ processing returns NXDOMAIN (name does not exist)
>>> ; *. RPZ processing returns NODATA (name exists but no
>>> answers returned)
>>> ; rpz-drop. No response is returned to the user query
>>> ; rpz-passthru. This identifies an exception(a whitelisted name)
Well you are wrong. There are 4 special CNAME right hand sides. The rest can
be
used to re-write the response. This is documented in chapter 6 of the ARM.
https://bind9.readthedocs.io/en/v9.18.29/chapter6.html#dns-firewalls-and-response-policy-zones
A response policy action can be one of the following:
• to synthesize a “domain does not exist” (NXDOMAIN) response
• to synthesize a “name exists but there are no records of the requested
type” (NODATA) response
• to drop the response
• to switch to TCP by sending a truncated UDP response that requires the
DNS client to try again with TCP
• to replace/override the response’s data with specific data (provided
within the response policy zone)
• to exempt the response from further policy processing
>>> I missed this the first time through, but the rpz.mozilla zone _is_
>>> flagged as a response policy zone in named.conf
>>> response-policy { zone "rpz.mozilla"; zone "rpz.zone"; zone "rpz.urlhaus"; }
>>>break-dnssec yes
>>>recursive-only no
>>>qname-wait-recurse no;
Well named-checkzone does not read named.conf. Named-checkconf reads
named.conf.
Even if named-checkzone did read named.conf it still wouldn’t have rejected the
zone.
>>> It seems to me that named-checkzone should be using RPZ syntax instead
>>> of the 'normal' domain name syntax. But it's not worth arguing
>>> about.. the program doesn't check what I think needs checking so I'll
>>> look elsewhere or write my own.
It is using RPZ syntax. If it wasn’t a valid RPZ zone it would have been
rejected by named.
>>> In any case, thanks for the answer. Now that I know that
>>> named-checkzone is working correctly I don't need to waste any more
>>> time with it.
>>>
>>> Best Regards,
>>> Lee
>>
>> The program is called named-checkzone not named-checkrpzzone and even then
>> it would not be an error because you really might want to add CNAMES to
>> ,.rpz.mozilla.
>
> Call it a failure of imagination on my part, but unless comma becomes
> a defined CNAME value in an RPZ file I just can't imagine me _wanting_
> to add a comma for a CNAME value in an rpz file.
CNAMEs *are* a defined part of a RPZ file. “,” is not more or less special
that “example.com.” or any other possible domain name on the RHS of the
CNAME. They fall within "to replace/override the response’s data with
specific data (provided within the response policy zone)”.
>> There is no way for the program to know. “.” and “*.” are
>> just “special” CNAMEs for the RPZ code to process differently to how it
>> processes other CNAMEs in the zone.
>
> You notice I'm not arguing. .. or suggesting how named-checkzone
> could be extended. right?
No, you are arguing that is it broken. I’m saying it is not broken
and why it is not broken.
>> We don’t have “do what I want” software we have “do what is programmed”
>> software.
>
> Ages ago I was a programmer & one group I was in used to joke about
> the "doit" processor that magically did we were
> having problems with at the time.
>
> In any case, this took me so long because I've pretty much forgotten
> how to program. & while it's ugly as all get-out it seems to do the
> job:
>
> $ ./check-rpzzone /etc/bind/db.rpz-mozilla
> OhNoes!!! line 17 invalid CNAME value: broken-cname.net
> CNAME ,
Well ./check-rpzzone appears to be broken if it is designed to process
generic RPZ zones. The CNAME is not invalid in a RPZ zone. Now having
a CNAME that points into a RPZ zone is a bit strange but it isn’t invalid
and it actually works.
> $ ./chec
Re: named-checkzone fail
> On 11 Sep 2024, at 12:10, Lee wrote:
>
> On Tue, Sep 10, 2024 at 6:17 PM Mark Andrews wrote:
>>
>> Comma is legal in a domain name. It isn’t legal in a host name which are a
>> subset of domain names. Named-checkzone is working exactly as it should.
>
> Except this isn't really a domain name - it's a whatever-it's-called
> in a response policy zone. As far as I know there's only 4 valid
> tokens that can come after CNAME in an RPZ:
> ; . RPZ processing returns NXDOMAIN (name does not exist)
> ; *. RPZ processing returns NODATA (name exists but no
> answers returned)
> ; rpz-drop. No response is returned to the user query
> ; rpz-passthru. This identifies an exception(a whitelisted name)
>
> I missed this the first time through, but the rpz.mozilla zone _is_
> flagged as a response policy zone in named.conf
> response-policy { zone "rpz.mozilla"; zone "rpz.zone"; zone "rpz.urlhaus"; }
> break-dnssec yes
> recursive-only no
> qname-wait-recurse no;
>
> It seems to me that named-checkzone should be using RPZ syntax instead
> of the 'normal' domain name syntax. But it's not worth arguing
> about.. the program doesn't check what I think needs checking so I'll
> look elsewhere or write my own.
>
> In any case, thanks for the answer. Now that I know that
> named-checkzone is working correctly I don't need to waste any more
> time with it.
>
> Best Regards,
> Lee
The program is called named-checkzone not named-checkrpzzone and even then
it would not be an error because you really might want to add CNAMES to
,.rpz.mozilla. There is no way for the program to know. “.” and “*.” are
just “special” CNAMEs for the RPZ code to process differently to how it
processes other CNAMEs in the zone.
We don’t have “do what I want” software we have “do what is programmed”
software.
Mark
>> If the current origin is example.com. then comma expands to ,.example.com.
>> as it is treaded as a relative name.
>>
>> --
>> Mark Andrews
>>
>>> On 11 Sep 2024, at 03:55, Lee wrote:
>>>
>>> I had a few typos in an RPZ file where I had a comma instead of a dot.
>>> I tried using named-checkzone to find all the typos but it didn't
>>> complain about anything!? Is that expected behavior?
>>>
>>> And a related question.. can anyone recommend a vim syntax file
>>> checker for bind files?
>>>
>>> $ named-checkzone rpz.mozilla /etc/bind/db.rpz-mozilla
>>> zone rpz.mozilla/IN: loaded serial 2024091001
>>> OK
>>>
>>> $ cat /etc/bind/db.rpz-mozilla
>>> $ORIGIN rpz.mozilla.
>>> ;
>>> https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
>>> ; return NXDOMAIN for use-application-dns.net name lookup
>>> ;
>>> https://kb.isc.org/docs/using-response-policy-zones-to-disable-mozilla-doh-by-default
>>> $TTL604800
>>>
>>> @ IN SOA localhost. root.home.net. (
>>> 2024091001 ; Serial
>>> 604800 ; Refresh
>>> 86400 ; Retry
>>> 2419200; Expire
>>> 604800 ) ; Minimum
>>> IN NS localhost.
>>>
>>> ; tell Firefox to not use DOH (Dns Over Https)
>>> use-application-dns.net CNAME .
>>> broken-cname.netCNAME , <=
>>> COMMA not a period
>>> ; --- end ---
>>>
>>> $ dig broken-cname.net
>>>
>>> ; <<>> DiG 9.16.50-Debian <<>> broken-cname.net
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62006
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1432
>>> ; COOKIE: ad32c4ae2224c66d010066e082286d1625c0e8f2160c (good)
>>> ;; QUESTION SECTION:
>>> ;broken-cname.net. IN A
>>>
>>> ;; ANSWER SECTION:
>>> broken-cname.net. 5 IN CNAME ,.rpz.mozilla.
>>>
>>> ;; AUTHORITY SECTION:
>>> rpz.mozilla.604800 IN SOA localhost.
>>> root.home.net. 2024091001 604800 86400 2419200 604800
>>>
>>> ;; ADDITIONAL SECTION:
>>> rpz.mozilla.1 IN SOA
Re: named-checkzone fail
Comma is legal in a domain name. It isn’t legal in a host name which are a subset of domain names. Named-checkzone is working exactly as it should. If the current origin is example.com. then comma expands to ,.example.com. as it is treaded as a relative name. -- Mark Andrews > On 11 Sep 2024, at 03:55, Lee wrote: > > I had a few typos in an RPZ file where I had a comma instead of a dot. > I tried using named-checkzone to find all the typos but it didn't > complain about anything!? Is that expected behavior? > > And a related question.. can anyone recommend a vim syntax file > checker for bind files? > > $ named-checkzone rpz.mozilla /etc/bind/db.rpz-mozilla > zone rpz.mozilla/IN: loaded serial 2024091001 > OK > > $ cat /etc/bind/db.rpz-mozilla > $ORIGIN rpz.mozilla. > ; > https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https > ; return NXDOMAIN for use-application-dns.net name lookup > ; > https://kb.isc.org/docs/using-response-policy-zones-to-disable-mozilla-doh-by-default > $TTL604800 > > @ IN SOA localhost. root.home.net. ( >2024091001 ; Serial >604800 ; Refresh >86400 ; Retry >2419200; Expire >604800 ) ; Minimum >IN NS localhost. > > ; tell Firefox to not use DOH (Dns Over Https) > use-application-dns.net CNAME . > broken-cname.netCNAME , <= > COMMA not a period > ; --- end --- > > $ dig broken-cname.net > > ; <<>> DiG 9.16.50-Debian <<>> broken-cname.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62006 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1432 > ; COOKIE: ad32c4ae2224c66d010066e082286d1625c0e8f2160c (good) > ;; QUESTION SECTION: > ;broken-cname.net. IN A > > ;; ANSWER SECTION: > broken-cname.net. 5 IN CNAME ,.rpz.mozilla. > > ;; AUTHORITY SECTION: > rpz.mozilla.604800 IN SOA localhost. > root.home.net. 2024091001 604800 86400 2419200 604800 > > ;; ADDITIONAL SECTION: > rpz.mozilla.1 IN SOA localhost. > root.home.net. 2024091001 604800 86400 2419200 604800 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Sep 10 13:30:16 EDT 2024 > ;; MSG SIZE rcvd: 194 > -- > 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: bind918 malfunction?
#x27;_sip._tcp.tel.t-online.de. 3600 IN SRV 10 0 5060 > mue000-l01-mav-pc-rt-001.edns.t-ipnet.de.' > 295591670 | 31.08.2024 08:10:16.976788 CEST | 31.08.2024 08:10:17.018826 CEST > | QUESTION | 1 | 'mue000-l01-mav-pc-rt-001.edns.t-ipnet.de. IN A' > 295591670 | 31.08.2024 08:10:16.976788 CEST | 31.08.2024 08:10:17.018826 CEST > | ANSWER | 1 | 'mue000-l01-mav-pc-rt-001.edns.t-ipnet.de. 3600 IN A > 217.0.148.69' > > We can see that the required queries 295572089 and 295581205 are not > answered at all! > Let's see what was sent instead: > >id |mess > > ---+--------- > 117965258 | ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: ** > + > | ;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, > ADDITIONAL: 0+ > | ;; QUESTION SECTION: > + > | ;_sip._udp.tel.t-online.de. IN SRV > + > > > Now what do we have in the logs --- > > Aug 31 06:12:10 conr named[4456]: lame-servers: info: success > resolving '_sip._tcp.tel.t-online.de/SRV' after disabling qname minimization > due to 'failure' > Aug 31 06:12:10 conr named[4456]: lame-servers: info: success > resolving '_sips._tcp.tel.t-online.de/SRV' after disabling qname minimization > due to 'failure' > > That's all, and that doesn't look very helpful. It doesn't mention the > relevant query at all, and no other problems either. > > > So, the nature of the problem might be explained with this. > > The configuration is a LAN-providing caching Nameserver, fully DNSSEC > enabled, IPv4+v6, with rootslave, and authoritative for the LAN zones. > The LAN zones are DNSSEC-wise chained to my public ones, trust-anchors > are only used for reverse-DNS. > > I'm currently working on retrieving the relevant dialogue with the > rootslave, but it doesn't seem very much helpful info in there either. > > cheerio, > PMc > -- > 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 statistics
> On 27 Aug 2024, at 06:04, Havard Eidnes via bind-users > wrote: > >> On Mon, Aug 26, 2024 at 06:05:19PM +0200, Havard Eidnes via bind-users wrote: >>> Thanks. I found it, and it's more than a little embarassing. >>> >>> This is what you get when not building with --with-libxml2: an >>> "un-rendered" xsl file as a result, in essence just the content >>> of bin/named/xsl.c. And this happened because I wasn't paying >>> attention to what options were turned on by default for the >>> package I was putting together. "Surely stats is on by default!" >>> Not so. (Well, I didn't even think it was optional.) Lesson >>> learned. >> >> It *is* on by default, if it can find libxml2. Does yours live in >> a nonstandard location? > > Time for more confessions. > > This is in NetBSD's pkgsrc, which only builds with explicitly > "buildlinked" libraries, so that build dependencies are > explicitly declared, and not automatically picked up from those > you just accidentally happen to have installed on the build host. > What I had overlooked was that I in /etc/mk.conf needed > > PKG_OPTIONS.bind+= bind-xml-statistics-server > > It's another matter whether this one should default to "on" in > the package itself -- I'm leaning in that direction, but need to > discuss with some others before I change the default. And I also > need the "dnstap" option in my deployment, so I need a custom > build anyway. Like I said, "lesson learned". > >> Perhaps, if libxml2 and libjson-c are both unavailable, we should >> disable statistics-channels in the configuration - at least that way >> the problem would've been easier to figure out. > > Right, I was sort of thinking in that direction as well, but > would not be too insistent on something along those lines. > Perhaps return a web page saying "built without both libjson-c > and libxml2, so nothing to see here"? A simple “No such url” will do. See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9423 Also if you ask for http://.../xml you won’t get json by mistake. > 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 -- 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 statistics
On further reflection I suspect broken clocks. Named uses If-Modified-Since to
determine
whether to resend the style file. Named uses the server’s start time as the
modification time
in that calculation.
> On 26 Aug 2024, at 11:06, Mark Andrews wrote:
>
> We are probably not properly managing the style sheet versioning correctly.
> Flushing
> the browser’s cache when you install a new version of BIND should fix the
> display problems.
>
> As for collectd there are differences in which stats are collected. You a
> probably
> looking for something that is no longer present.
>
> git diff bind-9.18 bind-9.20 bin/named/bind9.xsl
>
>> On 26 Aug 2024, at 05:10, Havard Eidnes via bind-users
>> wrote:
>>
>> Hi,
>>
>> I'm mostly running BIND 9.18.x, and have configured statistics
>> publishing via
>>
>> statistics-channels {
>> inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
>> inet "actual-address" port 8053 allow { prefix1/24; prefix2/24; };
>> };
>>
>> I've started testing 9.20.x.
>>
>> I see BIND 9.20.x stats publishing is ... different.
>>
>> If I use firefox and visit http://actual-address:8053/ with BIND
>> 9.18.x, I get a reasonably rendered HTML display which is easy to
>> view.
>>
>> Not so for BIND 9.20.x; I get an XML document which firefox (in
>> this particular case version 120.0) informs me at the top
>>
>> This XML file does not appear to have any style information
>> associated with it. The document tree is shown below.
>>
>> and the document starts with
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > src="<a rel="nofollow" href="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/">https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/</a>>
>> <script type="text/javascript">
>> $(function($) { var wid=0; $('table.zones').each(function(i) { if(
>> $(this).width() > wid ) wid = $(this).width(); return true; });
>> $('table.zones').css('min-width', wid );
>> $("h2+table,h3+table,h4+table,h2+div,h3+div,h2+script,h3+script").prev().append('
>> <a class="tabletoggle" href="#" style="font-size:small">Show/Hide</a>
>> '); $(".tabletoggle").click(function(){ var n =
>> $(this).closest("h2,h3,h4").next(); if (n.is("script")) { n = n.next(); } if
>> (n.is("div")) { n.toggleClass("hidden"); n = n.next(); } if (n.is("table"))
>> { n.toggleClass("hidden"); } return false; }); });
>>
>>
>> and is quite different from what BIND 9.18.x presents:
>>
>>
>>
>> > version="3.13">2024-08-16T09:03:10.730Z
>>
>> etc. etc.
>>
>> The question is: am I alone in experiencing this?
>>
>> It also looks like I'll have to find out why collecting BIND
>> stats via collectd (5.12.0) no longer works after upgrading to
>> 9.20.x.
>>
>> 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
>
> --
> 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: BIND statistics
We are probably not properly managing the style sheet versioning correctly.
Flushing
the browser’s cache when you install a new version of BIND should fix the
display problems.
As for collectd there are differences in which stats are collected. You a
probably
looking for something that is no longer present.
git diff bind-9.18 bind-9.20 bin/named/bind9.xsl
> On 26 Aug 2024, at 05:10, Havard Eidnes via bind-users
> wrote:
>
> Hi,
>
> I'm mostly running BIND 9.18.x, and have configured statistics
> publishing via
>
> statistics-channels {
>inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
>inet "actual-address" port 8053 allow { prefix1/24; prefix2/24; };
> };
>
> I've started testing 9.20.x.
>
> I see BIND 9.20.x stats publishing is ... different.
>
> If I use firefox and visit http://actual-address:8053/ with BIND
> 9.18.x, I get a reasonably rendered HTML display which is easy to
> view.
>
> Not so for BIND 9.20.x; I get an XML document which firefox (in
> this particular case version 120.0) informs me at the top
>
> This XML file does not appear to have any style information
> associated with it. The document tree is shown below.
>
> and the document starts with
>
>
>
>
>
>
>
>
>
> src="<a rel="nofollow" href="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/">https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/</a>>
> <script type="text/javascript">
> $(function($) { var wid=0; $('table.zones').each(function(i) { if(
> $(this).width() > wid ) wid = $(this).width(); return true; });
> $('table.zones').css('min-width', wid );
> $("h2+table,h3+table,h4+table,h2+div,h3+div,h2+script,h3+script").prev().append('
> <a class="tabletoggle" href="#" style="font-size:small">Show/Hide</a>
> '); $(".tabletoggle").click(function(){ var n =
> $(this).closest("h2,h3,h4").next(); if (n.is("script")) { n = n.next(); } if
> (n.is("div")) { n.toggleClass("hidden"); n = n.next(); } if (n.is("table")) {
> n.toggleClass("hidden"); } return false; }); });
>
>
> and is quite different from what BIND 9.18.x presents:
>
>
>
> version="3.13">2024-08-16T09:03:10.730Z
>
> etc. etc.
>
> The question is: am I alone in experiencing this?
>
> It also looks like I'll have to find out why collecting BIND
> stats via collectd (5.12.0) no longer works after upgrading to
> 9.20.x.
>
> 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
--
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: v6-bias
> On 19 Aug 2024, at 00:59, Marco Moock wrote: > > Am 18.08.2024 um 23:44:26 Uhr schrieb Mark Andrews: > >>> On 18 Aug 2024, at 20:32, Marco Moock wrote: > >> It is. Go to the product page. Look at panel 3 “Configuration". >> Click on "Administrator Reference Manual (ARM)” then enter “v6-bias” >> in the search box. > > https://bind9.readthedocs.io/en/v9.18.28/reference.html#namedconf-statement-v6-bias > > As I searched on isc.org, I couldn't find it. > >>> I've set it to 200ms and I still see outgoing queries to IPv4 >>> destinations that are reachable via IPv6 and have a latency under >>> 20 ms. >> >> Named uses smooth measured RTT which means it still has to >> occasionally talk to servers over IPv4 to measure the RTT. > > Can that be disabled, so IPv4 fallback will only be used when IPv6 > query takes longer than the time set in v6-bias? It “doesn’t fall back to IPv4”. It sorts all the known server addresses for the zone adding v6-bias to the srtt of the IPv4 servers to order them. These are then tried in order using the actual srtt for the query timeout to move to the next server. 'rndc dumpdb' will allow you to see the srtt of the servers. > -- > kind regards > Marco > > Send unsolicited bulk mail to 1724017466mu...@cartoonies.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: I want to know why I suddenly can't resolve names.
I will repeat what I said before when you logged this as a bug. Stop using look aside validation. The service has been turned off for 7 years now. The only thing there is a empty zone that is returning NXDOMAIN for every lookup other than the apex which only has SOA, NS, NSEC and RRSIG records. There are no DLV records there to lookup. https://kb.isc.org/docs/disable-dnssec-lookaside-dlv-now-heres-how Also I am not going to ask operations what happened 2 weeks ago to cause the signature to be momentarily bad. Mark > On 19 Aug 2024, at 10:51, 秋林峻祐 wrote: > > This will be my first email. Sorry for any rough edges. > ISSUE:: I am using a DNS server in Japan. The DNS server failed to resolve > the domain name on August 2, 2024. It automatically recovered after a while. > The following message was recorded in the logs > I want to know why I suddenly can't resolve names. > logs:: > log1: validating @0x: dlv.isc.org DNSKEY: verify failed due > to bad signature (keyid=xxx): RRSIG has expired > log2: validating @0x: domain.example.com A: bad cache hit > (domain.example.com.dlv.isc.org/DLV) > timestamp:: Failure date: 2024.08.02 00:39:30 (JST) Failure recovery date: > 2024.08.02 05:06:06 (JST) > env:: CentOS release 6.4 (Final) BIND version: > bind-9.8.2-0.68.rc1.el6_10.8.x86_64 Execution user: /group:root / named > Considerations:: There were no other physical or internal OS failures. From > the fact that the recovery was automatic, I am guessing that there was a > failure or maintenance in the dlv repository for verification. If you have > any other information related to the cause of the problem, we would > appreciate it if you could share it with us. > Discussion:: > I know that “Look aside validation” has already been discontinued, but I have > a question to isolate the cause. > I would like to know why “Look aside validation” has already been > discontinued, yet the system usually operates without problems. > There were no other physical or internal OS failures. > The system recovered automatically. > I am guessing that it was caused by the dlv repository for validation. > If anyone has any other information relate > -- > 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: v6-bias
> On 18 Aug 2024, at 20:32, Marco Moock wrote: > > Hello! > > I couldn't find anything else than https://kb.isc.org/docs/aa-01349 > for v6-bias. > > Is that still relevant for current versions? Yes. > Is there a reason that option isn't described in the normal > documentation? It is. Go to the product page. Look at panel 3 “Configuration". Click on "Administrator Reference Manual (ARM)” then enter “v6-bias” in the search box. > I've set it to 200ms and I still see outgoing queries to IPv4 > destinations that are reachable via IPv6 and have a latency under 20 ms. Named uses smooth measured RTT which means it still has to occasionally talk to servers over IPv4 to measure the RTT. Additionally lots of zones don’t publish IPv6 glue records. The default is 50ms bias. > -- > kind regards > Marco > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: !AAAA in statistics
Negative cache entries. -- Mark Andrews > On 15 Aug 2024, at 22:10, Marco Moock wrote: > > Hello! > > named.stats includes that: > > [...] > ++ Cache DB RRsets ++ > [View: default] >3184 A >1059 NS > 108 CNAME > 8 SOA > 6 PTR > 1 TXT >2739 > 75 DS > 378 RRSIG > 6 NSEC > 21 DNSKEY > 6 HTTPS > 12 ! > 10 !DS > 4 !HTTPS > 6 NXDOMAIN > [View: _bind (Cache: _bind)] > > What do the lines with the ! mean? > > -- > kind regards > Marco > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: statistics-channels
> On 13 Aug 2024, at 06:44, Kretz wrote:
>
> Hi,
>
> BIND in OpenSuSE 15.6 is 9.18.24 and it's compiled with libxml, openssl, and
> libjson. I've got libxml and libxml-devel installed.
>
> When I start named, I get:
>
> unknown option 'statistics-channels'
>
> When I look at the man page for named.conf, statistics-channels isn't listed
> in the 'options' section.
That’s because it isn’t in the options section. It’s its own section. If you
continue read the man page
you will find it further down after ’server’ and before ’tls’.
statistics-channels {
inet 127.0.0.1 port 954 allow {any;};
};
options {
...
};
> What BIND version and/or compile options do I need to have to support
> statistics-channels?
> --
> 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: Adding Extra Text to EDNS EDE Responses in BIND 9.19.24
There is no code written to add reasons for rpz blocks. Feel free to add an
issue
via https://gitlab.isc.org/.
> On 13 Aug 2024, at 00:06, Robert Paolucci via bind-users
> wrote:
>
> Hello All,
> I’m currently working with BIND 9.19.24 and have successfully implemented
> EDNS EDE (Extended DNS Error) with the following configuration:
>
> response-policy {
> zone "rpz.example.com" ede blocked; }
> add-soa false
>
> This correctly returns the OPT code 15 for a blocked response:
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; OPT=15: 00 0f ("..")
>
> I would like to add some additional text to the EDE response, such as a
> reason for the block (e.g., "Blocked because – REASON").
> According to RFC 5198, it should be possible to use an extra-text field:
> EXTRA-TEXT:
> A variable-length, UTF-8-encoded [RFC5198] text field that may hold
> additional textual information. This information is intended for human
> consumption (not automated parsing). The EDE text may be null terminated but
> MUST NOT be assumed to be; the length MUST be derived from the OPTION-LENGTH
> field. The EXTRA-TEXT field may be zero octets in length, indicating that
> there is no EXTRA-TEXT included. Care should be taken not to include private
> information in the EXTRA-TEXT field that an observer would not otherwise have
> access to, such as account numbers.
> However, I haven’t been able to find an option for extra-text in the BIND
> configuration. Is this feature not supported yet, or is there a different
> approach I should be using?
> Thanks for your help!
>
> 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 have received this email in error please notify the system manager. This
> message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and delete
> this e-mail from your system. 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.
> --
> 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: strange reply dumped URGENT
time: 558 msec
;; SERVER: 2803:1920::4:a09#53(2803:1920::4:a09) (UDP)
;; WHEN: Tue Jul 16 10:17:30 AEST 2024
;; MSG SIZE rcvd: 70
%
Once you have fixed that confirm that you can transfer the zone from that
machine.
e.g. dig testadmin.ovh @2803:1920::4:a09 AXFR
Then check that your edge box has transferred the zone. You have configured it
as
a secondary like suggested?
zone testadmin.ovh {
type secondary;
file “testadmin.ovh.db”;
primaries { 2803:1920::4:a09; };
};
e.g. dig testadmin.ovh @199.38.247.210
Mark
> On 15 Jul 2024, at 22:51, Herman Brule wrote:
>
> Hi,
> Sorry I had to fix for my customer the domain ore.org.bo, but I have open
> another domain to test: testadmin.ovh
> Sorry for all this change. I have defined better test case and have normal IP
> to prevent problem from this part.
> 69.162.65.138 -> not my IP
>
> 2803:1920::4:a09 IPv6 only, VPS customer (here I'm the customer) <-> EDGE
> 199.38.247.210 IPv4+IPv6 <-> upstream provider of my autonomous system
> Each time I try enable log, named not start, see attached file
> Debian 12 into /etc/bind/named.conf.local
> I replace (/var/log/bind.log exist with bind user):
> logging {
>
>category default { null; };
>
> };
>
>
>
> logging {
>
> channel bind_log {
>
>file "/var/log/bind.log" versions 3 size 10m;
>
>severity info;
>
>print-category yes;
>
>print-severity yes;
>
>print-time yes;
>
>};
>
>
>
>category default { bind_log; };
>
> category lame-servers { null; };
>
> category update { bind_log; };
>
> category update-security { bind_log; };
>
>category security { bind_log; };
>
> };
>
>
>
>
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/15/24 02:43, Mark Andrews wrote:
>> Really it is very hard to help people who keep changing random things making
>> a moving
>> target. You started out with a machine at 45.225.75.8 that could reach
>> 2803:1920::c:1963
>> based on the forward zone declaration so it had to be dual stacked (both
>> IPv4 and IPv6).
>>
>> You have now added two new machines 69.162.65.138 and 192.169.93.210 which
>> may or may not
>> be able to reach 2803:1920::c:1963 and have changed the delegation to point
>> to them and they
>> return NXDOMAIN for smtp.ore.org.bo.
>>
>> Now if you have IPv4 only nameservers that need to get the zone content from
>> an IPv6 only
>> server you will need to have an intermediate dual stacked server that can
>> transfer the zone
>> content from the IPv6 only server and send it to the IPv4 only servers when
>> they request it.
>>
>> P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)
>>
>> Also read the nameserver’s logs. They will help you work out what is going
>> wrong.
>>
>> 2803:1920::c:1963 (IPv6 only):
>> zone ore.org.bo {
>> type primary;
>> file "ore.org.bo.db”;
>> };
>>
>> 45.225.75.8/ (dual stacked):
>> zone ore.org.bo {
>> type secondary;
>> file "ore.org.bo.db”;
>> primaries { 2803:1920::c:1963; };
>> };
>>
>> 69.162.65.138 (IPv4 only):
>> zone ore.org.bo {
>> type secondary;
>> file "ore.org.bo.db”;
>> primaries { 45.225.75.8; };
>> };
>>
>> Alternatively you can add IPv6 to an IPv4 only machine using services like
>> https://tunnelbroker.net/ even when the ISP does not support IPv6.
>>
>> Mark
>>
>>
>>> On 15 Jul 2024, at 11:00, Herman Brule wrote:
>>>
>>> I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have
>>> bind9):
>>> dig A ore.org.bo @199.38.247.210
>>> With on 199.38.247.210 (work):
>>> zone ore.org.bo {
>>> type master;
>>> file "/etc/bind/ore.org.bo.db";
>>> };
>>> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1232
>>> ; COOKIE: 9948d53f962
Re: qname minimisation per domain
Is it really too much effort for the servers to return NOERROR instead of an incorrect NXDOMAIN for the intermediate names? That would get rid of the log message. It’s changing 1 bit (0 vs 4 for the rcode) in the DNS header. They don’t even have to lookup if there are names below the query. The server can just assume that there are records there and return NOERROR for [0..255].zen.spamhaus.org, [0..255].[0..255].zen.spamhaus.org and [0..255].[0..255].[0..255].zen.spamhaus.org. Really we would like to be able to move to strict QNAME minimisation so we don’t need to make all the other queries after the first NXDOMAIN response but broken implementations like this are making that difficult. It’s not like this is a new requirement. A NOERROR response goes back the RFC 1034. Additionally Spamhaus controls how often resolvers re-query. 10 seconds is a very short negative response TTL. If they don’t like the query rate they can control it by returning longer negative cache responses. Named does check in the cache for negative cache entries to determine whether or not to make the intermediate QNAME minimisation queries. > On 15 Jul 2024, at 23:27, Matus UHLAR - fantomas wrote: > > Hello, > > I have noticed that especially DNS blocklist cause errors like: > > Jul 14 01:41:28 fantomas named[1854]: success resolving > 'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to > 'ncache nxdomain' > > and blocklists like spamhaus are sensitive to too many queries. > > is it possible to disable query minimisation for particular domains? > > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Atheism is a non-prophet organization. > -- > 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: strange reply dumped URGENT
Really it is very hard to help people who keep changing random things making a
moving
target. You started out with a machine at 45.225.75.8 that could reach
2803:1920::c:1963
based on the forward zone declaration so it had to be dual stacked (both IPv4
and IPv6).
You have now added two new machines 69.162.65.138 and 192.169.93.210 which may
or may not
be able to reach 2803:1920::c:1963 and have changed the delegation to point to
them and they
return NXDOMAIN for smtp.ore.org.bo.
Now if you have IPv4 only nameservers that need to get the zone content from an
IPv6 only
server you will need to have an intermediate dual stacked server that can
transfer the zone
content from the IPv6 only server and send it to the IPv4 only servers when
they request it.
P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)
Also read the nameserver’s logs. They will help you work out what is going
wrong.
2803:1920::c:1963 (IPv6 only):
zone ore.org.bo {
type primary;
file "ore.org.bo.db”;
};
45.225.75.8/ (dual stacked):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
69.162.65.138 (IPv4 only):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 45.225.75.8; };
};
Alternatively you can add IPv6 to an IPv4 only machine using services like
https://tunnelbroker.net/ even when the ISP does not support IPv6.
Mark
> On 15 Jul 2024, at 11:00, Herman Brule wrote:
>
> I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have
> bind9):
> dig A ore.org.bo @199.38.247.210
> With on 199.38.247.210 (work):
> zone ore.org.bo {
> type master;
> file "/etc/bind/ore.org.bo.db";
> };
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
> ;; QUESTION SECTION:
> ;ore.org.bo.IN A
>
> ;; ANSWER SECTION:
> ore.org.bo. 3600IN A 45.225.75.8
>
> ;; Query time: 99 msec
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
> ;; WHEN: Mon Jul 15 00:53:38 UTC 2024
> ;; MSG SIZE rcvd: 83
>
> With on 199.38.247.210 (not work):
> zone ore.org.bo {
> type secondary;
> file “/etc/bind/ore.org.bo.db”;
> primaries { 2803:1920::c:1963; };
> };
>
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
> ;; QUESTION SECTION:
> ;ore.org.bo.IN A
>
> ;; Query time: 87 msec
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
> ;; WHEN: Mon Jul 15 00:56:01 UTC 2024
> ;; MSG SIZE rcvd: 67
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/14/24 20:00, Mark Andrews wrote:
>>
>>
>>> On 13 Jul 2024, at 12:44, Herman Brule wrote:
>>>
>>> Thanks, I'm looking how solve this, cleanly.
>>> In my country only 1 ISP have IPv6, then I need keep IPv4.
>>> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
>>> Then:
>>> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
>>> correctly to all my dig query)
>>> 2) I have to provide a way to my customer can resolve query on their DNS
>>> server on their IPv6 VPS, their need be able to just put their vps dns or
>>> at least common server dns (where I had to put their zone, then I dislike
>>> this idea)
>>> For now your method fail, include I try:
>>> zone "ore.org.bo" {
>>> type master;
>>> file "/etc/bind/ore.org.bo.db";
>>> };
>>> But failed too.
>>>
>> Well I didn’t say to do that. You have they wrong type of zone. Make it a
>> secondary (slave) zone
>> like I told you to do.
>>
>> zone ore.org.bo {
>> type secondary;
>> file “ore.org.bo.db”;
>> primaries { 2803:
Re: strange reply dumped URGENT
> On 13 Jul 2024, at 12:44, Herman Brule wrote:
>
> Thanks, I'm looking how solve this, cleanly.
> In my country only 1 ISP have IPv6, then I need keep IPv4.
> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
> Then:
> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
> correctly to all my dig query)
> 2) I have to provide a way to my customer can resolve query on their DNS
> server on their IPv6 VPS, their need be able to just put their vps dns or at
> least common server dns (where I had to put their zone, then I dislike this
> idea)
> For now your method fail, include I try:
> zone "ore.org.bo" {
> type master;
> file "/etc/bind/ore.org.bo.db";
> };
> But failed too.
Well I didn’t say to do that. You have they wrong type of zone. Make it a
secondary (slave) zone
like I told you to do.
zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
Now that should work as I can AXFR the zone from that server. You should also
note the difference in
the flags in the responses for smtp.ore.org.bo. The one from 2803:1920::c:1963
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.
It also looks like someone tried to comment out *.ore.org.bo but used the wrong
comment character ‘#'
rather than ‘;’.
[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN 2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN 2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; 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: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47:47 AEST 2024
;; MSG SIZE rcvd: 88
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @45.225.75.8
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @45.225.75.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33189
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 42c6758d745eb62b0100669463baea9db7cd3474c256 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3266 IN A 45.225.75.8
;; Query time: 264 msec
;; SERVER: 45.225.75.8#53(45.225.75.8) (UDP)
;; WHEN: Mon Jul 15 09:48:10 AEST 2024
;; MSG SIZE rcvd: 88
[ant:~/git/bind9] marka%
Mark
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/12/24 19:01, Mark Andrews wrote:
>>
>>
>>> On 13 Jul 2024, at 04:38, Herman Brule via bind-users
>>> wrote:
>>>
>>> Because the customer are into IPv6 zone
>>>
>> Well all zones should be served by both IPv4 servers and IPv6 servers. IPv6
>> is nearly 30 years old now. There are
>> sites that are IPv6 only because they would prefer to not have to run
>> everything through 2 or 3 layers of NAT when
>> they don’t need it at all for IPv6 and would really like to not have to send
>> all there DNS queries though NAT64 boxes.
>>
>>
>>> And the EDGE router connecting IPv4 and IPv6 is internal to the data center
>>> company, not accessible for the customer.
>>> Forward zone to edge will be mo
Re: strange reply dumped URGENT
> On 13 Jul 2024, at 04:38, Herman Brule via bind-users > wrote: > > Because the customer are into IPv6 zone Well all zones should be served by both IPv4 servers and IPv6 servers. IPv6 is nearly 30 years old now. There are sites that are IPv6 only because they would prefer to not have to run everything through 2 or 3 layers of NAT when they don’t need it at all for IPv6 and would really like to not have to send all there DNS queries though NAT64 boxes. > And the EDGE router connecting IPv4 and IPv6 is internal to the data center > company, not accessible for the customer. > Forward zone to edge will be more complex, it's more simple just forward the > query. > Thanks for you observation, but I know, I doing this quickly, I will keep > like this for now, this will produce only problem for availability if the > server is down. Except you are wrong. You are writing here because it *is* causing you and everyone else a problem. The correct way to fix this is to transfer the zone contents to the listed primary servers if you are using nameservers. Alternatively don’t run nameservers at all but use IP level proxies. Either the whole address or port forward 53/TCP and 53/UDP. > alpha_one_x86/BRULE Herman > Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and > server management > IT, OS, technologies, research & development, security and business department > On 7/12/24 14:28, Marco Moock wrote: >> Am 12.07.2024 um 14:13:03 Uhr schrieb Herman Brule via bind-users: >> >> >>> bind to my proxy from IPv4 to IPv6 zone >>> >> Why don't you simply run multiple authoritative servers, some only >> accessible by IPv6, some dual-stack? >> >> They are independent of each other and only the zone transfer need to >> work. >> >> I also see some strange things: >> >> m@ryz:~$ host 811.vps.confiared.com. >> 811.vps.CONFIARED.com has address 45.225.75.8 >> 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963 >> m@ryz:~$ host 811b.vps.confiared.com. >> 811b.vps.CONFIARED.com is an alias for 811.vps.confiared.com. >> 811.vps.CONFIARED.com has address 45.225.75.8 >> 811.vps.CONFIARED.com has IPv6 address 2803:1920::c:1963 >> m@ryz:~$ >> >> You should have redundant servers and not 2 NS records that point to >> the same machine. >> >> Please fix that first and update your glue records. >> >> > -- > 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: strange reply dumped URGENT
Named can NOT be configured as a proxy server for an authoritative server. It
is NOT
designed to be run like that.
Forwarding is for RECURSIVE queries (made by stub resolvers) not ITERATIVE
queries (made
by recursive servers). When you specify forwarding you tell the recursive
server to behave
like a stub resolver for the specified namespace rather than being an iterative
resolver.
Transfer the zone from the hidden primary rather than configuring forward mode.
zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
Mark
> On 13 Jul 2024, at 04:13, Herman Brule via bind-users
> wrote:
>
> Hi,
> I have dns problem, mostly show by dig A smtp.ore.org.bo @8.8.8.8
> Then I have dump the connection by dumpcap, the raw reply by bind is wrong.
> As attached file:
> - dump of ethernet interface
> I have into /etc/bind/named.conf.rproxy:
> zone "ore.org.bo" {
>type forward;
>forward only;
>forwarders { 2803:1920::c:1963; };
> };
> /etc/bind/named.conf have:
> include "/etc/bind/named.conf.rproxy";
> bind to my proxy from IPv4 to IPv6 zone
> dig A smtp.ore.org.bo @45.225.75.8
> show me correct reply
> dig A smtp.ore.org.bo @2803:1920::c:1963
> show me correct reply
> --
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> --
> 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: qname minimization: me too :(
I should add that a resolver should be able to stop on the first NXDOMAIN. It’s only because we know there are mis-implementations of the protocol (returning NXDOMAIN rather that NOERROR for empty non-terminals) and mis-configurations (missing delegating NS records) that the default is to continue. If people where willing to put up with NXDOMAIN being returned rather than the data that is later found by continuing or not using QNAME minimisation the default could be changed. 'But it “works" when I ask Google' is a hard thing to fight against. Mark > On 25 Jun 2024, at 07:00, Mark Andrews wrote: > > It’s just a false positive when the result is NXDOMAIN. Because people forget > to put delegating NS records in parent zones when both are served by the same > server the lookups continue on NXDOMAIN. There is an issue to address this. > > -- > Mark Andrews > >> On 25 Jun 2024, at 06:36, Peter wrote: >> >> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote: >> ! On Fri, Jun 21, 2024 at 07:03:14AM +, >> ! 65;6800;1c Michael Batchelder wrote >> ! a message of 59 lines which said: >> ! >> ! > You'll need to fix these zones so that the response is NOERROR rather >> than NXDOMAIN. >> ! >> ! Yes and, if you want the whole context, you can read RFC 8020 >> ! <https://www.rfc-editor.org/info/rfc8020> and section 4 of RFC 7816 >> ! <https://www.rfc-editor.org/info/rfc7816>. >> >> >> Sure, I did that already. And I also talked to the maintainer of >> ns*.he.net, i.e. this one: >> >> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with >> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa >> ! > >> ! > You'll need to fix these zones so that the response is NOERROR rather >> than NXDOMAIN. >> >> And they seem to think, there is nothing wrong with that, because >> nobody ever has complained about that. >> >> >> Now I am really wondering: why do I, an unemployed old guy just >> running his own computer, suddenly find myself in between a root >> operator and the biggest v6 network on the planet? >> >> In other words: why do You guys no longer talk to each other? >> >> >> cheerio, >> PMc >> -- >> 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: qname minimization: me too :(
It’s just a false positive when the result is NXDOMAIN. Because people forget to put delegating NS records in parent zones when both are served by the same server the lookups continue on NXDOMAIN. There is an issue to address this. -- Mark Andrews > On 25 Jun 2024, at 06:36, Peter wrote: > > On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote: > ! On Fri, Jun 21, 2024 at 07:03:14AM +, > ! 65;6800;1c Michael Batchelder wrote > ! a message of 59 lines which said: > ! > ! > You'll need to fix these zones so that the response is NOERROR rather > than NXDOMAIN. > ! > ! Yes and, if you want the whole context, you can read RFC 8020 > ! <https://www.rfc-editor.org/info/rfc8020> and section 4 of RFC 7816 > ! <https://www.rfc-editor.org/info/rfc7816>. > > > Sure, I did that already. And I also talked to the maintainer of > ns*.he.net, i.e. this one: > > ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with > NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa > ! > > ! > You'll need to fix these zones so that the response is NOERROR rather > than NXDOMAIN. > > And they seem to think, there is nothing wrong with that, because > nobody ever has complained about that. > > > Now I am really wondering: why do I, an unemployed old guy just > running his own computer, suddenly find myself in between a root > operator and the biggest v6 network on the planet? > > In other words: why do You guys no longer talk to each other? > > > cheerio, > PMc > -- > 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 I provide invalid HTTPS values for testing?
> On 20 Jun 2024, at 15:29, Michael Richardson wrote: > > > Mark Andrews wrote: >> Named and nsupdate validate input for types they know about (both text >> and wire). You would have to use versions that are not HTTPS aware and >> use unknown type format. > > So, he could code it in Perl or Python or something which had a dynamic DNS > library. Bind itself wouldn't validate the "ascii-hex" part when it receives > it. Named will reject HTTPS records that it can determine are invalid. This includes in UPDATE requests. The server will return FORMERR to the dynamic update client. See lib/dns/rdata/in_1/svcb_64.c for all the checks performed. -- 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: can I provide invalid HTTPS values for testing?
Named and nsupdate validate input for types they know about (both text and wire). You would have to use versions that are not HTTPS aware and use unknown type format. Mark > On 20 Jun 2024, at 11:39, Stephen Farrell wrote: > > > Hiya, > > Apologies if this is a repeat, I spent a bit of time looking > but didn't find stuff... > > I'd like to publish various HTTPS RRs with dodgy encodings > in order to test which clients handle things well or badly. > > Were it possible to use nsupdate for that, that'd make my > life simpler, but I've not found a way to do that so far. > > What I'd like to be able to do in nsupdate would be like: > > update add example.com 300 HTTPS > > Where the ascii-hex value is some (broken) variant of what > I'd get from: > > dig +unknownformat https example.com > > Is there a way to do that? > > Thanks in advance, > Stephen. > > -- > 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: SERVFAIL error during the evening
Before you do anything else change your rndc shared key as you published it. > On 14 Jun 2024, at 01:00, sami.ra...@sofrecom.com wrote: > > Hello community, > We are experiencing a resolution problem: 'SERVFAIL error'. Our environment > is BIND 9.16.48, OS: Redhat8. I am sharing with you a part of the log that > contains this error, named.conf file. > What I've noticed is that the resolution problem is mainly related to domain > names that contain a CNAME record in the response, such as > 'account.api.here.com' and 'push-rtmp-l96.douyincdn.com' > P.S. DNSSEC is temporarily disabled to facilitate the diagnosis of the issue. > Regards 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 -- 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: Reuse RPZ zones between views
Have you read the fine documentation on BIND where it is stated this is not
(currently) possible?
If you want to extend named to support this we would be happy to review a
change request. It is complicated however which is why it has not been done.
--
Mark Andrews
> On 13 Jun 2024, at 02:38, Jesus Cea wrote:
>
> My RPZ zones are quite big, and I would like to be able to reuse them in
> several views sharing the memory instead of independent data structures.
>
> I thought that zone "in-view" would work, but it doesn't.
>
> I am doing something like:
>
> """
> view honeypot {
>match-clients { honeypot; };
>allow-recursion { honeypot; };
>
>zone "rpz" {
> type slave;
> [...];
>};
>response-policy {
>zone "rpz" policy disabled; //cname prueba.xx.xx;
> } break-dnssec yes;
> };
>
> view default {
>match-clients { any; };
>allow-recursion { any; };
>zone "rpz" { in-view "honeypot"; };
>response-policy {
> zone "rpz";
>} break-dnssec yes;
> };
> """
>
> Trying to activate that configuration produce an error:
>
> """
> response-policy zone 'rpz' for view default is not a primary or secondary zone
> """
>
> But "rpz" is secondary (slave) in "honeypot"
> I would think this a bug in bind?. I am using version 9.18.25.
>
> Any suggestion beside loading the "rpz" zone separately in each view?. That
> would explode my memory usage (I have quite a few views).
>
> --
> 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
--
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 default - where/how to determine what all its settings are?
elsewhere. >> There doesn't even seem to be an rndc command that can list >> defined dnssec-policy sets that are in place, nor that >> can list how they're configured. This information should be much more >> visible/findable, so ... where is it? I'm sure it must be present >> somewhere in the source, but haven't easily located it by searching. >> Shouldn't be necessary to run debugging to track down where this is >> and where in the source it comes from. So ... where does one find it? >> >> I've been looking at Debian BIND9 packages: >> bind9 1:9.18.24-1 >> bind9-doc 1:9.18.24-1 >> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation. >> -- >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >> this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> >> >> -- >> - Andrew "lathama" Latham - >> >> >> -- >> - Andrew "lathama" Latham - >> > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: Problem with a certain domain
you just want ‘port 53’. src throws away half of the transaction. > On 5 Jun 2024, at 07:32, Michael Batchelder wrote: > > Thomas, > > I just incorrectly wrote: > > > So at minimum add "icmp and arp" to your filter expression. > > I did not mean to use the logical "and". Your minimum filter should be > something like: > > "src port 53 or icmp or arp" > > Sorry for the confusion, > Michael > > Michael Batchelder > ISC Support > -- > 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: Debugging TSIG signed nsupdate problems
> print-time yes;
> };
>
> category default { default_file; };
> category general { general_file; };
> category database { database_file; };
> category security { security_file; };
> category config { config_file; };
> category resolver { resolver_file; };
> category xfer-in { xfer-in_file; };
> category xfer-out { xfer-out_file; };
> category notify { notify_file; };
> category client { client_file; };
> category unmatched { unmatched_file; };
> category queries { queries_file; };
> category network { network_file; };
> category update { update_file; };
> category dispatch { dispatch_file; };
> category dnssec { dnssec_file; };
> category lame-servers { lame-servers_file; };
> };
>
> with 'rndc trace 99', all files except /var/log/named/update.log receive
> copious amounts of information. The update log receives only the REFUSED line
> like 'rndc trace 1' below.
>
> With rndc trace 1 and single file logging I get:
> 26-May-2024 23:23:59.522 info: client @0x7fb4df8ad968 :
> updating zone '/IN': update failed: rejected by secure update
> (REFUSED)
>
> at rndc trace 7:
> 26-May-2024 23:26:21.611 debug 3: client @0x7fb4e4739568 #42321:
> UDP request
> 26-May-2024 23:26:21.612 debug 5: client @0x7fb4e4739568 #42321:
> using view '_default'
> 26-May-2024 23:26:21.612 debug 3: client @0x7fb4e4739568 #42321:
> request has valid signature:
> 26-May-2024 23:26:21.612 debug 3: client @0x7fb4e4739568 #42321/key
> : recursion available
> 26-May-2024 23:26:21.612 info: client @0x7fb4e4739568 #42321/key
> : updating zone '/IN': update failed: rejected by secure
> update (REFUSED)
Post your update-policy and the complete UPDATE message. The update is being
rejected by the policy. Unless you have a grant for every change in the UPDATE
section the result will be REFUSED. My hunch is that you allow A updates but
disallow updates and with the OS upgrade records are now being
updated.
You wanted to have your UPDATE messages succeed yet you continued to focus on
logging rather than supplying the UPDATE related configuration after being
requested to go back to the beginning. There really isn’t a security issue
with posting names and address. There is a myth that doing so will make you
insecure. It is just that a myth. Not posting them just makes it harder for
other people to help you.
Mark
> From nsupdate:
>
> nsupdate -L99 -dD -k TrueNAS.key nsupdate-cmds-py.txt
>
> show_message()
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 13334
> ;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 9, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;.INSOA
>
> ;; PREREQUISITE SECTION:
> . 0 ANYANY
>
> ;; UPDATE SECTION:
> . 0 ANYA
> . 0 ANY
> . 300 IN A
> . 300 IN
> . 300 IN A
> . 300 IN
> . 300 IN A
> . 300 IN A
> . 300 IN
>
> ;; TSIG PSEUDOSECTION:
> .0ANYTSIG . 1716789240 300 32
> NOERROR 0
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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: Debugging TSIG signed nsupdate problems
Start from the beginning. Show the actual configuration (named.conf, K* files, etc.). X out the secret keys. Show the actual commands you are running. Show the actual logs being produced. REFUSED can come from lots of things. Named emits log messages for almost all of them without needing to turn on debugging. Stop making us guess which version you BIND you upgraded from. This bind-users, not Fedora support. F36-F39 is meaningless here. If you are using nsupdate to send the UPDATE request turn on its debugging. At the moment all you have said is that you have a problem but have given NOTHING for people to work with to help you. Mark > On 27 May 2024, at 13:39, Mark Andrews wrote: > > > >> On 25 May 2024, at 03:25, Erik Edwards via bind-users >> wrote: >> >> algorithm hmac-sha256; >> >> named-checkconf -p shows the key with the matching name, algo, and secret. >> >> When I mis-configure, change, or typo the secret it returns "BAD SECRET" >> >> The error I'm seeing is "REFUSED" on a config that worked until the upgrade. >> It worked on F36-F39, upgrades were seamless. >> >> Really wondering how to get debug level logs on this module. >> >> On 5/24/24 11:31 AM, John Thurston wrote: >>> named-conf -px >> >> -- >> 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: named fails to start with bind-9.18.0
As Ondrej said. Upgrade. You compiled BIND 9.18.0. That is 27 release behind current. Unless you are doing archaeological investigations of old code you shouldn’t be trying to use old code like that. Running newer code means that you can avoid all the bugs that have been fixed in the meantime. Named logs what it finds wrong to syslog by default. Read your logs. You can also run named in the foreground and send the logs to stderr. named -g -c /etc/named.conf’ Due to Linux’s co-operating processes as its threading model, named can’t just daemonize once it has finished its startup phase. It has to daemonize then finish its startup. The parent process waits for the startup to complete and then exits with an appropriate error code. Somewhere in that startup something has failed. Mark > On 21 May 2024, at 14:10, avijeet gupta wrote: > > My Apologies. I was just trying to show the snippet of bind library code > where named was failing. > > I am trying to run named after compiling the bind library. The command I use > to run named is as follows: > > /bin/named -c /etc/named.conf > > It appears that it is failing when it tries to daemonize named. what could be > causing it ? > > named will eventually run as daemon in my dns server. > > Please let me know if more information is needed. > > Thanks, > Avi > > > > On Mon, May 20, 2024 at 10:47 AM Ondřej Surý wrote: >> Can someone please help what could be the issue here? > > > Not really. First start by using the latest 9.18 version and not something > that’s two years old and then you need to provide more information than a > screenshot of random code snippet. If you want free help you need to provide > information about what you are actually doing. > > This old essay is still true: > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > Ondrej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 20. 5. 2024, at 17:55, avijeet gupta wrote: >> >> Hi All, >> >> I compiled bind-9.18.0 successfully but when I try to run named via >> configuration file, named exits with return code 1. >> >> The below code in bin/named/os.c is where it is failing. >> >> >> >> >> When i run named with gdb , i see that it is exiting in the above code. >> >> Can someone please help what could be the issue here? >> >> Thanks, >> Avij >> >> -- >> 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: RFC8482: Implementation through HINFO record
And named already handles ANY being used as an reflection amplifier. This was written for servers using databases where getting the ANY response is actually hard. Cloudflare was using a response model that most thought was not really correct but wasn’t broken enough to say “Don’t do that”. If their customers where happy with this behaviour then ok. This RFC was written to allow them to continue doing what they where doing without having to fight that they where not RFC compliant. It was not written to say this is how you should respond to ANY. It also requires online signing for DNSSEC or adding a HINFO record for every name in your zone when offline signing. Mark -- Mark Andrews > On 21 May 2024, at 00:31, Ondřej Surý wrote: > > I would suggest you to create a feature request in our GitLab. This way it > won't get lost > in the tides of time. > > Personally, I actually quite like the idea, but it would have to be an option > to turn off and on, > so it's not going to save us from having a code that supports ANY anyway. > > Ondřej > -- > 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. > >> On 20. 5. 2024, at 16:03, Amaury Van Pevenaeyge >> wrote: >> >> Hello everyone, >> >> How is it possible to set up a resource record of type HINFO so that it is >> returned on every ANY request without all the other records in the zone? I'm >> looking to implement RFC8482 as Cloudflare can do in the following article: >> https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any >> >> Thanks in advance for your help. >> -- >> 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: RFC8482: Implementation through HINFO record
Named does not support this. There is no requirement to support this. -- Mark Andrews > On 21 May 2024, at 00:04, Amaury Van Pevenaeyge > wrote: > > > Hello everyone, > > How is it possible to set up a resource record of type HINFO so that it is > returned on every ANY request without all the other records in the zone? I'm > looking to implement RFC8482 as Cloudflare can do in the following article: > https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any > > Thanks in advance for your help. > -- > 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: Missing cookie
> On 20 May 2024, at 07:37, J Doe wrote: > > Hi list, > > I run a validating recursive resolver with BIND 9.18.27. Over the > course of many days, I have noted the following warning about a missing > cookie from a particular server: > >09-May-2024 20:09:22.277 resolver: info: missing expected cookie >from 192.5.5.241#53 > > This server runs in the cloud with excellent connectivity, I don't do > anything special with my firewall and I do not run any software that > would mutate the DNS data over port 53. > > What could be causing the cookie to not be received from this particular > server over a number of days ? > > Thanks, > > - J Named keeps track of where it has received DNS COOKIE responses from and expects to get one if it has received one before from that address. Depending upon the version named will fallback to TCP if it thinks that is should have got a DNS COOKIE responses but didn’t. Having different server capabilities in an anycast server can lead to this message being logged. Also spoofing attempts can lead to this message. As for 192.5.5.241 the instances run by Cloudflare on ISC’s behalf don’t support DNS COOKIE where as those run by ISC directly do. Changes in routing can mean that the particular instance that answers your query will change. Mark > -- > 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: queries for "_.domain"
Correct. Later versions use NS queries as that allows named to cache the non-existence of the NS RRset. Using _.domain doesn’t allow that to happen. NS queries do however expose broken delegations. Make sure you have working NS records at the zone apex and at the delegation point. This is especially important when the server serves multiple levels in the zone hierarchy as intermediate delegations are often not seen without QNAME minimisation but are with QNAME minimisation. We have had bug reports due to all delegating NS records referring to non-existing servers. We have had bug reports due to garbage records at the zone apex. Mark -- Mark Andrews > On 17 May 2024, at 23:31, Stephane Bortzmeyer wrote: > > On Fri, May 17, 2024 at 03:25:01PM +0200, > Matus UHLAR - fantomas wrote > a message of 43 lines which said: > >> I have noticed that BIND sends strange (for me) queries. >> >>5 0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A >> _.net.akadns.net OPT > > QNAME minimisation (RFC 9156), probably? > -- > 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: Special-use names and RPZ
> On 15 May 2024, at 04:34, John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > • invalid. > • test. > • onion. > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) > >> caching DNS servers SHOULD, by default, generate immediate negative >> responses for all such queries. > > RFC 7686 (onion. Section 2.4) > >> where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to >> look up records for .onion names. They MUST generate NXDOMAIN for all such >> queries. > > Is there some reason these should not just be hammered into our RPZ ? Because despite what you quote above, having a resolver generate negative results without appropriate NSEC and RRSIG records actually causes problems when they are sent by validating clients. Having a local copy of the root zone and returning answers from that suppresses the traffic and the answers are verifiable. > -- > -- > 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: Truncated TCP ?
> On 6 May 2024, at 07:38, J Doe wrote: > > Hello, > > I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I > noticed the following: > >01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response >resolving 'www.ipfire.org/A/IN': 74.113.60.134#53 > > I am aware that there are issues with DNS UDP traffic being truncated > and/or rejected via firewalls or middle-boxes that enforce limits on > expected packet size (I believe one of the goals of a recent Flag Day > was to address these configs), but what would lead to truncated TCP > traffic in the context of DNS ? Usually it is a software bug in the server where it doesn’t support 65535 byte responses or incorrectly applies UDP limits to TCP. Very occasionally the response actually won’t fit in 65535 bytes. Whatever it was I’m not seeing it now. Mark > 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
> On 1 May 2024, at 22:25, Walter H. via bind-users > wrote: > > On 01.05.2024 01:33, Mark Andrews wrote: >> >>> On 1 May 2024, at 03:32, Lee wrote: >>> >>> On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: >>>> On 29.04.2024 22:19, Lee wrote: >>>>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >>>>> wrote: >>>>> >>>>> something that I replied to and got this in response: >>>>> >>>>> Error Icon >>>>> Message blocked >>>>> Your message to Walter.H@[..snip..] has been blocked. See technical >>>>> details below for more information. >>>>> >>>>> The response from the remote server was: >>>>> 554 5.7.1 : Client host rejected: Use IPv4 >>>>> >>>>> >>>> For explanation: this is MY mail server, which blocks IPv6 connections from >>>> >>>> Outlook.com >>>> Gmail.com >>>> ... >>>> >>>> as these are the biggest SPAM senders >>> Which is fine .. your server, your rules. >>> But maybe what isn't so fine is me replying only to the list and still >>> getting a 'rejected: Use IPv4' msg. I don't know how the mailing list >>> works; I'm a bit surprised that I can reply only to the list, get the >>> Client host rejected msg and somehow you can still get the msg?? > > there are 2 pair of shoes, mails from the list are not from Outlook.com or > Gmail.com > > but if you put my mail address to "To: ", then its from Gmail.com ;-) > >> This is >> what happens when you put something into the rejection rules which has zero >> relationship whether something is spam or ham. > depends ... >> I just find it interesting that someone using mx01.ipv6help.de as a MX would >> be >> so interested in punishing IPv6 use. > > you are mixing up 2 independent things ... > > IPv6 clients aren't blocked at all, just Outlook.com, Gmail.com, ... > > that is the difference; just for Outlook.com the following fact is true but > bullshit > > # host -t MX outlook.com > outlook.com mail is handled by 5 outlook-com.olc.protection.outlook.com. > # host outlook-com.olc.protection.outlook.com > outlook-com.olc.protection.outlook.com has address 52.101.8.47 > outlook-com.olc.protection.outlook.com has address 52.101.9.15 > outlook-com.olc.protection.outlook.com has address 52.101.40.30 > outlook-com.olc.protection.outlook.com has address 52.101.194.14 > # > > as you see no IPv6 at all; > > why then the need of accepting their SPAM on IPv6 transport? Well lets look at the sender that started this thread. % dig mx gmail.com +short 40 alt4.gmail-smtp-in.l.google.com. 5 gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. % dig gmail-smtp-in.l.google.com +short 2404:6800:4003:c01::1b % % dig txt gmail.com +short "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=" "v=spf1 redirect=_spf.google.com" % dig txt _spf.google.com +short "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" dig txt _netblocks2.google.com +short "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all" % Which we verify then sign to say that we have verified the incoming email. But for you email from @gmail.com over IPv6 is “proof” that it is spam and you send back a rejection which says to send it again over IPv4 when none of the senders has any control over the transport being used and no one is going to add special rules to force email to you to go over IPv4 when you advertise MX servers with addresses. Mark > -- > 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-analyzer.verisignlabs.com aaaa lookup fail
> On 1 May 2024, at 03:32, Lee wrote: > > On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: >> >> On 29.04.2024 22:19, Lee wrote: >>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >>> wrote: >>> >>> something that I replied to and got this in response: >>> >>> Error Icon >>> Message blocked >>> Your message to Walter.H@[..snip..] has been blocked. See technical >>> details below for more information. >>> >>> The response from the remote server was: >>> 554 5.7.1 : Client host rejected: Use IPv4 >>> >>> >> For explanation: this is MY mail server, which blocks IPv6 connections from >> >> Outlook.com >> Gmail.com >> ... >> >> as these are the biggest SPAM senders > > Which is fine .. your server, your rules. > But maybe what isn't so fine is me replying only to the list and still > getting a 'rejected: Use IPv4' msg. I don't know how the mailing list > works; I'm a bit surprised that I can reply only to the list, get the > Client host rejected msg and somehow you can still get the msg?? Presumably ISC sent the list message over IPv6 to them and the rejection rules kicked in. ISC sends email over IPv6 and they accept email over IPv6. This is what happens when you put something into the rejection rules which has zero relationship whether something is spam or ham. I just find it interesting that someone using mx01.ipv6help.de as a MX would be so interested in punishing IPv6 use. > Anyway.. best regards > Lee > -- > 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-analyzer.verisignlabs.com aaaa lookup fail
And it has been fixed. % dig dnssec-analyzer.verisignlabs.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9048 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 9fcb48e259ddaedd010066308ef2d1dcce4f0e1ca7fe (good) ;; QUESTION SECTION: ;dnssec-analyzer.verisignlabs.com. IN ;; ANSWER SECTION: dnssec-analyzer.verisignlabs.com. 3600 IN CNAME dnssec-analyzer-verisignlabs.gslb.verisign.com. ;; AUTHORITY SECTION: gslb.verisign.com. 60 IN SOA gslb.ilg1.verisign.com. hostmaster.gslb.ilg1.verisign.com. 2024041709 10800 3600 604800 60 ;; Query time: 1155 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Tue Apr 30 16:25:54 AEST 2024 ;; MSG SIZE rcvd: 203 % > On 30 Apr 2024, at 06:55, Lee wrote: > > On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: >> >> It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it >> serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is >> actually delegated to it. >> >> % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all >> ;; BADCOOKIE, retrying. >> >> ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer-gslb.verisignlabs.com >> +trace +all >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37498 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 > <.. snip lots ..> > >> ;; AUTHORITY SECTION: >> com. 60 IN SOA this.name.is.invalid. hostmaster.this.name.is.invalid. >> 2023030710 10800 3600 604800 60 > > I did a search for "this.name.is.invalid" and the only results I got > were for F5 support pages - eg. > The fix in BIG-IP DNS 14.1.0 introduces a new setting, > wideip-zone-nameserver, which defaults the WideIP zone nameserver to > this.name.is.invalid. > > Wouldn't a badly configured F5 server be a better explanation? > > Thanks > Lee -- 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-analyzer.verisignlabs.com aaaa lookup fail
> On 30 Apr 2024, at 13:39, Walter H. via bind-users > wrote: > > On 29.04.2024 22:19, Lee wrote: >> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >> wrote: >> >> something that I replied to and got this in response: >> >> Error Icon >> Message blocked >> Your message to Walter.H@[..snip..] has been blocked. See technical >> details below for more information. >> >> The response from the remote server was: >> 554 5.7.1 : Client host rejected: Use IPv4 >> >> > For explanation: this is MY mail server, which blocks IPv6 connections from > > Outlook.com > Gmail.com > ... > > as these are the biggest SPAM senders As far as I know they deliver email over both IPv4 and IPv6 (spam and ham) independently of the transport. The only thing that blocking one transport like this does is cause email to be unreliable. The sender has no control over the transport protocol used. > -- > 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-analyzer.verisignlabs.com aaaa lookup fail
I prefer to only name and shame when I’m 100% sure of the target. -- Mark Andrews > On 30 Apr 2024, at 06:56, Lee wrote: > > On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: >> >> It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it >> serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is >> actually delegated to it. >> >> % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all >> ;; BADCOOKIE, retrying. >> >> ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer-gslb.verisignlabs.com >> +trace +all >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37498 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 > <.. snip lots ..> > >> ;; AUTHORITY SECTION: >> com. 60 IN SOA this.name.is.invalid. hostmaster.this.name.is.invalid. >> 2023030710 10800 3600 604800 60 > > I did a search for "this.name.is.invalid" and the only results I got > were for F5 support pages - eg. > The fix in BIG-IP DNS 14.1.0 introduces a new setting, > wideip-zone-nameserver, which defaults the WideIP zone nameserver to > this.name.is.invalid. > > Wouldn't a badly configured F5 server be a better explanation? > > Thanks > Lee -- 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-analyzer.verisignlabs.com aaaa lookup fail
And the SMTP server doesn’t need to listen on IPv6 if it isn’t going to accept messages over that transport. Talk about a way to DoS yourself. -- Mark Andrews > On 30 Apr 2024, at 06:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > wrote: > > something that I replied to and got this in response: > > Error Icon > Message blocked > Your message to Walter.H@[..snip..] has been blocked. See technical > details below for more information. > > The response from the remote server was: > 554 5.7.1 : Client host rejected: Use IPv4 > > > > Which is strangely appropriate when trying to troubleshoot an issue > that applies only to IPv6. > But I've forgotten how to turn off IPv6 :( > -- > 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
l+c8KTZtM5DjNiTlHgYnXvnqENfRR9lervjCw PA/wbmrRwRyuaI8jXaOwKiH9N6/VyskkdtmhN/0MWUOXQ00M3HtPFRKh 5zs= ;; Query time: 222 msec ;; SERVER: 2001:500:127::30#53(y.arin.net) (UDP) ;; WHEN: Mon Apr 29 10:32:26 AEST 2024 ;; MSG SIZE rcvd: 399 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8021 ;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ; COOKIE: cd143583dd37c5d0011dc0242cf583ffbc0df6c25bae1d15235d6b1ee4 (good) ;; QUESTION SECTION: ;180.96.34.in-addr.arpa. IN NS ;; ANSWER SECTION: 180.96.34.in-addr.arpa. 21600 IN NS ns-gce-public2.googledomains.com. 180.96.34.in-addr.arpa. 21600 IN NS ns-gce-public4.googledomains.com. 180.96.34.in-addr.arpa. 21600 IN NS ns-gce-public1.googledomains.com. 180.96.34.in-addr.arpa. 21600 IN NS ns-gce-public3.googledomains.com. 180.96.34.in-addr.arpa. 21600 IN RRSIG NS 8 5 21600 20240518200316 20240426200316 2580 180.96.34.in-addr.arpa. a/v8r8emi3sMgoZXB9G6YG2+UyVpkcwP6V2GF7XhftKjVLxCHOviqLnI shoUfklqEXMLtdBTdzrZNMoWGfwTK3HfiqvhWQCPZVuzPpomwSX1YcXC BaNJ+ww+HRIiXLvxWlE0dFU+RwRCUID4nwnSU//7pQwXn5CIwN0SWNeP wGU= ;; Query time: 282 msec ;; SERVER: 2001:4860:4802:34::66#53(ns-gce-public2.googledomains.com) (UDP) ;; WHEN: Mon Apr 29 10:32:26 AEST 2024 ;; MSG SIZE rcvd: 399 % > On 28 Apr 2024, at 10:13, J Doe wrote: > > On 2024-04-26 16:45, Josh Kuo wrote: > >>In this particular case, isn't the resolver attempting to do a reverse >>lookup of the IP address that's listed ? >> >> >> You are right, I missed that this is a reverse-mapping zone. In that >> case, run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and >> you'll see the problem. Reverse-mapping zones work the same as >> forward-mapping zones, they also need to be delegated properly. >> >> If you prefer a more visual output, try DNSViz: >> https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/ >> <https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/> > > Hi Josh, > > Ok, sounds good! > > - 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
UERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> Lee > > this can't be a matter of DNSSEC, as there are only signed whole zones and > not just single DNS-records ... > > would it be a problem with just this DNS zone, why are only problems getting > the IPv6? > > > -- > 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 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
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: 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: 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: "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: 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: 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: 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: 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: 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
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: 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: 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: 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: 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: 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: 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
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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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
