Re: DNSSEC implementation on IPv6 PTR Zones

2021-11-18 Thread Mark Andrews
You do it exactly the same as any other zone.  You create DNSKEYs. You sign the 
zone. You add DS records to the parent zone. 

-- 
Mark Andrews

> On 18 Nov 2021, at 20:28, Divya  wrote:
> 
> 
> Dear Admin,
> 
> Has anybody implemented  DNSSEC on IPv6 reverse  zones?
> Kindly help us to configure DNSSEC on reverse zones of IPV6 segment with BIND 
> 9.17.16+CentOS  7.9.
> 
> With Thanks & Regards 
> Divya 
> 
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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-Slave with IPv6 only?

2021-11-07 Thread Mark Andrews
Use notify-explicit. 

-- 
Mark Andrews

> On 7 Nov 2021, at 20:30, Walter H. via bind-users  
> wrote:
> 
> Hello,
> 
> I have this situation:
> 
> both the master and the slave are dualstack (have both an IPv4 and IPv6 
> address),
> but the master is not reachable on IPv4 (RFC1918 IPv4 without a port 
> forwarding);
> 
> how can I prevent the following on slave side's log:
> 
> Nov  7 10:23:01 nilsholgerson named[20881]: client 17.17.17.17#27763: view 
> auth: received notify for zone '...'
> Nov  7 10:23:01 nilsholgerson named[20881]: zone .../IN/auth: refused notify 
> from non-master: 17.17.17.17#27763
> 
> named.conf on master has this:
> 
>   notify-source 0.0.0.0;
>   transfer-source 0.0.0.0;
> 
> the same in named.conf on slave;
> 
> Thanks,
> Walter
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 service suddenly fails to start

2021-11-05 Thread Mark Andrews
Check-names in enforced by UPDATE independent of the format the zone is stored in.  Named-compilezone will also reject by default.   -k mode  This  option  performs  check-names  checks  with  the  specified  failure  mode.   Possible  modes are fail (the default for named-compilezone), warn (the default for  named-checkzone), and ignore.the code to read in raw format doesn’t do check-names processing.  It is assumed that named-compilezone and UPDATE checks in named are enough.  We could slow down the load a little by adding check-name checks on that path as well if needed. On 6 Nov 2021, at 00:03, Petr Menšík  wrote:I am not 100% sure, but what format of the zone were used?I think this should be usually catched by default check-names value on master zones. However, in masterfile-format, I found this sentence [1]:In particular, check-names checks do not apply for the raw format.Does that mean dynamic updated zones saved in raw format would never have check-names active, both on dynamic updates and on (re)start of named? I have not tested it yet, but it might be somehow hard to avoid. I found no details about dynamic updates related in check-names. I think it should refuse such updates on primary server, but not sure that is enforced. Especially if zone file format is raw.Cheers,Petr1. https://bind.isc.org/doc/arm/9.11/Bv9ARM.ch06.html#options_grammarOn 11/4/21 20:27, Bruce Johnson via bind-users wrote:On Nov 4, 2021, at 12:01 PM, Bruce Johnson  wrote:This morning our server started failing to reload or start. checking the status reveals not a lot of info:systemctl status named-chroot● named-chroot.service - Berkeley Internet Name Domain (DNS)  Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled)  Active: failed (Result: exit-code) since Thu 2021-11-04 11:55:17 MST; 27s ago Process: 2020 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exit>named-checkconf -z revealed a name had been entered with underscores. The person responsible has been sacked. (not really, merely reminded no underscores are allowed in A records :-)Does named-checkzone not check for this? -- Bruce JohnsonUniversity of ArizonaCollege of PharmacyInformation Technology GroupInstitutions do not have opinions, merely customs___Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Petr MenšíkSoftware EngineerRed Hat, http://www.redhat.com/email: pemen...@redhat.comPGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB___Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Mark Andrews, ISC1 Seymour St., Dundas Valley, NSW 2117, AustraliaPHONE: +61 2 9871 4742  INTERNET: ma...@isc.org___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 service suddenly fails to start

2021-11-04 Thread Mark Andrews


> On 5 Nov 2021, at 07:11, Grant Taylor via bind-users 
>  wrote:
> 
> On 11/4/21 1:27 PM, Bruce Johnson via bind-users wrote:
>> named-checkconf -z revealed a name had been entered with underscores. The 
>> person responsible has been sacked. (not really, merely reminded no 
>> underscores are allowed in A records :-)
> 
> You might want to apologize to them.
> 
> Underscores are legitimate in DNS record owner names, despite the 
> disagreement of their use in hostnames.
> 
> Underscores are used in _acme-challenge., TLSA records 
> _25._tcp._smtp., and DMARC _dmarc. to name a few 
> legitimate uses.  (from a quick `fgrep dig $HISTFILE | fgrep _`)
> 
> Remember, DNS is (a lot more) than /just/ hostnames.

If the policy is no underscores in A record then there is nothing to apologise 
for.  Additionally publishing A records with non LDH owners and expecting them 
to work in the context of address lookups is asking for trouble.

Sane software checks responses from the DNS.  There are lots of security issues 
if you don’t.

https://storage.googleapis.com/site-media-prod/meetings/NANOG83/2399/20211101_Jeitner_Injection_Attacks_Reloaded__v1.pdf

> -- 
> Grant. . . .
> unix || die
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.22 - rndc reload not sending to secondaries.

2021-11-03 Thread Mark Andrews
Read up on NOTIFY. Secondaries poll the primary for changes based on SOA 
timers. NOTIFY informs the secondaries to poll earlier. Named uses the NS 
records to find the default set on machines to send NOTIFY messages to.

> On 4 Nov 2021, at 08:08, Speagle, Andy via bind-users 
>  wrote:
> 
> Hi Team,
> 
> I'm not a bind expert... we're upgrading from 9.11 to 9.16 as we
> migrate to new servers... and for some reason we can't get zone
> transfers working from the primary to secondary.
> 
> We have this directive in our options for named.conf 
> 
> allow-transfer { secondaries; };
> 
> and of course... an acl later in the named.conf
> 
> acl secondaries { x.x.x.x; };
> 
> I watch the logs on the secondary... and make a change to a zone on the
> primary... update the serial... run an rndc reload...
> 
> Yet... I see nothing on the secondary.
> 
> Anyone have any clues or hints?
> -- 
> Andy Speagle
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: ECS-IP in the RPZ-Log?

2021-10-27 Thread Mark Andrews
Submit a issue at https://gitlab.isc.org/

> On 28 Oct 2021, at 01:00, Tom  wrote:
> 
> Hi
> 
> Using BIND-9.16.21. I'm wondering, if it's possible to have the ECS client IP 
> address in the RPZ log.
> In front of our BIND, which has an RPZ configuration, is a dnsdist, which 
> inject the ECS-IP.
> 
> BIND could log the ECS-IP with the builtin "querylog" (rndc querylog on). In 
> the following example, the effective client-IP is 172.16.16.33/32, which is 
> logged fine here:
> 27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 
> 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 
> 172.16.16.33/32/0]
> 
> 
> But in the RPZ log, I can correctly see only the dnsdist IP and not the one 
> from the effective source (172.16.16.33):
> 27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 
> (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via 
> example.ch.blacklist-rpz.test.local
> 
> Is there a way to have/see the ECS-IP in the RPZ log?
> 
> Many thanks.
> Kind regards,
> Tom
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Certbot rfc2136

2021-10-26 Thread Mark Andrews


> On 26 Oct 2021, at 21:23, Paul van der Vlis  wrote:
> 
> Hi Mark, and others,
> 
> Op 25-10-2021 om 23:58 schreef Mark Andrews:
>>> On 26 Oct 2021, at 08:02, Paul van der Vlis  wrote:
>>> 
>>> Hello,
>>> 
>>> I've made some progress..
>>> 
>>> Op 24-10-2021 om 21:39 schreef Paul van der Vlis:
>>> (...)
>>>> I've tried to specify the "key-directory" in the bind configuration, but 
>>>> when I do that I get an error during "rndc reload", so I cannot specify a 
>>>> key-directory.  This is Bind 9.16.15 from Debian 11.
>>>> What do I wrong?
>>> 
>>> What I did wrong here, is putting this key-directory option into the bind 
>>> configuration (/etc/bind/named.conf). The correct place is in the zone, so 
>>> I did put it in the "rndc modzone" command. This works ;-)
>> Well it can go in named.conf.  It needs to be in the options and/or view 
>> and/or zone sections.  This is documented.
> 
> OK..  Maybe it would work if I did put it in the options file.
> 
>>> But now I have a next problem:
>>> --
>>> Oct 25 22:27:53 ns1 kernel: [540901.362643] audit: type=1400 
>>> audit(1635193673.521:12): apparmor="DENIED" operation="mknod" 
>>> profile="named" name="/etc/bind/zones/hallo24.nl.signed.jnl" pid=343 
>>> comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=107 ouid=107
>>> Oct 25 22:27:53 ns1 named[343]: /etc/bind/zones/hallo24.nl.signed.jnl: 
>>> create: permission denied
>>> --
>>> 
>>> Hmm, maybe it's not a good idea that bind would change those static 
>>> configfiles. What I would like, is that bind would change only temporary 
>>> the database in /var/cache/bind/ . Would that be possible?  Or do you have 
>>> a better idea?
>> It’s not named’s job to update SELinux or AppArmour. I suspect we would get 
>> complaints if we attempted to do that. Changing security policy is the job 
>> of the operator.
> 
> I know how to configure apparmor, my question is not about that.
> 
> My question is about what is a good way to implement rfc2136 in Bind.

Use DDNS with TSIG or SIG(0) as authentication.

> I guess it's not a good idea that Bind really changes the zone-files in 
> /etc/bind using rfc2136 because /etc is for static configuration data. But 
> maybe I am wrong.
> 
> Is it the way to go to update Apparmor to make Bind write in /etc/bind , or 
> is there a better way?

The point of AppArmour is to prevent files being accidentally modified that 
shouldn’t be.  There is nothing special about /etc/bind except convention.  If 
all the files in there are to be modified by named change AppArmour to allow 
named to write to it otherwise put the zone file in a directory that is allowed 
to be updated.  There is nothing wrong with named modifying primary files if 
that is the intention.

> With regards,
> Paul van der Vlis.
> 
> -- 
> Paul van der Vlis Linux systeembeheer Groningen
> https://www.vandervlis.nl/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Certbot rfc2136

2021-10-25 Thread Mark Andrews


> On 26 Oct 2021, at 08:02, Paul van der Vlis  wrote:
> 
> Hello,
> 
> I've made some progress..
> 
> Op 24-10-2021 om 21:39 schreef Paul van der Vlis:
> (...)
>> I've tried to specify the "key-directory" in the bind configuration, but 
>> when I do that I get an error during "rndc reload", so I cannot specify a 
>> key-directory.  This is Bind 9.16.15 from Debian 11.
>> What do I wrong?
> 
> What I did wrong here, is putting this key-directory option into the bind 
> configuration (/etc/bind/named.conf). The correct place is in the zone, so I 
> did put it in the "rndc modzone" command. This works ;-)

Well it can go in named.conf.  It needs to be in the options and/or view and/or 
zone sections.  This is documented.

> But now I have a next problem:
> --
> Oct 25 22:27:53 ns1 kernel: [540901.362643] audit: type=1400 
> audit(1635193673.521:12): apparmor="DENIED" operation="mknod" profile="named" 
> name="/etc/bind/zones/hallo24.nl.signed.jnl" pid=343 comm="isc-worker" 
> requested_mask="c" denied_mask="c" fsuid=107 ouid=107
> Oct 25 22:27:53 ns1 named[343]: /etc/bind/zones/hallo24.nl.signed.jnl: 
> create: permission denied
> --
> 
> Hmm, maybe it's not a good idea that bind would change those static 
> configfiles. What I would like, is that bind would change only temporary the 
> database in /var/cache/bind/ . Would that be possible?  Or do you have a 
> better idea?

It’s not named’s job to update SELinux or AppArmour. I suspect we would get 
complaints if we attempted to do that.  Changing security policy is the job of 
the operator.

> This is the rndc modzone command what I give at the moment:
> --
> rndc modzone hallo24.nl "{ type master; file 
> \"/etc/bind/zones/hallo24.nl.signed\"; key-directory \"/etc/bind/keys\"; 
> allow-transfer { 91.198.178.25; 2a01:1b0:7999:424::25; 45.95.238.187; 
> 2a10:3781:13b6::2; }; update-policy {grant test3.hallo24.nl. name 
> _acme-challenge.test3.hallo24.nl. txt;}; };"
> --
> 
> With regards,
> Paul van der Vlis
> 
> -- 
> Paul van der Vlis Linux systeembeheer Groningen
> https://www.vandervlis.nl/
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Certbot rfc2136

2021-10-24 Thread Mark Andrews


> On 25 Oct 2021, at 06:39, Paul van der Vlis  wrote:
> 
> Hello,
> 
> I am trying to get Certbot working using rfc2136. But during the validation I 
> get these errors:
> ---
> Oct 24 02:14:21 ns1 named[343]: client @0x7f70e43b7d08 
> 45.95.238.187#57242/key test3.hallo24.nl: updating zone 'hallo24.nl/IN'
> : adding an RR at '_acme-challenge.test3.hallo24.nl' TXT 
> "qYxXiH34V8T0lFtsUOd_BPMZCBiA-FgAiJ-0nUGHsYE"
> Oct 24 02:14:21 ns1 named[343]: dns_dnssec_findzonekeys2: error reading 
> Khallo24.nl.+013+02962.private: file not found
> Oct 24 02:14:21 ns1 named[343]: dns_dnssec_findzonekeys2: error reading 
> Khallo24.nl.+013+01290.private: file not found
> ---
> 
> These files are in /etc/bind/keys/, and normally that's no problem.
> 
> I've tried to specify the "key-directory" in the bind configuration, but when 
> I do that I get an error during "rndc reload", so I cannot specify a 
> key-directory.  This is Bind 9.16.15 from Debian 11.
> 
> What do I wrong?

Failed to post the actual error messages reported.  Named would have logged 
error messages.

Failed to post what you actually did.  “I tried to specify the "key-directory" 
in the bind configuration” is not what you actually did.  Post the parts of 
named.conf.

Failed to run named-checkconf before you ran 'rndc reload’ to check that you 
didn’t have an error.

How do you start named?  Do you run chrooted?

At the moment you are saying “I did something. It didn’t work. Tell me what I 
did wrong.”  Without crystal balls no one here has a chance of telling you.

> Does somebody know a good howto to get this working? I use now this:
> https://certbot-dns-rfc2136.readthedocs.io/en/stable/
> but in my opinion it's not complete enough.
> 
> With regards,
> Paul
> 
> 
> 
> 
> 
> 
> 
> -- 
> Paul van der Vlis Linux systeembeheer Groningen
> https://www.vandervlis.nl/
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: use dig query

2021-10-24 Thread Mark Andrews
:41:15 AEDT 2021
;; MSG SIZE  rcvd: 127

;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6266
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5bf7fc115302779201006176356bd1232de50c54ecaa
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN  A

;; QUERY SIZE: 77

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6266
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN  A

;; AUTHORITY SECTION:
1.1.1.in-addr.arpa. 3600IN  SOA alec.ns.cloudflare.com. 
dns.cloudflare.com. 2036583626 1 2400 604800 3600

;; Query time: 297 msec
;; SERVER: 2400:cb00:2049:1::a29f:7e2#53(2400:cb00:2049:1::a29f:7e2)
;; WHEN: Mon Oct 25 15:41:15 AEDT 2021
;; MSG SIZE  rcvd: 111

% 

> On 25 Oct 2021, at 13:52, Champion Xie  wrote:
> 
>  dig version 9.14.8 
> 
> Using the following command can not achieve the desired effect, dnssec 
> information will still be output
> dig 1.1.1.1.in-addr.arpa   +trace +nodnssec 
> 
> Normally, the parameters should not be in sequence
> 
> 
> -- 
> Best Regards!!
> champion_xie
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: consolidating Reverse Zones

2021-10-21 Thread Mark Andrews


> On 21 Oct 2021, at 18:33, Edwardo Garcia  wrote:
> 
> Hai all,
> 
> We have been given task of doing some migrations within new merger.
> One of these is we have a number of reverse zones, a /19 in fact, they are 
> mostly GENERATE'd  for regions with fixed gw and a few other local custom PTRs
> 
> I have played roughly with a fictitious in-addr.arpa (I play with cgnat range 
> since it will not affect or interfere with anyone whilst we play around)
> 
> In our examples I have tried
> zone "8-15.110.100.in-addr.arpa" {
> type master;
> file "cgnat.rev";
> notify no;
> }; 
> I also tried 8/21.110.100...  and it always complain 
> loading from master file cgnat.rev failed: unknown class/type

Remove the white space from the front on the record on this indicated line.

“ 151.10 PTR blue.stop.” is not the same as "151.10 PTR blue.stop.”

Leading white space is “take the name from the previous record”.

> The zone file has usual header, and PTR entry are only
> 151.10  PTR blue.stop.
> (even tried   10.151)  
> 
> I guess bind can not consolidate like this and we have to put up with a 
> million /24 zone files ?  I was thinking because we can do classless dele 
> with smaller than /24, it would work on bigger  :)
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: libisc-9.16.15-Debian.so: undefined symbol: uv_udp_connect

2021-09-29 Thread Mark Andrews
You are missing libuv or have changed libuv versions.

> On 30 Sep 2021, at 07:30, Maihöfer via bind-users  
> wrote:
> 
> Hi,
> 
> for whatever reason my bind, or anything related to that library, is not
> starting anymore
> 
> error is:
> 
> phil...@sources.list.d$ dig
> dig: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libisc-9.16.15-Debian.so: undefined symbol:
> uv_udp_connect
> phil...@sources.list.d$
> 
> Having the same error message with "host" or "named-rrchecker".
> 
> I am running a Debian 11 (Bullseye)
> 
> Any help, please?
> 
> Best regards
> 
> Philipp
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Query regarding tmp-xxxx files in ../named/zones

2021-09-16 Thread Mark Andrews
You are in the best place to answer what they are by looking at them.

Named uses temporary files to create new versions of files then renames them to 
replace
existing files atomically. This includes zone files, journals and any other 
file where
a partial instance would be problematic.

Now if something goes wrong in there generation the error handling is supposed 
to remove
them but there can alway be omissions on error paths.  Similarly if you don’t 
shutdown
named cleanly there can be temporary files left around if named was in the 
process of
updating a file.  Similarly if named happens to die unexpectedly and it was in 
the
process of writing out a file they will be left behind.

Mark

> On 16 Sep 2021, at 13:44, Rajnish Kamboj via bind-users 
>  wrote:
> 
> Hello All,
>  
> We have a query with the tmp-<> file generation in ../named/zones in BIND 9
> Over a period of time the tmp files grows and disk usage was full.
>  
> What is the purpose of these tmp files and when are these generated.??
> This will help us to take our internal decision on handling (delete etc.) 
> these temp files.
>  
>  
> Regards
> Rajnish Kamboj
>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: [External] : Re: NS query on bind9

2021-09-15 Thread Mark Andrews
Really, please read the RFCs and don’t try to reverse engineer a DNS server.
You will get it wrong.  As a recursive server developer we are sick and tired
of people who do half baked DNS implementations because they failed to take
the time to read the specifications.

Read the errata. Read the updating RFC.

RFC 1034, 4.3.2. Algorithm
RFC 8906, 3.1.2. Unknown/Unsupported Type Queries

Your type list is also too short to meet the minimal set of types needed for
an interoperable server.  Read the other half of STD13, RFC 1035.

Mark

> On 15 Sep 2021, at 17:40, Sonal Pahuja  wrote:
> 
> Hi Mark,
> 
> Thanks for the response. Now NS query is working fine!!
> 
> But I have one more query-
> 
> we have our application to resolve e164 domain queries i.e NS, NAPTR and 
> CNAME queries only. If user give any other query type then application sends 
> RCODE=4(NOT_IMPLEMENTED) in response.
> But bind9 is rejecting our response and sends SERVFAIL.
> 
> Attached is the PCAP.
> 
> Please share your views again on this. Thanks in advance!
> 
> Regards,
> Sonal
> 
> 
> 
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org] 
> Sent: Wednesday, September 15, 2021 1:51 AM
> To: Sonal Pahuja 
> Cc: bind-users@lists.isc.org
> Subject: [External] : Re: NS query on bind9
> 
> Named is very picky about returned SOA records in negative responses.  If it 
> has followed/seen a delegation then the returned SOA record in the response 
> needs to be at or below that point.
> 
> I suspect that named has a cached NS RRset between e164.arpa and 
> 4.0.4.5.2.4.1.4.2.0.2.4.e164.arpa which is causing the returned response to 
> be rejected.
> 
> Mark
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> <15sep_RCODE=4.pcap>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: NS query on bind9

2021-09-14 Thread Mark Andrews
Named is very picky about returned SOA records in negative responses.  If it 
has followed/seen a delegation then the returned SOA record in the response 
needs to be at or below that point.

I suspect that named has a cached NS RRset between e164.arpa and 
4.0.4.5.2.4.1.4.2.0.2.4.e164.arpa which is causing the returned response to be 
rejected.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: SMIMEA syntax question

2021-09-03 Thread Mark Andrews
yes

> On 3 Sep 2021, at 20:41, raf via bind-users  wrote:
> 
> Hi,
> 
> Sorry, but I'm having trouble finding zonefile syntax
> documentation.
> 
> Is the following correct syntax for an SMIMEA record?
> 
> ef809616390533e15df60e10478b6e5c7040a2152f762f173ef6c014._smimecert.raf.org 
> IN SMIMEA (
>  3 0 0
>  308204c8308202b0020101300d06092a864886f70d01010b05003012
>  [...skip many hex lines...]
>  be412474f2c5f04d193124990ef9b15490883604e4aa9adb
>  )
> 
> Thanks.
> 
> cheers,
> raf
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: KSK signing zone records

2021-09-02 Thread Mark Andrews
Just give it time. Named will choose the appropriate DNSKEY when it comes time 
to re-sign the RRset. 

-- 
Mark Andrews

> On 3 Sep 2021, at 03:26, Timothy A. Holtzen  wrote:
> 
> Okay, so if I'm interpreting this correctly.  When the new alg 14 KSKs
> were created and then the zone was signed (either automatically or via a
> command) there was probably only a valid alg 8 ZSK available.  As a
> result bind used the alg 14 KSK as a defacto CSK and singed the zone
> RRSets directly.  This would make sense given the nature of the issue I
> had with my key rotation process.  However now I have both valid alg 8
> and alg 14 ZSK available.  Is there a way to go back and get bind to
> re-evaluate the zone to recognize the valid ZSK records and sign them only?
> 
> Timothy A. Holtzen
> Campus Network Administrator
> Nebraska Wesleyan University
> Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D  C7DD DFFB 7662 24E6 
> C30D
> Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9  CCFC 426E 76AF DABC B3D7
> 
>> On 8/31/21 18:07, Mark Andrews wrote:
>> Named will continually re-sign parts of the zone as the RRSIGs for a RRset 
>> fall due
>> for replacement.  Named looks at which keys are in the active state to 
>> determine along
>> with the afore mentioned controls to work out which DNSKEYs will be used to 
>> re-sign the
>> RRset.  If in the past you only had one key type and you now have two, 
>> different keys
>> may be used to re-sign the RRset.  If you changed policy in named.conf, the 
>> new policy
>> will be implemented as the RRSIGs are re-generated.
>> 
>> It looks like you told named to re-sign the zone when there was only one 
>> type of DNSKEY
>> key record (or you where unlucky enough for named to check the available 
>> keys whiles there
>> was only one active key present) resulting in named overriding the policy in 
>> named.conf.
>> 
>> Mark
>> 
>>>> On 1 Sep 2021, at 03:44, Timothy A. Holtzen via bind-users 
>>>>  wrote:
>>> 
>>> I'm using Algorithm 8 RSA/SHA-256, and Algorithm 14 ECDSA/SHA-384.  I
>>> have one RSA KSK and one RSA ZSK.  In addition I have two ECDSA KSK and
>>> two ECDSA ZSK.   The RSA KSK seems perfectly happy to sign the ECDSA
>>> ZSKs.  And both the RSA and ECDSA ZSKs seem to be singing records
>>> correctly.  It just seems to be the two newer ECDSA KSKs that instead of
>>> signing the ZSKs are singing the domain records directly. 
>>> 
>>> Even more perplexing is that one of the domains seems to have fixed
>>> itself.  Now all the KSKs for that domain are singing the ZSKs and the
>>> ZSKs are signing the domain records.  But I've still got a couple of
>>> other domains where it is doing it wrong.  Is there some kind of timeout
>>> or maintenance that gets run automatically that might have fixed the
>>> issue?  I've tried running an "rndc sign" command on the domains several
>>> times.
>>> 
>>> Timothy A. Holtzen
>>> Campus Network Administrator
>>> Nebraska Wesleyan University
>>> Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D  C7DD DFFB 7662 
>>> 24E6 C30D
>>> Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9  CCFC 426E 76AF DABC B3D7
>>> 
>>> On 8/30/21 17:40, raf via bind-users wrote:
>>>> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton 
>>>>  wrote:
>>>> 
>>>>> What algorithm(s) are you using for ZSK and KSK? If they’re not the
>>>>> same algorithm, then both will be used to sign the entire zone.
>>>>> 
>>>>> Regards,
>>>>> Chris Buxton
>>>> Just out of curiosity, why is that?
>>>> Isn't having the KSK sign the ZSK enough?
>>>> What difference does the nature of the thing
>>>> being signed make?
>>>> 
>>>> cheers,
>>>> raf
>>>> 
>>>> ___
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>>> unsubscribe from this list
>>>> 
>>>> ISC funds the development of this software with paid support 
>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more 
>>>> information.
>>>> 
>>>> 
>>>> bind-users mailing list
>>>> bind-users@lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>> ___
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>> unsubscribe from this list
>>> 
>>> ISC funds the development of this software with paid support subscriptions. 
>>> Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: KSK signing zone records

