Re: HTTP API for bind
On Fri, 2023-05-26 at 16:51 +0530, Shailendra Gautam wrote:
> Does bind provide any way to manage(add,update,delete) resource
> records
> with HTTP API, like powerdns?
Not TTBOMK. It does have an API for managing RRs but that is using RFC
2136 and not HTTP.
> I currently use zonefiles to store DNS data
> and have been planning to switch to an API to add/remove records. Is
> there
> any way to do that with bind?
Sounds like you want a tool which has an HTTP API and can translate
those calls into the RFC 2136 update protocol.
Or you could just use the RFC 2136 update protocol directly.
Or you could use CLI tools supplied with BIND even, such as "nsupdate"
that can do updates.
If you really want an HTTP API, I guess you could start doing searches
for "RFC2136 HTTP" and see if anyone has implemented such a thing.
Maybe https://github.com/frillip/noip-rfc2136 does what you want.
Perhaps there are others. I will leave that search as an exercise for
the reader.
Or you could even write your own. I have a faint recollection of
writing such a thing as a CGI script in the past. It should not be
terribly difficult. Yeah. I found it:
#!/bin/bash
key_name="put your key name here"
args_string=${REQUEST_URI##*\?}
eval "${args_string//\&/ }"
# undo url encoding
pass=${pass//\%2F/\/}
pass=${pass//\%3D/=}
cat &2
rm -f /tmp/kfile.*
echo "Content-type: text/html
good $REMOTE_ADDR"
But most likely you will want to use that GitHub project I pointed out
above rather than my Q hack above. Above is just to illustrate how
basic and simple it could be.
Cheers,
b.
signature.asc
Description: This is a digitally signed message part
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
filter queries for A records from some clients
I am trying to do some testing of an IPv6-only network here using some nat64 to reach the "legacy" :-) IPv4 Internet. My network is currently dual-stack. I have dns64 query mapping working, but I am still seeing some clients that I am trying to test with (that still have IPv4 addresses until the test proves successful) using IPv4 to the Internet. I can only surmise that this is a case where the client did a happy-eyeballs query for both A and records and got an A record back first. To that effort, I want to try filtering out A record queries (or responses) from those clients so that they only get the results back whether those are real IPv6 addresses or dns64 mapped addresses. Is there any way to filter A queries or replies to achieve this goal? I am noticing the .rpz-ip trigger, but being pretty green at RPZ policy writing, it's not clear to me if that can be used to filter just A records. Cheers, b. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: copy EDNS options to resolver response
On Sun, 2022-02-20 at 08:16 +1100, Mark Andrews wrote: > > EDNS is hop by hop. There is no copying by any compliant server. Fair enough. I thought it was a long shot. Cheers, b. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: copy EDNS options to resolver response
On Sat, 2022-02-19 at 19:02 +0100, Matus UHLAR - fantomas wrote: > > what's the point of this setup? > BIND can resolve by itself perfectly and you wouldn't rely on 3rd > party > service Except that it cannot do EDE, as I already said in my original message. Cheers, b. signature.asc Description: This is a digitally signed message part -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
copy EDNS options to resolver response
I have a BIND9 server configured as a resolver for the local network to forward all requests to 1.1.1.1. Given that that 1.1.1.1 includes (RFC8914) EDE EDNS options in it's responses, can I configure the BIND resolver to forward those EDNS options in it's response to the client? While I know BIND9 doesn't yet do EDE itself, I am hoping for an option in BIND to just blindly copy whatever EDNS options it receives to it's client. Cheers, b. signature.asc Description: This is a digitally signed message part -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
"overlay" views
I'm really not sure about what the name of this feature I am going to describe would be. I would probably call it an "overlay view". But I am sure there are better names. Imagine I have a BIND 9 server for the following network topology: Network 1 192.168.1.0/24 -|.254 | | Router | Network 2| | 192.168.2.0/24 | | -|.254 | | | Network 3| | 192.168.3.0/24 | | -|.254 | There are a few dozen hosts/services on Network 3 which hosts from Network 1 and Network 2 need to resolve names of. All pretty straightforward. But the hosts on Network 1 and Network 2 need to resolve the same name (let's call it "gateway") to the address of their interface on Router. So that is, hosts on Network 1 want a query of "gateway." to resolve to 192.168.1.254 and hosts on Network 2 want a query of "gateway." to resolve to 192.168.2.254. So this is currently all achievable through "views" in BIND 9, but requires that the zone data for each view be 98% duplicate (Network 3 resources) and continually copy-n-paste updated whenever names on Network 3 are added. What I am looking for is a way to save the duplicate copying of Network 3 resources to the views for Network 1 and Network 2. This is where the term "overlay" comes in. What I'd like to do is reference a single copy of data from Network 3 in Network 1 and 2's views but "overlay" some view-specific resources on top of that, namely the "gateway." name, with it's per-view specific value. Thoughts? b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Wed, 2018-01-17 at 10:45 -0500, Brian J. Murrell wrote: > I have a BIND (9.9.4)[1] server that runs well most of the time, but > periodically it will start returning SERVFAIL for very high-level > domains such as *.google.com, *.gstatic.com, *.github.com, etc. It > seems to happen most frequently with Google domains, but I wonder if > that is just a reflection on the percentage of queries I have for > those > here. The culprit here is the DDNS processing. Once I moved the DDNS processing (that is coming from the DHCP server) off onto a separate server the problem server stopped having SERVFAIL for names that it should just not happen for, like www.google.com. So, now I just have to chase down why DDNS is causing this. This BIND server is from the FreeIPA project so it's an LDAP-backed BIND so perhaps (probably?) that has something to do with it. I will take it up with the FreeIPA folks since it's their build of BIND that is causing the problems. Much much thanks for the help and patience here while I got to the root cause. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 09:53 -0700, Grant Taylor via bind-users wrote: > > Could you try disabling DDNS updates for a little while? That's effectively what I have done. I set up a second server configuration running new zone on a different IP address and pointed the DHCP server at it so that the DHCP server is no longer sending DDNS updates to the server that is having these intermittent outages. I've set up CNAME pointers from the main server to the new server for the names (of DHCP clients) that need to be resolvable as well as for a reverse zone on the new server. > Maybe you'll > get lucky (for a given value of luck) and find that the problem > continues happening even with DDNS updates disabled. Thus you will > have > a reasonable idea that the issue is not related to DDNS updates. Exactly my goal. I'm fairly sure that the problem is going to stop happening now that the server is no longer processing DDNS updates. Unfortunately it's impractical to run like this for the long term as any DHCP client that comes into the network ought to be able to be resolvable by it's name in the main zone, but that would require CNAMEs for any and every possible name that could show up in a DHCP client. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote: > > pretty sure it's possible and likely not much different than the > unbound-sample below which asks a rbldnsd on port 1043 on the same > machine > > stub-zone: > name: "zone-name." > stub-addr: 127.0.0.1@1053 This all falls apart because you cannot instruct the ISC DHCP server to send DDNS updates to a non-standard (!53) port. :-( I seem to have no choice but to run the isolated server on a different IP address and then have to start managing the listen-on directive in the main server to list all addresses other than the isolated server's address. :-( Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote: > > pretty sure it's possible and likely not much different than the > unbound-sample below which asks a rbldnsd on port 1043 on the same > machine > > stub-zone: > name: "zone-name." > stub-addr: 127.0.0.1@1053 That's the sort of path I was going to take with a forward zone in the main server to my DHCP-DDNS-isolation server, but in the new zone I create on the isolation server I have to list NS(es) for the new zone and while those will be on the (IP address of the) main server they will be on a different port. Of course anything doing an NS query for that new zone on that server will just get an IP address for the NS and not the port also. Maybe in such an isolated environment that doesn't matter since the only thing doing an queries to that isolated server on the alternate port will be the main server on behalf of the clients in the local network. I'll give it a shot. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
Here's a new most interesting data point. All of these outages happen right after a DHCP client connect and sends a DDNS update to BIND. It would be an interesting experiment to isolate the zone that receives DDNS updates for the DHCP clients onto a separate server to see if that makes this problem go away for the main server, but I don't have another machine to run another BIND on and I don't think it's possible to run two BINDs on the same machine on different ports and have one (on port 53) delegate a zone to another running on some other port. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote: > > lame-servers is also a log category, and tends to be quite noisy > about > various problems :-) Turns out I do already have lame server logging enabled. I.e.: 20-Jan-2018 12:01:37.053 lame server resolving 'backup-ns.yn.cninfo.net' (in 'yn.cninfo.net'?): 202.98.160.68#53 20-Jan-2018 12:01:37.054 lame server resolving 'backup-ns.yn.cninfo.net' (in 'yn.cninfo.net'?): 202.98.160.68#53 But there isn't a single lame server message with "google" anywhere in it. This problem is really not looking like a lame delegation issue, wouldn't you agree? Any further ideas? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 16:10 +, Tony Finch wrote: > > You should make sure it is enabled, because there are vital clues in > those > log lines :-) But they will only occur if there is some lameness with the ns[1- 4].google.com records and that will already be reported with lame:n in the "fetch completed at resolver.c" lines won't they, or am I completely misunderstanding something here? > Yes, and you should track down when they occur and look for other > error > indications areound that time. So, over the last week of tracing I have only these lines which match "fetch completed at resolver.c:[0-9]* for ns[1-4].google.com": 19-Jan-2018 09:41:53.347 fetch completed at resolver.c:7492 for ns4.google.com/ in 0.042154: success/success [domain:google.com,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] 19-Jan-2018 09:41:53.350 fetch completed at resolver.c:7492 for ns2.google.com/ in 0.042019: success/success [domain:google.com,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] 19-Jan-2018 09:41:53.356 fetch completed at resolver.c:7492 for ns3.google.com/ in 0.043881: success/success [domain:google.com,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] 19-Jan-2018 09:41:53.362 fetch completed at resolver.c:7492 for ns1.google.com/ in 0.047039: success/success [domain:google.com,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] None of them show any lame servers. Wouldn't I see occurrences of those with lame:n if I there were any lameness? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote: > > The thing to look out for is the minutes before the outage starts - > see > what kind of failures you get. So, taking this approach, looking for the first occurrence of just any one of the names ns[1-4].google.com prior to the A/ queries that are in http://brian.interlinx.bc.ca/named.run.log starting at: 19-Jan-2018 18:04:50.785 createfetch: ns1.google.com A (which end up resulting in the SERVFAIL for www.google.com/IN/A) the first previous occurrence of just any one of those names is: 19-Jan-2018 17:48:59.122 resquery 0x7f10102ecd50 (fctx 0x7f10102e5dc0(lh4.ggpht.com/)): response 19-Jan-2018 17:48:59.122 received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3024 ;; flags: qr cd; QUESTION: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;lh4.ggpht.com. IN ;; AUTHORITY SECTION: ggpht.com. 172800 IN NS ns2.google.com. ggpht.com. 172800 IN NS ns1.google.com. ggpht.com. 172800 IN NS ns3.google.com. ggpht.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20180124054922 20180117043922 46967 com. pjslTFtda4UfkpJtO9rbVmzSRQ+JslWRuBl/r0tkeyX4nBA8wjOIQjCH DJl+C6CA8TMW lO9dfx5ZHM2s59N/XfQG3fp2N68bf3rhSp5OwUEVy205 6LMbiiW7wjp0MEQOGorvf29kS6ApuZHGOseP5HQrAIBO4XxZvomAPME+ Q1c= FGFB71PIIJ5JUGA7GFUQ06ANFUVDRKBA.com. 86400 IN NSEC3 1 1 0 - FGFGQ2SH7LNK03PV0R76S8B47TPVJK59 NS DS RRSIG FGFB71PIIJ5JUGA7GFUQ06ANFUVDRKBA.com. 86400 IN RRSIG NSEC3 8 2 86400 20180125052147 20180118041147 46967 com. DkAophVbTjntmUtcj2HIiigTv5yxlNuTIAGWgXY+W9QhAJp4UUYpqxOe jmyxVEUtfYqS 3ANVWz7EI+ucYS1CE8UKuWUx4eGAz8F/YbN/KA5cvxWO SEqri5Lg3W2MjiB/DXXFI/WrnmuLPNIQdDZD2H1lQ56CTUAL0pPpDby9 788= ;; ADDITIONAL SECTION: ns2.google.com. 172800 IN A 216.239.34.10 ns1.google.com. 172800 IN A 216.239.32.10 ns3.google.com. 172800 IN A 216.239.36.10 ns4.google.com. 172800 IN A 216.239.38.10 I realize this query result has nothing to do with www,google.com, but it is the first occurrence of just any of the names ns[1-4].google.com prior to the start of the subsequent SERFAIL processing that starts at 18:04:50.785 and it's more than 10 minutes prior to the SERVFAIL. That seems to indicate that nothing at all to do with any of the names ns[1-4].google.com happens for more than 10 minutes before a SERVFAIL is returned for www.google.com right? Nothing at all happens that could result in a any of those names being lame, right? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote: > > They'll have a log category of edns-disabled. But if the problem were EDNS, would it be so intermittent and always fixable by rndc reload? > But, looking through the > code, if this is leading to lameness you will also get lame-servers > log > messages. So just looking for lame servers will cover EDNS issues also then, right? > lame-servers is also a log category, and tends to be quite noisy > about > various problems :-) Yeah. Must be disabled by default on EL7 I would guess, just because it's so noisy. > The tagged values there are various kinds of things that happened > when > resolving; the lame: tag is a count of the lame servers that were > encountered, including both newly discovered lame servers and cached > lame > servers. So, if lame servers were a problem with resolving ns[1-4].google.com, then I would see messages like in my previous message with a lame:n tag where n > 0, yes? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote: > > That indicates that it has already marked the servers as lame, so the > packet trace isn't going to tell you what caused the lameness. OK. > The thing to look out for is the minutes before the outage starts - > see > what kind of failures you get. > > Also, check the logs for EDNS What do EDNS problem messages look like? Just something to grep for I mean. > or lame-servers complaints Does the "lame:1" in this message indicate lameness: 18-Jan-2018 11:12:47.103 fetch completed at resolver.c:3074 for 149.243.194.103.in-addr.arpa/PTR in 0.000744: failure/success [domain:243.194.103.in-addr.arpa,referral:0,restart:1,qrysent:0,timeout:0,lame:1,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Of course, that one is irrelevant to my situation, I'm just using it as an example of how to find lame delegations. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
OK. I now have named trace logging http://brian.interlinx.bc.ca/named.run.log and a packet dump: http://brian.interlinx.bc.ca/dns-packets.txt that demonstrates how BIND is getting .com referrals from the root servers when doing a query for www.google.com and then doing nothing with those referrals before returning a SERVFAIL. The packet trace also shows that BIND queried ns2.google.com for an RR: 18:04:42.444669 IP server.interlinx.bc.ca.8727 > ns2.google.com.domain: 4359% [1au] ? playatoms-pa.googleapis.com. (56) 18:04:42.491612 IP ns2.google.com.domain > server.interlinx.bc.ca.8727: 4359*- 2/0/0 CNAME googleapis.l.google.com., 2607:f8b0:400b:80e::200a (107) 18:04:42.494681 IP server.interlinx.bc.ca.21592 > ns2.google.com.domain: 50060% [1au] ? googleapis.l.google.com. (52) 18:04:42.541496 IP ns2.google.com.domain > server.interlinx.bc.ca.21592: 50060*- 1/0/0 2607:f8b0:400b:808::200a (69) only 9 seconds before returning a SERVFAIL on another name that same server is authoritative for so it had data for at least one of the servers that are authoritative for the domain. Yet only 8 seconds later it starts looking for it's IP address again. At 18:04:50.805 it started the A and queries for ns2.google.com: 19-Jan-2018 18:04:50.805 fctx 0x7f10230b1950(ns2.google.com/A): start 19-Jan-2018 18:04:50.805 fctx 0x7f10230b1950(ns2.google.com/A): try 19-Jan-2018 18:04:50.805 fctx 0x7f10230b1950(ns2.google.com/A): cancelqueries 19-Jan-2018 18:04:50.805 fctx 0x7f10230b1950(ns2.google.com/A): getaddresses 19-Jan-2018 18:04:50.805 fctx 0x7f10230b1950(ns2.google.com/A): query 19-Jan-2018 18:04:50.805 resquery 0x7f10230b60d0 (fctx 0x7f10230b1950(ns2.google.com/A)): send 19-Jan-2018 18:04:50.806 resquery 0x7f10230b60d0 (fctx 0x7f10230b1950(ns2.google.com/A)): sent 19-Jan-2018 18:04:50.807 fctx 0x7f102309d0d0(ns2.google.com/): start 19-Jan-2018 18:04:50.807 fctx 0x7f102309d0d0(ns2.google.com/): try 19-Jan-2018 18:04:50.807 fctx 0x7f102309d0d0(ns2.google.com/): cancelqueries 19-Jan-2018 18:04:50.807 fctx 0x7f102309d0d0(ns2.google.com/): getaddresses 19-Jan-2018 18:04:50.807 fctx 0x7f102309d0d0(ns2.google.com/): query 19-Jan-2018 18:04:50.807 resquery 0x7f10230b68e0 (fctx 0x7f102309d0d0(ns2.google.com/)): send 19-Jan-2018 18:04:50.807 resquery 0x7f10230b68e0 (fctx 0x7f102309d0d0(ns2.google.com/)): sent 19-Jan-2018 18:04:50.808 resquery 0x7f10230b60d0 (fctx 0x7f10230b1950(ns2.google.com/A)): udpconnected 19-Jan-2018 18:04:50.808 resquery 0x7f10230b60d0 (fctx 0x7f10230b1950(ns2.google.com/A)): senddone 19-Jan-2018 18:04:50.808 resquery 0x7f10230b68e0 (fctx 0x7f102309d0d0(ns2.google.com/)): udpconnected At 18:04:51.236 it got the referral to the .com servers: 19-Jan-2018 18:04:51.236 fctx 0x7f102309d0d0(ns2.google.com/): sendevents 19-Jan-2018 18:04:51.236 resquery 0x7f10230b60d0 (fctx 0x7f10230b1950(ns2.google.com/A)): response 19-Jan-2018 18:04:51.236 received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9693 ;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ns2.google.com.IN A ;; AUTHORITY SECTION: com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com.86400 IN RRSIG DS 8 1 86400 2018020120 2018011919 41824 . kw9YN9f0zLsasR4xqRWC5zNwOlfhY7/1WwhfHnJpqpUpZok9MPefvv8q JpAG4ZVed57r4oZzv0dB1l3fu+dEZi7UFS1xX6H0GFxGDYrpLuXR4Emn +1ih6zIM/iWE0O6H7ElgTvgs4tZNJ7n2BX4keEAtCCSa0j9OtEYAlxHx SZumcmDxb/btwTmuT9BfxXj0UeJ/96rud5jfuz+fi6cF8fuiy728262G FjjzjjO8T1qqPcRlDDm41JXe5D0XmKV13T+I2bSaRHp5HSp0TV2p3mGH 2UobkPZ9pUpGvCwgsNaxjyCBVosnOUbQJ2uKQUQlkrMqQakDjvvPcT1h OgqYMA== ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Fri, 2018-01-19 at 15:22 +, Tony Finch wrote: > > You don't have any weird middleboxes between your resolver and the > Internet, do you? I don't believe so. Not entirely sure what "weird middleboxes" refers to in this context though. And by resolver are you referring to my BIND9 server or the resolvers on the clients of that server? I've added packet capturing to the debug collection so that I can see what my BIND9 server is sending and receiving in the way of queries and responses when this happens again. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Fri, 2018-01-19 at 14:54 +, Tony Finch wrote: > > Those responses look like referrals from the root servers to the .com > servers; Ahhh. Right. That makes sense. > I would expect you to see `named` repeating the queries as it > follows the iterative resolution algorithm. Indeed. I will looking further down the log then... So, between that initial: 19-Jan-2018 09:06:18.893 resquery 0x7f1010f3bd90 (fctx 0x7f1010f23d90(www.google.com/A)): response is just the referrals to .com for that query and the referrals to .com for the subsequent ns[1-4].google.com queries before we get to: 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): query failed (SERVFAIL) for www.google.com/IN/A at query.c:7007 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): error 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): send 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): sendto 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): senddone 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): next 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): ns_client_detach: ref = 0 19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): endrequest 19-Jan-2018 09:06:18.967 fetch completed at resolver.c:7415 for www.google.com/A in 0.547099: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] 19-Jan-2018 09:06:18.967 fetch 0x7f1012541cd0 (fctx 0x7f1010f23d90(www.google.com/A)): destroyfetch 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): query failed (SERVFAIL) for www.google.com/IN/A at query.c:7007 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): error 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): send 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): sendto 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): senddone 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): next 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): ns_client_detach: ref = 0 19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): endrequest 19-Jan-2018 09:06:18.968 fetch 0x7f102c5def88 (fctx 0x7f1010f23d90(www.google.com/A)): destroyfetch 19-Jan-2018 09:06:18.968 fctx 0x7f1010f23d90(www.google.com/A): shutdown 19-Jan-2018 09:06:18.968 fetch 0x7f10125423f0 (fctx 0x7f1010d86e80(ns1.google.com/A)): destroyfetch 19-Jan-2018 09:06:18.968 fctx 0x7f1010d86e80(ns1.google.com/A): shutdown 19-Jan-2018 09:06:18.968 adb: fetch of 'ns1.google.com' A failed: SERVFAIL 19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES 19-Jan-2018 09:06:18.968 cfan: skipping find 0x7f10228d7630 19-Jan-2018 09:06:18.968 fetch 0x7f10191e91e8 (fctx 0x7f1010d88a40(ns1.google.com/)): destroyfetch 19-Jan-2018 09:06:18.968 fctx 0x7f1010d88a40(ns1.google.com/): shutdown 19-Jan-2018 09:06:18.968 adb: fetch of 'ns1.google.com' failed: SERVFAIL 19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES 19-Jan-2018 09:06:18.968 cfan: processing find 0x7f10228d7630 19-Jan-2018 09:06:18.968 sending event 0x7f10228d76b8 to task 0x7f10247a2f10 for find 0x7f10228d7630 19-Jan-2018 09:06:18.968 fetch 0x7f102069a2d0 (fctx 0x7f1010a83a60(ns2.google.com/A)): destroyfetch 19-Jan-2018 09:06:18.968 fctx 0x7f1010a83a60(ns2.google.com/A): shutdown 19-Jan-2018 09:06:18.968 adb: fetch of 'ns2.google.com' A failed: SERVFAIL 19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES 19-Jan-2018 09:06:18.968 cfan: skipping find 0x7f10208679e0 19-Jan-2018 09:06:18.968 fetch 0x7f10206998b0 (fctx 0x7f1010a83ea0(ns2.google.com/)): destroyfetch 19-Jan-2018 09:06:18.968 fctx 0x7f1010a83ea0(ns2.google.com/): shutdown 19-Jan-2018 09:06:18.968 adb: fetch of 'ns2.google.com' failed: SERVFAIL 19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES 19-Jan-2018 09:06:18.968 cfan: processing find 0x7f10208679e0 19-Jan-2018 09:06:18.968 sending event 0x7f1020867a68 to task 0x7f10247a2f10 for find 0x7f10208679e0 19-Jan-2018 09:06:18.968 fetch 0x7f102112d400 (fctx 0x7f1010b6bee0(ns3.google.com/)): destroyfetch 19-Jan-2018 09:06:18.970 fctx 0x7f1010b6bee0(ns3.google.com/): shutdown 19-Jan-2018 09:06:18.970 adb: fetch of 'ns3.google.com' failed: SERVFAIL 19-Jan-2018 09:06:18.970 DNS_EVENT_ADBNOMOREADDRESSES 19-Jan-2018 09:06:18.970 cfan: skipping find 0x7f102309fc10 19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 (wifi-test.mobidia.com): query failed (SERVFAIL) for wifi-test.mobidia.com/IN/A at query.c:7007 19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 (wifi-test.mobidia.com): error 19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 (wifi-test.mobidia.com): send 19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 (wifi-test.mobidia.com): sendto
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Thu, 2018-01-18 at 17:46 +, Tony Finch wrote: > Brian J. Murrell <br...@interlinx.bc.ca> wrote: > > On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote: > > > > > > The default is 10 minutes - try reducing it and see if the outage > > > becomes shorter. > > > > If it does, what is that telling me? > > My hypothesis here is that `named` has marked all the nameservers for > the > domain that is failing as lame, so it no longer has anywhere to send > queries for the domain, so it returns a SERVFAIL. Seems this might be the case. Using a trace level of 11, when a failure starts this seems to be the trail... 19-Jan-2018 09:06:18.893 resquery 0x7f1010f3bd90 (fctx 0x7f1010f23d90(www.google.com/A)): response 19-Jan-2018 09:06:18.893 received packet: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25156 ;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1472 ;; QUESTION SECTION: ;www.google.com.IN A ;; AUTHORITY SECTION: com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com.86400 IN RRSIG DS 8 1 86400 2018020105 2018011904 41824 . IwT0e9jOKKgASgCQXGsryxFFeN5R0e/HPGCzQuD7rhtCYg4UywLcJ9A1 Ftn0drh2mggBE5wWX90dc5u26P8Gt1jkJ8XbxyjNHA5uTmakjVnGGOZ+ 9N/6JMtDApT4F6q/3EN8dkctxWvEe9uph8dFR1Uj0aqCNS3aQ0ge4LkS JPfRQ2FIQCQxsh+Ts2hdiC6mThpWoFmwmfBxGPu/NsS92/iA5EaP4ZOK oIRqrvgyV4PrTDJM8StJJk9qw7z78RC+3/RfEsnwICXKptIGE4AekqIa RiVhkTrXhCZAibab5gtqkCkWZ6kF1/6Xbcjexj4VHL+FxqlQCec6CUcz Wpt/DA== ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN A 192.26.92.30 c.gtld-servers.net. 172800 IN 2001:503:83eb::30 d.gtld-servers.net. 172800 IN A 192.31.80.30 d.gtld-servers.net. 172800 IN 2001:500:856e::30 e.gtld-servers.net. 172800 IN A 192.12.94.30 e.gtld-servers.net. 172800 IN 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN A 192.35.51.30 f.gtld-servers.net. 172800 IN 2001:503:d414::30 g.gtld-servers.net. 172800 IN A 192.42.93.30 g.gtld-servers.net. 172800 IN 2001:503:eea3::30 h.gtld-servers.net. 172800 IN A 192.54.112.30 h.gtld-servers.net. 172800 IN 2001:502:8cc::30 i.gtld-servers.net. 172800 IN A 192.43.172.30 i.gtld-servers.net. 172800 IN 2001:503:39c1::30 j.gtld-servers.net. 172800 IN A 192.48.79.30 j.gtld-servers.net. 172800 IN 2001:502:7094::30 k.gtld-servers.net. 172800 IN A 192.52.178.30 k.gtld-servers.net. 172800 IN 2001:503:d2d::30 l.gtld-servers.net. 172800 IN A 192.41.162.30 l.gtld-servers.net. 172800 IN 2001:500:d937::30 m.gtld-servers.net. 172800 IN A 192.55.83.30 m.gtld-servers.net. 172800 IN 2001:501:b1f9::30 19-Jan-2018 09:06:18.894 fctx 0x7f1010f23d90(www.google.com/A): noanswer_response 19-Jan-2018 09:06:18.894 log_ns_ttl: fctx 0x7f1010f23d90: noanswer_response: www.google.com (in '.'?): 1 518400 19-Jan-2018 09:06:18.894 log_ns_ttl: fctx 0x7f1010f23d90: DELEGATION: www.google.com (in 'com'?): 0 518400 19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): cache_message 19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): cancelquery 19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): nameservers now above QDOMAIN 19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): done 19-Jan-2018 09:06:18.896 fctx 0x7f1010f23d90(www.google.com/A): stopeverything 19-Jan-2018 09:
Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote: > > Does the time to recovery correspond to the lame-ttl setting? I am not sure. I'm not always aware of when it starts. I guess if I am running a trace level permanently the log would tell me though. > The default > is 10 minutes - try reducing it and see if the outage becomes > shorter. If it does, what is that telling me? The problem domains are listing NSes that don't actually host the zone? I thought named normally logged lame delegations but I don't see a single one in the last few days. That said, if such a high-visibility domain as googles were misconfigured, it would be wreaking havoc all over the Internet, and drawing lots of attention wouldn't it? > When you have a failure, try `rndc flushtree` to more selectively > drop > problematic state - you might have to find out the nameservers of the > broken domain and flush them. (The google.com nameservers are under > google.com; GitHub's are under dynect.net and a bunch of awsdns > domains.) rndc flushtree takes a domain name though doesn't it? In what case would I need to find nameservers? So, when I do rndc reload am I flushing the cache? :-( > Look at the end of the dump - the address database, ; Address database dump ... ; ns3.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns2.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns1.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns4.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] > bad cache, Empty. > and > servfail cache. Non-existent section in my database dump. > > Do I need tracing enabled before the situation happens? > > That will make it a lot easier, yes :-) > > > What level (how many "rndc trace"s should I run)? > > You can specify a number directly, like `rndc trace 11` - level 11 is > handy because it includes query and response packet dumps (er, but > that > is a 9.11 feature - in 9.9 you'll only get the response packets). I'll set that trace now and hope to hit the problem again soon -- before I fill up my filesystem. :-) Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
intermittent SERVFAIL for high visible domains such as *.google.com
I have a BIND (9.9.4)[1] server that runs well most of the time, but periodically it will start returning SERVFAIL for very high-level domains such as *.google.com, *.gstatic.com, *.github.com, etc. It seems to happen most frequently with Google domains, but I wonder if that is just a reflection on the percentage of queries I have for those here. In any case when this happens, it will last a few minutes until it resolves itself and/or I issue an "rndc reload". That always seems to correct it if I don't care to wait it out. I'm wondering what the steps are to try to get to the bottom of this. I have a db dump (rndc dumpdb) as well as some trace (rndc trace x10) while this is happening. Is this enough? If so, what should I look for as a cause of the SERVFAILs? If not, what more do I need to collect? Do I need tracing enabled before the situation happens? What level (how many "rndc trace"s should I run)? Very greatful for any help. Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
error (insecurity proof failed) resolving './DS/IN'
Trying to follow an example I found of manually verifying a name's DNSSEC records I did the following: # dig . DNSKEY | grep -Ev '^($|;)' root.keys # dig +sigchase +trusted-key=./root.keys www.eurid.eu. A That resulted in some errors but more importantly the following in my syslog: Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.33.4.12#53 Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.203.230.10#53 Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.58.128.30#53 Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.112.36.4#53 Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.228.79.201#53 Mar 23 08:11:16 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 193.0.14.129#53 Mar 23 08:11:16 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.5.5.241#53 Mar 23 08:11:16 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:503:ba3e::2:30#53 Mar 23 08:11:16 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 128.63.2.53#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 192.36.148.17#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:500:3::42#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:dc3::35#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:503:c27::2:30#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:7fd::1#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:500:2f::f#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 198.41.0.4#53 Mar 23 08:11:17 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:500:1::803f:235#53 Mar 23 08:11:18 linux named[19256]: error (insecurity proof failed) resolving './DS/IN': 2001:500:84::b#53 I'm really not sure why though. I'm using BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' Any ideas on what this is or what more information I can provide to help chase it down? Cheers, b. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Nintendo('s NSes) are asking my IP for it's rdns
I've come across something interesting in my named logs: 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied where 216.58.37.216 is my IP address, assigned by my ISP and reverse resolved by my ISP's name servers. What is interesting is the fact that 205.166.76.12 are asking me (216.58.37.216) for the PTR for my address. Is this just broken NS software or are they (Nintendo, FWIW) doing something interesting, like giving everyone an opportunity to provide an rdns for their own IP address without everyone having to make classless in-addr.arpa delegation arrangements with their ISP (which mine refused to do)? It's kind of a neat concept if it's not just an accident of broken NS software. Has anyone else seen anything like this before? Is there some (proposed even) standard for doing this that I'm not aware of? In any case, now to the BIND part. It seems reasonable for me to answer that query, either with my own data or simply by allowing that query to recurse. I suppose I could create a zone for it and put some data in it for that one record if I wanted to provide my own data. But what if I just wanted to allow recursive queries on that name so that I simply returned whatever the proper NSes for it reports? I guess I could add a zone record for it with a forwarder(s) configured to the name's proper NSes, yes? But that means me having to maintain those forward records in tandem with my ISP playing musical NSes (which I don't expect but why create a possible maintenance headache). So how could I configure BIND to allow a query for 5.37.58.216.in- addr.arpa to be recursive for everyone, but of course, continue to disallow general open recursive querying for names not served here? Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nintendo('s NSes) are asking my IP for it's rdns
On 12-07-24 07:05 AM, Brian J. Murrell wrote: I've come across something interesting in my named logs: 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied where 216.58.37.216 That should be 216.58.37.5. is my IP address, assigned by my ISP and reverse resolved by my ISP's name servers. What is interesting is the fact that 205.166.76.12 are asking me (216.58.37.216) for the PTR for my address. And again, that should be 216.58.37.5. Sorry for the typos. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nintendo('s NSes) are asking my IP for it's rdns
On 12-07-24 07:53 AM, Phil Mayers wrote: On 24/07/12 12:05, Brian J. Murrell wrote: Change ISP? A. You must be one of those people who live in that part of the world where internet service providing is not a monopoly, duopoly or at best a price-fixing oligopoly. :-) Unfortunately that's not all of us. Besides, although my ISP won't delegate the in-addr.arpa. for my one single IP address to me, they will allow me to tell them what to put in for it's PTR. So it doesn't totally suck. I don't think that's what is going on. But even if it were, I think that would be a bad idea, personally. Why? I mean other than a knee-jerk reaction to that behavior not (yet) being documented in an RFC somewhere? I mean for practical purposes why is what they are (or rather, could be, assuming my suggestion about what they could be doing is correct) doing necessarily bad? DNS is well-specified in the RFCs. Sure. So there is no room for expansion? Violating those to work around lazy ISPs is not a good solution. What exactly is it violating? Is there somewhere in an RFC that says an NS MUST NOT try to query a nameserver at a given IP for the PTR RR for itself? If we assume they are first going to an IP address to see if it's willing to provide a PTR for itself and then falling back to using the procedure defined in the RFCs and asking the NSes defined for that IP, what are they breaking? It seems to be they are extending, not violating. The fact that it's Nintendo which does create networkable hardware is what makes me wonder if it's more by design than brokenness. What if, for example, they put a lightweight NS into all of their hardware (i.e. handheld and other game units) that returns a PTR for it's own IP as a means of identifying the unit? Certainly, they could have just invented their own who are you protocol, but instead they decided to do something interesting with an existing protocol that already answers who is. My son has a gameboy or 2. It might be interesting to see if it responds to a PTR query. I will have to wait for him to come back from camp to see. We see all kinds of weird nonsense come into our DNS servers. We see LOTS AND LOTS of these two zones, continually: 75.97.111.76#27300: view main: query (cache) 'mx241.emailfiltering.com/A/IN' denied 41.218.219.221#26895: view main: query (cache) 'service17.mimecast.com/A/IN' denied Yeah, but these are not interesting. These look like either misconfigured resolvers, or opendns probing, or something. The thing that makes the behavior I posted about interesting (IMHO) is the possible usefulness of it. But we also see a trickle of other crap that is nothing to do with us, for example: 190.26.0.2#16074: view main: query (cache) 'ns1.webservices.net/A/IN' denied 59.90.143.134#48824: view main: query (cache) 'a20.g.akamai.net/A/IN' denied Sure, I think we all get that. Same as above. But none of it is interesting. I've never established why this happens, whether it's some kind of attempt at cache poisoning from botnets or just broken software. But frankly I don't care - I just ignore it. Of course. So do I. And I have been ignoring the queries I posted about until I realized they had some interesting aspect to them. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 07:16 PM, Mark Andrews wrote: dnssec-validation auto; Well, this seems to have done the trick. Changing it from yes to auto has eliminated most (almost all in fact) of the validation warnings/errors I was getting in my logs. tells named to use the compiled in root key in addition to enabling validation. A. So yes just enables validation but doesn't use any compiled in root key? If so, this is an annoying (all due respect) and small but important distinction. I'm not sure about anyone else, but a yes/no/auto selector to me means either an explicit yes or explicit no with auto meaning some kind of do what you think is right in terms of making it yes or no. I don't typically think of it as no or yes plus some additional functionality. Anyway, you have my since appreciation for persevering with me in my efforts to figure this out. b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-05-15 09:01 AM, Phil Mayers wrote: Sorry about the way delayed response. There seems to be some confusion about which list/group gmane is following. Isn't it more likely it's a local problem? Indeed. But what, is the question (and I do have the answer, now -- see below). Which version of bind are you running? I was running 9.8.3 and now 9.9.1-P1 Does *any* zone validate Yes. e.g. try: dig +dnssec @localhost www.ic.ac.uk # dig +dnssec @localhost www.ic.ac.uk ; DiG 9.9.1-P1 +dnssec @localhost www.ic.ac.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 725 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.ic.ac.uk. IN A ;; ANSWER SECTION: www.ic.ac.uk. 3600IN A 155.198.140.14 www.ic.ac.uk. 3600IN RRSIG A 5 4 3600 20120812165527 20120713164639 4743 ic.ac.uk. UZDw0aM0xPFXAmb5/PReP8hSWR/eNmMA479JFoZyHmxRrepTaJWLya+R 1F2Y2LI/T12QlFkw09KBsgZo+hGr2MWfPyMAjNttzDLCqGM7dDNBUnuz H4G7DUnTvpnIV3VcLHqIh2z+j5ZmBb4+O4MIbNbBh8reVIacM8jgGNPH Evs= ;; AUTHORITY SECTION: ic.ac.uk. 86400 IN NS ns1.ic.ac.uk. ic.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. ic.ac.uk. 86400 IN NS ns2.ic.ac.uk. ic.ac.uk. 86400 IN NS ns0.ic.ac.uk. ic.ac.uk. 86400 IN RRSIG NS 5 3 86400 20120806213024 20120707210235 4743 ic.ac.uk. AYa7xE/1ZDMvt0c1wGY/+eu4vgbJm4EV+i+1YYZhtLu44bdnHndfptNZ ECxeOI8JVeaKUq1zPspK9UnTCLFDkfCq9cIVFjZhpHQSPHtd3Vss40Vl gKrOG6qm4RfmPbLaUDKxu/LsR/W+iRbbiwI2fsso34BTUJeKPZGwqHPG j9k= ;; ADDITIONAL SECTION: ns0.ic.ac.uk. 86400 IN A 155.198.142.80 ns0.ic.ac.uk. 86400 IN 2001:630:12:600:1::80 ns1.ic.ac.uk. 86400 IN A 155.198.142.81 ns1.ic.ac.uk. 86400 IN 2001:630:12:600:1::81 ns2.ic.ac.uk. 86400 IN A 155.198.142.82 authdns1.csx.cam.ac.uk. 86400 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 86400 IN 2001:630:212:12::d:a1 ns0.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120807164706 20120708162343 4743 ic.ac.uk. SDz7qZbq+O/SMopAP4L1W9QeeuJu6+vBW25h4WIoDmFgXb+OPx3/M/6H 6pBFUpO2XoBfurRHly0r2yy7C4x3X7vth8nT9Xo16ZL9nauYwbUIM3f3 zDECyEzrkPf8EDcwRYycOJfcKcAlxG0FiPBav+WJW8PNMR43YAsr6w5D ZLU= ns0.ic.ac.uk. 300 IN RRSIG 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. U+LTVkUNoTWXNTabEd/rt15qze4iLWhDFyw+inaYgToGxYA5y3JS+fnx qfe2+GUFSLOz/Xo6czEe7728vCLgXzLQckAyS3g56NUfHKyXO1WWa6lQ k1r9UoNOSj5vTu0YLQN1FgP4aSFjowZzeQtbX//aDXZEVHKjNz4UFwBA zPs= ns1.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120816015657 20120717011404 4743 ic.ac.uk. dFRwdOkf670aLyyLtnLAYwo18XQGIFgT8YWQukrsj514pINSR5WUkcpd ReUOGLy9+RDEfpWwDsvdp1DLrxbUzElTF5Qkg/1d76qqB6WxmnQq6lqz r5zKgfh9GNZHKrAOzvLcxlUFhd2xm1NXjktjIhb6CLH+qrJRR9h9+Zxy MlQ= ns1.ic.ac.uk. 300 IN RRSIG 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. OBSX8EyrqDcE6QzArCOaecx3Rf5fuBqfMctc/6M+3SnCHqQ9Dzp0YZly 2f6OJXu2JCrR4lGEUfgnA8rXDCKLgkzVIWFZi4y0GVuY2VHXhBptT9ri P0xRDqytbK9FAmIQMjn0gVuRBA6FhHhalh59FrcimXT/DyEj3TjsW2iD IsQ= ns2.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120804065011 20120705063843 4743 ic.ac.uk. IQ9KZAqCZLRpDwSpFpwor5ru7ltRfgBkFITKVs5ICz0fGrMQ9uWeWVY2 CLNVmPeXtMseId7Y67+CM4q2Zu+zfBtSiLlDbbqD13FnSdmjqLCHF4PG 7UVW1Z9uqjSHndKuuXeihNUSogyDZyoqf1b4SRcmRwOjgsM7HX0gWy87 jBs= ;; Query time: 451 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 07:24:59 2012 ;; MSG SIZE rcvd: 1466 ...and you should see: ; -HEADER- opcode: QUERY, status: NOERROR, id: 18199 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11 Note the ad flag - authenticated data. Yup, I did see that. The problem here seems to be fragmented UDP. I only ever receive the first fragment. Since I am tcpdumping on the external interface of my router, I know it's not my router dropping it (which does have an iptables policy installed, but tcpdump happens before iptables AFAIU; that is you see *everything* with tcpdump, even on an interface where iptables is set to drop traffic). I can only assume it's my ISP or something upstream. I am able to receive fragmented ICMP however. For example: $ ping -M want -s 3000 74.125.226.17 PING 74.125.226.17 (74.125.226.17) 3000(3028) bytes of data. 3008 bytes from 74.125.226.17: icmp_req=1 ttl=58 time=29.1 ms 3008 bytes from 74.125.226.17: icmp_req=2 ttl=58 time=28.2 ms 3008 bytes from 74.125.226.17: icmp_req=3 ttl=58 time=28.6 ms 3008 bytes from 74.125.226.17: icmp_req=4 ttl=58 time=29.0 ms 3008 bytes from 74.125.226.17: icmp_req=5 ttl=58 time=29.9 ms 3008 bytes from 74.125.226.17: icmp_req=6 ttl=58 time=28.8
Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 08:34 AM, Brian J. Murrell wrote: The problem here seems to be fragmented UDP. I seem to have misdiagnosed this due to tcpdump peculiarities. I only initially saw/suspected the problem since my capture for port 53 packets was including (only the first) ipv4 fragments. When adding a capture specifically to get all ipv4 fragments in addition to my port 53 packets, I do see all of the fragments. So back to the drawing board. In my previous posting, I was able to demonstrate that I do get some queries authenticated, but others (corresponding to the errors in my logs) are not. For example: Jul 20 08:59:37 linux named[17472]: validating @0xf48d01b0: 119.in-addr.arpa SOA: no valid signature found and sure enough: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 49713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;119.in-addr.arpa. IN SOA ;; ANSWER SECTION: 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk= ;; AUTHORITY SECTION: 119.in-addr.arpa. 78212 IN NS ns1.apnic.net. 119.in-addr.arpa. 78212 IN NS sec1.authdns.ripe.net. 119.in-addr.arpa. 78212 IN NS ns2.lacnic.net. 119.in-addr.arpa. 78212 IN NS ns4.apnic.net. 119.in-addr.arpa. 78212 IN NS ns3.apnic.net. 119.in-addr.arpa. 78212 IN NS apnic1.dnsnode.net. 119.in-addr.arpa. 78212 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: ns1.apnic.net. 167 IN A 202.12.29.25 ns1.apnic.net. 164129 IN 2001:dc0:2001:0:4608::25 ns2.lacnic.net. 82967 IN A 200.3.13.11 ns2.lacnic.net. 164257 IN 2001:13c7:7002:3000::11 ns3.apnic.net. 167 IN A 202.12.28.131 ns3.apnic.net. 164129 IN 2001:dc0:1:0:4777::131 ns4.apnic.net. 167 IN A 202.12.31.140 ns4.apnic.net. 164129 IN 2001:dc0:4001:1:0:1836:0:140 sec1.authdns.ripe.net. 167 IN A 193.0.9.3 apnic1.dnsnode.net. 3767IN A 194.146.106.106 tinnie.arin.net.35918 IN A 199.212.0.53 tinnie.arin.net.35918 IN 2001:500:13::c7d4:35 sec1.authdns.ripe.net. 167 IN RRSIG A 5 4 3600 20120819100246 20120720090246 16848 ripe.net. PnInozslOygv30AuohnYIzlCkeShxybKYeZ4114kpClfsMB/t3liXNmw in7Ha8Mh1mOZFtv2lvYDNlnrZgO65xXkUwsH2iz1jCMFU6ZjwGhqVhaX PpN6T6BXDHSohpFkVlx0yu9J7BcPMuCD6FJB5yLF4V0UUkJoPOXFAKBa mto= ;; Query time: 239 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 09:02:18 2012 ;; MSG SIZE rcvd: 892 no ad bit set. But why? Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 09:11 AM, Phil Mayers wrote: Or, what happens if you start bind up in debug mode and run the query? There will be a lot of output, but I've found most problems to be fairly obvious if you read through it. Yeah, there is a lot of output. Too big of a haystack for me to find the needle I'm afraid. I probably had way too much debug enabled. I'd be happy to trim it back if desired. Just tell me which categories you'd want to see and what severity to set. In any case, the log is at http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was: dig +dnssec @localhost 119.in-addr.arpa SOA The log should be as brief as it can be as I started named, did the query and waited for the response and then stopped bind. Just for good measure, since I think I have posted this before, but here are the options I have set in my bind configuration with regard to dnssec: dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 10:42 AM, Mark Andrews wrote: The NS RRset is the delegation records and as such has no RRSIGs. If you turn on minimal-responses the NS rrset won't be added and AD won't be cleared. AD is only set to 1 if all the records in the answer and authority sections are marked as secure. OK. So I added: minimal-responses yes; and the dig response does indeed look much more minimal, but the ad bit is still not being set: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45253 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;119.in-addr.arpa. IN SOA ;; ANSWER SECTION: 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk= ;; Query time: 720 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 10:50:21 2012 ;; MSG SIZE rcvd: 310 Strangely I didn't get an error logged about there being no valid signature for 119.in-addr.arpa SOA though. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-05-02 09:29 AM, Mark Andrews wrote: * a firewall blocking EDNS queries. * using a non DNSSEC enabled forwarder so you don't get signatures. * a firewall blocking fragmented UDP and named falling back to plain DNS. * other packet loss causing named to fallback to plain DNS. Given that I have confirmed EDNS works with: dig edns-v4-ok.isc.org TXT dig edns-v6-ok.isc.org TXT and that I don't have a firewall that would/should be dropping (properly) fragmented UDP[1] and I have no other indications of packet loss, are we looking at a bug in BIND9 to explain this (mis-)behavior? Cheers, b. [1] I'd be happy to test and provide evidence if anyone has a test that will do so. Perhaps a dig command targeted at one of the many failures that my logs are constantly showing? signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named validating @0x...: ... SOA: no valid signature found
On 12-05-02 09:29 AM, Mark Andrews wrote:
The zones are signed. Possible reason are:
* a firewall blocking EDNS queries.
This shouldn't be the case. Outgoing traffic from the bind9 server
being used here should be completely unfettered.
* using a non DNSSEC enabled forwarder so you don't get signatures.
I believe my forwarder (bind9 server) is DNSSEC enabled:
options {
...
// enable DNSSEC
dnssec-enable yes;
dnssec-validation yes;
// as of 9.7, use auto instead
// dnssec-lookaside . trust-anchor dlv.isc.org.;
dnssec-lookaside auto;
};
* a firewall blocking fragmented UDP and named falling back to
plain DNS.
Again, the firewall should be allowing bind9 to do whatever it wants.
* other packet loss causing named to fallback to plain DNS.
I'm not seeing any evidence of that here otherwise.
Can you prescribe any tests that I can do to [dis-]prove any of the
above theories?
Cheers and much thanks,
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind restart needed to reflect changes to dynamic zone in multiple views
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic update to a common
zone, only the internal view sees that change. External queries still
return the data prior to the update. If I restart the server, then
external queries get the updated data.
To provide an (excerpted, for brevity) example...
zones.common
zone rbl.interlinx.bc.ca {
type master;
file /etc/bind/master/rbl.interlinx.bc.ca.zone;
allow-update { ... };
allow-transfer { ... };
allow-query { any; };
};
zones.common
named.conf
view trusted {
match-clients { trusted_networks; }; // our internal networks
...
include /etc/bind/zones.common;
...
zone interlinx.bc.ca {
type master;
file /etc/bind/master/interlinx.bc.ca.zone;
allow-update { ... };
allow-query { ... };
allow-transfer { ... };
};
...
};
view greatunwashed {
match-clients { any; }; // all others hosts
...
include /etc/bind/zones.common;
allow-query { great_unwashed_allowed_query; };
zone interlinx.bc.ca {
type slave;
file /etc/bind/slave/interlinx.bc.ca.zone;
masters { ... };
allow-query { any; };
};
};
named.conf
To demonstrate, given the above configuration:
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca. not found: 3(NXDOMAIN)
dns_server $ nsupdate
server localhost
zone rbl.interlinx.bc.ca.
update add 1.2.3.4.rbl.interlinx.bc.ca 60 A 127.0.0.2
send
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # /usr/sbin/rndc reload
server reload successful
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # service bind9 restart
* Stopping domain name service... bind9
...done.
* Starting domain name service... bind9
...done.
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
As you can see, it took a complete server restart for the greatunwashed
view to get the zone update.
Is this expected behavior or a (known?) bug?
Cheers,
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 12:39 PM, Evan Hunt wrote: You can specify the view in the reload command: $ rndc reload example.com in external But reload doesn't work for dynamic zones: # rndc reload rbl.interlinx.bc.ca in greatunwashed rndc: 'reload' failed: dynamic zone and since I want the same zone definition file to be included in both views, I can't (without separating and mostly duplicating) easily do that. I don't think I can even point a non-dynamic zone definition at a dynamic zone file because of the journal and all that, right? You can also configure the zone in one view as a master and the one in the other view as a slave; then reloading the master will automatically send a notify to the slave. Yeah, so I've been hearing about. I suppose in this case I am creating separate definitions for the zones also. :-( This all seems like a pretty serious deficiency in BIND9. That it exists I suppose attests to the difficulty in fixing it though. :-( Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 01:47 PM, Evan Hunt wrote:
Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
Yeah. I got the master/slave approach working with your suggestion
below as a model. I reversed the master/slave relationship however to
reflect that changes come from internal only.
I guess it's hoping for too much though to have the master sent notifies
to the slave given that master and slave are both on the same host, yes?
Hence your suggestion of periodic reload commands?
The data really does need to be quite in sync though. I'm not sure a
period of less than a second or two is going to be acceptable. :-(
The master/slave approach really works better, though. Something like
this:
view internal {
match-clients { !key example-key; localnets; };
zone example.com {
type slave;
masters { localhost key example-key; }
};
};
view external {
match-clients { any; };
zone example.com {
type master;
file filename;
update-policy { grant example-key zonesub ANY; };
also-notify { 127.0.0.1; };
};
};
Cheers, and thanx much for all of that.
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 03:19 PM, David Sparro wrote: Do you have control of the update process. Sure. You could potentially send and update to both views (in other words, send two updates). How do I, with nsupdate, specify which view's zone I want to update? I think you'd need separate zone files on the server, too. Sure, that's not hard. The hard (or rather, unknown) part is how to tell nsupdate which view to interact with? b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Jeremy C. Reed jreed at isc.org writes: I was reading it all along, but could never reproduce. Given the new information I have, I'll hazard to guess that you were trying to reproduce with something newer than 9.7.0-P2. I thought it was a temporary issue. I see your new bug report. Someone will follow up soon. That can probably be closed out (I will follow-up on it as soon as I'm done here) but I have taken a variance from my distro's prescribed BIND version of 9.7.0-P2 and built a 9.7.2-P2 and after about 12h of data collecting the problem seems to be gone. I am going to bug report with said distro also as I hate varying from the working set because it just causes possible future problems trying to bug report with them. you are not using the version we support, bla, bla, bla. So in the end it seems that perhaps it was a bug/situation that was cleared up between 9.7.0-P2 and 9.7.2-P2. Thanx to all that persevered through all of this. I really should have just bitten the bullet and upgraded in the first place. Cheers, b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes: I still don't have the answer to this. Fair enough. I was just looking for clarification on your previous statements. Perhaps a BIND developer may have better insight into the log messages and what may be going on. Yeah, I was hoping to have caught the attention of a BIND developer here with all of this by now. Perhaps they just don't hang out here. Maybe I will try to find out where to ask questions that they might see. Thanx! b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes: After a review of NSEC3 showed that this particular behavior is expected because org has been signed using NSEC3 with the opt-out bit set. I'm afraid I'm getting a bit lost due to my real lack of understanding of the details of DNSSEC. I wish I had the time to really sit down and understand the concepts in complete detail. :-( So does the RFC reference just explain why the AD bit (i.e. and not the bigger problem of the spew of log entries from named) is not set or does that explain the entire problem I am seeing (namely the continuous log spew from named)? Cheers, b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Brian J. Murrell brian at interlinx.bc.ca writes: Casey Deccio casey at deccio.net writes: Do you get a NOERROR response with the AD bit set? Yup: ... Was any of that information I posted in the previous message useful? If not, I'd be happy to gather some more. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes: On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell brian at interlinx.bc.ca wrote: $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt Doh! I forgot the +dnssec. What happens when you run the following queries: dig +dnssec @linux -p 1053 org SOA Do you get a NOERROR response with the AD bit set? Yup: $ dig +dnssec @linux -p 1053 org SOA ; DiG 9.7.1-P2 +dnssec @linux -p 1053 org SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 44657 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;org. IN SOA ;; ANSWER SECTION: org.670 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2009390492 1800 900 604800 86400 org.670 IN RRSIG SOA 7 1 900 20101124135902 20101110125902 61598 org. cqufQ6aorG5AeM7mFR/lwm9TnLwdK9PjTH36lEo4fYBk5jH+sgLM17rG wZD6c4/ZZHuT4ZvcQMa6pR1CgEtBLq1YAIT5zl0ncWs2pbyS2BFr35k5 B9thalfcHAGXFATzCFcVzQTVBSFy5QDPMuHpz2LTvaFc0xiE6sGqF+Fr Q14= ;; AUTHORITY SECTION: org.86175 IN NS a2.org.afilias-nst.info. org.86175 IN NS b0.org.afilias-nst.org. org.86175 IN NS a0.org.afilias-nst.info. org.86175 IN NS d0.org.afilias-nst.org. org.86175 IN NS c0.org.afilias-nst.info. org.86175 IN NS b2.org.afilias-nst.org. org.86175 IN RRSIG NS 7 1 86400 20101123154737 20101109144737 61598 org. KncVCF0Fbp56Cf7xW376cEuGnNL/G19WM0GfXhWwWHuWKn2HDjx7OJMi a0OYeoo/KlUn0pO0ORgT96vurhOkweEfdZXnpdPRRHBStfmpFZYD9wxG FiyGounAQuso/EWSZhmwHXsFieElBQ8+J8sKY+EDo4K92uCZ5QtQAI6S 7m8= ;; Query time: 2 msec ;; SERVER: 10.75.22.3#1053(10.75.22.3) ;; WHEN: Wed Nov 10 09:02:03 2010 ;; MSG SIZE rcvd: 536 dig +dnssec @linux -p 1053 bondedsender.org DS Do you get a NOERROR response with AD bit No AD bit set, however... set and NSEC3 RRs and their covering RRSIGs? I do get NSEC3 and RRSIG RRs: ; DiG 9.7.1-P2 +dnssec @linux -p 1053 bondedsender.org DS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18923 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;bondedsender.org. IN DS ;; AUTHORITY SECTION: org.590 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2009390497 1800 900 604800 86400 org.590 IN RRSIG SOA 7 1 900 20101124140403 20101110130403 61598 org. C92vKu2HbiWyt+hgBJD5Arj4egcuL197n0AQWgnKPMQ+XdG90tGG0/5h 81dQZI/xKQQsoTA5I4oKa9qspxXqC1T1Ej7bBzFqnSrgVDpv1fI/GvIt UWbxYL888sn9XE/IP/tHWsbY6aIoSsheYTdJP0oOuunVMkF+i4c25c0v 9Yo= h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN RRSIG NSEC3 7 2 86400 20101124140403 20101110130403 61598 org. qUeV9GSkAD4cY9ftHxclrhrX9tzzZmUJSDXgDab78x8DoBFZ9LNKg+jG Yvqqbk0CqOxAJKE7CGDV6WzcsBQJCdM1+3r3+L660i6jIgubxMwGpWc0 C/GXRhtYZXOuAHpVI0gHPCSoQzLqYU+QxxBepgOUUxSnLS4Zx7tftpqI zAg= h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN NSEC3 1 1 1 D399EAAB H9PLJ7JCGLSRA48965QFJNJ3D0HC4FP5 NS SOA RRSIG DNSKEY NSEC3PARAM t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN RRSIG NSEC3 7 2 86400 20101124010350 2010111350 61598 org. MLy2iRpF6yKCUfcb0zxow1Dn6ky7BaZQrMZCHsfbFOsV7p5fI13JQJ2r ihceyFt5G3VcJrnzm5E51YVlKKFEJmHIwaTUdHDTcBznqzOk+s3xm1iC o3cBgrMMEOOQwsX7sVMHLg9NuQ395lq2GZtOrvYZWAEpCU9dOmqcSbFO 2+M= t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN NSEC3 1 1 1 D399EAAB T2GH7ROARI9U6G24CR9QK4J52L88HKPV ;; Query time: 3993 msec ;; SERVER: 10.75.22.3#1053(10.75.22.3) ;; WHEN: Wed Nov 10 09:03:23 2010 ;; MSG SIZE rcvd: 756 The above produced the following in the bind debug log [ sorry for all the line wrapping. Stupid gmane enforces that ]: dnssec: validating @0x20fc49b0: bondedsender.org DS: starting dnssec: validating @0x20fc49b0: bondedsender.org DS: attempting negative response validation dnssec: validating @0x20fc49b0: bondedsender.org DS: nsecvalidate: creating validator for org SOA dnssec: validating @0x20fc7b98: org SOA: starting dnssec: validating @0x20fc7b98: org SOA: attempting positive response validation dnssec: validating @0x20fc7b98: org SOA: keyset with trust 8 dnssec: validating @0x20fc7b98: org SOA: verify rdataset (keyid=61598): success dnssec: validating @0x20fc7b98: org SOA: marking as secure, noqname proof not needed dnssec: validator @0x20fc7b98: dns_validator_destroy dnssec: validating @0x20fc49b0: bondedsender.org DS: in authvalidated dnssec: validating @0x20fc49b0: bondedsender.org DS: resuming nsecvalidate dnssec: validating @0x20fc49b0: bondedsender.org DS
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes:
Reproducing these errors and analyzing the debug-level log messages
would be helpful since everything looks consistent from a DNSSEC
perspective, as far as I can see.
Well, I have attempted this. I reproduced my existing bind configuration and
added the following to logging:
category dnssec { debug_log; };
channel debug_log {
file /var/tmp/named.debug;
severity debug 100;
print-category yes;
};
The only written to that file when one of those broken chain lookups happen is:
dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bondedsender.org TXT:
starting
dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bondedsender.org TXT:
attempting negative response validation
dnssec: validator @0x2295e9b0: dns_validator_destroy
The dig query that produced that:
$ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
; DiG 9.7.1-P2 @linux -p 1053
41.70.55.206.sa-trusted.bondedsender.org
txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 40957
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;41.70.55.206.sa-trusted.bondedsender.org. IN TXT
;; Query time: 43 msec
;; SERVER: 10.75.22.3#1053(10.75.22.3)
;; WHEN: Tue Nov 9 23:08:39 2010
;; MSG SIZE rcvd: 58
And the syslog entry:
Nov 9 23:08:39 linux named[11040]: error (broken trust chain) resolving
'41.70.55.206.sa-trusted.bondedsender.org/TXT/IN': 209.51.221.2#53
So nothing terribly interesting in the debug as far as I can see. Perhaps I
don't have enough/the correct debugging enabled?
Cheers,
b.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes:
There is a difference between a broken trust chain and a trust chain
that securely ends before reaching the name being queried.
Ahhh. That makes sense.
However, a broken chain means that the validating resolver expects a
chain to exist, but the chain does not extend properly.
How does a resolver come to this expectation? What is happening that makes
this situation any different than an insecure delegation? If we take one of
the examples from my original post:
named error (broken trust chain) resolving '133.168.163.66.sa-
trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
Where/why does it break? Who's is breaking it? I can see that org. is rife
with DNSSEC data but that bondedsender.org. is completely void of it. But
surely that would be the case of a plain insecure delegation, yes?
I'm assuming the error above refers to a broken chain, but it's hard
to tell why without looking at the context, including cache contents
at the time of the failure, etc. The DNSSEC configuration (resulting
in insecure answer) looks okay from my perspective. Is the error
persistent or was it a one-time deal?
Well given the particular one above is a dnsbl lookup it's difficult to say if
I've even looked it up more than once.
Looking at the various occurrences I have it seems to be pervasive for reverse
addr lookups in bb.barracudacentral.org, sa-accredit.habeas.com, sa-
trusted.bondedsender.org, rbl-plus.mail-abuse.org, relays.mail-abuse.org,
dialups.mail-abuse.org, blackholes.mail-abuse.org looking for A and TXT records.
It also seems to occur quite frequently for lookups to domains like
{seal,ocsp}.verisign.net, login.facebook.com, *.slashdot.org,
newswww.bbc.net.uk, and others.
Apart from that there are a few domains in which A, MX and PTR lookups return a
broken chain, but nowhere near as much as the reverse addr lookups and the
lookups above.
Cheers,
b.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Stephane Bortzmeyer bortzmeyer at nic.fr writes: Indeed. Your analysis seems right. May be you have somewhere another trust anchor (for DLV at ISC or directly for bondedsender.org?) Hrm. I'm not sure TBH. I know I didn't install any trust anchor specifically for bondedsender.org, but I do have dnssec-lookaside auto; configured in my bind options. I don't know how to do the same verification of bondedsender.org given that however. Another possibility: sa-trusted.bondedsender.org is badly lame (none of the name servers reply), so it may trigger a bad error message from BIND. Both s0.rpdns.net. and s1.rpdns.net. seem to be responsive. The number of high- profile domains involved seems to reduce the probability of this option. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Stephane Bortzmeyer bortzmeyer at nic.fr writes: They are not name servers of sa-trusted.bondedsender.org: Damn. Yes, you are correct. I forgot it was sa-trusted.bondedsender.org. in our example and stopped at bondedsender.org. However going that one more sub- domain deeper and testing it's NSes, they are all responsive. And per my previous message, the number of domains affected makes the idea that it's lame servers lower probability. Thanx for keeping me honest. :-) b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes: This can happen in a number of different ways: If any RRSIGs in the chain of trust are bogus, expired, or missing. If NSEC/NSEC3 records are not provided or are insufficient to prove that no DS records exist for an insecure delegation. If DS RRs do exist, but none correspond to any self-signing DNSKEYs in the child zone. If DNSKEYs are not returned by the resolver. None of which appear to be the case for this example-case domain sa- trusted.bondedsender.org as far as I have been able to determine with my green DNSSEC skills. Yes, bondedsender.org is an insecure delegation. So from what I have been able to learn so far, there shouldn't be any legitimate reason why one should be getting broken trust chain errors about a domain that has been insecurely delegated, yes? I mean there is no security in the delegation to be broken, right? Reproducing these errors and analyzing the debug-level log messages would be helpful since everything looks consistent from a DNSSEC perspective, as far as I can see. I might be able to set up a shadow bind installation that mirrors the configuration of primary resolver here to do some debugging. Do you have any suggestions as to which debug flags/levels to set to get some meaningful information? Once set up, simply doing some digs with +dnssec against the configured server should suffice, yes? b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
error (broken trust chain) resolving
Since enabling DNSSEC on my resolving server I have been seeing various instances of the following sort of messages: named error (broken trust chain) resolving '133.168.163.66.sa- trusted.bondedsender.org/TXT/IN': 173.45.100.146#53 named error (broken trust chain) resolving '173.65.147.69.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '133.168.163.66.sa- accredit.habeas.com/TXT/IN': 72.232.184.122#53 named error (broken trust chain) resolving '151.168.163.66.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '149.65.147.69.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '133.168.163.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53 named error (broken trust chain) resolving '52.241.193.67.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '61.94.196.66.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '154.168.163.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53 named error (broken trust chain) resolving '106.94.196.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53 named error (broken trust chain) resolving '184.34.137.98.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '92.45.136.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '36.34.137.98.bb.barracudacentral.org/A/IN': 75.101.130.80#53 named error (broken trust chain) resolving '154.168.163.66.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '64.218.193.67.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '92.45.136.98.sa- accredit.habeas.com/TXT/IN': 173.45.100.162#53 named error (broken trust chain) resolving '148.65.147.69.bb.barracudacentral.org/A/IN': 75.101.130.80#53 named error (broken trust chain) resolving '158.169.163.66.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '172.65.147.69.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '45.34.137.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '92.45.136.98.sa- trusted.bondedsender.org/TXT/IN': 64.251.27.187#53 named error (broken trust chain) resolving '40.34.137.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53 named error (broken trust chain) resolving '101.43.195.217.sa- accredit.habeas.com/TXT/IN': 64.251.27.185#53 named error (broken trust chain) resolving '103.179.83.130.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '101.43.195.217.bb.barracudacentral.org/A/IN': 75.101.143.130#53 named error (broken trust chain) resolving '101.43.195.217.sa- trusted.bondedsender.org/TXT/IN': 72.232.192.162#53 I haven't been able to find an explanation of what that broken trust chain message means, exactly. Anyone care to explain? Thanx, b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Alan Clegg aclegg at isc.org writes: Hi Alan, There isn't a chain of signed DS records that lead from a trust anchor to the thing that you are trying to resolve. I guess I'm going to have to learn a bit more about DNSSEC in order to parse that. :-) Are there any good tutorials on the mechanics (as opposed to howtos about setting up and configuring trusted zones, etc.) of DNSSEC? i.e. Alice and Bob examples. Thanx much! b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Alan Clegg aclegg at isc.org writes: On 11/2/2010 8:11 AM, Brian J. Murrell wrote: named error (broken trust chain) resolving '133.168.163.66.sa- trusted.bondedsender.org/TXT/IN': 173.45.100.146#53 There isn't a chain of signed DS records that lead from a trust anchor to the thing that you are trying to resolve. So basically it just means that one or more zones from . down to the thing I'm trying to resolve has not been DNSSECized? i.e. no zone keys, signing, etc.? Wouldn't that be the case for the majority of things I (or anyone else) would be trying to resolve, in these early days of DNSSEC? It just seems like I'd see way more records (i.e. pretty much everything we try to resolve here) of the sort that I posted if that were the case. Maybe the variation in things we try to resolve here is not as much as I'd have thought. Am I misunderstanding? b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
