Re: nsupdate apparently not working for me. What am I overlooking / doing wrong?
On Wed, 29 Jul 2020, Mark Andrews wrote: Make sure you are using the CORRECT name in the dig query. You used ddns-key.ottawatch.ca instead of ddns-update.ottawatch.ca. Thanks Mark... so tired I didn't see that when staring at it. (Blame grass allergies and terrible heat lately.) Also you can delete and add in the same UPDATE operation. Remove the first “send” in nsupdate.script. Yes, thanks for the tip. I did man nsupdate :-) I had nsupdate debug enabled earlier, so split this it up while testing. Also ottawatch.ca has DS records but the zone is not signed. You need to fix this as lookups are failing for anyone that is validating responses. Again, testing artifact. Domain is actually signed but I disabled that and took it out of the config to simplify while testing. Domain is not live for anything now but my kicking around so no harm done except to eagle eyes like yours who look up DNSSEC chain of trust :-) Thanks for your second look and premiere response. Brett p.s. this Mailman list is slightly misconfigured. I have DKIM signing and a DMARC policy, so get lots of failure reports when I post to this list. Any chance you guys could toggle that flag so the list doesn't break DKIM signing? It's a straight-forward toggle; I use it on Mailman lists I run.___ 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: nsupdate apparently not working for me. What am I overlooking / doing wrong?
Make sure you are using the CORRECT name in the dig query. You used
ddns-key.ottawatch.ca instead of ddns-update.ottawatch.ca.
Also you can delete and add in the same UPDATE operation. Remove the
first “send” in nsupdate.script.
Also ottawatch.ca has DS records but the zone is not signed. You need
to fix this as lookups are failing for anyone that is validating responses.
ottawatch.ca. 86400 IN DS 63970 8 1
FE95768ADB2B2F9E87B3C6B4210D4C21766A2EC6
ottawatch.ca. 86400 IN DS 63970 8 2
1139FAEF396A03435BD093ACA623306B3307D11163188D4D5143909D 3CEF76EC
Mark
> On 29 Jul 2020, at 12:30, Brett Delmage wrote:
>
> nsupdate works according to updated contents of a dynamic zonefile but dig
> does not report the added A record.
>
> What am I doing stupidly here?
>
> BIND version 1:9.16.5-1+ubuntu18.04.1
> - both authoritative and local recursive
>
> zone config:
> zone "ottawatch.ca"
>{
>type master;
>file "/var/lib/bind/master/ottawatch.ca";
>allow-transfer { key "pannier-xfer"; };
>notify yes;
>update-policy { grant ddns-key.ottawatch.ca subdomain ottawatch.ca.; };
>};
>
> [do I have the correct update-policy syntax?]
> (I also tried "update-policy local" with nsupdate -l, with same results.)
>
>
> # nsupdate -D -k ddns-key.ottawatch.ca nsupdate.script
>
> nsupdate.script:
>
> server 127.0.0.1
> zone ottawatch.ca.
> update del ddns-update.ottawatch.ca. a
> send
> update add ddns-update.ottawatch.ca. 999 a 3.4.5.8
> send
>
> zone DB after update and "rndc sync" executed to incorporate .jnl:
>
> $ORIGIN .
> $TTL 900; 15 minutes
> ottawatch.caIN SOA cacloud.ottawatch.ca.
> hostmaster.ottawatch.ca. (
>2020072808 ; serial
>900; refresh (15 minutes)
>180; retry (3 minutes)
>2419200; expire (4 weeks)
>900; minimum (15 minutes)
>)
>NS cacloud.ottawatch.ca.
>NS pannier.ottawatch.ca.
>A 206.248.172.47
>MX 10 mail1.ottawajazzscene.ca.
>TXT "v=spf1 a ip4:206.248.172.47 -all"
> $ORIGIN ottawatch.ca.
> cacloud A 23.111.69.176
>2607:7b00:7200:1::281a:5de2
> $TTL 999; 16 minutes 39 seconds
> ddns-update A 3.4.5.8 <--- nsupdate worked (it seems)
> $TTL 900; 15 minutes
> pannier A 206.248.172.47
>2607:f2c0:a000:1d1::73:1
>
>
>
> # dig -4 @cacloud.ottawatch.ca cacloud.ottawatch.ca. a
>
> ; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca cacloud.ottawatch.ca. a
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1862
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 195a1192604da78e01005f20daf7193b36ec5545d879 (good)
> ;; QUESTION SECTION:
> ;cacloud.ottawatch.ca. IN A
>
> ;; ANSWER SECTION:
> cacloud.ottawatch.ca. 900 IN A 23.111.69.176
>
> ;; Query time: 0 msec
> ;; SERVER: 23.111.69.176#53(23.111.69.176)
> ;; WHEN: Tue Jul 28 22:12:07 EDT 2020
> ;; MSG SIZE rcvd: 93
>
> BUT dig does not report the nsupdate-added a record (NXDOMAIN):
>
> # dig -4 @cacloud.ottawatch.ca ddns-key.ottawatch.ca. a
>
> ; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca ddns-key.ottawatch.ca.
> a
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49598
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 6db0ccbd0085ecca01005f20db0f7cdb769b038236f9 (good)
> ;; QUESTION SECTION:
> ;ddns-key.ottawatch.ca. IN A
>
> ;; AUTHORITY SECTION:
> ottawatch.ca. 900 IN SOA cacloud.ottawatch.ca.
> hostmaster.ottawatch.ca. 2020072808 900 180 2419200 900
>
> ;; Query time: 0 msec
> ;; SERVER: 23.111.69.176#53(23.111.69.176)
> ;; WHEN: Tue Jul 28 22:12:31 EDT 2020
> ;; MSG SIZE rcvd: 133
>
>
> A record added to the dynamic zone file manually works:
>
> dig -4 @cacloud.ottawatch.ca bb.ottawatch.ca. a
>
> ; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca bb.ottawatch.ca. a
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8033
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 8feed7fd82821e9a01005f20dc3de1670c37be1dadbc (good)
>
nsupdate apparently not working for me. What am I overlooking / doing wrong?
nsupdate works according to updated contents of a dynamic zonefile
but dig does not report the added A record.
What am I doing stupidly here?
BIND version 1:9.16.5-1+ubuntu18.04.1
- both authoritative and local recursive
zone config:
zone "ottawatch.ca"
{
type master;
file "/var/lib/bind/master/ottawatch.ca";
allow-transfer { key "pannier-xfer"; };
notify yes;
update-policy { grant ddns-key.ottawatch.ca subdomain ottawatch.ca.; };
};
[do I have the correct update-policy syntax?]
(I also tried "update-policy local" with nsupdate -l, with same results.)
# nsupdate -D -k ddns-key.ottawatch.ca nsupdate.script
nsupdate.script:
server 127.0.0.1
zone ottawatch.ca.
update del ddns-update.ottawatch.ca. a
send
update add ddns-update.ottawatch.ca. 999 a 3.4.5.8
send
zone DB after update and "rndc sync" executed to incorporate .jnl:
$ORIGIN .
$TTL 900; 15 minutes
ottawatch.caIN SOA cacloud.ottawatch.ca. hostmaster.ottawatch.ca. (
2020072808 ; serial
900; refresh (15 minutes)
180; retry (3 minutes)
2419200; expire (4 weeks)
900; minimum (15 minutes)
)
NS cacloud.ottawatch.ca.
NS pannier.ottawatch.ca.
A 206.248.172.47
MX 10 mail1.ottawajazzscene.ca.
TXT "v=spf1 a ip4:206.248.172.47 -all"
$ORIGIN ottawatch.ca.
cacloud A 23.111.69.176
2607:7b00:7200:1::281a:5de2
$TTL 999; 16 minutes 39 seconds
ddns-update A 3.4.5.8 <--- nsupdate worked (it seems)
$TTL 900; 15 minutes
pannier A 206.248.172.47
2607:f2c0:a000:1d1::73:1
# dig -4 @cacloud.ottawatch.ca cacloud.ottawatch.ca. a
; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca cacloud.ottawatch.ca. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1862
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 195a1192604da78e01005f20daf7193b36ec5545d879 (good)
;; QUESTION SECTION:
;cacloud.ottawatch.ca. IN A
;; ANSWER SECTION:
cacloud.ottawatch.ca. 900 IN A 23.111.69.176
;; Query time: 0 msec
;; SERVER: 23.111.69.176#53(23.111.69.176)
;; WHEN: Tue Jul 28 22:12:07 EDT 2020
;; MSG SIZE rcvd: 93
BUT dig does not report the nsupdate-added a record (NXDOMAIN):
# dig -4 @cacloud.ottawatch.ca ddns-key.ottawatch.ca. a
; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca ddns-key.ottawatch.ca. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49598
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 6db0ccbd0085ecca01005f20db0f7cdb769b038236f9 (good)
;; QUESTION SECTION:
;ddns-key.ottawatch.ca. IN A
;; AUTHORITY SECTION:
ottawatch.ca. 900 IN SOA cacloud.ottawatch.ca.
hostmaster.ottawatch.ca. 2020072808 900 180 2419200 900
;; Query time: 0 msec
;; SERVER: 23.111.69.176#53(23.111.69.176)
;; WHEN: Tue Jul 28 22:12:31 EDT 2020
;; MSG SIZE rcvd: 133
A record added to the dynamic zone file manually works:
dig -4 @cacloud.ottawatch.ca bb.ottawatch.ca. a
; <<>> DiG 9.16.5-Ubuntu <<>> -4 @cacloud.ottawatch.ca bb.ottawatch.ca. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8033
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8feed7fd82821e9a01005f20dc3de1670c37be1dadbc (good)
;; QUESTION SECTION:
;bb.ottawatch.ca. IN A
;; ANSWER SECTION:
bb.ottawatch.ca.900 IN A 3.4.5.9
;; Query time: 0 msec
;; SERVER: 23.111.69.176#53(23.111.69.176)
;; WHEN: Tue Jul 28 22:17:33 EDT 2020
;; MSG SIZE rcvd: 88
END OF DETAILS
___
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 trust chain
A network link that is dropping packets can trigger EDNS failures in versions of BIND before 9.13.3. These versions have code to compensate for servers that fail to respond to EDNS queries or fail to respond to EDNS queries with DO=1 or fail to respond to queries with (particular) EDNS options set. BIND would fallback to plain DNS queries to workaround these issues, but that broke DNSSEC when the answers where coming from a signed zone and the packet loss is due to network issues. 5029. [func] Workarounds for servers that misbehave when queried with EDNS have been removed, because these broken servers and the workarounds for their noncompliance cause unnecessary delays, increase code complexity, and prevent deployment of new DNS features. See https://dnsflagday.net for further details. [GL #150] > On 29 Jul 2020, at 09:10, > wrote: > > Hi All, > > I am using Bind as resolver for end users . > > At various time, bind logs show "broken trust chain" continuously , for > about 20mn ~ 30 mn causing an increase of "recursive clients" shown in "rndc > status" and a decrease of "DNS sucess rate KPI" supervised from end users > side. then the error disappear and everything is OK. > > the problem appears on different server at different time. > > What could be the problem? > > Regards, > > > « Ce message et toutes les pièces y jointes sont susceptibles de contenir des > informations confidentielles ou privilégiées, lesquelles ne doivent être > reproduites, diffusées ou exploitées sans autorisation. L’intégrité des > messages électroniques n’étant pas garantie, WANA CORPORATE décline toute > responsabilité dans le cas où ce message aurait été altéré, déformé ou > falsifié. > > Ce message est établi à l'attention exclusive de ses destinataires. Si vous > avez reçu ce message par erreur, veuillez le signaler à l’expéditeur et le > détruire y compris les pièces jointes. > > Merci. » > > > > « This message and its attachments may contain confidential or privileged > information that should not be copied, distributed or used without > authorization. As the integrity of emails may not be guaranteed, WANA > CORPORATE is not liable for messages that have been modified, changed or > falsified. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > Thank you. » > > ___ > 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 trust chain
What version of BIND are you using? John From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of youssef.fassifi...@inwi.ma Sent: Tuesday, July 28, 2020 6:10 PM To: bind-users@lists.isc.org Subject: broken trust chain Hi All, I am using Bind as resolver for end users . At various time, bind logs show "broken trust chain" continuously , for about 20mn ~ 30 mn causing an increase of "recursive clients" shown in "rndc status" and a decrease of "DNS sucess rate KPI" supervised from end users side. then the error disappear and everything is OK. the problem appears on different server at different time. What could be the problem? Regards, « Ce message et toutes les pièces y jointes sont susceptibles de contenir des informations confidentielles ou privilégiées, lesquelles ne doivent être reproduites, diffusées ou exploitées sans autorisation. L'intégrité des messages électroniques n'étant pas garantie, WANA CORPORATE décline toute responsabilité dans le cas où ce message aurait été altéré, déformé ou falsifié. Ce message est établi à l'attention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, veuillez le signaler à l'expéditeur et le détruire y compris les pièces jointes. Merci. » « This message and its attachments may contain confidential or privileged information that should not be copied, distributed or used without authorization. As the integrity of emails may not be guaranteed, WANA CORPORATE is not liable for messages that have been modified, changed or falsified. If you have received this email in error, please notify the sender and delete this message and its attachments. Thank you. » ___ 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
broken trust chain
Hi All, I am using Bind as resolver for end users . At various time, bind logs show "broken trust chain" continuously , for about 20mn ~ 30 mn causing an increase of "recursive clients" shown in "rndc status" and a decrease of "DNS sucess rate KPI" supervised from end users side. then the error disappear and everything is OK. the problem appears on different server at different time. What could be the problem? Regards, « Ce message et toutes les pièces y jointes sont susceptibles de contenir des informations confidentielles ou privilégiées, lesquelles ne doivent être reproduites, diffusées ou exploitées sans autorisation. L'intégrité des messages électroniques n'étant pas garantie, WANA CORPORATE décline toute responsabilité dans le cas où ce message aurait été altéré, déformé ou falsifié. Ce message est établi à l'attention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, veuillez le signaler à l'expéditeur et le détruire y compris les pièces jointes. Merci. » « This message and its attachments may contain confidential or privileged information that should not be copied, distributed or used without authorization. As the integrity of emails may not be guaranteed, WANA CORPORATE is not liable for messages that have been modified, changed or falsified. If you have received this email in error, please notify the sender and delete this message and its attachments. Thank you. » ___ 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
Calculate the size of a DNS record in the cache
Hello, My cache is 100MB and I'd like to know how many records can fit inside.I suppose that it depends on the record: isc.org is 7 characters and shorter than http://www.example.com And it probably depends on the type and adress. So which size would isc.org A 1.1.1.1 be ? I ask my question because I was wondering how many nxdomainattack1.example.com, nxdomainattack2.example.com...can I generate before fil in the cache of my recursive server According to the RFC, if my example.com SOA TTL is 86400, the NXDOMAIN entry would remain in the cache for 1 day. Thank you for sharing your thoughts ___ 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
RPZ wildcard domain passthru not effective in BIND 9.11.21
Hi all,
BIND version: 9.11.21
OS: RHEL 7
Compile options: ./configure --prefix=/usr --localstatedir=/var
--sysconfdir=/etc --with-openssl --enable-largefile --disable-ipv6
--enable-threads --enable-filter-
I have configured 4 RPZ zones (2 are from upstream feeds, and the other 2
are local overrides blacklist/whitelist).
The response-policy and RPZ zones configurations are as follows
response-policy {
zone "rpz.local.whitelist" policy passthru;
zone "rpz.local.blacklist" policy cname
sinkhole-local.domain.com;
zone "rpz.whitelist"policy passthru;
zone "rpz.blacklist" policy cname sinkhole-feed.domain.com;
};
zone "rpz.local.whitelist"{
type master;
file "zones/master/rpz.local.whitelist.db";
allow-query { localhost; };
};
zone "rpz.local.blacklist" {
type master;
file "zones/master/rpz.local.blacklist.db";
allow-query { localhost; };
};
zone "rpz.whitelist"{
type master;
file "zones/master/rpz.whitelist.db";
allow-query { localhost; };
};
zone "rpz.blacklist" {
type master;
file "zones/master/rpz.blacklist.db";
allow-query { localhost; };
};
Contents of zones that are relevant to the issue
# grep "*\.live\.com" rpz.*
rpz.blacklist.db:onedrive.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.blacklist.db:*.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.whitelist.db:*.live.com.rpz.whitelist. 3600 IN CNAME rpz.passthru.
# dig @dnsserver onedrive.live.com
;; QUESTION SECTION:
;onedrive.live.com. IN A
;; ANSWER SECTION:
onedrive.live.com. 5 IN CNAME sinkhole-feed.domain.com.
sinkhole-feed.domain.com. 900 IN A 127.66.66.66
I would expect the rpz.whitelist would allow *.live.com (passthru).
However, if I add the FQDN, not wildcard domain, in the rpz.local.whitelist
zone to override the external feeds, the FQDN resolution works
# grep "*\.live\.com" rpz.*
rpz.blacklist.db:onedrive.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.blacklist.db:*.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.local.whitelist.int.db:onedrive.live.com.rpz.local.whitelist. IN CNAME
rpz-passthru.
rpz.whitelist.db:*.live.com.rpz.whitelist. 3600 IN CNAME rpz.passthru.
# dig @dnsserver onedrive.live.com
;; QUESTION SECTION:
;onedrive.live.com. IN A
;; ANSWER SECTION:
onedrive.live.com. 60 IN CNAME odc-web-geo.onedrive.akadns.net.
odc-web-geo.onedrive.akadns.net. 36 IN CNAME odc-web-brs.onedrive.akadns.net
.
odc-web-brs.onedrive.akadns.net. 36 IN CNAME
odwebpl.trafficmanager.net.l-0004.dc-msedge.net.l-0004.l-msedge.net.
odwebpl.trafficmanager.net.l-0004.dc-msedge.net.l-0004.l-msedge.net. 240 IN
CNAME l-0004.l-msedge.net.
l-0004.l-msedge.net. 240 IN A 13.107.42.13
RPZ wildcard domain whitelist (passthru) doesn't seem to work as it should
be.
I have noticed that the last workable version is BIND 9.11.6-P1. I have
tested the same configurations with versions 9.11.8, 9.11.19 and 9.11.21,
and all produce the same issue.
Has anyone experienced a similar issue here? or have I
mis-configured something?
Thanks
myOcella
___
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