2021-09-01 Thread Mark Andrews
The primary reason that it is per algorithm is that validators and
signers are not required to support the same sets of algorithms and
if you want validation to work for everyone the zone has to be fully
signed for each algorithm that you state that it is signed for, i.e.
published in the DS RRset held in the parent zone.  CDS and CDNSKEY
also publish this but are not used as part of the validation process.

If publish that you are signed for ALG-A and ALG-B and the validator
only supports ALG-B, then if you don’t sign all the zone with ALG-B
there will be answers that can’t be validated.  The same applies if
the validator only supports ALG-A and you don’t fully sign the zone
with ALG-A.

Downgrade attacks are where you support both algorithms but someone
strips out the signatures from one of the algorithms because they
have succeeded in breaking the other algorithm.  DNSSEC does not
require that validators detect this condition, though some validators
can be configured to force checks for every published algorithm that
you support. If a validator wants to protect itself from downgrade
attacks it needs to limit itself to only checking RRSIGs for algorithms
listed in the DS RRset and ensure that all algorithms listed there are
present in the response and that the signatures are good.

Mark 

> On 2 Sep 2021, at 09:30, raf via bind-users  wrote:
> 
> On Wed, Sep 01, 2021 at 03:04:56PM +0100, Tony Finch  wrote:
> 
>> raf via bind-users  wrote:
>>> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton 
>>>  wrote:
>>> 
>>>> What algorithm(s) are you using for ZSK and KSK? If they’re not the
>>>> same algorithm, then both will be used to sign the entire zone.
>>> 
>>> Just out of curiosity, why is that?
>>> Isn't having the KSK sign the ZSK enough?
>> 
>> As well as what Mark said, the reason signing is per-algorithm is to do
>> with downgrade protection: if there's a situation where validators support
>> different algorithms (e.g. some have deprecated a bad algorithm but some
>> have not yet deployed its replacement) then a signer can support all the
>> validators by signing with both algorithms, without causing problems for
>> the newer validators that want to distrust the old algorithm. A validator
>> can decide whether a zone is secure or not based purely on the algorithms
>> listed in its DS RRset.
>> 
>> Tony.
>> -- 
>> f.anthony.n.finchhttps://dotat.at/
>> Northwest Bailey: Southwesterly 3 to 5. Slight. Showers. Good.
> 
> Thanks.
> 
> cheers,
> raf
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: KSK signing zone records

2021-08-31 Thread Mark Andrews
Named will continually re-sign parts of the zone as the RRSIGs for a RRset fall 
due
for replacement.  Named looks at which keys are in the active state to 
determine along
with the afore mentioned controls to work out which DNSKEYs will be used to 
re-sign the
RRset.  If in the past you only had one key type and you now have two, 
different keys
may be used to re-sign the RRset.  If you changed policy in named.conf, the new 
policy
will be implemented as the RRSIGs are re-generated.

It looks like you told named to re-sign the zone when there was only one type 
of DNSKEY
key record (or you where unlucky enough for named to check the available keys 
whiles there
was only one active key present) resulting in named overriding the policy in 
named.conf.

Mark

> On 1 Sep 2021, at 03:44, Timothy A. Holtzen via bind-users 
>  wrote:
> 
> I'm using Algorithm 8 RSA/SHA-256, and Algorithm 14 ECDSA/SHA-384.  I
> have one RSA KSK and one RSA ZSK.  In addition I have two ECDSA KSK and
> two ECDSA ZSK.   The RSA KSK seems perfectly happy to sign the ECDSA
> ZSKs.  And both the RSA and ECDSA ZSKs seem to be singing records
> correctly.  It just seems to be the two newer ECDSA KSKs that instead of
> signing the ZSKs are singing the domain records directly. 
> 
> Even more perplexing is that one of the domains seems to have fixed
> itself.  Now all the KSKs for that domain are singing the ZSKs and the
> ZSKs are signing the domain records.  But I've still got a couple of
> other domains where it is doing it wrong.  Is there some kind of timeout
> or maintenance that gets run automatically that might have fixed the
> issue?  I've tried running an "rndc sign" command on the domains several
> times.
> 
> Timothy A. Holtzen
> Campus Network Administrator
> Nebraska Wesleyan University
> Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D  C7DD DFFB 7662 24E6 
> C30D
> Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9  CCFC 426E 76AF DABC B3D7
> 
> On 8/30/21 17:40, raf via bind-users wrote:
>> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton 
>>  wrote:
>> 
>>> What algorithm(s) are you using for ZSK and KSK? If they’re not the
>>> same algorithm, then both will be used to sign the entire zone.
>>> 
>>> Regards,
>>> Chris Buxton
>> Just out of curiosity, why is that?
>> Isn't having the KSK sign the ZSK enough?
>> What difference does the nature of the thing
>> being signed make?
>> 
>> cheers,
>> raf
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: KSK signing zone records

2021-08-30 Thread Mark Andrews
The rules for what get signed by what are per algorithm.  Additionally the
SEP bit is hint to the signer as to what is desired.  Named has controls to
say whether to pay attention to the SEP bit or not.  Additionally it will
override those controls to pay attention to the SEP but if it believes that
the zone won’t be correctly signed if it paid attention to the SEP bit.

People have created zones where one algorithm has keys with and without the SEP
bit for one algorithm but for a second algorithm there are only keys with 
(without)
the SEP bit.  If the signer has been told to honour the SEP bit then for the 
first
algorithm it will be honoured and for the second algorithm the instruction will
be overridden.

See dnssec-dnskey-kskonly, update-check-ksk and the keys sub-clause of
dnssec-policy.

> On 31 Aug 2021, at 13:54, Chris Buxton  wrote:
> 
> I honestly don’t remember the reasoning, only the outcome. Maybe Mark or 
> someone else from ISC can shed some light? I couldn’t find the answer to this 
> regular (but infrequent) question in the ISC KB.
> 
> Regards,
> Chris Buxton
> 
>> On Aug 30, 2021, at 3:40 PM, raf via bind-users  
>> wrote:
>> 
>> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton 
>>  wrote:
>> 
>>> What algorithm(s) are you using for ZSK and KSK? If they’re not the
>>> same algorithm, then both will be used to sign the entire zone.
>>> 
>>> Regards,
>>> Chris Buxton
>> 
>> Just out of curiosity, why is that?
>> Isn't having the KSK sign the ZSK enough?
>> What difference does the nature of the thing
>> being signed make?
>> 
>> cheers,
>> raf
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?

2021-08-30 Thread Mark Andrews
Michael,
there has never been needed to pre-publish RRSIGs because the DNS is
a loosely coherent system and from outside you can’t determine which DNSKEY
RRset signed which other RRset.  There is only one regularly lookup where you
can determine whether the RRset is signed by all the algorithms in the DNSKEY
RRset and that is for the DNSKEY RRset itself.  For every other regular lookup
it is impossible to determine because you have a DNSKEY RRset and seperate
RRset that may or may not have come from the same instance of the zone.  The
validation rules where designed to allow answers from different instances of
a zone to be validated.

It is this indeterminism that allows BIND to incrementally sign zones when
introducing new DNSKEY algorithms.

Supporting pre-publishing RRSIGs just complicates code for no good reason
so it is not supported.

Mark

> On 31 Aug 2021, at 10:39, Michael Sinatra  wrote:
> 
> Hi,
> 
> I have, in the past, used the "conservative" approach to performing algorithm 
> rollovers for various domains.  For many domains, this is probably overkill, 
> but I'd prefer to have the option of doing it, especially for those 
> mission-critical domains where you really don't want to rely simply on the 
> hope that nobody who needs to reach you (or your org/company) is using a 
> resolver that is still following the strictest interpretation of RFC 4035, 
> section 2.2.
> 
> In the past, I have handled this completely manually, signing the zone using 
> dnssec-signzone to sign the zone with keys of both algs before (again 
> manually) including the the new alg keys in the DNSKEY RRSET. But for zones 
> which I am inline-signing as a provider for someone else, I would like to use 
> a more automated method.  It doesn't appear that BIND currently supports 
> this, either with dnssec-keymgr and 'inline-signing' or with KASP.
> 
> I did try the trick of setting the key metadata manually ('publish' in the 
> future and 'activate' in the past), but BIND 'inline-signing' would not sign 
> the zone prior with the key prior to its publication, despite my timing 
> metadata settings.
> 
> So I am assuming that only the "liberal" approach is supported.  One thing I 
> thought of was trying a "moderate" approach, where the various TTLs are 
> manipulated so that the zone RRSIGs expire quickly before the new alg is 
> added and then flipping it so that the DNSKEY RRSET expires quickly and the 
> zone/RRSIG TTLs stay in cache longer.  But that is still a fairly tricky 
> approach and I am not sure it would work...
> 
> michael
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 dnssec question

2021-08-17 Thread Mark Andrews

> On 18 Aug 2021, at 10:23, Edwardo Garcia  wrote:
> 
> Hola Mark,
> 
> Thank you, so to be clear, what is mean to delegate zone, the black zone? I 
> am not dns expert unfortunately

Yes, create a seperate zone for black.example.net.

In example.net you add NS records for black.example.net.  They can use the
same nameservers as for example.net.

black.example.net. NS some.name.server.
black.example.net. NS some-other.name.server

you will end up with 2 zone clauses.  Apart from the obvious name differences
you won’t add the instructions to sign black.example.net to its stanza.

zone example.net {
type primary;
file “example.net.db”;
...
};

zone black.example.net {
type primary;
file “black.example.net.db”;
...
};

The top of black.example.net.db has an SOA record and the same NS records
as you put in the parent zone for it.  The two sets of NS records are
supposed to be the same.

Mark

> On Wed, Aug 18, 2021 at 6:23 AM Mark Andrews  wrote:
> Delegate the zone. Do NOT add a DS for it.
> 
> -- 
> Mark Andrews
> 
>> On 17 Aug 2021, at 23:47, Edwardo Garcia  wrote:
>> 
>> 
>> Hola
>> 
>> We have dnssec working for long time but need now to have a subdomain 
>> excluded, we are going to be use it to replace an internal blacklist, we 
>> have 14 smtp servers and it is cumbersome to keep in sync.
>> 
>> So we have example.net signed,
>> but we want black.example.net, and of course all addresses under, eg:  
>> 4.3.2.1.black.example.net  to work, at present of course this presents 
>> SERVFAIL because dnssec, obvious "black" needs to be in example.net zone, nd 
>> its dns is ns999 whichwork when dnssec disabled but this is not optimum
>> 
>> looking for suggestion or guidance to how we fix this please? Ir this is not 
>> possible?
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 dnssec question

2021-08-17 Thread Mark Andrews
Delegate the zone. Do NOT add a DS for it.

-- 
Mark Andrews

> On 17 Aug 2021, at 23:47, Edwardo Garcia  wrote:
> 
> 
> Hola
> 
> We have dnssec working for long time but need now to have a subdomain 
> excluded, we are going to be use it to replace an internal blacklist, we have 
> 14 smtp servers and it is cumbersome to keep in sync.
> 
> So we have example.net signed,
> but we want black.example.net, and of course all addresses under, eg:  
> 4.3.2.1.black.example.net  to work, at present of course this presents 
> SERVFAIL because dnssec, obvious "black" needs to be in example.net zone, nd 
> its dns is ns999 whichwork when dnssec disabled but this is not optimum
> 
> looking for suggestion or guidance to how we fix this please? Ir this is not 
> possible?
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.19 repeated crashes on FreeBSD 12.2-p6

2021-08-13 Thread Mark Andrews



> On 13 Aug 2021, at 15:12, Randy Bush  wrote:
> 
>> Presumably you are running with `named -u`
> 
># grep named /etc/rc.conf
>named_enable=YES
>named_program=/usr/local/sbin/named
>named_conf=/usr/home/dns/named.conf
>named_chrootdir=""
>named_chroot_autoupdate=NO
>named_uid=bind
>named_gid=bind
>named_wait=YES
>named_auto_forward=YES
>named_flags="-u bind"
>named_auto_forward_only=NO
> 
> named crashed
> 
># find / -name *.core
>#
> 
> what am i misunderstanding?

Named calls set{re}uid(2), when running with `named -u`, which DISABLES core
dumps of the process unless the kernel has been told otherwise.  This has
to be done by the ADMINISTRATOR as it is a SYSTEM WIDE configuration knob.
There is no per process knob.

See the afore mentioned KB articles for how to do this.

> randy

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.19 repeated crashes on FreeBSD 12.2-p6

2021-08-12 Thread Mark Andrews

> On 13 Aug 2021, at 10:03, Randy Bush  wrote:
> 
> FreeBSD 12.2-RELEASE-p6 GENERIC on amd64
> bind 9.16.19 from binary ports
> 
> ok, i was quietly waiting for a fix to magically appear and is hasn't.
> 
> i am getting 10-20 crashes a day on each of two servers.  it is not
> leaving disk flowers; and i see no config option to encourage it to do
> so.

Presumably you are running with `named -u` so tell the kernel to allow
core dumps for suid binaries [1] or allow an ordinary user to bind to
reserved ports [2] and start named as the ordinary user rather than using
'named -u’.  Use chroot rather su if you are using `named -t`.

su -u user named …

chroot -u user  named … 

[1] https://kb.isc.org/docs/aa-00340
[2] https://kb.isc.org/docs/aa-00621

Mark

> randy
> 
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Switching key types for authorizing updates

2021-08-12 Thread Mark Andrews
You could also switch to using SIG(0) instead of TSIG.  The the client
can just update the KEY RRset which is stored in the zone.

> On 13 Aug 2021, at 03:49, John Thurston  wrote:
> 
> On 8/12/2021 5:00 AM, Tony Finch wrote:
>> i.e. using the "subdomain" rule type instead of "selfsub", so the
>> domain name (second foo...) doesn't need to match the keyname (first
>> foo...)
> 
> 
> Yes, indeed. That's the ticket.
> Thank you very much, Tony.
> 
> --
> Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Does BIND supports ANAME RR

2021-08-09 Thread Mark Andrews
Please, don’t reply to threads with unrelated subject matter.  This is
just good mailing list etiquette.

Please create a new message, not a reply, and ask the question again.

Mark

> On 10 Aug 2021, at 13:48, Divya  wrote:
> 
> Dear Admin,
> 
> Has anybody used advance features of bind DoT and DoH, Kindly help me to 
> configure DoT and DoH in DNS with bind BIND 9.17.16+CentOS  7.9.
> 
> With Regards 
> Divya 
> 
> - Original Message -
> From: "Ondřej Surý" 
> To: "klaus darilion" 
> Cc: bind-users@lists.isc.org
> Sent: Monday, August 9, 2021 10:48:54 PM
> Subject: Re: Does BIND supports ANAME RR
> 
> No, and there’s no strong usercase for that. The ANAME was wrong on every 
> level from the protocol perspective and I am glad it is gone.
> 
> 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.
> 
>> On 9. 8. 2021, at 17:23, Klaus Darilion via bind-users 
>>  wrote:
>> 
>> Does every application that uses gethostbyname have a benefit of 
>> HTTPS/SVCB? That is what I meant.
>> regards
>> Klaus
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Mark Andrews 
>>> Gesendet: Montag, 9. August 2021 15:55
>>> An: Klaus Darilion 
>>> Cc: Evan Hunt ; Gaurav Kansal ; bind-
>>> us...@lists.isc.org
>>> Betreff: Re: Does BIND supports ANAME RR
>>> 
>>> Every resolver on the planet already supports HTTPS and SVCB.  Every
>>> authoritative server on the planet already supports HTTPS and SVCB via
>>> unknown record format. iOS is already making HTTPS queries for every
>>> webpage. I believe other browsers also make HTTPS queries today. Go look
>>> at your DNS traffic.
>>> 
>>> The MR mentioned earlier allows named and the other tools to load and
>>> display the records in presentation format and to do the additional section
>>> processing.  None of that it required to be able to return these records.   
>>> It
>>> just makes it easier.
>>> 
>>> Just about all the other DNS vendors also have code that can read and
>>> display presentation format.
>>> 
>>> ANAME is dead.
>>> --
>>> Mark Andrews
>>> 
>>>> On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users >> us...@lists.isc.org> wrote:
>>>> 
>>>> 
>>>>> 
>>>>> -Ursprüngliche Nachricht-
>>>>> Von: bind-users  Im Auftrag von Evan
>>>>> Hunt
>>>>> Gesendet: Samstag, 7. August 2021 20:21
>>>>> An: Gaurav Kansal 
>>>>> Cc: bind-users@lists.isc.org
>>>>> Betreff: Re: Does BIND supports ANAME RR
>>>>> 
>>>>>>> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
>>>>>>> I need the help in figuring out whether BIND supports ANAME ? If yes,
>>>>>>> then from which version on wards ?
>>>>>> 
>>>>>> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
>>>>>> it'll be coming back.
>>>>>> 
>>>>>> The new HTTPS and SVCB records look like a better approach anyway.
>>>>>> BIND will have support for those pretty soon.
>>>> 
>>>> But honestly SVCB will not solve the ANAME problem. I will take years until
>>> all resolvers/client would support SVCB whereas ANAME would be
>>> implemented in the authoritative name server and hence would work for
>>> every client/resolver as client/resolver never sees the ANAME but only the
>>> A/ record.
>>>> 
>>>> regards
>>>> Klaus
>>>> ___
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>>> unsubscribe
>>> from this list
>>>> 
>>>> ISC funds the development of this software with paid support
>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>> information.
>>>> 
>>>> 
>>>> bind-users mailing list
>>>> bind-users@lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support

Re: Does BIND supports ANAME RR

2021-08-09 Thread Mark Andrews
If you mean stop publishing CNAME as meaning “the server for this service is …” 
then yes. HTTPS can be published along side MX, A, and .  Just start doing 
it. 

Mark
-- 
Mark Andrews

> On 10 Aug 2021, at 07:13, Klaus Darilion  wrote:
> 
> Do you think that we can get rid of CNAME too? 
> 
> regards
> Klaus
> 
>> -Ursprüngliche Nachricht-
>> Von: Ondřej Surý 
>> Gesendet: Montag, 9. August 2021 19:19
>> An: Klaus Darilion 
>> Cc: Mark Andrews ; bind-users@lists.isc.org
>> Betreff: Re: Does BIND supports ANAME RR
>> 
>> No, and there’s no strong usercase for that. The ANAME was wrong on every
>> level from the protocol perspective and I am glad it is gone.
>> 
>> 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.
>> 
>>> On 9. 8. 2021, at 17:23, Klaus Darilion via bind-users > us...@lists.isc.org> wrote:
>>> 
>>> Does every application that uses gethostbyname have a benefit of
>> HTTPS/SVCB? That is what I meant.
>>> regards
>>> Klaus
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: Mark Andrews 
>>>> Gesendet: Montag, 9. August 2021 15:55
>>>> An: Klaus Darilion 
>>>> Cc: Evan Hunt ; Gaurav Kansal ;
>> bind-
>>>> us...@lists.isc.org
>>>> Betreff: Re: Does BIND supports ANAME RR
>>>> 
>>>> Every resolver on the planet already supports HTTPS and SVCB.  Every
>>>> authoritative server on the planet already supports HTTPS and SVCB via
>>>> unknown record format. iOS is already making HTTPS queries for every
>>>> webpage. I believe other browsers also make HTTPS queries today. Go
>> look
>>>> at your DNS traffic.
>>>> 
>>>> The MR mentioned earlier allows named and the other tools to load and
>>>> display the records in presentation format and to do the additional
>> section
>>>> processing.  None of that it required to be able to return these records.  
>>>>  It
>>>> just makes it easier.
>>>> 
>>>> Just about all the other DNS vendors also have code that can read and
>>>> display presentation format.
>>>> 
>>>> ANAME is dead.
>>>> --
>>>> Mark Andrews
>>>> 
>>>>> On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users >>> us...@lists.isc.org> wrote:
>>>>> 
>>>>> 
>>>>>> 
>>>>>> -Ursprüngliche Nachricht-
>>>>>> Von: bind-users  Im Auftrag von
>> Evan
>>>>>> Hunt
>>>>>> Gesendet: Samstag, 7. August 2021 20:21
>>>>>> An: Gaurav Kansal 
>>>>>> Cc: bind-users@lists.isc.org
>>>>>> Betreff: Re: Does BIND supports ANAME RR
>>>>>> 
>>>>>>>>> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
>>>>>>>>> I need the help in figuring out whether BIND supports ANAME ? If
>>> yes,
>>>>>>>>> then from which version on wards ?
>>>>>>>> 
>>>>>>>> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
>>>>>>>> it'll be coming back.
>>>>>>>> 
>>>>>>>> The new HTTPS and SVCB records look like a better approach anyway.
>>>>>>>> BIND will have support for those pretty soon.
>>>>>> 
>>>>>> But honestly SVCB will not solve the ANAME problem. I will take years
>>> until
>>>>> all resolvers/client would support SVCB whereas ANAME would be
>>>>> implemented in the authoritative name server and hence would work for
>>>>> every client/resolver as client/resolver never sees the ANAME but only the
>>>>> A/ record.
>>>>>> 
>>>>>> regards
>>>>>> Klaus
>>>>>> ___
>>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe
>>>>> from this list
>>>>>> 
>>>>>> ISC funds the development of this software with paid support
>>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>>>> information.
>>>>>> 
>>>>>> 
>>>>>> bind-users mailing list
>>>>>> bind-users@lists.isc.org
>>>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>> ___
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>> unsubscribe
>> from this list
>>> 
>>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Does BIND supports ANAME RR

2021-08-09 Thread Mark Andrews
Every resolver on the planet already supports HTTPS and SVCB.  Every 
authoritative server on the planet already supports HTTPS and SVCB via unknown 
record format. iOS is already making HTTPS queries for every webpage. I believe 
other browsers also make HTTPS queries today. Go look at your DNS traffic. 

The MR mentioned earlier allows named and the other tools to load and display 
the records in presentation format and to do the additional section processing. 
 None of that it required to be able to return these records.   It just makes 
it easier.

Just about all the other DNS vendors also have code that can read and display 
presentation format.

ANAME is dead. 
-- 
Mark Andrews

> On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users 
>  wrote:
> 
> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: bind-users  Im Auftrag von Evan
>> Hunt
>> Gesendet: Samstag, 7. August 2021 20:21
>> An: Gaurav Kansal 
>> Cc: bind-users@lists.isc.org
>> Betreff: Re: Does BIND supports ANAME RR
>> 
>>> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
>>> I need the help in figuring out whether BIND supports ANAME ? If yes,
>>> then from which version on wards ?
>> 
>> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
>> it'll be coming back.
>> 
>> The new HTTPS and SVCB records look like a better approach anyway.
>> BIND will have support for those pretty soon.
> 
> But honestly SVCB will not solve the ANAME problem. I will take years until 
> all resolvers/client would support SVCB whereas ANAME would be implemented in 
> the authoritative name server and hence would work for every client/resolver 
> as client/resolver never sees the ANAME but only the A/ record.
> 
> regards
> Klaus
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Using catz (catalog zones): BIND does not remove the catz-journal file on the slave

