priming and dnskey
I found a packet requesting dnskey record at priming,in spite of removing "validator" from my config. What is the purpose of this function? I think this function may cause trouble with KSK rollover. -- -- T.Suzuki
Re: NOTIMP for unrecognized qtypes
Petr Špaček via Unbound-users wrote: > Well, the spec is from 1987. Even the meaning of MUST/SHOULD etc. was > not standardized yet back then ... Even worse, this language appears to have been copied verbatim from RFC 883, which is even older (1983) :-) -- Robert Edmonds edmo...@debian.org
Re: NOTIMP for unrecognized qtypes
On 28.7.2017 00:15, Jacob Hoffman-Andrews via Unbound-users wrote: > On 07/27/2017 01:28 PM, Robert Edmonds wrote: >> Jacob Hoffman-Andrews via Unbound-users wrote: >>> I'm trying to write some documentation for users of Let's Encrypt about >>> CAA. I believe it's the case that standards-conformant authoritative >>> resolvers should return NOERROR for qtypes they don't recognize, rather >>> than NOTIMP. Is this correct? If so, what is the relevant standard? I >>> haven't been able to find a citation in >>> https://tools.ietf.org/html/rfc3597, >>> https://tools.ietf.org/html/rfc6895, or https://tools.ietf.org/html/rfc1035. >> >> RFC 1035 seems to be pretty clear that NOTIMP applies to the OPCODE, not >> the QTYPE. >> >> Mockapetris[Page 25] >> >> RFC 1035Domain Implementation and SpecificationNovember 1987 >> >> >> 4.1.1. Header section format >> >> […] >> >> OPCODE A four bit field that specifies kind of query in this >> message. This value is set by the originator of a query >> and copied into the response. The values are: >> >> 0 a standard query (QUERY) >> […] >> >> RCODE Response code - this 4 bit field is set as part of >> responses. The values have the following >> interpretation: >> […] >> 4 Not Implemented - The name server does >> not support the requested kind of query. >> […] >> >> That is, OPCODE specifies the "kind of query", and NOTIMP indicates that >> the "kind of query" (= OPCODE) isn't supported. > > Thanks, this is very helpful! Adding in a little more from RFC 1035: > > > QTYPE a two octet code which specifies the type of the query. > The values for this field include all codes valid for a > TYPE field, together with some more general codes which > can match more than one type of RR. > > So I take it the distinction is that QTYPE represents the "type of" the > query, while OPCODE represents the "kind of" the query, and since RCODE > refers to "kind of" it only affects OPCODE? I can sort of see the > distinction, but since "type of" and "kind of" have almost identical > colloquial meanings I'm surprised that the distinction is not called out > in more detail. Well, the spec is from 1987. Even the meaning of MUST/SHOULD etc. was not standardized yet back then ... Anyway, I will try to give you some examples to help you understand this: Imagine that term "query" in OPCODE decription refers to "type of request", i.e. the term "query" here means "packet sent to server". In other words, OPCODE affects semantics of the DNS message. Exaple: One of OPCODEs is UPDATE which modifies data on authoritative server. RCODE=NOTIMP is suitable e.g. for situation when a resolver got UPDATE request etc. I.e. the resolver is replying with "I have no idea what you operation are requesting from me". On the other hand, RR type in general do not affect message semantics, so there is no reason to return NOTIMP based on RR type. I hope it helps. -- Petr Špaček @ CZ.NIC
Re: private ipv6 address space
Le mercredi 2 août 2017, 08:46:31 CEST W.C.A. Wijngaards via Unbound-users a écrit : > Hi, > > Also, > local-zone: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." nodefault > has to be d.f.ip6.arpa nodefault, to disable the default zone that is > upwards from your private zone. > > Best regards, Wouter > > On 01/08/17 18:29, Eric Luehrsen via Unbound-users wrote: > > dnsmasq is a forwarding resolver and you need "forward" clauses instead > > of "stub" clauses. As you know its similar user configuration syntax, > > but different communication behaviors. "Stub" is a short cut to an > > authoritative server. Also, dnsmasq compiled with authoritative > > conditional compile options can pretend but it has limited function. > > > > On 08/01/2017 04:16 AM, Stephane Guedon via Unbound-users wrote: > >> Good (insert your locale time of the day) all members of this list. I > >> have a trouble with my instance of Unbound (OpenBSD 6.1 stable) with > >> private ipv6 space. I have a local dns resolver/cache (Dnsmasq) which > >> works perfect on my router. The Unbound instance is supposed to > >> redirect all dns requests regarding private domains and address space > >> to it: private-address: fd00:2016:22::/48 access-control: ::0/0 refuse > >> access-control: ::1/128 allow access-control: fd00:2016:22::/48 allow > >> local-zone: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." nodefault > >> domain-insecure: "22decembre.eu." domain-insecure: "22december.dk." > >> > >> domain-insecure: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." stub-zone: > >>name: "22decembre.eu."stub-addr: "fd00:2016:22:dec::1" > >> > >> stub-zone:name: "22december.dk."stub-addr: > >> "fd00:2016:22:dec::1" stub-zone:name: "d.f.ip6.arpa." > >> > >>stub-addr: "fd00:2016:22:dec::1" stub-zone:name: > >> "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa."stub-addr: > >> "fd00:2016:22:dec::1" > >> > >> #domain-insecure: "6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa." #local-zone: > >> "6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa." stub-zone:name: > >>"6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa."stub-addr: > >> "fd00:2016:22:dec::1" > >> > >> (In the begining - aka before two days ago - I used forward zones > >> pointing at fd00:2016:22:dec::1 aka dnsmasq and the whole thing worked > >> smoothly as intended. It does not anymore and I tried to upgrade my > >> conf according to the manual and my understanding is that this conf' > >> is supposed to be done with stub-zones.) > >> > >> > >> > >> But apparently, whenever I send request on 22decembre.eu or > >> 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. I get blocked : ; <<>> DiG 9.4.2-P2 > >> <<>> @unbound mirror.22decembre.eu ; (2 servers found) ;; global > >> options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > >> status: NOERROR, id: 6329 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > >> AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: > >> ;mirror.22decembre.eu. IN A ;; Query time: 3 msec ;; > >> SERVER: fd00:2016:22:dec::3#53(fd00:2016:22:dec::3) ;; WHEN: Tue Aug > >> > >> 1 10:10:01 2017 ;; MSG SIZE rcvd: 38 > >> > >> stephane@blackblock:/home/stephane dig -t ptr @unbound > >> 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. ; <<>> DiG 9.4.2-P2 <<>> -t ptr > >> @unbound 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. ; (1 server found) ;; > >> global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: > >> QUERY, status: NXDOMAIN, id: 46873 ;; flags: qr aa rd ra; QUERY: 1, > >> ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: > >> ;2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. IN PTR ;; AUTHORITY SECTION: > >> d.f.ip6.arpa. 10800 IN SOA localhost. > >> nobody.invalid. 1 3600 1200 604800 10800 > >> > >> Can anyone tell me what mistake(s) I make ? Thank you in advance. I answer in order to give the solution to those in need, as I found it. I needed to have : private-domain: "22decembre.eu." So my domain can have private address (10.0.0.0/8 and fd00:2016...). signature.asc Description: This is a digitally signed message part.
Re: Oddity with nsd-based in-addr.arpa zone
Hi Dave, What must be happening is that your authority server for the combine 192.168 stub clause, does not actually host a 192.168 reverse zone. And that causes unbound to detect that the delegation is lame. Lameness check only performed for authoritative servers (i.e. stub zones). And now that unbound has classified this server as lame it won't ask any more. What you would need to do is actually host a zone with the name of the stub zone on NSD. In this case 168.192.in-addr.arpa. Put in an empty zonefile (or nearly empty, with no PTR data), for example. This in addition to your other zonefiles for 1.168.192, or 100.168.192 and so on. This makes NSD answer authoritatively (and non-lame) for the zone and thus no lameness for unbound and the stub clause works. Best regards, Wouter On 01/08/17 21:06, Dave Ulrick via Unbound-users wrote: > I'm using Unbound & nsd to provide DNS services on my home LAN. nsd > listens on udp/5053 and acts as authoritative DNS server for a forward > zone (home.du) and a reverse zone (168.192.in-addr.arpa). The forward > zone works well as an Unbound 'stub-zone' but I've run into some > strangeness with the reverse zone. > > Most of my IPs are in 192.168.1.x but I have a few IPs in other > 192.168.x.x subnets: 192.168.56.x and 192.168.100.x in particular. > > Assuming that I have this statement in unbound.conf: > > local-zone: "168.192.in-addr.arpa." nodefault > > I get good resolver performance if I create separate nsd zones for: > > 1.168.192.in-addr.arpa > 56.168.192.in-addr.arpa > 100.168.192.in-addr.arpa > > which are defined like this in nsd.conf: > > zone: > name: "1.168.192.in-addr.arpa" > zonefile: "1.168.192.in-addr.arpa.zone" > > and define them to Unbound like so: > > stub-zone: > name: "1.168.192.in-addr.arpa" > stub-addr: 192.168.1.5@5053 > > stub-zone: > name: "56.168.192.in-addr.arpa" > stub-addr: 192.168.1.5@5053 > > stub-zone: > name: "100.168.192.in-addr.arpa" > stub-addr: 192.168.1.5@5053 > > but given that my DNS setup is so small I'd really rather just have one > reverse zone: > > 168.192.in-addr.arpa > > defined in nsd like: > > zone: > name: "168.192.in-addr.arpa" > zonefile: "168.192.in-addr.arpa.zone" > > This consolidated zone is structured thusly: > > $TTL 3D > @SOA... > NS... > NS... > > $ORIGIN 1.168.192.in-addr.arpa. > 1PTR... > ... > > $ORIGIN 56.168.192.in-addr.arpa. > 1PTR... > ... > > $ORIGIN 100.168.192.in-addr.arpa. > 1PTR... > ... > > Given this consolidated zone, nsd promptly answers queries that are > directly sent to it such as with 'nslookup -port=5053 - 0.0.0.0'. > However, if I configure the zone in unbound.conf like this: > > stub-zone: > name: "168.192.in-addr.arpa" > stub-addr: 192.168.1.5@5053 > > the queries are _not_ resolved. However, if I define the zone as a > forward-zone it works perfectly (all queries are replied to either > positively or negatively in a prompt manner): > > forward-zone: > name: "168.192.in-addr.arpa" > forward-addr: 192.168.1.5@5053 > > Note that adding the trailing '.' to the zone name in the Unbound or nsd > configuration files appears to have no functional or performance effect. > (Of course, the zone files themselves _do_ use trailing '.' at the end > of each name.) > > My understanding is that a 'stub-zone' is to be used for authoritative > zones whereas a 'forward-zone' is to be used if recursive lookups might > occur. Given that nsd is purely an authoritative DNS server, it doesn't > make sense that I'd get bad results with 'stub-zone' but good results > with a 'forward-zone'. In fact, using a 'forward-zone' for an nsd-hosted > zone doesn't make any sense at all! > > An Internet search reveals that many others have had issues with > configuring reverse zones but nobody seems to have ended up with my > exact configuration. Therefore, I thought I ought to run this by the > Unbound experts to see if you can shed any light on this. > > Thanks, > Dave signature.asc Description: OpenPGP digital signature
Re: private ipv6 address space
Hi, Also, local-zone: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." nodefault has to be d.f.ip6.arpa nodefault, to disable the default zone that is upwards from your private zone. Best regards, Wouter On 01/08/17 18:29, Eric Luehrsen via Unbound-users wrote: > dnsmasq is a forwarding resolver and you need "forward" clauses instead > of "stub" clauses. As you know its similar user configuration syntax, > but different communication behaviors. "Stub" is a short cut to an > authoritative server. Also, dnsmasq compiled with authoritative > conditional compile options can pretend but it has limited function. > > > On 08/01/2017 04:16 AM, Stephane Guedon via Unbound-users wrote: >> >> Good (insert your locale time of the day) all members of this list. I >> have a trouble with my instance of Unbound (OpenBSD 6.1 stable) with >> private ipv6 space. I have a local dns resolver/cache (Dnsmasq) which >> works perfect on my router. The Unbound instance is supposed to >> redirect all dns requests regarding private domains and address space >> to it: private-address: fd00:2016:22::/48 access-control: ::0/0 refuse >> access-control: ::1/128 allow access-control: fd00:2016:22::/48 allow >> local-zone: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." nodefault >> domain-insecure: "22decembre.eu." domain-insecure: "22december.dk." >> domain-insecure: "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa." stub-zone: >>name: "22decembre.eu."stub-addr: "fd00:2016:22:dec::1" >> stub-zone:name: "22december.dk."stub-addr: >> "fd00:2016:22:dec::1" stub-zone:name: "d.f.ip6.arpa." >>stub-addr: "fd00:2016:22:dec::1" stub-zone:name: >> "2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa."stub-addr: >> "fd00:2016:22:dec::1" >> >> #domain-insecure: "6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa." #local-zone: >> "6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa." stub-zone:name: >>"6.7.5.1.0.0.0.4.6.0.a.2.ip6.arpa."stub-addr: >> "fd00:2016:22:dec::1" >> >> (In the begining - aka before two days ago - I used forward zones >> pointing at fd00:2016:22:dec::1 aka dnsmasq and the whole thing worked >> smoothly as intended. It does not anymore and I tried to upgrade my >> conf according to the manual and my understanding is that this conf' >> is supposed to be done with stub-zones.) >> >> >> >> But apparently, whenever I send request on 22decembre.eu or >> 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. I get blocked : ; <<>> DiG 9.4.2-P2 >> <<>> @unbound mirror.22decembre.eu ; (2 servers found) ;; global >> options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, >> status: NOERROR, id: 6329 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, >> AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: >> ;mirror.22decembre.eu. IN A ;; Query time: 3 msec ;; >> SERVER: fd00:2016:22:dec::3#53(fd00:2016:22:dec::3) ;; WHEN: Tue Aug >> 1 10:10:01 2017 ;; MSG SIZE rcvd: 38 >> stephane@blackblock:/home/stephane dig -t ptr @unbound >> 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. ; <<>> DiG 9.4.2-P2 <<>> -t ptr >> @unbound 2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. ; (1 server found) ;; >> global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: >> QUERY, status: NXDOMAIN, id: 46873 ;; flags: qr aa rd ra; QUERY: 1, >> ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: >> ;2.2.0.0.6.1.0.2.0.0.d.f.ip6.arpa. IN PTR ;; AUTHORITY SECTION: >> d.f.ip6.arpa. 10800 IN SOA localhost. >> nobody.invalid. 1 3600 1200 604800 10800 >> >> Can anyone tell me what mistake(s) I make ? Thank you in advance. >> > signature.asc Description: OpenPGP digital signature