2021-07-29 Thread Mark Andrews
Opened issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2842

> On 28 Jul 2021, at 23:38, Tom  wrote:
> 
> Hi
> 
> Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), 
> then the journal files are not removed on the slave:
> 
> Current situation before removing the zone "example.com" from catz:
> 
> $ ls -lahF
> -rw-r--r--. 1 named named 4.0K 28. Jul 15:21 
> __catz___default_catalog.123456.local_example.com.db
> -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 
> __catz___default_catalog.123456.local_example.com.db.jnl
> 
> 
> After removing the zone on the master (catz), the slave removes the 
> __catz___default_...-files for the corresponding zone, but not the 
> journal-file:
> 
> 28-Jul-2021 15:29:56.018 general: info: catz: updating catalog zone 
> 'catalog.123456.local' with serial 2021072803
> 28-Jul-2021 15:29:56.018 xfer-in: info: zone catalog.123456.local/IN: 
> transferred serial 2021072803: TSIG 'master-slave'
> 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123456.local/IN' 
> from 172.16.1.1#53: Transfer status: success
> 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123546.local/IN' 
> from 172.16.1.1#53: Transfer completed: 1 messages, 5 records, 343 bytes, 
> 0.001 secs (343000 bytes/sec) (serial 2021072803)
> 28-Jul-2021 15:29:56.020 general: info: catz: deleting zone 'example.com' 
> from catalog 'catalog.123456.local' - success
> 28-Jul-2021 15:29:56.021 general: warning: catz: catz_delzone_taskaction: 
> zone 'example.com' deleted
> 
> $ ls -lahF
> -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 
> __catz___default_catalog.123456.local_example.com.db.jnl
> 
> Is this intentional or possibly a bug?
> 
> Many thanks.
> Kind regards,
> Tom
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Compile problems on musl/arm32 since 9.16.8

2021-07-18 Thread Mark Andrews
Please open a issue at https://gitlab.isc.org/

> On 19 Jul 2021, at 07:19, Ed W  wrote:
> 
> Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my 
> libc. I am hitting a compile error, that I have determined happens on 9.16.9 
> onwards, yet I can build fine with 9.16.8 and earlier
> 
> 
> 
> The specific error snippet I see is:
> 
> armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 
> -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 
> -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o sample-async \
> sample-async.o ../dns/libdns.a  ../isccfg/libisccfg.a ../isc/libisc.a 
> -lcrypto -luv -ldl
> /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
>  ../isc/libisc.a(backtrace.o): in function `btcallback':
> backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
> armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 
> -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 
> -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o resolve \
> resolve.o ../irs/libirs.a ../dns/libdns.a  ../isccfg/libisccfg.a 
> ../isc/libisc.a -lcrypto -luv -ldl
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:494: sample-gai] Error 1
> make[1]: *** Waiting for unfinished jobs
> /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
>  ../isc/libisc.a(backtrace.o): in function `btcallback':
> backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:502: sample-request] Error 1
> /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
>  ../isc/libisc.a(backtrace.o): in function `btcallback':
> backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:490: sample-async] Error 1
> /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld:
>  ../isc/libisc.a(backtrace.o): in function `btcallback':
> backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:486: resolve] Error 1
> 
> 
> 
> I think this is related to this change here:
> 
> --- 
> /var/tmp/portage/net-dns/bind-tools-9.16.9/work/bind-9.16.9/lib/isc/backtrace.c
> 2020-11-16 14:44:37.0 +
> +++ 
> /var/tmp/portage/net-dns/bind-tools-9.16.8/work/bind-9.16.8/lib/isc/backtrace.c
> 2020-10-13 08:41:40.0 +
> @@ -40,7 +40,7 @@
>   */
>  #ifdef HAVE_LIBCTRACE
>  #define BACKTRACE_LIBC
> -#elif defined(HAVE_UNWIND_BACKTRACE)
> +#elif defined(__GNUC__) && (defined(__x86_64__) || defined(__ia64__))
>  #define BACKTRACE_GCC
>  #elif defined(WIN32)
>  #define BACKTRACE_WIN32
> 
> 
> 
> If I revert this change then my compile succeeds (although it may not be 
> correct?)
> 
> 
> 
> I'm not really skilled enough to understand the details of gcc backtrace 
> implementation on arm. I'm using gcc 10.3.0 to compile this, and I can see 
> that I have a header:
> 
> /usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/include/unwind.h
> 
> So I'm assuming that I have gcc compiled with some kind of unwind 
> implementation? 
> 
> I use a very similar profile to compile near identical code base for both 
> amd64 and x86 architectures and both of those have no issues compiling latest 
> bind-tools (and previous). Also, near as I can see I have my gcc configured 
> identically across all three systems... 
> 
> 
> 
> Now I *can* compile bind-tools ok if I install the libunwind library, 
> however, that then breaks (re)compiling my gcc compiler, so I'm really 
> thinking that's the wrong route to go down?
> 
> Temporarily I'm reverting the above change locally, but I wonder if you could 
> either guide me to a correct solution, or if someone more knowledgeable can 
> revert or write some correct #if test for this situation please?
> 
> 
> 
> I'm sure I have failed to provide enough details at this stage. Please be 
> gentle...
> 
> Thanks
> 
> Ed W
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.is

Re: query-source and listened interfaces

2021-07-08 Thread Mark Andrews
No. If you want to do that then you will need to run 3 instances.

> On 8 Jul 2021, at 17:08, Xinyu Wang  wrote:
> 
> Hi guys,
> 
> Is it possible to make a recursive BIND send queries to authorities from the 
> interface which the original query was sent to.
> 
> For instance,
> the recursive BIND is listening 3 interfaces, they are 1.1.1.1, 1.1.1.2, and 
> 1.1.1.3
> 
> when a  recusive query arrived at 1.1.1.1, then BIND use 1.1.1.1 to complete 
> the recursion process.
> 
> when a  recusive query arrived at 1.1.1.2, then BIND use 1.1.1.2 to complete 
> the recursion process.
> 
> when a  recusive query arrived at 1.1.1.3, then BIND use 1.1.1.3 to complete 
> the recursion process.
> 
> Hopefully I made myself clear, and looking  forward to some help.
> Thanks
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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

2021-07-07 Thread Mark Andrews
This is an old style referral like you would have got out of BIND4
where the referral appears in the answer section.  Note AA is NOT
set so it is not a valid answer to the question.

% dig +norec ns ok.contact @fwd3.dccdns.com

; <<>> DiG 9.15.4 <<>> +norec ns ok.contact @fwd3.dccdns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11820
;; flags: qr ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ok.contact.IN  NS

;; ANSWER SECTION:
ok.contact. 3600IN  NS  fwd1.dns.ws.
ok.contact. 3600IN  NS  fwd3.dns.ws.
ok.contact. 3600IN  NS  fwd2.dns.ws.
ok.contact. 3600IN  NS  fwd4.dns.ws.

;; Query time: 176 msec
;; SERVER: 64.70.78.82#53(64.70.78.82)
;; WHEN: Thu Jul 08 15:09:04 AEST 2021
;; MSG SIZE  rcvd: 121

% 

> On 8 Jul 2021, at 01:03, tale  wrote:
> 
> On Mon, Jul 5, 2021 at 8:20 PM Mark Andrews  wrote:
>> This is an error with the delegation of ok.contact.  The NS records at the 
>> delegation point do
>> not match those at the zone apex.
> 
> I'm curious if this is a re-purposing of the existing "non-improving
> referral" message.  I totally get how that brief phrase makes sense
> for a sideways referral, but I'm not seeing how that statement makes
> sense for ok.contact.
> 
> # Delegation for .contact
> $ dig +noall +auth ns contact @a.root-servers.net
> contact. 172800 IN NS demand.beta.aridns.net.au.
> contact. 172800 IN NS demand.alpha.aridns.net.au.
> contact. 172800 IN NS demand.delta.aridns.net.au.
> contact. 172800 IN NS demand.gamma.aridns.net.au.
> 
> # Delegation for ok.contact
> $ dig +noall +auth ns ok.contact @demand.alpha.aridns.net.au.
> ok.contact. 86400 IN NS fwd2.dccdns.com.
> ok.contact. 86400 IN NS fwd1.dccdns.com.
> ok.contact. 86400 IN NS fwd4.dccdns.com.
> ok.contact. 86400 IN NS fwd3.dccdns.com.
> 
> # Apex NS for ok.contact
> $ dig +noall +ans ns ok.contact @fwd1.dccdns.com
> ok.contact. 3499 IN NS fwd4.dns.ws.
> ok.contact. 3499 IN NS fwd2.dns.ws.
> ok.contact. 3499 IN NS fwd1.dns.ws.
> ok.contact. 3499 IN NS fwd3.dns.ws.
> 
> Yes, the apex NS names aren't the same as the delegating NS (though
> the adb addresses are), but that last one isn't a referral.
> 
> I trust you are right, Mark.  I'm just not sure what I'm missing about
> "non-improving referral".
> -- 
> tale

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: compile flag to disable AAAA responses is unrecognized

2021-07-06 Thread Mark Andrews
 filtering is now a plug-in (as of 9.14).  This is documented in the ARM.

> On 7 Jul 2021, at 05:05, Scott Strattner  wrote:
> 
> I successfully built 9.16.18 on my RH8.4 ppc64el VM. But after doing so I 
> wanted to set it up so that if it receives a query over IPv4 it will not 
> return any  records in the reply.
>  
> I found this: https://kb.isc.org/docs/aa-00576
>  
> Which mentions using --enable-filter- and then applying the right option 
> in named.conf. However when I added this to my configure flags, it says it is 
> not recognized (see below).
>  
> What is the current way to enforce this behavior? I tried adding the 
> "filter--on-v4 yes;" in named.conf (perhaps that compile option was now 
> enabled by default?) but did not work (queries still return both A and  
> results).
>  
> Configuration summary:
> ---
> Optional features enabled:
> GSS-API (--with-gssapi)
> Allow 'fixed' rrset-order (--enable-fixed-rrset)
> Print backtrace on crash (--enable-backtrace)
> Use symbol table for backtrace, named only (--enable-symtable)
> Use GNU libtool (--with-libtool)
> CMocka Unit Testing Framework (--with-cmocka)
> DNSSEC validation active by default (--enable-auto-validation)
> Dynamically loadable zone (DLZ) drivers:
> Filesystem (--with-dlz-filesystem)
> ---
> Features disabled or unavailable on this platform:
> Small-system tuning (--with-tuning)
> Allow 'dnstap' packet logging (--enable-dnstap)
> GeoIP2 access control (--enable-geoip)
> DNS Response Policy Service interface (--enable-dnsrps)
> Using PKCS#11 for Public-Key Cryptography (--with-native-pkcs11)
> Very verbose query trace logging (--enable-querytrace)
> IDN support (--with-libidn2)
> ---
> Configured paths:
> prefix: /usr/local
> sysconfdir: ${prefix}/etc
> localstatedir: ${prefix}/var
> ---
> Compiler: gcc
> gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> Unrecognized options:
> --enable-filter-
> Scott Strattner
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 internal/external VIEWs

2021-07-05 Thread Mark Andrews
If you want the content to be the same in both views and to be dynamically 
updatable then use

view view1 {
zone example.com {
type primary;
[ allow-update / update-policy ] { … };
…
};
};

view view2 {
zone example.com { in-view “view1”; };
};

If you want the zone content to be different then use different file names for 
the zone
and use different TSIG names to select views for NOTIFY, UPDATE, and AXFR.

key view1-update-example.com { … };
key view2-update-example.com { … };
key view1-xfr-example.com { … };
key view2-xfr-example.com { … };

view view1 {
match-clients {
view1-update-example.com; !view2-update-example.com;
view1-xfr-example.com; !view2-xfr-example.com;
…
};
server  {
key view1-xfr-example.com; // so NOTIFY goes to the correct view
};
zone example.com {
type primary;
allow-update { view1-update-example.com; }; // or update-policy
allow-transfer { view1-xfr-example.com; };
file “view1/example.com.db”;
};
};

view view2 {
match-clients { 
!view1-update-example.com; view2-update-example.com;
!view1-xfr-example.com; view2-xfr-example.com;
…
};
server  {
key view1-xfr-example.com; // so NOTIFY goes to the correct view
};
zone example.com {
type primary;
allow-update { view2-update-example.com; }; // or update-policy
allow-transfer { view2-xfr-example.com; };
file “view2/example.com.db”;
};
};

and on the secondaries you 

key view1-update-example.com { … };
key view2-update-example.com { … };
key view1-xfr-example.com { … };
key view2-xfr-example.com { … };

view view1 {
match-clients {
view1-update-example.com; !view2-update-example.com;
view1-xfr-example.com; !view2-xfr-example.com;
…
};
server  {
key view1-xfr-example.com; // so SOA, IXFR and AXFR go to the 
correct view.
};
zone example.com {
type secondary;
primaries { ; };
allow-transfer { view1-xfr-example.com; };
file “view1/example.com.db”;
};
};

view view2 {
match-clients { 
!view1-update-example.com; view2-update-example.com;
!view1-xfr-example.com; view2-xfr-example.com;
…
};
server  {
key view2-xfr-example.com;  // so SOA, IXFR and AXFR go to the 
correct view.
};
zone example.com {
type secondary;
primaries { ; };
allow-transfer { view2-xfr-example.com; };
file “view2/example.com.db”;
};
};

> On 6 Jul 2021, at 05:36, Dean Gibson (DNS Administrator)  
> wrote:
> 
> Currently running Bind v9.11.4:
> 
> Several years ago, I implemented multiple VIEWs using (almost) the exact 
> example in the Reference Manual.  However, I wanted the "example-internal.db" 
> and "example-external.db" to be the same file.
> 
> This worked until I wanted to have "example.com" updateable via ddns.  I 
> don't remember the exact error, but I have a note in my configuration file of 
> "don't do that!" (use the same file).  So, I removed the first zone 
> declaration for "example.com".  That was still with Bind v9, but a lesser 
> minor version.
> 
> So, the result is that I can't do a "dig -k tsig.file @localhost -t axfr 
> example.com" from the server command line.  The transfer is denied, because 
> "match-clients" forces me into the first (internal) VIEW.
> 
> The server is behind a firewall (which has a forward to the server), so "dig" 
> works if I specify "dig -k tsig.file @ns1.example.com".  Because of this, I 
> can still use "dig" like I want on the server.
> 
> However, I'd think this must be a common issue.  Any resolution (like 
> recognizing & dealing with two references to a dynamically updated file)?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___

Re: non-improving referral

2021-07-05 Thread Mark Andrews



> On 6 Jul 2021, at 06:40, @lbutlr  wrote:
> 
> I've been getting a few errors along these lines (bind 9.16.18), the IPs 
> changes, but I don't know what "non0improving referral" means or if I should 
> be concerned. 
> 
> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for 
> 127.0.0.1#16749: non-improving referra
> 
> This IP is  owned bv CenturyLink, which was the company providing our 
> Internet service (they have recently become something called "Lumen", but the 
> IP blocks respond as savvin.net).
> 
> Other IPs have appeared, but I did not note them as the logs rolled as I was 
> distracted by other issues at the time.
> 
> My concern is that they may point to a configuration issue on my end, though 
> dnsviz is happy.

This is an error with the delegation of ok.contact.  The NS records at the 
delegation point do
not match those at the zone apex.

> -- 
> Bart, don't use the Touch of Death on your sister.
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: dig standalone source?

2021-07-05 Thread Mark Andrews

> On 6 Jul 2021, at 05:56, Eric Germann via bind-users 
>  wrote:
> 
> Has ISC given any thought to releasing dig as a separate source package?
> 
> It’s good for testing DoH, but you need to build the entire bind package to 
> get it.  It would be useful for support analysts without the overhead of 
> compiling all of bind to get it

Really, it a couple of extra megabytes of disk space and a couple of extra 
minutes of compile
time.  Dig is not a stand alone component.  It depends on libisc, libdns, 
libisccfg, libirs, and
libbind9.  Thats most of the libraries we build.  It makes no sense to have a 
seperate source
package for dig.

> ---
> Eric Germann
> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
> LinkedIn: https://www.linkedin.com/in/ericgermann
> Twitter: @ekgermann
> Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712
> 
> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
> 
> 
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: 'managed-keys' is deprecated ??

2021-06-14 Thread Mark Andrews
https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf

> On 15 Jun 2021, at 13:51, ToddAndMargo via bind-users 
>  wrote:
> 
> Hi All,
> 
> Fedora 34
> bind 9.16
> 
> The Duck is failing me.
> 
> Placing
>   include "/etc/named.root.key";
> in my bind.conf, give me the following error:
> 
> # named-checkconf -l -t /var/named/chroot /etc/named.conf
> /etc/named.root.key:1: option 'managed-keys' is deprecated
> 
> What do I use in its place?
> 
> Many thanks,
> -T
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.11 to 9.16: need directions

2021-06-13 Thread Mark Andrews
Mbox names are user\.host.example where \. embeds a period in the label. 

-- 
Mark Andrews

> On 13 Jun 2021, at 21:09, Eric Germann via bind-users 
>  wrote:
> 
> bind doesn’t support @ signs for the email contact.  It would be 
> root.rn6.xyz.local
> 
> Line 15, missing the class (IN)?  
> 
> DeadStick IN A 192.168.255.156
>> 
>>INTXT"310702541c5622d0e6001136bd71a6578b"
> 
> ---
> Eric Germann
> ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
> LinkedIn: https://www.linkedin.com/in/ericgermann
> Twitter: @ekgermann
> Telegram || Signal || Phone +1 {dash} 419 {dash} 513 {dash} 0712
> 
> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
> 
> 
> 
> 
> 
> 
> 
>> On Jun 12, 2021, at 8:33 PM, ToddAndMargo via bind-users 
>>  wrote:
>> 
>>> On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote:
>>> Hi All,
>>> I just upgraded from Fedora 33 to Fedora 34.
>>> Bind was updated from 9.11 to 9.16 in Fedora 34.
>>> It completely broke my Fedora 33 configuration.
>>> Would someone please point me to the directions
>>> as to how to migrate from 9.11 to 9.16?
>>> Many thanks,
>>> -T
>> 
>> Some of my error messages:
>> 
>> # named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts
>> 
>> xyz.hosts:3: ignoring out-of-zone data (xyz.local)
>> xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local)
>> 
>> 
>> 
>> 1$ORIGIN .
>> 2$TTL 86400; 1 day
>> 3xyz.localIN SOAxyz.local. root\@rn6.xyz.local. (
>> 4265; serial
>> 510800  ; refresh (3 hours)
>> 63600   ; retry (1 hour)
>> 7360; expire (5 weeks 6 days 16 hours)
>> 886400  ; minimum (1 day)
>> 9)
>>10NSxyz.local.
>>11A192.168.255.10
>>12MX10 xyz.local.
>>13$ORIGIN xyz.local.
>>14$TTL 3600; 1 hour
>>15DeadStickA192.168.255.156
>>16TXT"310702541c5622d0e6001136bd71a6578b"
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.11 to 9.16: need directions

2021-06-12 Thread Mark Andrews
Please don’t hid details if you want help.

If you really want help post all the un-doctored log messages. 

B.T.W. The messages below are because you used the wrong zone name on the 
named-checkconf command line.  The zone file is for xyz.local and you said the 
zone name you used was xyz without the .local. 

-- 
Mark Andrews

> On 13 Jun 2021, at 10:33, ToddAndMargo via bind-users 
>  wrote:
> 
> On 6/12/21 5:30 PM, ToddAndMargo via bind-users wrote:
>> Hi All,
>> I just upgraded from Fedora 33 to Fedora 34.
>> Bind was updated from 9.11 to 9.16 in Fedora 34.
>> It completely broke my Fedora 33 configuration.
>> Would someone please point me to the directions
>> as to how to migrate from 9.11 to 9.16?
>> Many thanks,
>> -T
> 
> Some of my error messages:
> 
> # named-checkzone -t /var/named/chroot/var/named/slaves xyz xyz.hosts
> 
> xyz.hosts:3: ignoring out-of-zone data (xyz.local)
> xyz.hosts:15: ignoring out-of-zone data (DeadStick.xyz.local)
> 
> 
> 
> 1$ORIGIN .
> 2$TTL 86400; 1 day
> 3xyz.localIN SOAxyz.local. root\@rn6.xyz.local. (
> 4265; serial
> 510800  ; refresh (3 hours)
> 63600   ; retry (1 hour)
> 7360; expire (5 weeks 6 days 16 hours)
> 886400  ; minimum (1 day)
> 9)
>10NSxyz.local.
>11A192.168.255.10
>12MX10 xyz.local.
>13$ORIGIN xyz.local.
>14$TTL 3600; 1 hour
>15DeadStickA192.168.255.156
>16TXT"310702541c5622d0e6001136bd71a6578b"
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: no _smtp_tls in published zone

2021-06-01 Thread Mark Andrews


> On 2 Jun 2021, at 14:59, Brett Delmage  wrote:
> 
> I have added the following two records
> _mta-sts.BrettDelmage.ca. 180 IN TXT"v=STSv1; 
> id=2021060102;"
> _smtp._tls.BrettDelmage.ca.   180 IN TXT"TLSRPTv1; 
> rua=mailto:br...@brettdelmage.ca;
> to a signed zone to enable Mail Transfer Agent Strict Transport Security.
> 
> When I run
> 
> /var/lib/bind/master# named-compilezone -k warn -o - BrettDelmage.ca 
> BrettDelmage.ca
> 
> I get the expected error for the leading _, but only for _mta_sts.

Underscore is not an issue for TXT records.  The check-names report is for 
mta_sts.BrettDelmage.ca not _mta_sts.BrettDelmage.ca.

> BrettDelmage.ca:21: mta_sts.BrettDelmage.ca: bad owner name (check-names)
> zone BrettDelmage.ca/IN: loaded serial 2021060110
> BrettDelmage.ca.  180 IN SOA
> cacloud.brettdelmage.ca. hostmaster.BrettDelmage.ca. 2021060110 180 300 
> 1814400 3600
> ...
> _mta-sts.BrettDelmage.ca. 180 IN TXT"v=STSv1; 
> id=2021060102;"
> _smtp._tls.BrettDelmage.ca.   180 IN TXT"TLSRPTv1; 
> rua=mailto:br...@brettdelmage.ca;
> ...
> OK
> 
> When I load the zone I can fetch _mta-sts.BrettDelmage.ca
> dig @127.0.0.1 _mta-sts.brettdelmage.ca txt +short
> "v=STSv1; id=2021060102;"
> 
> but not _smtp._tls.BrettDelmage.ca.:
> 
> dig @127.0.0.1 _smtp._tls.brettdelmage.ca txt
> 
> ; <<>> DiG 9.16.16-Ubuntu <<>> @127.0.0.1 _smtp._tls.brettdelmage.ca txt
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37893
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: a70534bd6a80a8c7010060b70dbd54a4db11f1a5b7d1 (good)
> ;; QUESTION SECTION:
> ;_smtp._tls.brettdelmage.ca.IN  TXT
> 
> ;; AUTHORITY SECTION:
> BrettDelmage.ca.180 IN  SOA cacloud.brettdelmage.ca. 
> hostmaster.BrettDelmage.ca. 2021060110 180 300 1814400 3600
> 
> -
> named -v
> BIND 9.16.16-Ubuntu (Stable Release) 
> 
> What am I doing wrong here?

Not looking at the nameserver’s logs when the zone is loaded.  If it has failed 
to load for any reason that will be reported.

> Thanks!
> 
> Brett
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: configure notify for ixfer?

2021-06-01 Thread Mark Andrews

> On 2 Jun 2021, at 01:18, Cuttler, Brian R (HEALTH) via bind-users 
>  wrote:
> 
> My dns secondary is often behind on its dynamic zone tables.
> It looks to me like we are doing automatic transfer IXFR but not requently 
> enough, but randomly.
>  
> It looks to me that default 10 second interval for min transfer wait time.
>  
> I'm missing something but haven't found the magic yet.
>  
> Both primary/secondary BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 on Centos 
> 7.9.
>  
> Goal is to have dynamic entries replicated on the secondary within a few 
> minutes if not a few seconds.
>  
> From what I’m reading I should be sending a notify from the primary to the 
> secondary when a dynamic zone is updated but I don’t seem to be doing that.
>  
> Would someone please point me to the option I’m missing to do so? I’ve either 
> completely missed it, mis-understood what I read or am going in the wrong 
> direction.
>  
> 01-Jun-2021 07:49:05.425 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 
> 1501355783 -> 1501355796)
> 01-Jun-2021 07:49:05.426 xfer-out: client @0x7f17335f9450 10.50.156.70#45583 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 08:46:52.595 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 
> 1501355796 -> 1501355835)
> 01-Jun-2021 08:46:52.596 xfer-out: client @0x7f17334a7e80 10.50.156.70#39191 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR started (serial 
> 1501355835 -> 1501355858)
> 01-Jun-2021 09:35:10.776 xfer-out: client @0x7f1732f45d60 10.50.156.70#39230 
> (dai.wadsworth.org): transfer of 'dai.wadsworth.org/IN': IXFR ended
>  
> Thanks in advance,
> Brian

Named uses the NS records for the zone to find the addresses of the secondary 
servers to send the NOTIFY messages to. Both primary and secondary servers do 
this by default.  The nameserver listed in the SOA record MNAME field is 
excluded this process.  Ensure you have address record for all your nameservers.

If a secondary is not listed in the NS RRset then you can use also-notify as 
Anand said.

> Brian Cuttler
>  
> ITG - Information Technology Group, Network and System Administrator
> Wadsworth Center, NYS Department of Health
> Empire State Plaza, Albany, NY 12201
> (518) 486-1697 | brian.cutt...@health.ny.gov
>  
>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Mark Andrews
Sorry, miss read your version 11 vs 16.  That said it is hard to work out what 
is going wrong when
you keep changing things and don’t actually have nameservers that are 
responding.   You had servers
that where giving DNSSEC responses, then ones that are returning unsigned 
responses and now ones
that are not answering.

> On 16 May 2021, at 16:44, Dan Egli  wrote:
> 
> Upgrade to WHAT? You said it was fixed in 9.11.25, but isn't that a lot OLDER 
> than 9.16.15, which is what I'm running?
> jupiter ~ # named -v
> BIND 9.16.15 (Stable Release) 
> jupiter ~ # dig -v
> DiG 9.16.15
> 
> 
> On 5/16/2021 12:06 AM, Mark Andrews wrote:
>> 
>>> On 16 May 2021, at 10:17, Dan Egli via bind-users 
>>>  wrote:
>>> 
>>> On 5/10/2021 12:38 PM, Tony Finch wrote:
>>>> Dan Egli 
>>>>  wrote:
>>>> 
>>>>> Still not working for me. The dig doesn't report anything, and I don't 
>>>>> HAVE a
>>>>> keyfile since i'm using inline signing. Or does inline signing still 
>>>>> require a
>>>>> key to be generated?
>>>>> 
>>>> Yes, you need to do your own key management with inline-signing using
>>>> dnssec-keygen. The new dnssec-policy feature can do automatic key
>>>> management for you.
>>>> 
>>>> Tony.
>>>> 
>>> So, I updated the settings. Now I have keyfiles generated by bind, as well 
>>> as a binary .zone.signed in addition to the plain text .zone which has no 
>>> DNSSEC information at all in it. I ran the signing routine and bind said it 
>>> was signed good. So I obtained the DS and put in the registrar. Now I am 
>>> getting SERVFAIL errors whenever I try to query my zone from another name 
>>> server. Here's what I did:
>>> 
>>> #dig newideatest.site dnskey | dnssec-dsfromkey -2 -f - newideatest.site
>>> newideatest.site. IN DS 49236 13 2 
>>> 
>>> Ok. Copy the long hash to the Registrar, plug it in. Check, done that.
>>> 
>>>  # dig mx newideatest.site @8.8.4.4
>>> 
>>> ; <<>> DiG 9.16.15 <<>> mx newideatest.site @8.8.4.4
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 631
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;newideatest.site.  IN  MX
>>> 
>>> ;; Query time: 50 msec
>>> ;; SERVER: 8.8.4.4#53(8.8.4.4)
>>> ;; WHEN: Sat May 15 18:12:44 MDT 2021
>>> ;; MSG SIZE  rcvd: 45
>>> ServFail?! WHAT?
>> This is a known bug fixed in BIND 9.11.25.  Upgrade.  Once the DS is added 
>> to .site for
>> newideatest.site the resolution will work.
>>   
> 
> -- 
> Dan Egli
> From my Test Server
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Inline signing fails dnsviz test - STILL [LONG]

2021-05-16 Thread Mark Andrews
, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
> Warnings (13)
> 
>   • newideatest.site/A: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/: The server responded with no OPT record, 
> rather than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/DNSKEY (alg 13, id 49236): The server responded with 
> no OPT record, rather than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 
> 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_512_D_KN)
>   • newideatest.site/MX: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN, 
> UDP_-_EDNS0_512_D_KN)
>   • newideatest.site/NS: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 103.6.87.125, 
> 119.252.20.56, 2001:19f0:7001:381::3, 2401:1400:1:1201:0:1:7853:1a5, 
> 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, UDP_-_EDNS0_4096_D_KN)
>   • newideatest.site/SOA: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 
> 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> TCP_-_EDNS0_4096_D_N, UDP_-_EDNS0_4096_D_KN, UDP_-_EDNS0_4096_D_KN_0x20)
>   • newideatest.site/TXT: The server responded with no OPT record, rather 
> than with RCODE FORMERR. (31.220.30.73, 45.77.29.133, 
> 103.6.87.125, 119.252.20.56, 2001:19f0:7001:381::3, 
> 2401:1400:1:1201:0:1:7853:1a5, 2403:2500:4000::f3e, 2a04:bdc7:100:1b::3, 
> UDP_-_EDNS0_4096_D_KN)
>   • site to newideatest.site: The following NS name(s) were found in the 
> authoritative NS RRset, but not in the delegation NS RRset (i.e., in the site 
> zone): jupiter.newideatest.site
>   • site to newideatest.site: The following NS name(s) were found in the 
> delegation NS RRset (i.e., in the site zone), but not in the authoritative NS 
> RRset: jupiter.eglifamily.name
>   • site/DS (alg 8, id 51676): DNSSEC specification prohibits signing 
> with DS records that use digest algorithm 1 (SHA-1).
>   • site/DS (alg 8, id 51676): DNSSEC specification prohibits signing 
> with DS records that use digest algorithm 1 (SHA-1).
>   • site/DS (alg 8, id 51676): DS records with digest type 1 (SHA-1) are 
> ignored when DS records with digest type 2 (SHA-256) exist in the same RRset.
>   • site/DS (alg 8, id 51676): DS records with digest type 1 (SHA-1) are 
> ignored when DS records with digest type 2 (SHA-256) exist in the same RRset.
> So, what am I doing wrong? Here's the zone statement for the newideatest.site 
> zone in my named.conf:
> 
> zone "newideatest.site" {
> type master;
> file "pri/newideatest.zone";
> allow-query { any; };
> allow-transfer {
>   108.61.224.67; 116.203.6.3; 107.191.99.111; 185.22.172.112; 
> 103.6.87.125; 192.184.93.99; 119.252.20.56; 31.220.30.73; 185.34.136.178; 
> 185.136.176.247; 45.77.29.133; 116.203.0.64; 167.88.161.228; 199.195.249.208; 
> 104.244.78.122; 2605:6400:30:fd6e::3; 2605:6400:10:65::3; 
> 2605:6400:20:d5e::3; 2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 
> 2a06:fdc0:fade:2f7::1; 2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3; 
> 2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e; 
> 2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3;   
> 2a01:4f8:1c0c:8115::3; 2001:19f0:6400:8642::3;
> };
> allow-update { trusted; };
> key-directory "/var/bind/pri/keys";
> inline-signing yes;
>     dnssec-policy default;
> };
> };
> Help? If you have errors reaching me, try d...@eglifamily.name, as it doesn't 
> seem to be having issues.
> --Dan Egli
> From my Test Server
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 

Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

2021-05-12 Thread Mark Andrews
There is enough information to reproduce. Dig does have +besteffort but it 
doesn’t recover from this. 

You don’t want default handling to accept broken records so just skipping isn’t 
good behavior.  It should be possible to extend +besteffort to print bad 
records in unknown format. 

-- 
Mark Andrews

> On 12 May 2021, at 22:17, Stoffel, John (TAI)  
> wrote:
> 
> Tony,
> A big thanks to you for your suggestion on using the Perl Net::DNS module, 
> using that, I was then able to run named-checkzone on the dumped file 
> (35,000+ lines!) to find the one bad record which was making things crap out. 
>  I'm back a bit on bind versions, but not that far back, so I would have 
> expected bind to just ignore that bogus record instead of crapping out.  
> 
> Unfortunately, I don't think I saved a copy of the bad record so I could file 
> a bug report, too busy trying to make things work.  
> 
> Cheers,
> John
> 
> 
> Sr. Storage Architect
> TOSHIBA AMERICA, INC.
> 290 Donald Lynch Blvd - Suite 201
> Marlborough, MA 01752
> 508-736-5499 (mobile)
> E-Mail:  john.stof...@toshiba.com
> Website: Service Now Self Service Portal
> 
> 
> -Original Message-
> From: Tony Finch  On Behalf Of Tony Finch
> Sent: Tuesday, May 11, 2021 7:13 PM
> To: Stoffel, John (TAI) 
> Cc: bind-users@lists.isc.org
> Subject: RE: ISC Bind as secondary to Windows Server: bad bitmap error on 
> named xfer.
> 
> Stoffel, John (TAI)  wrote:
>> 
>> And it does dump some errors too, which hopefully will give me an idea 
>> of where my crappy bad record is located, and no use hiding crap:
> 
> yuck, this looks like no fun...
> 
>> http://www.cisco.toshiba.com.  3600IN  CNAME   redirect.toshiba.com.
>> http://www.cisco.toshiba.com.  3600IN  RRSIG   CNAME 8 4 3600 
>> 20210517093721 20210507083721 38628 t
>> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN 
>> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ C6zJn9HHdC9o2dwBoGpknTwJM 
>> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM= ;; Got 
>> bad packet: bad bitmap
>> 16358 bytes
> 
> does it print more hexdump? who knows where the problem might be in 16KB of 
> wire-format DNS...
> 
> I would try another DNS AXFR client that might not give up so easily, e.g.
> if you have a handy copy of perl and Net::DNS, put your Windows DNS server IP 
> address into this one-liner instead of 127.0.0.1
> 
> perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); 
> $r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { 
> $rr->print }'
> 
> The bit of the hexdump you pasted shows another similar CNAME and its RRSIG, 
> so it isn't very enlightening.
> 
>> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73  Ftos
>  headerRR counts qname = zone name
>> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69  hiba.com..ci
>  00fc = axfr
>> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10  tibank..
> backpointer to zone = c00c 0005 = cname
> 
> citibank looks like it follows cisco alphabetically which suggests the zone 
> transfer might be in canonical order, which could perhaps make it easier to 
> find the stray NXT / TYPE30 record(s)
> 
>> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00  ...redirect.
>   cname target  c01d = backpointer to citibank
>> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e  
>  2e = rrsig   type covered = 0005 (cname)
>> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68  .`.9Q`..A...tosh
>> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54  iba.com2..*T
>> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae  e..(A..`
> 
> etc.
> 
> Tony.
> --
> f.anthony.n.finch
> https://urldefense.com/v3/__https://dotat.at/__;!!BiNunAf9XXY-!TxYeCrRieZyIcOGlb6sXZGm2RAMoSAa_FQxkoFEaSb2XkNsrzZa1Jjd7CvB-n6i-tTNB$
> Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight or 
> moderate in Fisher, smooth or slight in German Bight. Showers, fog patches. 
> Moderate, occasionally very poor.
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: [External] strange queries incrementing letter by letter

2021-05-07 Thread Mark Andrews
Some piece of software trying to speed up resolution by resolving names as you 
type.

-- 
Mark Andrews

> On 8 May 2021, at 04:21, Kevin A. McGrail  wrote:
> 
> 
> Weird.
> 
> Thoughts are:
> 
> Bad software?  What we call ratware.  
> 
> UDP/TCP Firewall issues?
> 
> Regards,
> 
> KAM
> 
>> On 5/7/2021 1:32 PM, Kevin Kretz wrote:
>> I see occasional series of queries like this, from within my network and 
>> among disparate types of host (linux, windows):
>> 
>> If there's a host called 
>> 
>> hostname.mynet.com
>> 
>> I'll see a sequence of queries like
>> 
>> hostname.m
>> hostname.my
>> hostname.myn
>> hostname.myne
>> hostname.mynet
>> hostname.mynet.c
>> hostname.mynet.co
>> hostname.mynet.com
>> 
>> Can anyone tell me what this is?
>> 
>> 
>> thanks
>> 
>> Kevin
>> 
>> 
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> 
> 
> 
> 
>  
> 
> Kevin A. McGrail
> CEO Emeritus
> Peregrine Computer Consultants Corporation
>  
> 
> +1.703.798.0171   
> 
> kmcgr...@pccc.com
> 
>  https://pccc.com/
> 
> https://raptoremailsecurity.com
> 
> 10311 Cascade Lane, Fairfax, Virginia 22032-2357 USA
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 won't listen

2021-05-06 Thread Mark Andrews
listen-on is a ACL.  0.0.0.0 is short hand for 0.0.0.0/32 and that matches an
interface that is NOT configured.  Use “any;”.

> On 7 May 2021, at 15:37, Dan Egli  wrote:
> 
> Okay, I got all the zones loaded by named-checkzone, and named-checkconf 
> returns no errors. So I started up named in the foreground using the -g 
> option. All looks good, UNTIL it gets to where it is supposed to listen on 
> port 53. Then I get:
> 
> 06-May-2021 23:35:20.979 not listening on any interfaces
> 
> Why not? My config file specifically says listen-on { 0.0.0.0; }; and 
> listen-on-v6 { ::; };
> 
> -- 
> Dan Egli
> From my Test Server
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 refusing my DKIM key

2021-05-06 Thread Mark Andrews
Split the record at 255 characters.  TXT field need to be <= 255 characters.
Complain to the developers of the tool that created this record that it is
INVALID as the field length is TOO BIG. 

> On 7 May 2021, at 14:35, Dan Egli  wrote:
> 
> I don't know what's up, but when I tried to put my DKIM into the test server, 
> named-checkzone keeps giving a syntax error on the key line. Here's what I'm 
> putting in (it really is on one line in the zone file, just too long for my 
> MUA to put on one line):
> 
> key1._domainkeyINTXT
> "v=DKIM1;p=QUFBQUIzTnphQzF5YzJFQUFBQURBUUFCQUFBQWdRQ3B0Uy9SMzRJQm5yZEhGZFYzNE4zMmdWUjQyelFDUnpXdkJMWDloNkUwOUlRNnBsV0p3S09aL0hHQ3ZjSHlaNytKZVk4MWlCR1p4NWhLN1pvQkZaYTMxcjlmMDRZU2NkeVZmVUQrb004UjJCQzBGNVdQY3ptMGl1TVJQemFqY29tSU5LSHltWEplRHU0K05oTnlhWEJoRi9oS0hrUlNJeFNDU3JqbWxlZWRsdz09IA=="
> 
> 
> But when I run checkzone:
> dns_rdata_fromtext: myzone.zone:26: syntax error
> zone eglifamily.name/IN: loading from master file myzone.zone failed: syntax 
> error
> 
> What's wrong? Why is it failing?
> -- 
> Dan Egli
> From my Test Server
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: took a while to figure out why all your tests fail

2021-05-06 Thread Mark Andrews
First of all the user running the tests needs to be able to write to 
bin/tests/system. See the permission denied from tee. 

-- 
Mark Andrews

> On 7 May 2021, at 08:20, Dennis Clarke via bind-users 
>  wrote:
> 
> 
> 
> I very carefully created an airgap test system for this process and did
> setup all the required network interfaces. However all tests fail
> terribly due to some weird python requirement ?
> 
> airgap$ ./runall.sh -n
> + SYSTEMTESTTOP=.
> + . ./conf.sh
> ++ TOP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005
> ++ DEFAULT_ALGORITHM=RSASHA256
> ++ DEFAULT_ALGORITHM_NUMBER=8
> ++ DEFAULT_BITS=1280
> ++ TMPDIR=/tmp
> ++ ALTERNATIVE_ALGORITHM=RSASHA1
> ++ ALTERNATIVE_ALGORITHM_NUMBER=5
> ++ ALTERNATIVE_BITS=1280
> ++ DISABLED_ALGORITHM=ECDSAP384SHA384
> ++ DISABLED_ALGORITHM_NUMBER=14
> ++ DISABLED_BITS=384
> ++ NAMED=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named
> ++
> LWRESD='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/named/named -l'
> ++ DIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/dig
> ++ DELV=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/delv/delv
> ++ RNDC=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/rndc/rndc
> ++
> NSUPDATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/nsupdate/nsupdate
> ++
> DDNSCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/ddns-confgen
> ++
> TSIGKEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/tsig-keygen
> ++
> RNDCCONFGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/confgen/rndc-confgen
> ++
> KEYGEN=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keygen
> ++
> KEYFRLAB=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-keyfromlabel
> ++
> SIGNER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-signzone
> ++
> REVOKE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-revoke
> ++
> SETTIME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-settime
> ++
> DSFROMKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-dsfromkey
> ++ HOST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/host
> ++
> IMPORTKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-importkey
> ++
> CHECKDS=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-checkds
> ++
> COVERAGE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-coverage
> ++
> KEYMGR=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/python/dnssec-keymgr
> ++
> CHECKZONE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkzone
> ++
> CHECKCONF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/check/named-checkconf
> ++
> PK11GEN='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-keygen
> -q -s 0 -p 1234'
> ++
> PK11LIST='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-list
> -s 0 -p 1234'
> ++
> PK11DEL='/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/pkcs11/pkcs11-destroy
> -s 0 -p 1234 -w 0'
> ++
> JOURNALPRINT=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-journalprint
> ++
> VERIFY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dnssec/dnssec-verify
> ++
> ARPANAME=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/arpaname
> ++
> RESOLVE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/lib/samples/resolve
> ++
> RRCHECKER=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-rrchecker
> ++
> GENRANDOM=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/genrandom
> ++
> NSLOOKUP=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/dig/nslookup
> ++
> DNSTAPREAD=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/dnstap-read
> ++ MDIG=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/mdig
> ++
> NZD2NZF=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tools/named-nzd2nzf
> ++ FSTRM_CAPTURE=
> ++
> FEATURETEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/feature-test
> ++
> RANDFILE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/random.data
> ++
> BIGKEY=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rsabigexponent/bigkey
> ++
> GENCHECK=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/rndc/gencheck
> ++
> KEYCREATE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keycreate
> ++
> KEYDELETE=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/tkey/keydelete
> ++
> LWTEST=/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.005/bin/tests/system/lwresd/lwtest
> ++
> MAKEJOURNAL=/opt/bw/build/bind-9.11.31

Re: Slightly baffled about Undefined symbols that are in OpenSSL

2021-05-05 Thread Mark Andrews
Use a non EoL version of OpenSSL. 

-- 
Mark Andrews

> On 5 May 2021, at 22:32, Dennis Clarke via bind-users 
>  wrote:
> 
> 
> This has kept me spinning in a few hours since yesterday. So I gave a
> try at configure and compile of bind-9.11.31 on ye Fujitsu/Oracle SPARC
> Solaris 10 boxen and I see :
> 
> 
> .
> .
> .
> /opt/developerstudio12.6/bin/cc -mt
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 -I../..
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include
> -I../../lib/dns/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include
> -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include
> -I../../lib/bind9/include  -I/opt/bw/include  -D_REENTRANT
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL
> -DVERSION=\"9.11.31\" -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 -m64
> -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full
> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff
> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1
> -xregs=no%appl -xdebugformat=dwarf -I/usr/include/libxml2-KPIC-c
> isc-hmac-fixup-symtbl.c
> gmake[3]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
> Undefined   first referenced
> symbol in file
> EVP_MD_CTX_new  ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_sha512  ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha384  ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha224  ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_sha256  ../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_DigestInit  ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_DigestUpdate../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_MD_CTX_reset../../lib/isc/libisc-nosymtbl.a(sha2.o)
> EVP_md5 ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_sha1../../lib/isc/libisc-nosymtbl.a(sha1.o)
> EVP_DigestFinal ../../lib/isc/libisc-nosymtbl.a(md5.o)
> EVP_MD_CTX_free ../../lib/isc/libisc-nosymtbl.a(md5.o)
> ld: fatal: symbol referencing errors. No output written to
> isc-hmac-fixuptmp1
> gmake[2]: *** [Makefile:495: isc-hmac-fixup] Error 1
> gmake[2]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin/tools'
> gmake[1]: *** [Makefile:79: subdirs] Error 1
> gmake[1]: Leaving directory
> '/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/bin'
> gmake: *** [Makefile:88: subdirs] Error 1
> 
> 
> That is just bizarre because I can cd into the bin/tools directory and
> do the link stage manually just fine :
> 
> alpha $ /opt/developerstudio12.6/bin/cc -mt \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003 \
>> -I../.. \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/dns/include \
>> -I../../lib/dns/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isc/include \
>> -I../../lib/isc \
>> -I../../lib/isc/include \
>> -I../../lib/isc/unix/include \
>> -I../../lib/isc/pthreads/include \
>> -I../../lib/isc/noatomic/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/isccfg/include \
>> -I../../lib/isccfg/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/lwres/include \
>> -I../../lib/lwres/unix/include \
>> -I../../lib/lwres/include \
>> -I/opt/bw/build/bind-9.11.31_sunos5.10_sparcv9.003/lib/bind9/include \
>> -I../../lib/bind9/include \
>> -I/opt/bw/include \
>> -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DOPENSSL \
>> -DVERSION=\"9.11.31\" \
>> -D_XPG4_2 -D__EXTENSIONS__ -std=iso9899:2011 \
>> -m64 -xarch=sparc -g -mc -xs -errfmt=error -erroff=%none -errshort=full \
>> -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none -xildoff \
>> -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil -xunroll=1 \
>> -xregs=no%appl -xdebugformat=dwarf -KPIC \
>> -H -# -c isc-hmac-fixup-symtbl.c
> ### cc: Note: NLSPATH =
> /opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
> 

Re: managed-keys-error since BIND-9.16.15

2021-05-02 Thread Mark Andrews
I suspect we missed a auto detection case.  Can you open ticket on 
https://gitlab.isc.org.  We will need to see the journal and
whatever else was logged at the same time.

That said "named-journalprint -u /var/named/slave/example.com.hosts.jnl" should 
fix the issue.  Only run this when named
is stopped.

> On 3 May 2021, at 15:31, Tom  wrote:
> 
> I see the same error also on a couple of slave zones on a updated 
> authoritative server, not only on the "managed-keys.bind"-file. So this is 
> also not critical and can be ignored?
> 
> 03-May-2021 00:20:28.532 general: error: 
> /var/named/slave/example.com.hosts.jnw: journal file corrupt: expected serial 
> 2021050100, got 2021050300
> 03-May-2021 00:20:28.532 general: error: zone example.com/IN: 
> dns_journal_compact failed: unexpected error
> 
> Thank you.
> Kind regards,
> Tom
> 
> 
> On 01.05.21 08:52, Mark Andrews wrote:
>> Named should automatically correct this error. The journal version was not 
>> updated when the transaction header was updated. This has been corrected and 
>> named detects the unexpected transaction header and writes out a corrected 
>> journal.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: managed-keys-error since BIND-9.16.15

2021-05-01 Thread Mark Andrews
Named should automatically correct this error. The journal version was not 
updated when the transaction header was updated. This has been corrected and 
named detects the unexpected transaction header and writes out a corrected 
journal. 

-- 
Mark Andrews

> On 30 Apr 2021, at 21:16, Tom  wrote:
> 
> Hi
> 
> After upgrading to BIND-9.16.15, I have the following error in named.log:
> 
> 30-Apr-2021 12:41:29.194 general: error: managed-keys.bind.jnw: journal file 
> corrupt: expected serial 1823, got 1824
> 30-Apr-2021 12:41:29.194 general: error: managed-keys-zone: 
> dns_journal_compact failed: unexpected error
> 
> $ l /var/named/managed-keys.bind*
> -rw-r--r--. 1 named named  821 30. Apr 12:41 /var/named/managed-keys.bind
> -rw-r--r--. 1 named named 4.5K 30. Apr 12:41 /var/named/managed-keys.bind.jnl
> 
> Yesterday (after initially starting the latest version) the error occured the 
> first time on server1. Then I stopped named on server1, removed both files 
> (.bind and .bind.jnl), and startet named again.
> 
> Today, the same error appeared one time on server2, but named seems working 
> fine, also DNSSEC verification. With "named-journalprint" I'm able to print 
> to content of the managed-keys.bind.jnl.
> 
> Any hints about this error?
> 
> Thank you.
> Kind regards,
> Tom
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Configuring the location of named .jnl files

2021-04-26 Thread Mark Andrews
Well if you are not allowed to update the zone file for “security reasons” then
allowing a journal to be written shouldn’t be allowed for the same “security 
reasons”.
There is no difference between updating a zone file and updating a journal from 
a
security perspective.

Additionally you will just be adding more and more processing to the startup of 
named
if you have a un-writeable zone file as every change to the zone through the 
life of
the zone will have to be applied serially.  You will also have problems if you 
have
to roll the zones serial number as journals really aren’t designed to be used 
with
a zone file that is not being consolidated regularly.  Journals are not 
designed to
have serial numbers loop over.  Which instance of serial 5 are you referring 
too if
there are multiple 5s in the journal.

I suggest that you go back as re-examine your security policy.  Even SELinux 
moves
dynamically updatable zones to a writable directory so that the zone files can 
be
updated.

Mark

> On 27 Apr 2021, at 03:26, Ivan Avery Frey  wrote:
> 
> Yes, I was using nsupdate to test my implementation. For security reasons the 
> directory that holds the zone file is readonly for named. So named couldn't 
> create its journal file there. I misinterpreted the reference manual for the 
> description of the "journal" command. Where it mentioned that the "filename" 
> could be overridden I wasn't thinking it could be a pathname.
> 
> Just to clarify, I will be using the certbot client with the dns-rfc2136 
> plugin to receive my certificates.
> 
> I wonder why they don't have a dns-local plugin. It would be a whole lot 
> simpler.
> 
> On Mon., Apr. 26, 2021, 09:57 Kevin Darcy via bind-users, 
>  wrote:
> [ Classification Level: GENERAL BUSINESS ]
> 
> Ivan,
>I've never done the Let's Encrypt thing myself, but from my skim 
> of the documentation, it appears they want you to place a TXT record in a 
> specific part of your domain's namespace hierarchy.
> 
> I sincerely hope you're not trying to write the TXT record directly to the 
> journal file. That could lead to corruption, or, at the very least, your 
> changes could be overwritten, since journal files are written dynamically.
> 
> The safe way to update DNS programmatically is through the Dynamic Update 
> extension to DNS, typically via the "nsupdate" command-line utility, or via 
> various libraries/modules of scripting languages like Perl or Python.
> 
> One of the bash-based ACME client implementations linked from Let's Encrypt's 
> webpage, for instance, is github.com/bruncsak/ght-acme.sh, and for the DNS-01 
> challenge method, it feeds some commands to nsupdate. The code is rather 
> crude, assuming no crypto-based authentication on the server side, among 
> other things, but it's at least a start on a recommended way to update DNS 
> data. Better than mucking around with journal files.
> 
> There is a learning curve associated with Dynamic Update. On the server side, 
> for instance, you'll need to establish permissions via allow-update. Limiting 
> updates to localhost at least would protect your DNS data from unauthorized 
> changes from remote hosts, but ideally, you'd generate a key and use that.
> 
>   
>- Kevin
> 
> On Sun, Apr 25, 2021 at 7:39 PM Ivan Avery Frey  
> wrote:
> I'm trying to obtain certificates from Let's Encrypt using the DNS-01
> challenge method.
> 
> I just want to confirm that there is no option to configure the
> directory for the .jnl files independently of the zone files.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/c

Re: Configuring the location of named .jnl files

2021-04-25 Thread Mark Andrews
zone example {
…;
journal ;
};

> On 26 Apr 2021, at 09:38, Ivan Avery Frey  wrote:
> 
> I'm trying to obtain certificates from Let's Encrypt using the DNS-01
> challenge method.
> 
> I just want to confirm that there is no option to configure the
> directory for the .jnl files independently of the zone files.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Ask for automated KSK roll with DS checking

2021-04-15 Thread Mark Andrews
and the following for the child side should work.  If you are only interested
in DS algorithm 2 check that $6 == 2 (&& $6 == 2) when selecting DS and CDS 
records from the
stream.  Again untested.

while read zone garbage
do
( echo "ds -q $zone"; echo "cds -q $zone"; ) |
dig +noall +answer +nottl -f - |
tr '[A-Z]' '[a-z]' |
sort |
awk 'BEGIN { last = "" ; cds=""; ds="" }
$3 == "cds" {
if ($1 != last) {
if (last != "" && cds == ds) {
print "rndc dnssec -checkds published", last
}
if (last != "" && ds == "" && match(cds, "0 0 00")) {
print "rndc dnssec -checkds withdrawn", last
}
last=$1; cds=""; ds=""
}
csd=cds " " $0
}
$3 == "ds" {
ds=ds " " $0
}
END {
if (last != "" && cds == ds) {
print "rndc --checkds published", last
} 
if (last != "" && ds == "" && match(cds, "0 0 00")) {
print "rndc dnssec -checkds withdrawn", last
}
}'
done

> On 16 Apr 2021, at 03:54, Bob Harold  wrote:
> 
> 
> On Thu, Apr 15, 2021 at 12:44 PM Tony Finch  wrote:
> Matthijs Mekking  wrote:
> > On 15-04-2021 16:35, Bob Harold wrote:
> > >
> > > If BIND holds both the child and parent zone, will it add the DS record
> > > at the correct time?  Or do I still need to write scripts to update the
> > > DS records in all my sub-zones?  And is there some signal from BIND at
> > > the time the DS record should be written, or do i need to calculate the
> > > right time?
> >
> > Currently you still have to write scripts to update DS records in all
> > your parent zones.
> >
> > The CDS/CDNSKEY records are published in the child zones that indicate
> > the DS should be published, so I would script against that.
> >
> > Then when the DS is seen in the parent, call the rndc dnssec -checkds
> > published/withdrawn command.
> 
> dnssec-cds can tell you what the parental DS record(s) should be. It
> can maintain a dsset file for each child zone that you can $INCLUDE in the
> parent. It's fairly bare so it needs to be wrapped with a script that does
> the necessary queries and updates.
> 
> I don't know if the dnssec-policy stuff includes timing parameters or
> checks to protect against parental publication delays; if not then the
> wrapper script will have to keep track of time or poll the parent servers
> or something.
> 
> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Fair Isle: South 3 to 5, occasionally 6 later. Slight or moderate,
> becoming rough later in west. Fair. Good.
> 
> Seeing that I still need some scripting, does anyone already have scripts 
> that work?
> 
> -- 
> Bob Harold
>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Ask for automated KSK roll with DS checking

2021-04-15 Thread Mark Andrews
The following should work.  I’ve not tested it.

zone=“$1"
shift
dig axfr -q "${zone}" |
tr '[A-Z]' '[a-z]' |
awk ‘
BEGIN { zone=“” }
$4 == “soa” { zone=$1 }
$1 != zone && $4 == "ns" { print "cds", $1 }' |
sort -u |
dig -f - |
awk '
BEGIN { last = ""; secure=0 }
$1 = ";;" && $2 == "flags:" {
if (/ad;/) {
secure=1
} else {
secure=0
}
}
secure == 1 && $4 == "CDS" {
if (last != $1) {
if (last != "") {
print "send"
}
print "update delete", $1, "DS"
last = $1;
}
if ($5 != "0" && $6 != "0" && $7 != "00") {
$4 = "DS"
print "update add", $0
}
}
END { if (last != "") { print "send" } }
' |
nsupdate “$@"


> On 16 Apr 2021, at 03:54, Bob Harold  wrote:
> 
> 
> On Thu, Apr 15, 2021 at 12:44 PM Tony Finch  wrote:
> Matthijs Mekking  wrote:
> > On 15-04-2021 16:35, Bob Harold wrote:
> > >
> > > If BIND holds both the child and parent zone, will it add the DS record
> > > at the correct time?  Or do I still need to write scripts to update the
> > > DS records in all my sub-zones?  And is there some signal from BIND at
> > > the time the DS record should be written, or do i need to calculate the
> > > right time?
> >
> > Currently you still have to write scripts to update DS records in all
> > your parent zones.
> >
> > The CDS/CDNSKEY records are published in the child zones that indicate
> > the DS should be published, so I would script against that.
> >
> > Then when the DS is seen in the parent, call the rndc dnssec -checkds
> > published/withdrawn command.
> 
> dnssec-cds can tell you what the parental DS record(s) should be. It
> can maintain a dsset file for each child zone that you can $INCLUDE in the
> parent. It's fairly bare so it needs to be wrapped with a script that does
> the necessary queries and updates.
> 
> I don't know if the dnssec-policy stuff includes timing parameters or
> checks to protect against parental publication delays; if not then the
> wrapper script will have to keep track of time or poll the parent servers
> or something.
> 
> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Fair Isle: South 3 to 5, occasionally 6 later. Slight or moderate,
> becoming rough later in west. Fair. Good.
> 
> Seeing that I still need some scripting, does anyone already have scripts 
> that work?
> 
> -- 
> Bob Harold
>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Preventing a particular type of nameserver abuse

2021-04-14 Thread Mark Andrews


> On 15 Apr 2021, at 11:35, @lbutlr  wrote:
> 
> On 14 Apr 2021, at 01:48, Anand Buddhdev  wrote:
>> This is a short-sighted opinion. If just one authoritative server sends
>> out REFUSED responses towards an innocent, it won't matter. But if 1000
>> authoritative servers all send out REFUSED responses towards an innocent
>> IP address, their combined volume and packet rate *is* significant.
> 
> Is it?
> 
> How big is a REFUSED response?

Approximately the same size as the request.  It depends on the request and
the server’s capabilities.

> Even if it is 100 bytes (and I think it is not that large, but I cannot find 
> it), 1000 refused would be 100K.
> 
> How many thoudanss of servers do you need in this "DDoS" to overwhelm a 
> pretty average connection? (My home connection is only 200Mbps down).
> 
> Granted, a million machines would be generating a 100MB of data, which is 
> insignificantes, but the number of pockets at that scale would probably be an 
> issue. But is a million servers realistic?
> 
> I don't think calling this a DDoS is accurate. It is more likely;y there is a 
> known exploit for some servers and they are probing or it is some script 
> kiddie just blasting out packets hoping to get lucky.

If you really want to do something, talk to your local politician and get laws 
written up that require ISPs to deploy BCP38.  This is completely fixable if 
ISPs deploy BCP38 filters on themselves and all of their customers.  There is 
some CAPEX and OPEX to deploying BCP38 filters and making it a requirement 
under law levels the playing field between ISPs.

> -- 
> "Are you pondering what I'm pondering?"
> "I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
>   it doing right now?"
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: No logging of failed queries

2021-04-13 Thread Mark Andrews
Real world configurations would have a catch all view after the more specific 
views. Add one. 

-- 
Mark Andrews

> On 13 Apr 2021, at 22:41, Sachchidanand Upadhyay via bind-users 
>  wrote:
> 
> 
> Hi,
> 
>I am using bind's geoip feature, created one ACL to allow country IN. I am 
> not getting logs of a failed query if the client IP is other than than 
> country IN.
>Rest all is working fine, getting logs of successful queries. Below find 
> the config details:
> 
> BIND 9.16.13 (Stable Release) 
> running on Linux x86_64 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 
> UTC 2021
> built by make with '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--mandir=/usr/share/man' '--with-libtool=/usr/lib64' '--disable-static' 
> '--with-maxminddb'
> compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
> compiled with OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
> linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
> compiled with libuv version: 1.41.0
> linked to libuv version: 1.41.0
> compiled with zlib version: 1.2.7
> linked to zlib version: 1.2.7
> linked to maxminddb version: 1.2.0
> threads support is enabled
> 
> default paths:
>   named configuration:  /etc/named.conf
>   rndc configuration:   /etc/rndc.conf
>   DNSSEC root key:  /etc/bind.keys
>   nsupdate session key: /var/run/named/session.key
>   named PID file:   /var/run/named/named.pid
>   named lock file:  /var/run/named/named.lock
>   geoip-directory:  /usr/share/GeoIP
> 
> 
> acl "test" {
>  geoip country IN;
> };
> 
> options {
>   geoip-directory  "path to geo db";
> 
> view "local" {
> match-clients {  test; };
> recursion yes;
> 
> channel queries {
> file "/var/log/queries";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category queries {
> queries;
> };
> channel security {
> file "/var/log/security";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category security {
> queries;
> };
> channel query-errors {
> file "/var/log/query-errors";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category query-errors {
> query-errors;
> };
> 
> 
> BR,
> Sachchidanand 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 126.0.0.1 has 0 SOIA records

2021-04-12 Thread Mark Andrews
Please open a ticket at https://gitlab.isc.org/ for this.
The zone file is being updated and re-written when it shouldn’t be.
We will want more details from you.

> On 13 Apr 2021, at 08:19, @lbutlr  wrote:
> 
> On 12 Apr 2021, at 07:04, Matthijs Mekking  wrote:
>> Perhaps inspect the zone file?
> 
> Ah, since it is named localhost-reverse.db I assumed it was not plain txtm 
> but some db format.
> 
>>>> FILE
> $ORIGIN .
> $TTL 3600   ; 1 hour
> 0.ip6.arpa  IN SOA  localhost. nobody.localhost. (
>48 ; serial
>86400  ; refresh (1 day)
>43200  ; retry (12 hours)
>604800 ; expire (1 week)
>10800  ; minimum (3 hours)
>)
>NS  localhost.
>CDS 0 0 0 (
>00 )
>CDNSKEY 0 3 0 (
>AA==
>) ; ZSK; alg = 0 ; key id = 768
> $ORIGIN 0.0.0.ip6.arpa.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR localhost.
> 1   PTR localhost.
> FILE
> 
> That looks… very wrong. I wonder what happened. OK, storing that file from 
> backup too.
> 
>> Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from 
>> the unsigned zone files?
> 
> Yeah, I don't know what happened to these files; they should be the default 
> ones FreeBSD makes )they are, now, once again)
> 
> Thank you so much, I would never have found that.
> 
> -- 
> Keep Virginia clean...throw your trash into Maryland.
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: forwarding zone setup from a BIND slave (without recursion?)

2021-04-07 Thread Mark Andrews



> On 8 Apr 2021, at 00:37, Tony Finch  wrote:
> 
> Chuck Aurora  wrote:
>> 
>> A stub or static-stub zone would not require recursion.  In that case
>> named is asking for authoritative data from upstream.  But type
>> forward zones indeed cannot work if recursion is disabled.
> 
> Be careful in this kind of situation to be very clear about which client
> or server is doing what: in this case, it isn't clear what doesn't require
> recursion for stub or static stub.
> 
> All three types of zone configuration (stub, static stub, and forward)
> are only useful on a server that is providing recursive service.
> 
> Forward zones require the upstream server to be recursive too.

More correctly, the upstream server has to serve the entire namespace being
forwarded if it does not off recursion to the client for forwarding to
work.

> Stub and static-stub expect the upstream server to be authoritative;
> the stub server list is a hint that gets replaced by the authoritative
> server list from the zone (a bit like the root hints) whereas static-stub
> only uses the configured upstream servers.
> 
>>> What I've learned from this list is that you should split
>>> authoritative and recursive service.
>> 
>> I would suggest that as a general best practice, but not an absolute
>> one.  There's nothing wrong with having internal-only authoritative
>> zones on your recursive resolver.  The potential problem comes when
>> you're a globally-published NS for your zones; having recursion
>> enabled can make you vulnerable to more possible attacks.
> 
> Right: the rule is that authoritative servers listed as targets of NS
> records should be authoritative-only; it's OK if recursive servers have
> authoritative copies of zones: it can make them more resilient to outages,
> though it does slightly weird things to DNSSEC validation.
> 
> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4,
> then southwest 4 to 6 later. Very rough at first in north, otherwise
> moderate or rough. Snow showers, then rain for a time later. Good,
> occasionally very poor at first.
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Maximum limit in a NAPTR RR

2021-03-31 Thread Mark Andrews
The flags, services and regexp are each limited to 255 characters.

https://tools.ietf.org/html/rfc2915

8. DNS Packet Format


 The packet format for the NAPTR record is:

  1  1  1  1  1  1
0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  | ORDER |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |   PREFERENCE  |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  / FLAGS /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  /   SERVICES/
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  /REGEXP /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  /  REPLACEMENT  /
  /   /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+





Mealling & Daniel   Standards Track[Page 13]
 
RFC 2915  NAPTR DNS RRSeptember 2000



where:

   FLAGS A  which contains various flags.

   SERVICES A  which contains protocol and service
  identifiers.

   REGEXP A  which contains a regular expression.

   REPLACEMENT A  which specifies the new value in the
  case where the regular expression is a simple replacement
  operation.

and  as used here are defined in
   
RFC1035 [1].



> On 31 Mar 2021, at 21:53, Harshith Mulky  wrote:
> 
> Hello Experts,
> 
> Need a help,
> How do I know what is the maximum limit in a NAPTR RR which I am trying to 
> configure?
> 
> If I configure as below
> 
> 5.4.7.7.7.0.1.telus.com. IN NAPTR 8 0 "u" "sip+E2U" 
> "!^(.*)()(..)$!sip:\\1@154.11.143.16;maddr=\\2.\\3.prim-sc.RL.telus.com;x-nortel-profile=canadian.destinations;lata=;tgrp=EGRESS;name=example;place=india;animal=peacock;thing=wheel;test1=;test2=;test3=;test4=;test5=;test6=;test7=!".
> 
> I am getting Error as below:
> # named-checkzone telus.com telus.zone
> dns_rdata_fromtext: telus.zone:35: syntax error
> zone telus.com/IN: loading from master file telus.zone failed: syntax error
> zone telus.com/IN: not loaded due to errors.
> 
> But if I have a reduced response removing few lines/characters as below
> 5.4.7.7.7.0.1.telus.com. IN NAPTR 8 0 "u" "sip+E2U" 
> "!^(.*)()(..)$!sip:\\1@154.11.143.16;maddr=\\2.\\3.prim-sc.RL.telus.com;x-nortel-profile=canadian.destinations;lata=;tgrp=EGRESS;name=example;place=india;animal=peacock;thing=wheel;test1=;test2=;test3=;test4=;test5=;test6=!";
> 
> I have no issues with loading the Zone file
> # named-checkzone telus.com telus.zone
> zone telus.com/IN: loaded serial 2021033103
> OK
> 
> My question:
> 
>   • Is there a limit to the number of characters in a Resource Record?
>   • If yes, is there a possibility to increase this limit in the RR? 
> Thanks in Advance
> Harshith
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.13 overwrote master files

2021-03-29 Thread Mark Andrews
Carl,
  can you add a “#” in front of "dnssec-policy” in bin/named/config.c
and see how that goes for you.  That will comment out the default 
‘dnssec-policy “none”;’.

Please let us know how that goes for you.

Mark

> On 29 Mar 2021, at 15:02, Carl Byington  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Mon, 2021-03-29 at 12:54 +1100, Mark Andrews wrote:
>> What do you have in options?
> 
> options {
>directory "/var/named";
>allow-recursion { "friends"; };
>dnssec-enable yes;
>dnssec-validation auto;
>bindkeys-file "/etc/named.bind.keys";
>managed-keys-directory "/var/named/dynamic";
>listen-on-v6 {any;};
>ixfr-from-differences yes;
>max-journal-size 2m;
>notify yes;
>response-policy { zone "rpz.five-ten-sg.com";}
>qname-wait-recurse no;
>rate-limit {
>responses-per-second 500;
>errors-per-second50;
>nxdomains-per-second 500;
>qps-scale4000;
>exempt-clients { "friends"; };
>};
>max-recursion-queries 200; qname-minimization disabled;
>fetches-per-server 50;
>fetches-per-zone   50;
>server-id hostname;
> };
> 
> This is on Centos 8. I will setup a VM tomorrow for more testing on
> this. For now, reverted back to 9.16.12.
> 
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYGFRRxUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsFm/wCbBpzr/W/QdtUMG0hhstYcI1wpsBcA
> nRdv220ju0R0IIEgbLzfbXs8CjHX
> =+zDb
> -END PGP SIGNATURE-
> 
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.13 overwrote master files

2021-03-28 Thread Mark Andrews
What do you have in options?

> On 28 Mar 2021, at 09:18, Carl Byington via bind-users 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I just updated from 9.16.12 to 9.16.13.
> 
> zone "naturediscovery.org" { type master;  file
> "named.naturediscovery.org";  };
> 
> 9.16.13 has overwritten the master file with the current zone contents,
> replacing the $INCLUDE statements with the contents of the included
> files.
> 
> Is there some new config item to prevent this?
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYF+vMBUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsHjeQCfRQ9MOrPma6hoUpYycgb3zbTSVhUA
> n3GNG6lyTPbYZ4W2w8EVPrL7Ltra
> =5yyq
> -END PGP SIGNATURE-
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Timeout setting

2021-03-26 Thread Mark Andrews


> On 26 Mar 2021, at 20:44, FUSTE Emmanuel  
> wrote:
> 
> Le 25/03/2021 à 22:15, Mark Andrews a écrit :
>> This is a bug in postfix. Temporary failures in the DNS are not supposed to 
>> result in permanent failure at the SMTP level.  SERVFAIL  is not NXDOMAIN.
>> 
> This is not a postfix bug. Temporary failure are perfectly handled by 
> postfix with a 450 SMTP temporary error, not a 550 permanent error.
> 
> 450 4.7.1 Client host rejected: cannot find your reverse hostname, 
> [17.179.250.111]; from= 
> to= proto=ESMTP helo= 
> (total: 1)

Fine. I shouldn’t comment before my first cup of tea in the morning.

> You should have OS/network configuration problems. Such timeout are 
> completely unnatural.

Timeouts will happen.  Networks aren’t perfect.  Links can be congested.
Links can be noisy.  Hosts can be congested.  Hosts can be down.  There can
be routing failures.  There are those that configure their DNS such that it
requires excessive numbers of lookups to actually resolve an lookup.  Then
there are those that drop ICMP and fragmented packets breaking legitimate
traffic flows.  There is a reason there are 400 codes for DNS lookup failures.

> Emmanuel.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.16.13 and Mac OS X 10.13.6 - problems with ./configure

2021-03-25 Thread Mark Andrews
libuv discovery requires pkg-config to be found.  macports/homebrew installs of 
libuv should register libuv correctly.


> On 26 Mar 2021, at 11:50, Paul Cizmas  wrote:
> 
> Hello:
> 
> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
> 10.13.6.
> 
> I downloaded version 9.16.13 and, following the suggestions from 
> https://krypted.com/mac-os-x/dns-install-bind-macos/, I am trying to 
> configure using
> 
> ./configure --enable-symtable=none --infodir="/usr/share/info" 
> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
> --with-gssapi=yes --with-libxml2=no
> 
> This fails because of libuv
> 
> checking for pthread_set_name_np... no
> checking for pthread_np.h... no
> checking for libuv... checking for libuv >= 1.0.0... no
> configure: error: libuv not found
> 
> I have libuv installed, however.  It is version 1.41.0.
> 
> I would appreciate any suggestions on how to fix this.
> 
> Thank you,
> Paul
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Timeout setting

2021-03-25 Thread Mark Andrews
This is a bug in postfix. Temporary failures in the DNS are not supposed to 
result in permanent failure at the SMTP level.  SERVFAIL  is not NXDOMAIN.

-- 
Mark Andrews

> On 26 Mar 2021, at 04:12, Julien Salort  wrote:
> 
> Hello,
> 
> 
> I have a VPS running postfix and bind9. Bind is used as a recursive resolver, 
> in particular to be able to query anti-spam database.
> 
> Postfix is also configured to reject incoming connections from servers with 
> no reverse dns.
> 
> It works great overall, but sometimes legitimate messages get rejected 
> because the reverse dns query fails.
> 
> Here is an example (anonymized email and host address):
> 
> In mail.log:
> 
> 450 4.7.1 Client host rejected: cannot find your reverse hostname, 
> [17.179.250.111]; from= 
> to= proto=ESMTP helo= (total: 
> 1)
> 
> In named journal:
> 
> mars 02 01:14:20 example.com named[2756114]: client @0x7f3a0808c750 
> 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
> 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)
> 
> mars 02 01:14:25 example.com named[2756114]: client @0x7f3a08079d00 
> 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
> 111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)
> 
> mars 02 01:14:32 example.com named[2756114]: client @0x7f3a0808c750 
> 127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query failed (timed out) for 
> 111.250.179.17.in-addr.arpa/IN/PTR at query.c:6883
> 
> mars 02 01:14:32 example.com named[2756114]: client @0x7f3a000d5110 
> 127.0.0.1#49520 (insideapple.apple.com): query: insideapple.apple.com IN MX + 
> (127.0.0.1)
> 
> 
> So there is a timeout.
> 
> Now if I try again:
> 
> $ dig -x 17.179.250.111 @localhost +short
> rn2-msbadger07105.apple.com.
> 
> 
> So it seems that it is just that sometimes the query takes a bit longer...
> 
> 
> Is there a general advice regarding timeout for bind?
> 
> Should I just choose a longer timeout? Or is there a reason for the default 
> value?
> 
> 
> I did not have such problems when I was using the ISP dns server instead of a 
> local recursive resolver. So I was wondering if the configuration is 
> sub-optimal somehow...
> 
> 
> Thank you,
> 
> 
> Cheers,
> 
> 
> Julien
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Compile Errors, Apple Silicon (M1), BIND 9.16.13

2021-03-22 Thread Mark Andrews
configure didn’t find uv_handle_get_data for some reason.  You will need to 
look at config.log to see why.

> On 23 Mar 2021, at 15:22, James Brown via bind-users 
>  wrote:
> 
> Can anyone help me get BIND 9.16.13 to work with Apple’s new M1s?
> 
> Compiler: gcc
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.29)
> Target: arm64-apple-darwin20.3.0
> Thread model: posix
> 
> ‘make’ fails with:
> 
> In file included from netmgr.c:37:
> In file included from ./netmgr-int.h:38:
> ./uv-compat.h:24:1: error: static declaration of 'uv_handle_get_data' follows 
> non-static declaration
> uv_handle_get_data(const uv_handle_t *handle) {
> ^
> /usr/local/include/uv.h:448:17: note: previous declaration is here
> UV_EXTERN void* uv_handle_get_data(const uv_handle_t* handle);
> ^
> In file included from netmgr.c:37:
> In file included from ./netmgr-int.h:38:
> ./uv-compat.h:31:1: error: static declaration of 'uv_handle_set_data' follows 
> non-static declaration
> uv_handle_set_data(uv_handle_t *handle, void *data) {
> ^
> /usr/local/include/uv.h:450:16: note: previous declaration is here
> UV_EXTERN void uv_handle_set_data(uv_handle_t* handle, void* data);
>^
> 2 errors generated.
> make[3]: *** [netmgr.o] Error 1
> make[2]: *** [subdirs] Error 1
> make[1]: *** [subdirs] Error 1
> make: *** [subdirs] Error 1
> 
> Any suggestions?
> 
> Running Big Sur, 11.2.3
> 
> Thanks,
> 
> James.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 signatures on packages.sury.org

2021-03-17 Thread Mark Andrews
I’ve pinged Ondrej but he is likely asleep as he is based in Europe.

> On 18 Mar 2021, at 10:15, Matthew Pounsett  wrote:
> 
> Beginning today, I'm seeing the following errors on systems that use
> the ISC Debian packages:
> 
> Err:5 https://packages.sury.org/bind buster InRelease
>  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743
> DEB.SURY.ORG Automatic Signing Key 
> 
> I haven't seen any official word from ISC that there are new keys to
> grab, so wanted to check that someone isn't messing about with your
> repository.
> ______

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Using NAT64 for IPv6 only DNS resolvers

2021-03-15 Thread Mark Andrews
There is an open issue https://gitlab.isc.org/isc-projects/bind9/-/issues/608
and merge request 
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2166
to do this.

That said you should be asking your OS vendors why they are not 
providing/enabling
a CLAT implementation.  You could also look at using one of the other IPv4AAS 
(IPv4
as a service) solutions that doesn’t require manipulating the DNS, nor dual 
application
layer translation (e.g. DS-Lite, MAP-E).

Mark

> On 16 Mar 2021, at 01:24, Nico Schottelius  
> wrote:
> 
> 
> Good morning,
> 
> I was wondering whether it is possible to configure IPv6 only BIND
> resolvers to make use of a NAT64 prefix for outgoing requests?
> 
> I.e. the following situation:
> 
> - Resolver = 2001:db8::1, IPv6 only
> - NAT64 prefix = 2001:db8:1:c001::/96
> 
> Now if bind sees example.com NS a.b.c.d, can we make bind reach out to
> 2001:db8:1:c001::a.b.c.d instead of trying to open up an IPv4 connection
> to a.b.c.d?
> 
> This would be very helpful, as we more and more have IPv6 only hosts,
> which only have access to the Internet via NAT64.
> 
> Note: this is not the same problem as enabling DNS64 for *clients*,
> but very similar.
> 
> Best regards,
> 
> Nico
> 
> 
> --
> Sustainable and modern Infrastructures by ungleich.ch
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 set for dynamic updating isn't updating

2021-03-04 Thread Mark Andrews
The permissions on the directory holding the zone file and journal need to 
allow named to create files.   Named will recreate new versions of these as 
part of processing the dynamic update and move them into place once they are 
complete. 

If you are running Linux also se SELinux settings as they add additional 
constraints.  Additionally if you are running as root named does not have 
permission to override file permissions root normally has. 

-- 
Mark Andrews

> On 5 Mar 2021, at 05:59, Bruce Johnson  wrote:
> 
> We have one zone set for Active directory to update dynamically that has 
> stopped doing so.
> 
> Someone manually updated the zone without doing a freeze/thaw and the host 
> that was added wasn’t properly resolving. What I found looking for a solution 
> was to freeze the zone, delete the .jnl file, update the serial #, then thaw 
> the zone. That got lookup working properly again, but now the zone is not 
> longer updating. I found a bunch of errors about permissions denied
> 
> Mar  2 14:00:30 example named[42659]: etc/DynZone.Hosts.jnl: create: 
> permission denied
> 
> I created the file and chowned it to named
> 
> but it hasn’t been written to:
> 
> -rw-r--r--. 1 root  root  108578 Feb 22 09:43 DynZone.Hosts
> -rw-rw-r--. 1 named named  0 Mar  2 14:01 DynZone.Hosts.jnl
> 
> I know that there have been new hosts added that should have been updated in 
> that zone.
> 
> It was working before the incident so I don’t think it’s a permissions issue, 
> but I could well be wrong.
> 
> Unfortunately I can’t really find any info on what the permissions SHOULD be 
> for the bind config and files.
> 
> Another clue that permissions are wrong, is that any time I’ve tried to set 
> up logging directives in named.conf restarting it results in a failure due to 
> permissions; but as I mentioned, it was working until recently.
> 
> This is the zone config in named.conf:
> 
> zone “DynZone.com" {
>   type master;
>   file “etc/DynZone.Hosts";
>   check-names ignore;
>   allow-update {"trusted";};
> };
> 
> The trusted acl is a list of our (name) vlans, but checking the config syntax 
> with named-checonf -z shows all are properly loading, and the zone transfers 
> after the manual update did work.
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 server; dig vs dig +trace on failing lookup.

2021-03-02 Thread Mark Andrews
dig +trace +all and it stood out.

> On 3 Mar 2021, at 13:20, Gregory Sloop  wrote:
> 
> Would you mind showing me how you got there?
> [The answer is fab, obviously. But give a man a fish...and all that. :) ]
> 
> -Greg
> 
> 
> 
> MA> The COM servers have stale glue
> 
> MA> srvns.pacifier.com. 172800  IN  A   216.65.128.5
> MA> webns.pacifier.com. 172800  IN  A   216.65.128.1
> 
> MA> vs
> 
> MA> srvns.pacifier.com. 86400   IN  A   64.255.237.241
> MA> webns.pacifier.com. 86400   IN  A   64.255.237.240
> 
> MA> The later set of servers are what you query when you run dig +trace.
> MA> If you prime the cache the plain lookup should work.  Report the out
> MA> of date glue to the zone administrator.
> 
> MA> Mark
> 
> >> On 3 Mar 2021, at 13:06, Gregory Sloop  wrote:
> 
> >> I've got a case, (and I see several other similar reports) where BIND is 
> >> failing to find an A record for a domain.
> >> Yet a dig +trace does.
> 
> >> (I'm doing the dig on the BIND server. It's set to be a root resolving 
> >> server, not a forwarder.)
> 
> >> As I understand this, +trace will also involve resolve.conf options. And 
> >> in this case, I've got Google DNS as one of the resolve.conf entries.
> >> So, I can see how +trace would deliver different results than simply 
> >> dig-ing - provided that +trace does involve resolve.conf.
> 
> >> Here's a plain dig, using the BIND server itself - from the console.
> >> ---
> >> dig cistus.com @10.8.20.5
> 
> >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5
> >> ;; global options: +cmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786
> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> >> ;; OPT PSEUDOSECTION:
> >> ; EDNS: version: 0, flags:; udp: 4096
> >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good)
> >> ;; QUESTION SECTION:
> >> ;cistus.com.IN  A
> 
> >> ;; Query time: 0 msec
> >> ;; SERVER: 10.8.20.5#53(10.8.20.5)
> >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021
> >> ;; MSG SIZE  rcvd: 67
> 
> >> ---
> 
> >> I could post the dig +trace, if it adds any information, but I suspect it 
> >> doesn't.
> 
> >> So, what methods or steps might I take to figure out why the above 
> >> lookup/dig fails?
> >> [I intended +trace to do that, but since it's not doing the same thing a 
> >> plain dig does, it's not very useful as a diagnostic tool.]
> 
> >> I've done some searching to see how to accomplish this, but it's a 
> >> difficult question to frame without a ton of worthless hits.
> >> So, can someone point me at a good source for a how-to/walk-through? A 
> >> previous list posting?
> 
> >> Again, the question is; what methods or steps (best practices) might I 
> >> take to figure out why the above lookup/dig fails?
> 
> >> TIA
> >> -Greg
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> >> unsubscribe from this list
> 
> >> ISC funds the development of this software with paid support 
> >> subscriptions. Contact us at https://www.isc.org/contact/ for more 
> >> information.
> 
> 
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 server; dig vs dig +trace on failing lookup.

2021-03-02 Thread Mark Andrews
The COM servers have stale glue

srvns.pacifier.com. 172800  IN  A   216.65.128.5
webns.pacifier.com. 172800  IN  A   216.65.128.1

vs

srvns.pacifier.com. 86400   IN  A   64.255.237.241
webns.pacifier.com. 86400   IN  A   64.255.237.240

The later set of servers are what you query when you run dig +trace.
If you prime the cache the plain lookup should work.  Report the out
of date glue to the zone administrator.

Mark

> On 3 Mar 2021, at 13:06, Gregory Sloop  wrote:
> 
> I've got a case, (and I see several other similar reports) where BIND is 
> failing to find an A record for a domain.
> Yet a dig +trace does.
> 
> (I'm doing the dig on the BIND server. It's set to be a root resolving 
> server, not a forwarder.)
> 
> As I understand this, +trace will also involve resolve.conf options. And in 
> this case, I've got Google DNS as one of the resolve.conf entries.
> So, I can see how +trace would deliver different results than simply dig-ing 
> - provided that +trace does involve resolve.conf.
> 
> Here's a plain dig, using the BIND server itself - from the console.
> ---
> dig cistus.com @10.8.20.5
> 
> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good)
> ;; QUESTION SECTION:
> ;cistus.com.IN  A
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.8.20.5#53(10.8.20.5)
> ;; WHEN: Fri Feb 26 12:18:24 PST 2021
> ;; MSG SIZE  rcvd: 67
> 
> ---
> 
> I could post the dig +trace, if it adds any information, but I suspect it 
> doesn't.
> 
> So, what methods or steps might I take to figure out why the above lookup/dig 
> fails?
> [I intended +trace to do that, but since it's not doing the same thing a 
> plain dig does, it's not very useful as a diagnostic tool.]
> 
> I've done some searching to see how to accomplish this, but it's a difficult 
> question to frame without a ton of worthless hits.
> So, can someone point me at a good source for a how-to/walk-through? A 
> previous list posting?
> 
> Again, the question is; what methods or steps (best practices) might I take 
> to figure out why the above lookup/dig fails?
> 
> TIA
> -Greg
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: dnstap shows little logging at debug 10

2021-03-01 Thread Mark Andrews
Do you have something reading the pipe?


> On 2 Mar 2021, at 10:30, Adam Augustine  wrote:
> 
> I can't seem to get any debug information out of BIND for troubleshooting a 
> dnstap problem I am having.
> 
> I have a CentOS 8.3.2011 VM with the COPR packages installed. 
> 
> My /etc/opt/isc/scls/isc-bind/named.conf :
> options {
> directory "/var/opt/isc/scls/isc-bind/named/data";
> listen-on { any; };
> listen-on-v6 { any; };
> dnssec-validation auto;
> dnstap {all;};
> //  dnstap-output unix "/var/opt/isc/scls/isc-bind/run/named/dnstap.sock";
> dnstap-output unix "/var/opt/isc/scls/isc-bind/log/named/dnstap.sock";
> dnstap-identity "dnstap01.ldschurch.org";
> dnstap-version "bind-9.16.12";
> };
> 
> logging {
> [SNIP]
>  channel dnstap_log {
>   file "/var/opt/isc/scls/isc-bind/log/named/dnstap" versions 3 size 
> 20m;
>   print-time yes;
>   print-category yes;
>   print-severity yes;
>   severity debug 10;
>  };
> [SNIP]
>  category dnstap { dnstap_log; default_debug; };
> };
> 
> On startup, the /var/opt/isc/scls/isc-bind/log/named/dnstap file is created, 
> but no information is logged:
> 
>  4 -rw-r--r--. 1 named named system_u:object_r:named_log_t:s054 Mar  
> 1 16:23 dnstap
> 
> This is despite /var/log/messages having the following line:
> 
>  opening dnstap destination '/var/opt/isc/scls/isc-bind/log/named/dnstap.sock'
> 
> Which I would have expected to see logged in 
> /var/opt/isc/scls/isc-bind/log/named/dnstap . On shutdown, this single entry 
> is logged in /var/opt/isc/scls/isc-bind/log/named/dnstap:
> 
> 01-Mar-2021 16:23:31.597 dnstap: info: closing dnstap
> 
> There is nothing relevant in /var/log/audit/audit.log, so I don't think it is 
> SELinux related, especially since there is successful log entry on shutdown.
> 
> I have tried changing the severity level from "info", to "debug 1", to "debug 
> 3", and then to "debug 10", but I can't seem to get any more information out 
> other than the single message about "closing dnstap".
> 
> Any idea what I am doing wrong?
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Impact on removing IPV6 DNS Server from client terminals when Dual-stack is enabled

2021-02-28 Thread Mark Andrews

> On 1 Mar 2021, at 16:00, Duleep Thilakarathne  wrote:
> 
> Hi,
> 
> This is not an issue but just to get ideas from experienced bind resources. 
> Please ignore this question, if it is out of the scope of this mailing 
> thread. 
> 
> Significant number of DNS requests can be observed when dual-stack enabled 
> and send both IPV4 and IPV6 DNS server addresses to clients through DHCP or 
> similar. 
> 
> 
> According to RCF 4472,
> 
> "Note that even though IPv6 DNS resolver discovery is a recommended
>procedure, it is not required for dual-stack nodes in dual-stack
>networks as IPv6 DNS records can be queried over IPv4 as well as
>IPv6.  Obviously, nodes that are meant to function without manual
>configuration in IPv6-only networks must implement the DNS resolver 
> 
>discovery function." 
> 
> client DNS request possibilities  as follows per domain. (client 
> browser/Application may send all or selected queries in parallel with short 
> time difference)
> 
> 1. A record requests to primary ipv4 dns server
> 2. A record request to secondary ipv4 dns
> 3.  record requests to primary ipv4 dns server
> 4.  record request to secondary ipv4 dns
> 5. A record requests to primary ipv6 dns server
> 6. A record request to secondary ipv6 dns
> 7.  to primary ipv6 dns server
> 8.  to secondary ipv6 dns server
> 
> What will happen,  if IPV6 DNS server addresses  are removed from DHCP or 
> similar assignment in dual-stack scenario and only keep IPV4 DNS servers. I 
> guess this will reduce load to DNS servers as well as SP networks. Are there 
> any practical limitations ?. Is it mandatory to send both IPV4 and IPV6 DNS 
> server addresses in a dual-stack scenario. 

Really I wouldn’t worry about it. Your primary and secondary servers are
likely to be dual stacked so the extra queries will be absorbed there.
Additionally, especially if you have BYOD, you have no control over machines
that are configured for IPv6-only.  Yes, there are plenty of IPv6-only networks
today.  On top of that you can have DHCP failures where RA continues to
work.  Why cause machines to break unnecessarily when that happens?

> Regards
> DT
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: TXT & SPF Record Syntax

2021-02-28 Thread Mark Andrews
Domain names without a trailing period are relative to the current origin.

Domain names with a trailing period are absolute.

If you want to add the record

foo.bar.example.com. TXT …

and the current origin is example.com. You can enter it as

foo.bar TXT …

or

foo.bar.example.com. TXT …

or you could set the origin to bar.example.com. and do this

$ORIGIN bar.example.com.
foo TXT …

This applies to all domain names in zone files.

Mark

> On 1 Mar 2021, at 10:41, Tim Daneliuk via bind-users 
>  wrote:
> 
> I am trying to understand when the LHS of a TXT record needs to be terminated 
> with '.'.
> 
> For example, I see this one of the machines I am managing.  The server in 
> question is
> the zone authority for foo.com:
> 
> foo.com. IN TXT "v=spf1 ...
> foo.com. IN SPF "v=spf1 ...
> something._domainkey IN TXT "v=DKIM1 ...
> _dmark.foo.com.  IN TXT "v=DMARC1 ...
> 
> Could some kind soul explain why the DKIM key name does not require the 
> trailing period, but
> why all the foo.com entries do?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Filtering A records in combination with DNS64

2021-02-18 Thread Mark Andrews
Have you actually played with dns64 settings?

dns64  {
break-dnssec ;
clients { ; ... };
exclude { ; ... };
mapped { ; ... };
recursive-only ;
suffix ;
}; // may occur multiple times


> On 19 Feb 2021, at 06:39, Nico Schottelius  
> wrote:
> 
> 
> Good morning everyone,
> 
> we have peculiar request to solve and were wondering whether it is at
> all possible with bind:
> 
> a)
> For a certain source range, let's say 2001:db8::/96, we want to *only*
> reply with generated DNS64 entries - i.e. we want bind to only reply
> with mapped IPv4 addresses, NOT with proper  entries, if they exist.

dns64  { clients { acl; }; exclude { ::/0; }; };

> b)
> For a different source range, let's say 2001:db:1::/64, we want to reply
> only with *proper* IPv6  entries, i.e. disable DNS64 for them.

dns64  { clients { !prefix; any; };

> 
> c) (optional)
> 
> In the best case, we would even like to remove A replies from the
> results, in case a misconfigured client requests A records.

Then you break the ability of those clients to do their own DNS64 mappings
which is required when they are doing DNSSEC themselves.

> Background for this is that we have clients in specific networks, which
> are mapped via SIIT to IPv4 addresses. These clients should never
> connect to an IPv6 address (besides they actually do...) after
> translation. And the clients in the other network should behave the
> opposite, they should *only* connect to IPv6 hosts.
> 
> However, both client networks are IPv6 only, as there is no IPv4 link
> into these networks, so we are dealing with NAT64/SIIT. And
> unfortunately we don't have a lot of control over the client behaviour,
> whether they will ask for A/ entries, so we will need to steer them
> on the DNS side.
> 
> Looking forward to your replies.
> 
> Best regards,
> 
> Nico
> 
> --
> Sustainable, Modern Infrastructures by ungleich.ch
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: underscore in A or PTR records

2021-02-17 Thread Mark Andrews
No. The PTR records that map from IP address to hostname enforce the hostname 
rules. 

-- 
Mark Andrews

> On 18 Feb 2021, at 02:20, Sten Carlsen  wrote:
> 
> 
> 
>> On 17 Feb 2021, at 12.34, ONRUBIA AVILES Carlos (CCS/MST) 
>>  wrote:
>> 
>> Hello,
>> 
>> Indeed my question was on A record but the issue is on PTR record.
>> I can configure the following line:
>> 
>> _ptr.dekil.nl.  3600IN  PTR 
>> _81.99-129-109.adsl-dyn.isp.dekil.nl
>> 
>> It workswe can use "_"  in both sides.
>> 
>> 
>> But what is strange is that the following configuration do not work:
>> 
>> 9.10.238.195.in-addr.arpa.   3600IN  PTR 
>> por_tal-bis.skynet.be.
>> 
>> "_" is not allowed
>> 
>> Is it due to extra check by bind when it sees it is an arpa zone so no  "_" 
>> is allowed?
> 
> As previously mentioned, the RFCs expressly forbids the "_" in names.
> 
> I assume that a leading "_" slips past Bind's control because it "could" be 
> part of a valid but at compile time unknown _tcp -like label.
> 
>> 
>> 
>> Regards,
>> 
>> Carlos,
>> 
>> 
>> Sensitivity: Internal Use Only
>> 
>> -Original Message-
>> From: Ondřej Surý 
>> Sent: 17 February 2021 10:52
>> To: ONRUBIA AVILES Carlos (CCS/MST) 
>> Cc: Mark Andrews ; bind-users@lists.isc.org
>> Subject: Re: underscore in A or PTR records
>> 
>>> 
>>>> On 17. 2. 2021, at 9:50, ONRUBIA AVILES Carlos (CCS/MST) 
>>>>  wrote:
>>> 
>>> The issue we face is that a telecom provider ask us to implement a PTR 
>>> record with a name like “example_try.net"
>> 
>> You are mixing the two things here. If the provider has asked you to create 
>> a PTR record, why do you keep trying to create a forward record? There’s 
>> some information missing somewhere.
>> 
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>> This e-mail cannot be used for other purposes than Proximus business use. 
>> See more on https://www.proximus.be/maildisclaimer
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: underscore in A or PTR records

2021-02-17 Thread Mark Andrews
The SRV and TXT records usage is depending on underscore not being part of a 
hostname.
The separator in hostname labels is dash.  e.g. my-host.example.net

_ssh._tcp.example.net SRV can be safely deployed because there are no legal 
hostnames
starting with _ssh and _tcp.

Hostname (and mail domain) syntax is defined by RFC 952 as modified by RFC1123 
(allows
labels to start with digits.

PTR records it depends on usage.

Mark

> On 17 Feb 2021, at 19:13, ONRUBIA AVILES Carlos (CCS/MST) 
>  wrote:
> 
> Hello ,
>  
> I face the following problem  è bind do not accept an A record with 
> underscore:
>  
> Example: example_try   A1.2.3.4
>  
>  
> Same for a PTR:
>  
> Example:   1.2.3.4   PTR   example_try
>  
>  
> Is it absolutely forbidden to have in such cases an ‘_’?
> I know that it is possible for SRV or TXT records.
>  
>  
> Thanks in advance to clarify the situation and sorry if this question has 
> already be asked.
>  
> Carlos,
>  
> 
> Sensitivity: Internal Use Only
> This e-mail cannot be used for other purposes than Proximus business use. See 
> more on https://www.proximus.be/maildisclaimer
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Problems with interfaces going down

2021-02-14 Thread Mark Andrews
Linux already uses capabilities so it doesn’t have this issue.

FreeBSD there are sysctl settings to allow specific non-root users to bind to 
specify addresses.

> On 15 Feb 2021, at 15:26, Paul Kosinski via bind-users 
>  wrote:
> 
> Would it be possible to use a virtual interface from within bind/named that 
> gets mapped by some privileged facility to a hardware interface? (This is the 
> sort of thing that VMs have to do all the time.) For example, could a brctl 
> bridge help?
> 
> Or maybe CAP_NET_BIND_SERVICE would allow the interface to be reactivated (if 
> it's a privileged port issue).
> 
> Just brainstorming.
> 
> Paul
> 
> 
> On Fri, 12 Feb 2021 18:33:21 -0500
> bindus...@prograde.net wrote:
> 
>> Greetings,
>> 
>> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on 
>> macOS.
>> 
>> 1: If an ethernet interface being listened to drops link, named immediately 
>> stops listening to it:
>> 
>> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
>> 
>> and
>> 
>> 2: when link returns I get 2 tries to reestablish listening:
>> 
>> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
>> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface 
>> ignored
>> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
>> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface 
>> ignored
>> 
>> which both fail because named is no longer running as root.
>> 
>> --
>> 
>> Where I’m confused is that this ISC KB article:
>> 
>> https://kb.isc.org/docs/aa-00420
>> 
>> seems to imply that the "no longer listening" event is due to a periodic 
>> interface scan finding the interface "unavailable".
>> 
>> That doesn’t fit my observations since it happens as soon as link is lost. 
>> If some minutes-long periodic scan were needed to detect the interface being 
>> down it would take, on average, half of that period to happen. It does not.
>> 
>> Further, I tried what the KB article advised by adding the option:
>> 
>>  interface-interval 0;
>> 
>> That does seem to stop the periodic scan (since my log is no longer filled 
>> with errors) but the “no longer listening” event still occurs right when the 
>> interface drops.
>> 
>> --
>> 
>> Is it not possible to have named drop to a non-root user (via -u) but still 
>> recover from (or ride through) a momentary ethernet link loss?
>> 
>> Having the server stop working due to a switch I have no control over 
>> burping is very suboptimal.
>> 
>> Thanks for any ideas.
>> 
>> 
> _______
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Problems with interfaces going down

2021-02-14 Thread Mark Andrews


> On 13 Feb 2021, at 10:33, bindus...@prograde.net wrote:
> 
> Greetings,
> 
> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on 
> macOS.
> 
> 1: If an ethernet interface being listened to drops link, named immediately 
> stops listening to it:
> 
> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
> 
> and
> 
> 2: when link returns I get 2 tries to reestablish listening:
> 
> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
> 
> which both fail because named is no longer running as root.
> 
> --
> 
> Where I’m confused is that this ISC KB article:
> 
> https://kb.isc.org/docs/aa-00420
> 
> seems to imply that the "no longer listening" event is due to a periodic 
> interface scan finding the interface "unavailable".
> 
> That doesn’t fit my observations since it happens as soon as link is lost. If 
> some minutes-long periodic scan were needed to detect the interface being 
> down it would take, on average, half of that period to happen. It does not.
> 
> Further, I tried what the KB article advised by adding the option:
> 
>   interface-interval 0;
> 
> That does seem to stop the periodic scan (since my log is no longer filled 
> with errors) but the “no longer listening” event still occurs right when the 
> interface drops.

``automatic-interface-scan``
   If ``yes`` and supported by the operating system, this automatically rescans
   network interfaces when the interface addresses are added or removed.  The
   default is ``yes``.  This configuration option does not affect the time-based
   ``interface-interval`` option; it is recommended to set the time-based
   ``interface-interval`` to 0 when the operator confirms that automatic
   interface scanning is supported by the operating system.

   The ``automatic-interface-scan`` implementation uses routing sockets for the
   network interface discovery; therefore, the operating system must
   support the routing sockets for this feature to work.

> --
> 
> Is it not possible to have named drop to a non-root user (via -u) but still 
> recover from (or ride through) a momentary ethernet link loss?

If you allow euid switching then you may as well not run with -u as the whole 
point of -u is
to be a safeguard in the case where there is a program flaw that allows 
arbitrary execution
to occur.

> Having the server stop working due to a switch I have no control over burping 
> is very suboptimal.
> 
> Thanks for any ideas.
> 
> -Mike
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Trying again on SERVFAIL

2021-02-11 Thread Mark Andrews
Machines still fall over. They take the same amount of time to fix now as they 
did 30 years ago.

You still have to diagnose the fault. You still have to get the replacement 
part. You still have to potentially restore from backups. Sometimes you can 
switch to a standby machine which makes things faster. 

I’ve seem day long outages in the last 7 days. They still happen. Personally I 
was happy the emails queued. 
-- 
Mark Andrews

> On 11 Feb 2021, at 23:26, Alessandro Vesely  wrote:
> 
> On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote:
>> Out of curiosity, what servers have you encountered that no longer use the 
>> five day cutoff ?
> 
> 
> I didn't take note, but I read discussions on the topic.  Users expect mail 
> to be delivered almost instantly.  The "warning, still trying" messages 
> should come sometime in between.  If it comes the next day, by various 
> people's experience, it is unacceptably too late.  If you reduce that to a 
> few hours, the total max queue lifetime cannot remain five days.
> 
> At mine, although I keep the default 5d, I cut queue time for specific 
> messages, such as complaints or dmarc reports, to ten hours.
> 
> Quoting from the web:
> 
>Queue lifetimes over a day is just Cargo Cult system administration, and a
>holdover from when the internet was much less "always on".
>
> https://serverfault.com/questions/735269/is-it-a-good-idea-to-reduce-the-give-up-time-for-e-mail-delivery#answer-826351
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.11 serving up false answers for a single domain.

2021-02-10 Thread Mark Andrews
Because they are connected at different points in the network and as such see 
different network faults. The servers can all be working fine, it the 
connections between them that are not working.  

-- 
Mark Andrews

> On 11 Feb 2021, at 04:54, sami's strat  wrote:
> 
> 
> Thank you all for responding.  One final query about this. I'm seeing this 
> issue on my production servers at work.  Yet, when I run the same queries at 
> home, I don't see those failed queries.  I actually flushed DNS cache, 
> cleared Linux O/S cache, and even bounced my personal DNS server trying to 
> reproduce the issue.  But I could not.
> 
> TIA
> 
>> On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews  wrote:
>> Run ‘dig +trace +all internet-dns1.state.ma.us’ which will show you the glue
>> records then try ‘dig +dnssec +norec internet-dns1.state.ma.us @’ 
>> for
>> all the addresses in the glue records.
>> 
>> e.g.
>> dig +dnssec +norec internet-dns1.state.ma.us @146.243.122.17
>> 
>> Mark
>> 
>> > On 10 Feb 2021, at 14:50, sami's strat  wrote:
>> > 
>> > Thanks Mark.
>> > 
>> > However, the traceroute to the hostnamed failed for the same reason.  
>> > Please note:
>> > 
>> > [root@myhost data]# dig internet-dns1.state.ma.us
>> >  
>> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us
>> > ;; global options: +cmd
>> > ;; Got answer:
>> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641
>> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> >  
>> > ;; OPT PSEUDOSECTION:
>> > ; EDNS: version: 0, flags:; udp: 4096
>> > ;; QUESTION SECTION:
>> > ;internet-dns1.state.ma.us. IN  A
>> >  
>> > ;; Query time: 1263 msec
>> > ;; SERVER: 192.168.33.12#53(192.168.33.12)
>> > ;; WHEN: Tue Feb 09 22:34:15 EST 2021
>> > ;; MSG SIZE  rcvd: 54
>> >  
>> > [root@myhost data]# dig internet-dns1.state.ma.us +trace
>> >  
>> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us 
>> > +trace
>> > ;; global options: +cmd
>> > .   516485  IN  NS  c.root-servers.net.
>> > .   516485  IN  NS  e.root-servers.net.
>> > .   516485  IN  NS  f.root-servers.net.
>> > .   516485  IN  NS  l.root-servers.net.
>> > .   516485  IN  NS  m.root-servers.net.
>> > .   516485  IN  NS  d.root-servers.net.
>> > .   516485  IN  NS  g.root-servers.net.
>> > .   516485  IN  NS  k.root-servers.net.
>> > .   516485  IN  NS  b.root-servers.net.
>> > .   516485  IN  NS  h.root-servers.net.
>> > .   516485  IN  NS  a.root-servers.net.
>> > .   516485  IN  NS  i.root-servers.net.
>> > .   516485  IN  NS  j.root-servers.net.
>> > .   516485  IN  RRSIG   NS 8 0 518400 
>> > 202103 2021020922 42351 . 
>> > QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f 
>> > mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w 
>> > SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG 
>> > NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb 
>> > q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK 
>> > N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA==
>> > ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms
>> >  
>> > us. 172800  IN  NS  a.cctld.us.
>> > us. 172800  IN  NS  b.cctld.us.
>> > us. 172800  IN  NS  c.cctld.us.
>> > us. 172800  IN  NS  e.cctld.us.
>> > us. 172800  IN  NS  f.cctld.us.
>> > us. 172800  IN  NS  k.cctld.us.
>> > us. 86400   IN  DS  21364 8 1 
>> > 260D0461242BCF8F05473A08B05ED01E6FA59B9C
>> > us. 86400   IN  DS  21364 8 2 
>> > B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
>> > us. 86400   IN  RRSIG   DS 8 1 86400 
>> > 2

Re: Bind 9.11 serving up false answers for a single domain.

2021-02-09 Thread Mark Andrews
 6PNtbZDMv6YX6QA8fWFLxNmeJ1/4L3wLu8EKYXaThA9Zxll7mKFj1iPf 
> nqiVq5hOo8Ul3inmfM/tjCQ21IHc/v0JZygZNd/h0SxXWlQXi+W3G9LN 
> +4z/qxtl9dGD1ka54Ln3MAVxB1Tp4pt0ri4qPLmfGKf/HA==
> couldn't get address for 'internet-dns3.state.ma.us': not found
> couldn't get address for 'internet-dns1.state.ma.us': not found
> couldn't get address for 'internet-dns2.state.ma.us': not found
> dig: couldn't get address for 'internet-dns3.state.ma.us': no more
> [root@myhost data]#
> 
> On Tue, Feb 9, 2021 at 10:10 PM Mark Andrews  wrote:
> Well you could try tracing the addresses of the nameservers for which
> there where errors reported.  It could be as simple as a routing issue
> between you and these servers.
> 
> > On 10 Feb 2021, at 13:25, sami's strat  wrote:
> > 
> > couldn't get address for 'internet-dns1.state.ma.us': not found
> > couldn't get address for 'internet-dns3.state.ma.us': not found
> > couldn't get address for 'internet-dns2.state.ma.us': not found
> > dig: couldn't get address for 'internet-dns1.state.ma.us': no more
> 
> Yet, I do this on my personal computer at home, and it works without an issue.
> 
> Any other thoughts?  TIA 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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.11 serving up false answers for a single domain.

2021-02-09 Thread Mark Andrews
Well you could try tracing the addresses of the nameservers for which
there where errors reported.  It could be as simple as a routing issue
between you and these servers.

> On 10 Feb 2021, at 13:25, sami's strat  wrote:
> 
> couldn't get address for 'internet-dns1.state.ma.us': not found
> couldn't get address for 'internet-dns3.state.ma.us': not found
> couldn't get address for 'internet-dns2.state.ma.us': not found
> dig: couldn't get address for 'internet-dns1.state.ma.us': no more

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Forward zone does not work when allow recursive is restrictive

2021-02-09 Thread Mark Andrews
“forward” does not mean “proxy".  Additionally servers out on the internet make 
iterative queries.  They are non-recursive *AND* follow delegations.  Making a 
proxy work is more that just relaying the request and the response.

BIND does not support proxying other servers.

> On 10 Feb 2021, at 08:44, Sebastian Neumann  wrote:
> 
> Hey there,
> 
> I am having an issue forwarding DNS queries and was hoping, that one of you 
> might be able to help me:
> 
> I have the following setup:
> 
> DNS-Server reachable from the internet, is authoritative for zone foo.com
> DNS-Server reachable only locally, should be authoritative for zone 
> test.lab.foo.com
> What I try to achieve:
> 
> When a DNS query from the outside world reaches the first DNS server for a 
> record belonging to the zone test.lab.foo.com, I want it to make a recursive 
> request to the second DNS server and then forward the records.
> 
> I explicitly don't want to do zone transfers or make the second DNS server 
> reachable from the internet.
> 
> my configuration looks like this: (I only copied the [what I think] important 
> parts to here, as all the Config would be a few hundret lines (because of 
> split view and many zones)
> 
> On the first DNS-Server
> 
> options {
> allow-recursion {
> localnets;
> localhost;
> internal;
> my-datacenter;
> mc-office;
> };
> };
> 
> zone "test.lab.foo.com" {
> forward only;
> forwarders {
> ;
> };
> type forward;
> };
> 
> zone "foo.com" {
> file "/etc/bind/zones/foo.com.zone";
> type master;
> };
> My issue:
> 
> When I am in a local network, that is whitelisted in the allow-recursion 
> block, then it works as expected. When I try the DNS lookup from the 
> internet, then i get a NOERROR with an empty response back.
> 
> During debugging, I adjusted the allow-recursion list and added any to it. 
> Then it was working. But I don't want my DNS server to allow any kind of 
> recursion. I actually only want "outside" lookups for this one specific zones 
> to be recursive.
> 
> How can I set something like allow-recursion for just one zone?
> 
> Thanks a lot already
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: rDNS for RFC1918 network fails

2021-01-24 Thread Mark Andrews
Use the correct zone name. 

1.168.192.IN-ADDR.ARPA
 
You have the full /24 so you don’t need to use RFC2317 techniques. 

-- 
Mark Andrews

> On 25 Jan 2021, at 08:04, Alex  wrote:
> 
> Hi, I have a fedora32 system with bind-9.11.25 and having a problem
> with setting up a reverse zone for a 192.168.1.0/24 internal network.
> 
> It loads okay, but queries fail:
> 
> # host 192.168.1.1
> Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
> 
> Jan 24 15:56:26 orion bash[1967667]: zone inside.example.com/IN:
> loaded serial 103
> Jan 24 15:56:26 orion bash[1967667]: zone
> 0-24.1.168.192.in-addr.arpa/IN: loaded serial 107
> Jan 24 15:56:26 orion bash[1967667]: zone localhost.localdomain/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone localhost/IN: loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone 1.0.0.127.in-addr.arpa/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone 0.in-addr.arpa/IN: loaded serial 0
> Jan 24 15:56:26 orion named[1967669]: starting BIND
> 9.11.25-RedHat-9.11.25-2.fc32 (Extended Support Version) 
> 
> Here is my /etc/named.conf zone info for the forward and reverse:
> 
> acl "trusted" {
>{ 127/8; };
>{ 68.195.111.40/29; };
>{ 192.168.1.0/24; };
> };
> 
> zone "inside.example.com." {
>type master;
>file "master/inside.example.com.db";
>forwarders {};
>allow-query { trusted; };
>allow-transfer { none; };
> };
> 
> zone "0-24.1.168.192.in-addr.arpa." {
>type master;
>file "master/192.168.1.db";
>allow-query { trusted; };
>allow-transfer { none; };
> };
> 
> Here is the actual zone file.
> /var/named/chroot/var/named/master/192.168.1.db
> 
> $TTL 1H
> $ORIGIN 0-24.1.168.192.in-addr.arpa.
> @ 3600  IN  SOA orion.inside.example.com. admin.example.com.
> 107 3H 1H 1W 1H
> @ 3600  IN  NS  orion.inside.example.com.
> @ 3600  IN  A   192.168.1.1
> 
> 1   IN  PTR orion.inside.example.com.
> 150 IN  PTR pixie.inside.example.com.
> 
> What could I possibly be doing wrong? When I run dig +trace it doesn't
> appear to look to the local name server, but instead goes to the
> Internet and the top-level name servers.
> 
> # dig +trace any 150.1.168.192.in-addr.arpa.
> 
> Thanks,
> Alex
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Secure Active Directory updates and allow-update-forwarding issues

2021-01-19 Thread Mark Andrews
Forwarding is designed for TSIG and works for SIG(0).  It doesn’t work for 
GSS-TSIG. 

-- 
Mark Andrews

> On 19 Jan 2021, at 22:23, Nagesh Thati  wrote:
> 
> 
> Hi,
> I am getting update failed on master DNS appliance when I am using 
> allow-update-forwading,
> updating zone '_msdcs.example.com/IN': update failed: rejected by secure 
> update (REFUSED)
> 
> example.com is a active directory enabled zone which has one master and one 
> slave. Master appliance is hidden, so active directory sends updates to slave 
> appliance using MNAME specified in the zone SOA section.
> 
> master(10.1.10.203) named.conf:
> 
> tkey-gssapi-keytab "/etc/krb5.keytab"; -> In the option section, in /etc 
> folder we have keytab file
> 
> zone "_msdcs.example.com" IN {
> type master;
> file "/var/named/zones/masters/db._msdcs.example.com";
> allow-transfer {10.1.10.144;};
> also-notify {10.1.10.144;};
> notify explicit;
> update-policy { grant * subdomain _msdcs.example.com. ANY; };
> check-names ignore;
> zone-statistics yes;
> };
> 
> slave(10.1.10.144) named.conf:
> zone "_msdcs.example.com" IN {
> type slave;
> file "/var/named/zones/slaves/db._msdcs.example.com";
> allow-notify {10.1.10.203;};
> masters {
> 10.1.10.203;
> };
> check-names ignore;
> zone-statistics yes;
> allow-update-forwarding{10.1.10.158;};
> };
> 
> 10.1.10.158 - AD server
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log

2021-01-13 Thread Mark Andrews


> On 7 Jan 2021, at 00:57, 同屋 <39223...@qq.com> wrote:
> 
> Actually, the background is a little bit complicated. In short, the topo is 
> as belows. dns1 were swapped by a new one (say dns1*), then the issue 
> happened. After that, we dropped all the  request from dns1*, then the 
> issue was gone.

Well if you stop making requests that result in negative responses (NXDOMAIN or 
NOERROR/NODATA) you no longer send responses with the incorrect SOA record in 
the authority section.

> There is no config change during the whole process, no idea why the caching 
> server has such log.

You get such logs because there are servers that are misconfigured.  If you 
delegate a zone to a server then ALL negative responses for queries in that 
delegated namespace should be coming back with a SOA record that matches the 
delegated zone.  Named checks the returned SOA record in the authority section 
and if it isn’t a expected value then named logs the messages you are seeing.

You can reproduce this with the following setup where example.com is delegated 
to server1.example.com and child.example.com is delegated to 
server2.example.com but it is incorrectly configured for a different version of
example.com.

server1.example.com(192.0.2.1):
example.com.SOA server1.example.com. . 0 0 0 0 0
example.com.NS  server1.example.com.
server1.example.com.A   192.0.2.1
server2.example.com.A   192.0.2.2
child.example.com.  NS  server2.example.com.

server2.example.com(192.0.2.2):
example.com.SOA server2.example.com. . 0 0 0 0 0
example.com.NS  server2.example.com.
server2.example.com.A   192.0.2.2
child.example.com.  A   192.0.2.3

A proper delegation would have:

server2.example.com(192.0.2.2):
child.example.com.  SOA server2.example.com. . 0 0 0 0 0
child.example.com.  NS  server2.example.com.
child.example.com.  A   192.0.2.3

Load balancers often end up with broken configuration because, it appears, the 
documentation is not clear enough.  The load balancing software knows about A 
queries and returns for them but punts all the other queries to a backing 
server which instead of being configured with the zone child.example.com is 
configured with the zone example.com which contains just the SOA and NS records.

example.com.SOA server1.example.com. . 0 0 0 0 0
example.com.NS  server1.example.com.

Client -> load balancer -> backing server.

If you ask for child.example.com/A you get back a A record with the computed 
value.

If you ask for child.example.com/ the load balancer says this not something 
I deal with and passes the request on to the backing nameserver which, because 
it has been configured to serve example.com instead of child.example.com, 
returns a negative response with example.com as the owner name of the SOA 
record rather than a child.example.com SOA record that is expected.

Mark

>    -
> |dns1  |  | dns2 |
>    -
> | |
>  --
>  |
>-
>   |caching server|  (where the log was observed)
>   --
> 
> -- Original --
> From:  "同屋";<39223...@qq.com>;
> Send time: Wednesday, Jan 6, 2021 8:43 PM
> To: "同屋"<39223...@qq.com>; "marka";
> Cc: "Bind-users";
> Subject:  re:Re: "not subdomain of zone {} -- invalid response" errors 
> found in named.run log
> 
> Thanks mark, but why this issue is related to load balancer?
> 
> 
> 
> -- Original Message --
> From: "Mark Andrews";
> Date: 2021-01-06 19:09
> To: "同屋"<39223...@qq.com>;
> To:
> "bind-users";
> 
> Subject: Re: "not subdomain of zone {} -- invalid response" errors found 
> in named.run log
> 
> 
> Complain to the administrators of the zone. They have not properly delegated 
> it.  We see this often with load balancers.
> 
> The zone a.b.example has been delegated but the answer is as if it is from 
> b.example. 
> 
> --
> Mark Andrews
> 
>> On 6 Jan 2021, at 21:02, 同屋 <39223...@qq.com> wrote:
>> 
>> 
>> The version of bind is BIND 9.10.5-P3 id:7d5676f 
>> 
>> One day, I found that the size of named.run is increasing very quickly. And 
>> a lot of "invalid response" entries were spotted in the log. Details is as 
>> follows (I replace the sensitive info with  {},{AAA} etc.)
>> 
>> DNS format error from {IP}#53 resolving 
>> {}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org/ for client 
>> 169.254.4.50#51099: Name epc.mnc{AAA}.mc

Re: SRV Record Server Availability

2021-01-06 Thread Mark Andrews
Well mDNS is not DNS.  It is a multicast request to all devices on the local 
network to respond.

To get the functionality being requested in the DNS it requires something to be 
polling the availability of the server listed in the SRV records and to 
add/remove/adjust them depending upon their load/availability.  In reality this 
should not be needed if people would just write client software to properly 
handle multi-homed servers.  There is nothing that say you must wait for a 
connection to timeout before you attempt to connect to a second address.

Happy Eyeballs RFC 8305 (previously RFC 6555) us about starting multiple 
connections across address families and only proceeding with the first that 
connects but there is NOTHING that says you can’t do the similar for all 
addresses independent of address family.

It isn’t hard to write a TCP client that attempts to connect to multiple 
servers simultaneously.

I will admit that it is slightly harder for UDP clients but in most cases it is 
not impossible.

For both protocols you do not wait seconds to get the initial response before 
trying the alternate addresses.  Most of the world is less that 300ms way 
(round trip).

Mark

> On 7 Jan 2021, at 03:42, Andrew P.  wrote:
> 
> Isn't this sort of dynamic functionality (real-time presence or absence of 
> SRV records) what mDNS and the avahi daemon are for?
> 
> 
> From: bind-users  on behalf of Matus UHLAR 
> - fantomas 
> Sent: Wednesday, January 6, 2021 8:51 AM
> To: bind-users@lists.isc.org
> Subject: Re: SRV Record Server Availability
> 
> On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote:
>> Your understanding is correct, i just thought that SRV can detect whose
>> server is alive so it can choose and provide an answer with the available
>> Server.
> 
> DNS is not designed to provide this functionality. While technically you can
> change contents of DNS depending on which servers are alive and which are
> not, it's almost never a good idea.
> 
> That means, BIND has nothing like this built in.
> 
>>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>>>  wrote:
>>>> Is DNS Bind SRV record can detect the Server's availability? If yes, how?
> 
>> On Tue, 5 Jan 2021, 23:53 tale  wrote:
>>> Could you provide more information about your goal?  I don't fully
>>> understand the question.
>>> 
>>> For my reading, the answer is basically no, in that an SRV record just
>>> provides data about where.a particular service can be found.  It's up
>>> to other systems to fetch that data and interpret it, including
>>> whether that service is actually available at the given endpoint.  In
>>> its typical operation, BIND will just take whatever name and port the
>>> zone administrator said to provide for that SRV record, and not do any
>>> sort of availability checks on it.
>>> 
>>> However, if you go deep into a far more complicated, custom use of
>>> BIND, you could set up a process that monitors the availability and
>>> changes the SRV record accordingly.
> 
> --
> 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.
> Microsoft dick is soft to do no harm
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: unsubscribe

2021-01-06 Thread Mark Andrews
Send the unsubscribe request to “bind-users-requ...@isc.org” or 
“bind-users-requ...@lists.isc.org”.
Those are the administrative addresses.

> On 7 Jan 2021, at 01:07, Michalewicz, Brian R (THIP) 
>  wrote:
> 
>  
> **
> This communication, including attachments, is for the exclusive use of 
> addressee and may contain proprietary, confidential and/or privileged 
> information. If you are not the intended recipient, any use, copying, 
> disclosure, dissemination or distribution is strictly prohibited. If you are 
> not the intended recipient, please notify the sender immediately by return 
> e-mail, delete this communication and destroy all copies.
> 
> **
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log

2021-01-06 Thread Mark Andrews
Complain to the administrators of the zone. They have not properly delegated 
it.  We see this often with load balancers. 

The zone a.b.example has been delegated but the answer is as if it is from 
b.example. 

-- 
Mark Andrews

> On 6 Jan 2021, at 21:02, 同屋 <39223...@qq.com> wrote:
> 
> 
> The version of bind is BIND 9.10.5-P3 id:7d5676f 
> 
> One day, I found that the size of named.run is increasing very quickly. And a 
> lot of "invalid response" entries were spotted in the log. Details is as 
> follows (I replace the sensitive info with  {},{AAA} etc.)
> 
> DNS format error from {IP}#53 resolving 
> {}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org/ for client 
> 169.254.4.50#51099: Name epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org (SOA) not 
> subdomain of zone node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org -- invalid 
> response
> 
> The response related to the above log is as follows:
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50664 ;; flags: qr aa rd 
> ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: 
> ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: 
> ;{}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. IN 
> 
> ;; AUTHORITY SECTION: ;epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. 86400 IN SOA 
> .mnc{AAA}.mcc{BBB}.gprs. dns-admin. ( ; 2020122704 ; serial ; 10800 ; refresh 
> (3 hours) ; 3600 ; retry (1 hour) ; 604800 ; expire (1 week) ; 86400 ; 
> minimum (1 day) ; )
> 
> 
> 
> Normally, the FQDN should be cached as a NXRRSET record as follows:
> 
> {}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org. 8412 - ;-$NXRRSET
> 
> But when the issue happens, it cannot be cached, I guess it's related to the 
> "invalid response" log.
> 
> From the error log, it mentions "zone 
> node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org", but I'm wondering where the zone 
> "node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org" comes from? I cannot found the 
> related SOA record in the dump file.
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: check-names conflicts with SPF macro definition

2021-01-04 Thread Mark Andrews
SPF records are TXT record which are NOT subject to check-names processing.

If you created a seperate zone use nameservers that DO NOT live within the zone.
ns1._spf.switch.ch is NOT a legal hostname as it is not LDH.

> On 4 Jan 2021, at 20:01, Daniel Stirnimann  
> wrote:
> 
> Hello all,
> 
> I changed SPF for switch.ch to use SPF macros (RFC 7208). I wanted to
> use the "_spf" label but bind9 check-names complained with a "bad owner
> name (check-names)" message.
> 
> I have now used "spf" instead of "_spf", e.g. exists:%{ir}.spf.switch.ch
> 
> I didn't want to disable check-names for switch.ch because of this
> conflict. However, SPF record publishing is generally recommended to use
> the "_spf" subdomain which is not possible in this case.
> 
> I guess, the only alternative would have been to make "_spf.switch.ch"
> its own zone and set check-names for this zone statement to "ignore". Or
> would this be a good reasons to loosen the check-names rules in bind9?
> 
> Thanks,
> Daniel
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Quick dynamic DNS?

2020-12-24 Thread Mark Andrews
See draft-ietf-dnssd-srp 

-- 
Mark Andrews

> On 25 Dec 2020, at 12:22, Grant Taylor via bind-users 
>  wrote:
> 
> On 12/24/20 3:05 PM, Mark Andrews wrote:
>> TSIG, GSS-TSIG and SIG(0) are all secure mechanisms to update DNS zones.
> 
> Thank you for the follow up Mark.
> 
> It's good to know that they are secure mechanisms.
> 
> With all the churn in the TLS space, I can't keep up with it, much less have 
> any idea how the concepts cross pollinate to other things.
> 
>> MacOS uses TSIG to update the DNS.
>> Windows uses GSS-TSIG in active directory.
> 
> *nod*
> 
> Jan-Piet Mens has a good article on this.
> 
>> SIG(0) is in future work for home net updating records added on a first come 
>> basis.  It can also be used to update records added by other means as long 
>> as the KEY records where added at the same time.
> 
> Would you please elaborate what you mean by "on a first come basis"?  Is it 
> simply the first person to put a KEY record, or someone that has knowledge 
> there of?
> 
> Thank you for enlightening me.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Quick dynamic DNS?

2020-12-24 Thread Mark Andrews
TSIG, GSS-TSIG and SIG(0) are all secure mechanisms to update DNS zones.

MacOS uses TSIG to update the DNS. 

Windows uses GSS-TSIG in active directory.

SIG(0) is in future work for home net updating records added on a first come 
basis.  It can also be used to update records added by other means as long as 
the KEY records where added at the same time. 
-- 
Mark Andrews

> On 25 Dec 2020, at 07:46, Grant Taylor via bind-users 
>  wrote:
> 
> On 12/24/20 8:48 AM, @lbutlr wrote:
>> That is what example.com always is, yes.
> 
> Sorry.  I'm so used to people not using documentation domains that I double 
> check that they aren't actually trying to literally use documentation domains 
> internally.
> 
> It's a refreshing change to see documentation domains / IPs / networks used 
> properly.
> 
> I tip my hat to you.
> 
>> As I said, it is authoritative for example.com.
> 
> ACK
> 
>> Yep.
>> No, I just want my bind server to get updated with the external IP of my 
>> home connection when it changes and update the A pointer.
> 
> Okay.  IMHO that's relatively easy to do.  See Stanley's reply as it seems 
> quite good.
> 
> About the only thing that I'd do differently is to use update-policy { ... } 
> "grant" statements to more granularly control what the key can update.  E.g. 
> allow it to /only/ update A and / or  records for the home.example.com 
> name and nothing else.
> 
> An alternative to grant statements is to use a CNAME to yourself in a 
> different sub-domain where you have carte blanch access to update.  But, 
> seeing as how the CNAME will reference explicitly one name, you have less of 
> a security risk in the alias domain.  E.g. home.example.com -> 
> home.client1.ddns.example.com.  Then give each client the ability to update 
> it's client#.ddns.example.com sub-doimain.
> 
>> I just want to update the IP address in a single A record.
> 
> IMHO that makes this almost trivial once you know how to do it.
> 
>> Possibly, though that is certainly part of what I am asking.
> 
> *nod*nod*
> 
>> But the bind server doesn't know the new IP address?
> 
> SSH from rPI to bind9 and remotely run a command.  Possibly extracting the IP 
> from the SSH_{CLIENT,CONNECTION} environment variable.  ;-)
> 
>> As I said. The bind server is at example.com. It is authoritative for 
>> example.com (and several other domains as well).
> 
> *nod*nod*nod*
> 
> I expect that many on this list have such systems at their disposal.  }:-)
> 
>> At home I have a connection to an ISP and that connection MAY change since 
>> it is in a DHCP pool. I want to be able to updated my DNS server so that 
>> "home.example.com" points to my home IP address.
> 
> Typical and quintessential use case.
> 
>> I have done this in the past with various dynamic DNS services (like DynDNS) 
>> where their software client would automatically update a custom subdomain of 
>> one of their domains like homeftp.net (the have many and which one isn't 
>> relevant) and then on the Bind server I would have, for example, in 
>> example.com,
>> homeCNAME lbutlr.homeftp.net. #example name, not real dynDNS address)
>> When the client updated my IP address, bind would simply relay connections 
>> to home.exmple.com to lbutlr.homeftp.net regardless of what the IP address 
>> was.
>> What I want to do is eliminate the 3rd party service and client so that the 
>> bind server can simply have:
>> homeA12.34.56.789 # obvs not a real IP
> 
> Aw ... no Test-Net IPs?  :-P
> 
> IMHO what you're wanting to do is quite doable with a little bit of knowledge 
> and trial and error.  See Stanley's email for more details on said knowledge.
> 
> The only parting thoughts I'll add is that I don't know if TSIG keys are 
> sufficiently secure, or if there is a better option.  I've not looked in a 
> while.  --  I personally tend to isolate what can be changed with grant 
> statements and consider it good enough.  --  This is also where remotely 
> executing nsupdate through SSH sort of elides this issue and makes things 
> somewhat simpler.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 solution needed please

2020-12-20 Thread Mark Andrews
Firstly, read your logs, they will most probably tell you what is going wrong.

Secondly, use TSIG between primary and secondary to select views for zone 
transfers.  It is much more reliable.

Thirdly, errors are almost always typos.  Using the documentation prefix hides 
these.  You are not writing documentation, you are asking for help with your 
system.  Show the real configuration details.

> On 20 Dec 2020, at 22:27, Walter H.  wrote:
> 
> Hello,
> 
> I'm using BIND as a caching resolver and also a authoritative DNS server for 
> a '.home.arpa' local used domain;
> 
> I have two BINDs, one as a master and the other as a slave;
> also two views are used, because there are some zones
> 
> e.g. 100.168.192.in-addr.arpa  or some public zones that a 'rewritten' to be 
> solved by a local web server e.g.  msftncsi.com
> 
> they are only needed on one part of the LAN or are not wanted on the other 
> part of the LAN
> 
> lets say the master has   2001:db8:0:0:0::10 and the slave has 
> 2001:db8:0:0:0::1;
> 
> the named.conf looks like this:
> 
> acl part-common { // this is the ACL for the common part, where some 
> zones are not wanted
>   localhost;  // or shall this be at the other acl for special 
> part?
>   2001:db8:0:0:0::1;  // I thought this would be a good idea
>   2001:db8:0:0:0::10;
>   !2001:db8:0:0:0::/80; // not for the special part, but there are the 
> DNS-servers itself, that are common to the complete LAN
>   2001:db8:0:0::/64;
> };
> 
> acl part-spcl { // this is the ACL for special part of the lan, which has 
> some extra zones, that are not wanted to be in the common part above;
>   !2001:db8:0:0:0::1;   // the reason above
>   !2001:db8:0:0:0::10;
>   2001:db8:0:0:0::/80;   // only the special part with some extra zones
> };
> 
> acl slave-dns-ip {
>   2001:db8:0:0:0::1;
> };
> 
> masters dns-master { 2001:db8:0:0:0::10; };
> 
> view "commonpart" {
>   match-clients { part-common; };
>   ...
>   include "lan.zones";
> };
> 
> view "spclpart" {
>   match-clients { part-spcl; };
>   ...
>   include "lan.zones";
>   include "extra.zones"; // here are the extra zones
> };
> 
> at the master the "lan.zones" looks like this:
> 
> zone "lan.home.arpa" IN {
> type master;
> notify yes;
> file "named.zone-lan.home.arpa";
> allow-transfer { slave-dns-ip; };
> allow-update { none; };
> };
> 
> at the slave the "lan.zones" looks like this:
> 
> zone "lan.home.arpa" IN {
> type slave;
> masters { dns-master; };
> file "slaves/named.zone-lan.home.arpa";
> };
> 
> and now the problem
> 
> when I modify 'named.zone-lan.home.arpa' and force the transfer to the slave 
> - 'rndc reload',
> the test if this works, fails for clients from the special part explicitly 
> asking the slave - why?

You haven’t shown the slaves configuration.  You have only show that of the 
zone lan.home.arpa.  The configuration is much more than that.

> nslookup  www.lan.home.arpa2001:db8:0:0:0::1
> works only from clients not from the special part of the LAN,
> even the zone is in both views ..., a complete restart of BIND resolves this, 
> but this can't be, as this throws away the cached part in memory ...
> 
> nslookup  www.lan.home.arpa2001:db8:0:0:0::10
> this works from any client
> 
> how can I face this?
> 
> any hints/suggestions would be great;
> 
> Thanks,
> Walter
> 
> 
> _______
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Forwarded lookup failing on no valid RRSIG

2020-12-20 Thread Mark Andrews


> On 21 Dec 2020, at 06:04, Matthew Pounsett  wrote:
> 
> 
> 
> On Fri, 18 Dec 2020 at 18:08, Nicolas Bock  wrote:
> Thanks Mark. Am I correct then that I need to either convince the 
> administrator of that DNS to enable DNSSEC or configure my DNS with 
> `dnssec-validation = no`?
> 
> The upstream administrator isn't required to be validating DNSSEC for this to 
> work, but in order for your DNS server to do DNSSEC validation, their DNS 
> server must be DNSSEC aware enough to be requesting DNSSEC data when it 
> queries the authoritative DNS servers.  Of course, the resilience of the 
> whole thing would also be improved by that server also validating.

Matthew, there is a difference between sometimes getting answers out of a 
forwarder that isn’t validating that validate and a system that is working.  If 
the forwarder is not validating then the system cannot recover from situations 
that a iterative validating resolver can recover from.

It is bad advice to deploy validating clients behind forwarders that are not 
validating.

> If they can't or won't update their server, then yes, you'll either have to 
> disable validation yourself, or select a better upstream.  Personally I'd go 
> looking for a better upstream (or just stop using a forwarder entirely, and 
> do your own direct recursion, if that's possible in your environment).

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 refusing update [never mind]

2020-12-19 Thread Mark Andrews
Stop using IP addresses for UPDATE authentication. Use TSIG instead between the 
DHCP server and named. 

-- 
Mark Andrews

> On 19 Dec 2020, at 18:25, Dan Egli  wrote:
> 
> I guess sometimes you just need to look at it in a differnet way. I never 
> noticed it was using the 10.0.2.15 IP to try to update. That's going to be 
> blocked because I don't have the outside world enabled for this server. So 
> let me go ask on the DHCP list why it's insisting on using that interface.
> 
>> On 12/18/2020 11:59 PM, Dan Egli wrote:
>> I'm really stumped as to what's going on. I'm trying to get dhcpd to 
>> automatically update name records for my internal network. This is NOT going 
>> to the public internet by any means. It's just an internal network. But 
>> every time either I or dhcpd try to add a record, named refuses to allow it. 
>> I'm getting a message in the log that says refused due to allow-query:
>> 
>> 19-Dec-2020 06:49:19.299 update-security: error: client @0x7fa61cd0 
>> 10.0.2.15#49948: update 'eglifamily.name/IN' denied due to allow-query
>> 
>> What's causing this, and how do I fix it? I'm including my named.conf and 
>> dhcpd.con files below. Can anyone help me?
>> 
>> dhcpd.conf:
>> default-lease-time 300;
>> max-lease-time 43200;
>> 
>> ddns-update-style interim;
>> 
>> authoritative;
>> log-facility local1;
>> 
>> 
>> allow booting;
>> 
>> subnet 10.0.2.0 netmask 255.255.255.0 {
>> # no services at all! That's the llnk from the ISP. Don't touch it!
>> }
>> 
>> 
>> subnet 192.168.10.0 netmask 255.255.255.0 {
>> range 192.168.10.128 192.168.10.254;
>> if exists user-class and option user-class = "iPXE" {
>> filename "pxelinux.efi";
>> } else {
>> filename "pxelinux.0";
>> }
>> next-server 192.168.10.3;
>> option domain-name-servers 192.168.10.2, 8.8.8.8;
>> option domain-name "eglifamily.name";
>> option routers 192.168.10.1;
>> 
>> }
>> 
>> host fixed-1 {
>> hardware ethernet 08:00:27:D5:AA:3C;
>> fixed-address 192.168.10.64;
>> option host-name "ethereum-1";
>> ddns-hostname "ethereum-1.eglifamily.name";
>> }
>> 
>> named.conf:
>> /*
>>  * Refer to the named.conf(5) and named(8) man pages, and the documentation
>>  * in /usr/share/doc/bind-* for more details.
>>  * Online versions of the documentation can be found here:
>>  * https://kb.isc.org/article/AA-01031
>>  *
>>  * If you are going to set up an authoritative server, make sure you
>>  * understand the hairy details of how DNS works. Even with simple mistakes,
>>  * you can break connectivity for affected parties, or cause huge amounts of
>>  * useless Internet traffic.
>>  */
>> 
>> acl "xfer" {
>> /* Deny transfers by default except for the listed hosts.
>>  * If we have other name servers, place them here.
>>  */
>> none;
>> };
>> 
>> /*
>>  * You might put in here some ips which are allowed to use the cache or
>>  * recursive queries
>>  */
>> acl "trusted" {
>> 192.168.10.0/24;
>> 127.0.0.0/8;
>> ::1/128;
>> };
>> 
>> acl "myself" {
>> 127.0.0.0/24;
>> ::1/128;
>> };
>> 
>> options {
>> directory "/var/bind";
>> pid-file "/run/named/named.pid";
>> 
>> /* https://www.isc.org/solutions/dlv >=bind-9.7.x only */
>> //bindkeys-file "/etc/bind/bind.keys";
>> tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
>> minimal-responses yes;
>> 
>> 
>> listen-on-v6 { none; };  // for now
>> listen-on { 192.168.10.2; 127.0.0.1; };
>> 
>> allow-query {
>> /*
>>  * Accept queries from our "trusted" ACL.  We will
>>  * allow anyone to query our master zones below.
>>  * This prevents us from becoming a free DNS server
>>  * to the masses.
>>  */
>> trusted;
>> };
>> 
>> allow-query-cache {
>> /* Use the cache for the "trusted" ACL. */
>> trusted;
>> };
>> 
>> allow-r

Re: Forwarded lookup failing on no valid RRSIG

2020-12-18 Thread Mark Andrews
Correct it is not validating. Additionally it isn’t even DNSSES aware. It will 
need to be updated for you to validate through it. 

-- 
Mark Andrews

> On 19 Dec 2020, at 05:07, Nicolas Bock  wrote:
> 
> Hi Mark,
> 
> Thanks so much for the reply. I ran this command and am
> getting the following:
> 
> $ dig +dnssec ds com @10.0.0.3
> 
> ; <<>> DiG 9.10.6 <<>> +dnssec ds com @10.0.0.3
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36260
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;com. IN DS
> 
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> 
> ;; Query time: 307 msec
> ;; SERVER: 10.0.0.3#53(10.0.0.3)
> ;; WHEN: Fri Dec 18 11:26:28 CST 2020
> ;; MSG SIZE rcvd: 80
> 
> In other words, the forwarder returns a Delegation Signer
> record but not an RRset Signature record. Presumably that
> means that that the forwarder is not validating the zone?
> 
> Thanks,
> 
> Nick
> 
>> On Thu, Dec 17 2020, Mark Andrews wrote:
>> 
>> DNSSEC requires that forwarders support DNSSEC.  Check that the forwarders 
>> return
>> DNSSEC records when they are queried.  The forwarders should also be 
>> validating to
>> filter spoofed responses from the internet.  You should be getting a answer 
>> like
>> this if the forwarders are validating.
>> 
>> [beetle:~] marka% dig +dnssec ds com
>> 
>> ; <<>> DiG 9.15.4 <<>> +dnssec ds com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
>> ;; QUESTION SECTION:
>> ;com.INDS
>> 
>> ;; ANSWER SECTION:
>> com.40483INDS30909 8 2 
>> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
>> com.40483INRRSIGDS 8 1 86400 2020122917 
>> 2020121616 26116 . 
>> cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF 
>> 7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 
>> 90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V 
>> 7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ 
>> FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu 
>> HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==
>> 
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
>> ;; MSG SIZE  rcvd: 395
>> 
>> [beetle:~] marka% 
>> 
>> 
>>>> On 18 Dec 2020, at 11:36, Nicolas Bock  wrote:
>>> 
>>> Hi,
>>> 
>>> When I configure my named to forward to our corporate DNS
>>> servers (10.0.0.2 and 10.0.0.3), I end up getting error
>>> messages such as
>>> 
>>>  Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A
>>>  Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>>> 'com/DS/IN': 10.0.0.2#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>>> 'com/DS/IN': 10.0.0.3#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
>>> 'www.canonical.com/A/IN': 10.0.0.2#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server named[843946]: validating 
>>> www.canonical.com/A: bad cache hit (com/DS)
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server nam

Re: Forwarded lookup failing on no valid RRSIG

2020-12-17 Thread Mark Andrews
DNSSEC requires that forwarders support DNSSEC.  Check that the forwarders 
return
DNSSEC records when they are queried.  The forwarders should also be validating 
to
filter spoofed responses from the internet.  You should be getting a answer like
this if the forwarders are validating.

[beetle:~] marka% dig +dnssec ds com

; <<>> DiG 9.15.4 <<>> +dnssec ds com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.40483   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.40483   IN  RRSIG   DS 8 1 86400 2020122917 
2020121616 26116 . cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF 
7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 
90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V 
7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ 
FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu 
HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
;; MSG SIZE  rcvd: 395

[beetle:~] marka% 


> On 18 Dec 2020, at 11:36, Nicolas Bock  wrote:
> 
> Hi,
> 
> When I configure my named to forward to our corporate DNS
> servers (10.0.0.2 and 10.0.0.3), I end up getting error
> messages such as
> 
>   Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A
>   Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
> 'com/DS/IN': 10.0.0.2#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
> 'com/DS/IN': 10.0.0.3#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331b080 
> com (bucket 2)
>   Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
> 'www.canonical.com/A/IN': 10.0.0.2#53
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: validating 
> www.canonical.com/A: bad cache hit (com/DS)
>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 0x7fa7e331e010 
> www.canonical.com (bucket 15)
>   Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving 
> 'www.canonical.com/A/IN': 10.0.0.3#53
> 
> I don't quite understand why. Are 10.0.0.{2,3} incorrectly
> set up for DNSSEC? It looks like DNSSEC is already breaking
> for com. How can I trace what the root cause is?
> 
> Thanks!
> 
> Nick
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: How Zone Files Are Read

2020-12-16 Thread Mark Andrews


> On 17 Dec 2020, at 06:44, Timothe Litt  wrote:
> 
> 
> On 16-Dec-20 13:52, Tim Daneliuk wrote:
>> On 12/16/20 12:25 PM, Timothe Litt wrote:
>> 
>>> On 16-Dec-20 11:37, Tim Daneliuk wrote:
>>> 
>>>> I ran into a situation yesterday which got me pondering something about 
>>>> bind.
>>>> 
>>>> In this case, a single line in a zone file was bad.  The devops automation
>>>> had inserted a space in the hostname field of a PTR record.
>>>> 
>>>> What was interesting was that - at startup - bind absolutely refused
>>>> to load the zone file at all.  I would have expected it to complain
>>>> about the bad record and ignore it, but load the rest of the
>>>> good records.
>>>> 
>>>> Can someone please explain the rationale or logic for this?  Not 
>>>> complaining,
>>>> just trying to understand for future reference.
>>>> 
>>>> TIA,
>>>> Tim
>>>> 
>>> DNS is complicated.  The scope of an error in a zonefile is hard to 
>>> determine.
>>> 
>>> To avoid this, your automation should use named-checkzone before releasing 
>>> a zone file.
>>> 
>>> This will perform all the checks that named will when it is loaded.
>>> 
>>> 
>> 
>> Kind of what I thought.  Whoever build the environment in question
>> really didn't understand DNS very well and hacked together a kludge
>> that I am still trying to get my head around.
>> 
>> 
> For a simple example of why it's complicated - what if the typo you had was 
> for a host that sends e-mail?
> 
> You'll see intermittent delivery errors when remote hosts can't resolve the 
> host's address; some require that a reverse lookup resolve to the host as an 
> anti-spoofing measure.  Others won't.  You'll spend a long time diagnosing.
> named can't tell this case from a typo for a local printer's PTR - where it's 
> unlikely that a reverse lookup failure will matter.  Of course, this means it 
> could go undetected for years - until it IS needed.
> 
> Or the typo is in a NS record - which you probably won't detect until the 
> other NS goes down...
> 
> And, any errors are cached for their TTL by resolvers.  The TTL may 
> (hopefully for query rate reduction) be large.  In your case, it would be the 
> negative TTL (meaning that even adding the record later wouldn't have 
> immediate effect).
> The bottom line is that named must assume that anything placed in a zone file 
> is important, and that the external impact - either sin of omission or 
> commission - might be large.
> 
> Thus, while named can't detect all (or even most) errors, those that it does 
> detect cause immediate failure to load.  That prevents caching and 
> propagation as well as getting human attention.
> When something's wrong, it's best to stop and fix it.  Error recovery is a 
> very good thing - but only when you can demonstrate that the cure is better 
> than the disease.  Skipping format errors in a zone file would not satisfy 
> that constraint.
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 

And on top of all this there is STD 13 (RFC 1034, RFC 1035) which says
in RFC 1035:

"5.2. Use of master files to define zones

When a master file is used to load a zone, the operation should be
suppressed if any errors are encountered in the master file.  The
rationale for this is that a single error can have widespread
consequences.  For example, suppose that the RRs defining a delegation
have syntax errors; then the server will return authoritative name
errors for all names in the subzone (except in the case where the
subzone is also present on the server).

Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
  it should be present.

   4. Information present outside of the authoritative nodes in the
  zone should be glue information, rather than the result of an
  origin or similar error."

Those of use with long memories have seen all the errors scenarios
reported here play out in real life because early versions of BIND
did just drop bad lines and continue on as “best effort".  We fixed
this behaviour over 2 decades ago now with no regrets other than we
didn’t fix it sooner.

The above list of thing to check is not exhaustive.  BIND 

  1   2   3   4   5   6   7   8   9   10   >