RE: How to validate DNSSEC signed record with dig?
Spain, Dr. Jeffry A. wrote: > > Checking your two name servers, 8.8.8.8 (google-public-dns-a.google.com) > doesn't appear to offer DNSSEC validation, and 78.46.213.227 > (rms.coozila.com) doesn't respond to my query at all. It's worse than that. Google Public DNS doesn't support DNSSEC at all, so you cannot use it to query DNSSEC records. DNSSEC requires resolvers to handle RRSIG and DS records in special ways even if they are not validating the signatures. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Utsire, South Utsire: Cyclonic mainly southerly or southeasterly, 5 to 7, occasionally gale 8 in east at first. Rough. Rain or snow. Moderate or poor. ___ 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: Same Transaction ID queries
Samer Khattab wrote: > What is BIND internal logic when such a series of queries are received, and > why it would not answer to all requests. Each query in progress from a given client must have a different ID, so queries with the same ID are logically the same query which only needs one reply. The usual situations in which this occurs are timeouts and retries. Tony. -- f.anthony.n.finchhttp://dotat.at/ East Sole: Northwesterly 4 or 5, becoming variable 4. Moderate or rough. Occasional rain. Moderate occasionally poor. ___ 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: How to validate DNSSEC signed record with dig?
William Thierry SAMEN wrote: > > I'm triying to sign a zone on Bind 9.8-P1 but i have this message: > > *dnssec-signzone: fatal: key myKSK.key not at origin* It means the zone name in the key is not the same as the zone you are signing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall, Malin, Hebrides, Bailey: Southerly 6 to gale 8, occasionally severe gale 9 except in Malin, veering northwesterly 4 or 5 for a time except in Malin and east Hebrides. Very rough, occasionally high except in Malin. Occasional rain. Moderate or poor. ___ 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: How to validate DNSSEC signed record with dig?
William Thierry SAMEN wrote: > > My file zone: Er this looks like a key file, not a zone file. The key has been generated incorrectly: it has a file name where the zone name should be. > ; This is a zone-signing key, keyid 12762, for *../etc/toto.com.* > ; Created: 20120207101131 (Tue Feb 7 11:11:31 2012) > ; Publish: 20120207101131 (Tue Feb 7 11:11:31 2012) > ; Activate: 20120207101131 (Tue Feb 7 11:11:31 2012) > *../etc/toto.com*. IN DNSKEY 256 3 5 > AwEAAbpc1rBsrB3XrOlUAE1Xxfyef9POsH8jypLVImuBPEGgE Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Southerly 5 to 7, occasionally gale 8 in Viking. Rough, becoming very rough in Viking. Rain later. Good, becoming moderate later. ___ 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: How to validate DNSSEC signed record with dig?
William Thierry SAMEN wrote: > > dnssec-signzone: error: dns_master_load: ../etc/toto.com:12: toto.com: not at > top of zone > dnssec-signzone: fatal: failed loading zone from '../etc/toto.com': not at > top of zone This is because your zone uses an include directive to import the key files, and keys were generated incorrectly: they have file names where the zone name should be. Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Southerly or southwesterly 4 or 5, increasing 6 to gale 8 for a time in north and west. Very rough or high. Showers. Good, occasionally poor. ___ 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: PLEASE READ: An Important Security Announcement from ISC
Chris Thompson wrote: > > More directly, http://www.cs.indiana.edu/classes/b649-gupt/kangLiNDSS12.pdf > > This is definitely worth reading, being an interesting new twist on a > fairly old theme. Paul Vixie was trying to do something about risks in this area a couple of years ago: http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 Tony. -- f.anthony.n.finchhttp://dotat.at/ Northwest FitzRoy: Southerly 4 or 5. Moderate or rough. Occasional rain or drizzle. Good, occasionally poor. ___ 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: DNSSEC and CVE-2012-1033 (Ghost domain names)
Florian Weimer wrote: > > Doesn't the DNSSEC-based mitigation rely on RRSIGs whose validity does > not extend too far into the future? It depends on the TTL of the DS record or its proof of nonexistence. Tony. -- f.anthony.n.finchhttp://dotat.at/ North FitzRoy, Sole: Northerly or northwesterly 5 to 7. Moderate becoming rough. Occasional drizzle. Good, occasionally moderate. ___ 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: block ddns by name
Melbinger Christian wrote:
>
> Does anyone know if there is a way to prevent the creation of certain
> records - by name?
http://ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
Based on that, something the following should do what you want:
update-policy {
deny "*" name "internal.example.com";
# ...
};
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Shannon: Westerly or southwesterly 5 or 6, but 4 until later in far south.
Moderate or rough. Occasional rain or drizzle. Moderate or good.
___
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: A few conceptual question about dnssec.
dE . wrote: > Firstly, where do we get the public key for the DS records? A zone's DNSKEY RRset contains its public keys, and these are hashed to make its DS records. For example, $ dig +nottl +noall +answer DS isc.org | perl -pe 's/\s+(?!$)/ /g' isc.org. IN DS 12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759 isc.org. IN DS 12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5 $ dig DNSKEY isc.org | dnssec-dsfromkey -f /dev/stdin isc.org isc.org. IN DS 12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759 isc.org. IN DS 12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5 > Why do I get multiple RRSIG records from some servers? - When you ask a GTLD server for the yahoo.com delegation NS records, you also get two NSEC3 records that bracket the yahoo.com delegation to prove it is insecure (no DS record), and an RRSIG record for each NSEC3 record. > Do we get a RRSIG for each RR retrieved? No, one per RRset, where an RRset is all the records with the same name, class, and type. > Lastly, what's the format for the output dis DNSSEC records? See RFC 4034. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall, Malin, Hebrides, Bailey: Southwest, veering northwest, 6 to gale 8, occasionally severe gale 9, except in Shannon and Malin. Very rough or high, occasionally very high in Rockall and Bailey, but rough at first in Shannon. Rain then squally snow showers. Moderate, occasionally poor. ___ 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: A few conceptual question about dnssec.
dE . wrote: > > Ok, so the DS record is not encrypted. DNSSEC is about signatures: nothing is encrypted. DS records are signed: a DS RRset has an RRSIG. For example, ; <<>> DiG 9.8.1-P1 <<>> +multi +dnssec DS isc.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53813 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;isc.org. IN DS ;; ANSWER SECTION: isc.org.86382 IN DS 12892 5 1 ( 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759 ) isc.org.86382 IN DS 12892 5 2 ( F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F 0EB5C777586DE18DA6B5 ) isc.org.86382 IN RRSIG DS 7 2 86400 20120309160141 ( 20120217150141 55440 org. SHpqmMeBQAyBB5LgBcrR5FcZiWiEudop/fl7X1xgz31X G4vFFQzq57RIq0hUkWZ0dR5oBCpRC15osOXSZEwVuz3L XXUd63GpI5aoGv/OtyPI/w4YTedgweoE9PWovcx6Ahr2 WonckP2YqTsHqzxwr+VSiiMFMe2VVquTo4/vEjE= ) ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Feb 20 12:33:26 2012 ;; MSG SIZE rcvd: 283 Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight, Portland, Plymouth: Southwesterly 4 or 5, increasing 6 or 7 later. Slight becoming moderate. Mainly fair. Mainly good. ___ 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: RFC 6303 and bind 9.9.0
Spain, Dr. Jeffry A. wrote: > Which of these alternative empty zones should be used in the current DNS > environment and why? In my named.conf I have set up empty zones for the whole of 240/4. I view RFC 6303 as the minimum necessary for a hygienic name server, but there are a number of other permanent bogon address ranges which it makes sense to stub out locally. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher: West or southwest, veering east or northeast, 4 or 5, decreasing 3 at times. Slight or moderate. Fog patches. Moderate, occasionally very poor. ___ 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: RFC 6303 and bind 9.9.0
Spain, Dr. Jeffry A. wrote:
>
> Would you please elaborate on how you are managing your bogon-related
> empty zones.
I have bogon declarations and empty zones for all the ranges listed in RFC
5735 except 224.0.0.0/4 which only has a bogon declaration. (The multicast
addresses shouldn't be used for DNS traffic but they do have public
reverse DNS zones.)
The IPv6 RFCs are less straightforward. I have bogon declarations and
empty zones for the following ranges. Perhaps I should add 6to4...
server ::/3{ bogus yes; };
server 2001:0010::/28 { bogus yes; };
server 2001:0db8::/32 { bogus yes; };
server 3000::/4{ bogus yes; };
server 4000::/2{ bogus yes; };
server 8000::/1{ bogus yes; };
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Southwest Forties, Cromarty, Forth: Southeasterly 4 or 5, increasing 6 or 7.
Slight becoming moderate. Fog patches, rain later. Moderate or good,
occasionally very poor.
___
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: Restricting access & keeping identical data across views
Jon A. wrote: > Is there a better practice to serve 100% the same authoritative data > in two views, but block recursion, cache use, and out of zone data? Don't use views, use allow-query and allow-recursion ACLs. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth, Biscay, FitzRoy: Northerly or northeasterly 4 or 5, occasionally 6 in south Fitzroy. Slight or moderate, occasionally rough later in south Fitzroy. Fair. Moderate or good. ___ 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
[ANN] ndsiff 1.39 - create nsupdate script from master file changes
nsdiff is a small perl program that examines old and new versions of a DNS zone and outputs the differences as a script for use by BIND's nsupdate program. It bridges the gap between static master files and dynamic updates. I have published version 1.39 which has a new -q quiet / quick check option, more consistent exit status, and better documentation. http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/conf/bind/bin/nsdiff Tony. -- f.anthony.n.finchhttp://dotat.at/ Southwest German Bight, East Humber: Easterly or southeasterly 5 to 7, decreasing mainly 4 or 5. Moderate or rough. Rain or showers. Moderate or good. ___ 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: Exclude a domain from DNSSEC validation, like Unbound's "domain-insecure".
Jan-Piet Mens wrote: > > From a Comcast talk at SATIN 2012 I believe they called that a "negative > trust anchor", and IIRC, the author wanted to publish a draft of its > operation. http://tools.ietf.org/html/draft-livingood-negative-trust-anchors There has been a lot of discussion on the IETF dnsop working group mailing list: http://www.ietf.org/mail-archive/web/dnsop/current/threads.html Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber: Southwest 5 to 7, becoming variable 3 or 4, then northeast 4 or 5 later in Humber. Moderate or rough, becoming slight or moderate later. Occasional rain. Moderate or good. ___ 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: Question about KSK
wbr...@e1b.org wrote: > We are authoritative for a few dozen small zones. Is it possible to use > the same KSK for all of them? I can see where if it gets compromised we > would need to resign all zones using the KSK at once. How much effort > would I be saving sharing the KSK? With BIND it is much easier not to share keys - the easy-to-use signing features (auto-dnssec maintain and dnssec-signzone -S) rely on key filenames that contain the zone name. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forth, Tyne, Dogger, Northwest Fisher: Northwesterly, veering northeasterly, 4 or 5, occasionally 6 in Dogger. Slight or moderate, occasionally rough at first. Showers. Good. ___ 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: Convice Bind to listen on IP alias with a range of IPs.
Augie Schwer wrote: > > I have a range of IPs bound to a local interface: > > lo:1 Link encap:Local Loopback > inet addr:10.0.0.1 Mask:255.255.255.224 > > And I want to convince Bind to listen on sub-set of the given range ( > 10.0.0.2 for example ) You can't do that without hacking the network stack, as far as I know. See for instance this rather old FreeBSD patch. Note that even this doesn't quite do what you want since it doesn't allow you to bind to a subset of a CIDR range configured on an interface. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/12071 Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: North or northeast 3 or 4, occasionally 5. Slight or moderate. Fair. Moderate or good. ___ 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: dynamic update to SOA records
cloud cache wrote: > > How to use nsupdate to dynamic update the SOA records? > For example, I want to update the zone's contact email and main NS server > name. Like this: $ dig +noall +answer soa fanf2.ucam.org fanf2.ucam.org. 3600IN SOA black.dotat.at. dot.dotat.at. 40 3600 600 604800 60 $ nsupdate -l > update add fanf2.ucam.org 3600 soa black.csi.cam.ac.uk fanf2.cam.ac.uk 41 > 3600 600 604800 60 > send > quit $ dig +noall +answer soa fanf2.ucam.org fanf2.ucam.org. 3600IN SOA black.csi.cam.ac.uk. fanf2.cam.ac.uk. 41 3600 600 604800 60 $ Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: South backing east, 5 to 7. Moderate or rough, becoming slight or moderate. Thundery showers. Moderate or good. ___ 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: dynamic update to SOA records
Chris Thompson wrote: > Our regular DNS changes (via [scripted] nsupdate) always add the SOA > explicitly (it's going to change anyway, after all), setting the serial > to the Unix time(2) value. BIND may have been incrementing the serial > itself as a result of re-signing activity, but we assume it hasn't > been doing so as often as once a second... My nsdiff script can set the serial number to unix time or MMDDNN; if that's too small it falls back to increment mode. There's still a bug, though: lack of support for proper modulo semantics :-) It also uses the SOA record as an update prerequisite for detecting races and other inconsistencies. (The system Chris is responsible for uses an HINFO record for this purpose.) http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/conf/bind/bin/nsdiff Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides: North or northeast 4 or 5. Slight or moderate. Fair. Good. ___ 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: Host command timing out sporadically
Lyle Giese wrote: > > Don't use host. It's not telling us what is going wrong and it's only doing > an A record lookup of host name. I agree dig is better for serious debugging, but for a quick check host isn't as bad as you suggest. $ host dotat.at dotat.at has address 212.13.197.229 dotat.at has IPv6 address 2001:ba8:1e3:: dotat.at mail is handled by 1 ppsw-mx-a.csi.cam.ac.uk. $ host nx.dotat.at Host nx.dotat.at not found: 3(NXDOMAIN) $ host bad-delegation.dotat.at ;; connection timed out; no servers could be reached $ Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole: Northeasterly 4 or 5, occasionally 6 until later in west. Moderate or rough, becoming slight or moderate. Fog patches in east, rain later. Moderate or good, occasionally very poor in east. ___ 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: qtype=any messages are cached especially in bind9 resolver?
zhanglikun wrote: > > So my question is why bind9 do like that? QTYPE=ANY is a special debugging facility. It just returns what is in the cache, and only makes a query to the authoritative server when there in nothing cached. Tony. -- f.anthony.n.finchhttp://dotat.at/ Cromarty: Cyclonic becoming northwest, 4 or 5. Slight or moderate. Rain or showers. Moderate or good. ___ 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: DNSSEC
Gaurav Kansal wrote: > DNSSEC is done on Authoritative side. Signing is done on authority servers. It's straightforward with inline-signing mode, or if you maintain your zone with dynamic updates. > Caching DNS only check whether that particular domain is signed or not, > only if that caching DNS is designed to do so. Validation is done on caches. In my experience validation is a pretty untroublesome feature to enable, provided you aren't completely hammering your name servers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides: Northeasterly 4 or 5, increasing 5 to 7 except in northwest. Moderate. Showers. Good. ___ 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: DNSSEC
Barry Margolin wrote: > > [Validation is] only untroublesome until someone screws things up on > their auth server. When one of your users can't access something.gov, > they'll complain to YOU, even though it's mostly out of your hands. > > This is true for other problems on auth servers as well, of course. But > DNSSEC is new enough that there tend to be more failures of this kind, > even by organizations that until now have seemed to know what they're > doing. Some of the early DNSSEC deployments (especially in .gov) did not use good tooling. That's much less of a problem now. See for instance the big DNSSEC deployments in Sweden, Czech, Brazil. Even third party DNSSEC screwups have not caused us much trouble. Tony. -- f.anthony.n.finchhttp://dotat.at/ Faeroes: Northeasterly backing northerly, 4 or 5, increasing 6 or 7 for a time in east. Moderate, becoming rough later in far east. Showers. Good. ___ 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: DNSSEC
wbr...@e1b.org wrote: > > So how do we implement one? Create a separate caching server with DNSSEC > validation turned off and forward all queries for the broken domain to it? That won't work, because a validating server validates replies from a forwarding server. Tony. -- f.anthony.n.finchhttp://dotat.at/ FitzRoy: Northeasterly 5 to 7, occasionally gale 8 in southeast. Moderate or rough, becoming very rough in southeast. Occasional rain. Moderate or good, occasionally poor. ___ 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: Clarification on wildcard falls into glue records
Sam Wilson wrote: > > Is a name on the RHS of an RR regarded as existing enough to prevent > wildcard lookup? No, only RR owner names. > In this I would have expected the NS lookup to be followed by an A > lookup for abc.a.example.com which would match the wildcard, assuming no > other records match that name on the LHS. Yes that should work. The latter answer might appear to be missing because additional section processing is a bit special. In your original question you mentioned glue, which is only necessary for delegations above the zone cut, and probably should not rely on wildcards. If this is a zone apex NS RRset then the server doesn't have to fill in the additional section. See the example below, from a nameserver that has minimal-responses turned on. ; <<>> DiG 9.8.1-P1 <<>> ns dotat.at ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41609 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dotat.at. IN NS ;; ANSWER SECTION: dotat.at. 3600IN NS ns1.gratisdns.dk. dotat.at. 3600IN NS black.dotat.at. dotat.at. 3600IN NS puck.nether.net. dotat.at. 3600IN NS ns3.gratisdns.dk. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 15 15:52:19 2012 ;; MSG SIZE rcvd: 123 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Northwest 5 to 7, occasionally 4 in Forth and Tyne. Moderate or rough, occasionally very rough in Forties and Dogger. Showers. Good, occasionally moderate. ___ 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: Clarification on wildcard falls into glue records
Sam Wilson wrote: > > Not I - another poster. Sorry! Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Northwest 5 to 7, occasionally 4 in Forth and Tyne. Moderate or rough, occasionally very rough in Forties and Dogger. Showers. Good, occasionally moderate. ___ 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: 9.9.1 continues to sign with inactive KSK
Axel Rau wrote: > > The tags of the KSKs with their dates are (set with dnssec-settime): > --- > [framail.de/KSK/1699/8(A:2012-05-23T17:55:02, I:2012-05-27T17:55:02, > D:2012-05-28T17:55:02)] > [framail.de/KSK/46210/8(A:2012-05-20T16:55:03, I:2012-05-24T16:55:03, > D:2012-05-25T16:55:03)] > --- > 46210 is inactive and still used to sign DNSKEYs (from dig +dnssec DNSKEY > framail.de. at 2012-05-25T13:55) : > --- > framail.de. 86400 IN RRSIG DNSKEY 8 2 86400 20120622185603 > 20120523175603 46210 framail.de... > framail.de. 86400 IN RRSIG DNSKEY 8 2 86400 20120623175502 > 20120524165502 1699 framail.de... > --- > Shouln't named have ceased signing keys with this key? The 46210 signature's inception date is 2012-05-23 which is before its key's inactive date 2012-05-24. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: East 3 or 4, becoming cyclonic 4 or 5, occasionally 6 later. Slight or moderate. Fog patches at first. Moderate or good, occasionally very poor at first. ___ 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
SOA TTL in negative answers
Not sure if this is a BIND question or a standards question. I'm experimenting with some stats gathering. To get the zone of a domain name I'm making a SOA query, which will either return a positive answer (if the domain is a zone apex) or a negative answer with the enclosing zone's SOA in the authority section. I noticed that the TTL on the SOA in NXDOMAIN replies is always zero. If I query for a different nonexistent type then the TTL is what I expect. This weirdness doesn't occur for noerror/nodata. $ dig +noall +authority soa nxdomain.dotat.at dotat.at. 0 IN SOA black.dotat.at. dot.dotat.at. 757 3600 600 604800 60 $ dig +noall +authority txt nxdomain.dotat.at dotat.at. 60 IN SOA black.dotat.at. dot.dotat.at. 757 3600 600 604800 60 $ dig +noall +authority soa www.dotat.at dotat.at. 60 IN SOA black.dotat.at. dot.dotat.at. 757 3600 600 604800 60 $ dig +noall +authority txt www.dotat.at dotat.at. 60 IN SOA black.dotat.at. dot.dotat.at. 757 3600 600 604800 60 I note that BIND and NSD behave differently: $ dig +noall +authority soa nxdomain. @f.root-servers.net. . 0 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012060600 1800 900 604800 86400 $ dig +noall +authority soa nxdomain. @l.root-servers.net. . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012060600 1800 900 604800 86400 Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet: Mainly south becoming cyclonic, 4 or 5 increasing 6 to gale 8, occasionally severe gale 9 later. Moderate becoming rough or very rough, occasionally high later in south. Rain. Moderate, occasionally poor. ___ 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: SOA TTL in negative answers
Mark Andrews wrote: > See draft-andrews-soa-discovery-02.txt and zero-no-soa-ttl Thanks! Tony. -- f.anthony.n.finchhttp://dotat.at/ North Irish Sea: Easterly becoming cyclonic later, 5 to 7. Slight or moderate becoming moderate or rough. Occasional rain, fog patches. Moderate, occasionally very poor. ___ 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: Delegation bit-rot detection?
Phil Mayers wrote: > > I'm wondering if anyone knows of a script that will process our logs looking > for "refused" queries, and then post-process these by tracing the delegations > and telling me what the nearest enclosing zone is, the NS records that led > inbound queries to us, and (if any of the other NS records are responding) the > SOA. One possibility is chiark-named-conf. It is oriented towards config file generation, but it also does a lot of sanity checking. http://www.chiark.greenend.org.uk/ucgi/~ian/git?p=chiark-utils.git;a=tree;f=scripts Tony. -- f.anthony.n.finchhttp://dotat.at/ North Bailey, Fair Isle, Faeroes, South-east Iceland: Mainly northerly or northeasterly 3 or 4, increasing 5 at times. Slight or moderate. Showers. Good. ___ 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 ignores changes in zonefiles
Marian Röß wrote: > > That is what bothers me. Even the debug messages show, that a change is > detected and the zone is loaded into the database. Are you running one copy of named on the server? It might be that you have an old instance of the server running and serving the old zone, and a new instance that failed to bind to its listening sockets (since the old server owns them) but which is successfully loading the new zones and logging about it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Biscay: Variable 3, becoming southeasterly 4 or 5 later. Slight or moderate, occasionally rough later. Occasional rain. Moderate or good.___ 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: limiting number of requests of a single hosts
Holemans Wim wrote: > > I have 2 questions, one, is there a way to rate-limit the amount of > request a single client (the AD servers in this case) can have standing > out against a bind server ? Kind of rate-limiting parameter for bind > name server. There isn't a way to do this in BIND. If you are running on Linux you might try the iptables hashlimit module, http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html (The recently announced response rate limiting patch won't work for you since it takes effect too late in the resolution process. http://www.redbarn.org/dns/ratelimits) I'm afraid I don't have an answer to your other question. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth, Northwest Biscay: Southwesterly 5 to 7, occasionally gale 8 in Plymouth. Rough or very rough, occasionally high in west Plymouth. Showers. Good, occasionally poor.___ 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: Moving DNS out of non-cooperative provider
Mark Andrews wrote: > In message <4fdf631a.4060...@brandeis.edu>, John Miller writes: > > > > We've actually run into this before. Once upon a time, RCN cable used > > to run some slave servers for us, but we've long since moved away from > > them, including zone transfers. We yanked them from our registrar a > > long time ago, and life was good. For whatever reason, RCN's still > > answering queries for brandeis.edu. > > And if there is another zone with a CNAME to a brandeis.edu domain > on those servers the clients will be getting old data. As you have > no control over creation of CNAMEs in other zones I would suggest > that you send them a Cease and Decist notice if they are still doing > it. Here's a tip for anyone running an open DNS hosting service: you can use "additional-from-auth no; additional-from-cache no;" to reduce problems of this kind. Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight: Variable 3 or 4. Smooth or slight. Fair. Moderate or good. ___ 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: Seeking Advice on DNSSEC Algorithm Rollover
Spain, Dr. Jeffry A. wrote: > > My experience with changing the timing metadata or removing the key > files is that named issues a warning like the following: zone /IN: > Key // missing or inactive and has no > replacement: retaining signatures. In this circumstance none of the > RRSIGs or NSECs are removed. They sit there indefinitely even after the > RRSIGs expire. If I remember correctly, that was because you removed the keyfile rather than just updating the timing metadata. Try updating the timing data and leaving the keyfiles in place until after BIND has acted on the deletion date. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties: Northwesterly 4 or 5, occasionally 6 in east. Slight or moderate, occasionally rough later. Mainly fair. Moderate or good. ___ 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: Understanding cause of DNS format error (FORMERR)
It looks to me like this is an EDNS bug. I am querying the authoritative server directly, with no firewalls in the way. The FORMERR is coming from the authoritative server not from BIND. I get the same result over IPv4 and IPv6. They also have a bug in their NXDOMAIN logic: extranet.microsoft.com does not exist therefore partners.extranet.microsoft.com cannot exist. ; <<>> DiG 9.9.1-P1 <<>> +noedns @ns1.msft.net. partners.extranet.microsoft.com ns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9931 ;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; ANSWER SECTION: partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com. ;; ADDITIONAL SECTION: dns12.one.microsoft.com. 3600 IN A 207.46.55.10 dns10.one.microsoft.com. 3600 IN A 131.107.125.65 dns13.one.microsoft.com. 3600 IN A 65.55.31.17 dns11.one.microsoft.com. 3600 IN A 94.245.124.49 ;; Query time: 159 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Mon Jun 25 12:38:51 2012 ;; MSG SIZE rcvd: 197 ; <<>> DiG 9.9.1-P1 <<>> +edns=0 @ns1.msft.net. partners.extranet.microsoft.com ns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20875 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Query time: 142 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Mon Jun 25 12:38:57 2012 ;; MSG SIZE rcvd: 60 ; <<>> DiG 9.9.1-P1 <<>> +noedns @ns1.msft.net extranet.microsoft.com ns ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 141 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;extranet.microsoft.com.IN NS ;; AUTHORITY SECTION: microsoft.com. 3600IN SOA ns1.msft.net. msnhst.microsoft.com. 2012062205 300 600 2419200 3600 ;; Query time: 142 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Mon Jun 25 12:44:44 2012 ;; MSG SIZE rcvd: 95 Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet: Southeast at first in Lundy and Fastnet, otherwise southwest, 4 or 5. Slight or moderate, occasionally rough in west Sole. Occasional rain or drizzle, fog patches. Moderate, occasionally very poor. ___ 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: Understanding cause of DNS format error (FORMERR)
Carsten Strotmann (private) wrote: > > The FORMERR I'm seeing is also quite odd, as it has the "AD" flag set, > which should normally not appear in an error type of response, but > might be caused by a mangled DNS packet: I think it is echoing the AD bit in the query. ; <<>> DiG 9.9.1-P1 <<>> +noad +qr @ns1.msft.net. partners.extranet.microsoft.com ns ; (2 servers found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3331 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 3331 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Query time: 142 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Mon Jun 25 12:57:06 2012 ;; MSG SIZE rcvd: 60 ; <<>> DiG 9.9.1-P1 <<>> +qr @ns1.msft.net. partners.extranet.microsoft.com ns ; (2 servers found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21060 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 21060 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Query time: 142 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Mon Jun 25 12:56:22 2012 ;; MSG SIZE rcvd: 60 Tony. -- f.anthony.n.finchhttp://dotat.at/ Dogger: Northwest 5 or 6 becoming variable 3 or 4. Moderate, becoming slight in west. Showers. Moderate or good. ___ 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: prevent DNS attack
pangj wrote: > > DNS is very easy to be attacked. > My named service got 1G or more traffic of attack some time. > How can we take some steps to prevent them? Incoming or outgoing? A number of people have been having this problem recently. You might want to join the dns-operations list: https://lists.dns-oarc.net/mailman/listinfo/dns-operations/ There has been much discussion of DDoS attacks this month and you can read the messages in the list archives. There is also a patch for BIND which can help: http://www.redbarn.org/dns/ratelimits Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames, Dover: Southwest backing southeast 4 or 5. Slight or moderate. Occasional rain, fog patches. Moderate, occasionally very poor. ___ 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: A lot of queries from a customer.
Rafael Molina wrote: > > I don´t find the ways to limit of queries per minutes on this customer > > Is it possible in Bind9 a filtering these queries, to limit the responses ? There is a patch for BIND which can help: http://www.redbarn.org/dns/ratelimits Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames, Dover: Southeast 4 or 5 veering southwest 5 or 6. Mainly moderate. Thundery showers, fog patches at first. Moderate, occasionally very poor, becoming good.___ 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: Corrupt zone transfer
Danny Horne wrote: > > I currently run two Bind 9.9.* nameservers (details below), I've just > added a slave zone to the Windows one, the Linux one being the master. > The zone transferred, however, seems to be corrupt in that when opened > in Notepad it contains what I can only describe as gobbledegook. BIND 9.9 stores slave zones in raw format by default. You can get a standard textual version using named-compilezone -j -f raw -o outfile zonename infile Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger, Fisher: South or southwest 5 to 7, decreasing 4 at times later. Moderate or rough. Showers. Good, occasionally moderate.___ 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, DNSSEC & AD
Marc Lampo wrote: > > you are aware that Windows DNS service understands DNSSEC algorithm 5 > (RSA/SHA-1 – NSEC) at most ? Carsten Strotmann's post says Windows Server 2012 fixes this limitation http://strotmann.de/roller/dnsworkshop/entry/dnssec_validation_in_microsoft_dns Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire: Southwesterly, backing southeasterly 4 or 5, occasionally 6 at first in Viking. Moderate. Rain or showers. Moderate or good.___ 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: getting edns disabling message in logs
Ben wrote: > > We run bind as caching only dns server for our customers. In logs, i can > see so many entries which tells > > success resolving 'x.y.z/A' (in '.'?) after disabling EDNS > > How to check that current bind installation has EDNS enabled or ? > what could be reason behind it? BIND has EDNS enabled by default. These log messages indicate that BIND is trying and failing to make EDNS queries. This is usually caused by a misconfigured firewall between the name server and the rest of the Internet. Tony. -- f.anthony.n.finchhttp://dotat.at/ FitzRoy: Southwesterly veering northwesterly 4 or 5, occasionally 6 later in northwest. Moderate, becoming rough in northwest. Rain then showers. Moderate or good, occasionally poor at first in north. ___ 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: getting edns disabling message in logs
Cathy Almond wrote: > > https://kb.isc.org/article/AA-00708/55/Why-does-BIND-log-messages-about-disabling-EDNS-or-reducing-the-advertised-packet-size > > (Just created, so apologies if there are any typos or other editorial > corrections needed - they will happen later) I suggest "middlebox" since "middleware" usually means something like a horrific enterprisey web services message bus framework. > > Is there any way that we can show that current disabling EDNS happens by > > firewall issue ? > > That's a bit tricky, if what's broken is not in your network space. On > the other hand, if you're getting this reported for every domain that is > queried, then it's probably *your* problem. Try the DNS-OARC reply size test server. https://www.dns-oarc.net/oarc/services/replysizetest/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Westerly or southwesterly 4 or 5, occasionally 6 later in southwest. Moderate, becoming rough later in west. Rain or thundery showers. Moderate or good. ___ 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: Query about mirroring Root DNS Server
Gaurav Kansal wrote: > > Somewhere I heard that one of the Root Servers allows you to take a zone > copy of that, so that if you want to look and feel about Root DNS > servers, you can do so. > > Is it true? If yes then can anyone please guide me which Root DNS Server > is allowing for the same? You can find out for yourself (see below). I usually use the F root since I know the ISC has a long-term policy of allowing zone transfers. Some people like to slave the root zone on their recursive servers instead of using the root zone hints. This is not the same as looking or feeling like a root server. If you want to actually look and feel like a root server, talk to ICANN who are very liberal in allowing sites to host instances of the L root. http://blog.icann.org/2012/03/l-root-in-your-pocket/ http://dns.icann.org/lroot/infocollect/ $ for i in `jot -c 13 97`; do echo === $i; dig axfr . @$i.root-servers.net | grep failed; done === a ; Transfer failed. === b === c === d ; Transfer failed. === e ; Transfer failed. === f === g === h ; Transfer failed. === i ; Transfer failed. === j ; Transfer failed. === k === l ; Transfer failed. === m ; Transfer failed. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking: Northeasterly 4 or 5, increasing 6 or 7 later in northwest. Slight or moderate, becoming rough later in north. Fair. Moderate or good. ___ 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: OpenSSL problem: bind98-base FreeBSD port
On 9 Jul 2012, at 20:05, Matthew Pounsett wrote: > On 2012/07/08, at 22:25, Barry Margolin wrote: >> In article >> >>> So to answer my earlier question, what file were you talking about copying >>> into the chroot environment for BIND? >> >> The shared library. When you link dynamically, all the libraries have to >> be in $chroot/usr/lib. > > No, they don't. Shared libraries are picked up at runtime. Chrooting happens > after that, once the libraries have already been read. Except that GOST is implemented as an "engine" which is dynamically loaded after startup. Called lib/engines/libgost.so I seem to remember that early versions of BIND's GOST support could not be disabled by the configure script - my build script hacked BIND's Makefile to disable it rather than put code in the chroot. Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ 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: already exists previous definition
On 20 Jul 2012, at 21:40, Active Venture - Tom wrote: > > 20-Jul-2012 15:26:40.181 config: error: > /var/named/etc/namedb/conf/zone_0.conf:1529: zone 'x.net': already exists > previous definition: /var/named/etc/namedb/conf/zone_0.conf:1529 > 20-Jul-2012 15:26:46.270 general: error: reloading configuration failed: > failure > > The puzzling aspect is, there is NO duplicated config or zone entries at all > for the domains listed in such error. Are there any duplicate include directives? Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ 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: DNSSEC troubles (no valid NSEC) ?
Frantisek Hanzlik wrote: > ; <<>> DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 <<>> @localhost -t MX br.ds.mfcr.cz > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43325 > Problem will be perhaps something with DNSSEC. What is interesting, > BIND v9.9.1, essentially with the same configuration > queried MX records solve without problems. > It is older version BIND problem? Either that, or RedHat's patches are broken. Tony. -- f.anthony.n.finchhttp://dotat.at/ Cromarty, Forth, Tyne, Dogger: Variable, becoming southeast 3 or 4, occasionally 5 in Cromarty. Smooth or slight. Mainly fair, showers and fog patches developing later. Moderate or good, occasionally very poor later. ___ 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: Dig 9.9.1 AD-bit
On 3 Aug 2012, at 02:25, "Marco Davids (SIDN)" wrote: > Dig 9.9.1 is setting the AD-bit in queries by default. > Does anyone know why? It means "I want the results of DNSSEC validation but not all the RRSIG and NSEC records I would get from DO=1." Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ 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
dnssec-verify and dnssec-dnskey-kskonly
Playing around with dnssec-verify: $ dig axfr dotat.at | dnssec-verify -o dotat.at /dev/stdin Loading zone 'dotat.at' from file '/dev/stdin' Verifying the zone using the following algorithms: RSASHA1. Zone fully signed: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked OK. But the manual says: -x Only verify that the DNSKEY RRset is signed with key-signing keys. Without this flag, it is assumed that the DNSKEY RRset will be signed by all active keys. When this flag is set, it will not be an error if the DNSKEY RRset is not signed by zone-signing keys. This corresponds to the -x option in dnssec-signzone. And my zone has only one RRSIG on its DNSKEY RRset: ; <<>> DiG 9.9.2b1 <<>> +dnssec +multiline dnskey dotat.at ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4260 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dotat.at. IN DNSKEY ;; ANSWER SECTION: dotat.at. 3600 IN DNSKEY 256 3 5 ( AwEAAczBisQAJbGom5SzZHxr7j/ddJBsoxuchn4Ki+Xl NASArKXs46UbXWbXZitymfv4F6wkY8mEErgEs4qil5Im p9zv7qmSpHJEFOSrgEP+XYyD6duCw57uvXYBv5mV2ulr wrbEHfcZmu1gYb9UDhTi4j7dBExUkNW2qSV5H4/kzCT/ ) ; ZSK; alg = RSASHA1; key id = 56700 dotat.at. 3600 IN DNSKEY 257 3 5 ( AwEAAZfTCuV4JYWU/COTmC6N37hek+RsIHLZ484GGO4O hGNpBYIIlcT+wubBD4VPyjmALVny0lV3nUVle9PrPHJC 4q02uJnoRi+NPAJ9eAVlBGkvJ75l0TgaSgCV+xtR69VM xomC1B00pBZHzfnY3Ig4OhrH6YoaezgQ4eyNkzg3fWVi SQvjosTZmuwwhnNfWu9bKQiM/WSRHLFiNBjB/H/YtjM1 It0dQaLDRiZMX2/dFZw0YewdHei46NjCXarNe/CwiTw7 +g3zPyGmDPSVFNr+INvdMDqyVRroHkZ8Ky+kPL4lLz9E oG1PcCzq7YjBr+JY6Hq7CjLbZZFw1wY0jKISoKk= ) ; KSK; alg = RSASHA1; key id = 5677 dotat.at. 3600 IN RRSIG DNSKEY 5 2 3600 ( 20120831190247 20120801184840 5677 dotat.at. EPDmmG99GNcPHRzMK7fbkWOpE7P+hbyNbCcpi9hYmwq9 GUNqmHI1VK3xNl4YiB6ARUtVuGqKi45SGltFlBKBh+KW i6NA+U7IXniKXnztUJqo7QSAWVdcZrRVcEpNE7MdPUeT lyijL9ytXfFV/q1398o00KErc7OGZ+rlRhQQZAX0SiU6 UV4C/ecA581j231rfSGb9ttGhqFK7lPNkv33B2jyc7uU qxm7Ra5WSWnfudPeBlhg3YcqCwoefwA0a7QviqR3VKjM Ak1pr4EH9KX5H2TFSP4EazJTqIuRvbGWH5TVuHMaH/cm rI7gCUkIOxPKWYgIhwnjSMp5E/mjMfoOmA== ) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 15 11:38:10 2012 ;; MSG SIZE rcvd: 757 Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 4 or 5, occasionally 6 later except in North Utsire. Slight or moderate. Showers. Moderate or good. ___ 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
playing with 9.9.2b1 and ECDSA
Is automatic signing with ECDSA supposed to work yet? I ran: $ dnssec-keygen -a ECDSAP256SHA256 -f KSK fanf2.ucam.org Generating key pair. Kfanf2.ucam.org.+013+03356 $ dnssec-keygen -a ECDSAP256SHA256 fanf2.ucam.org Generating key pair. Kfanf2.ucam.org.+013+63927 $ chmod g+r K* $ rndc loadkeys fanf2.ucam.org And BIND said: 15-Aug-2012 19:56:31.942 general: info: received control channel command 'loadkeys fanf2.ucam.org' 15-Aug-2012 19:56:31.954 general: info: zone fanf2.ucam.org/IN: reconfiguring zone keys 15-Aug-2012 19:56:31.969 general: error: zone fanf2.ucam.org/IN: update_sigs:add_sigs -> sign failure (blank line) 15-Aug-2012 19:56:31.970 general: error: zone fanf2.ucam.org/IN: sign_apex:update_sigs -> sign failure (blank line) dnssec-signzone appears to work. Tony. -- f.anthony.n.finchhttp://dotat.at/ Thames, Dover, Wight: South or southwest 4 or 5, increasing 6 at times, backing southeast later, 3 or 4. Slight or moderate, occasionally rough in Wight. Showers. Moderate or good. ___ 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: playing with 9.9.2b1 and ECDSA
Tony Finch wrote: > 15-Aug-2012 19:56:31.969 general: error: zone fanf2.ucam.org/IN: > update_sigs:add_sigs -> sign failure This turned out to be because /dev/random inside my chroot was set up incorrectly. FreeBSD has a somewhat unusual way of dealing with device nodes. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Version statement...
sth...@nethelp.no wrote: > > I have since learned that you get different version output from dig, > > named -v, and a dns query and the version statement only affects > > specific outputs. > > What is the difference between using dig and a DNS query? Dig reports its own version number in the comment at the start of its output. "rndc status" and "named -v" report named's version. The "version" configuration option affects responses to "version.bind ch txt" queries but not other version number reporting mechanisms. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: ho to filter hundeds of domains ?
fddi wrote: > > Is there another way I could achieve this ? BIND's RPZ (response policy zone) feature supports many kinds of evil. http://www.isc.org/community/blog/201007/taking-back-dns-0 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Root hints updates
Timothe Litt wrote: > > Until someone authoritative tells me that BIND manages the hints file on its > own, I'm taking the conservative route and letting my tool run > BTW, I do have systems that come on-line every 5 years or so. Automation is > good :-) Well, I'm not authoritative, but I don't have a root hints file on my systems. Instead I rely on the hints built in to named, which get updated when I update BIND. Also it doesn't matter if the hints are out of date since the root name server list changes very infrequently and you only need one of them to work for named to start OK. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Dig from workstation to answer?
Lightner, Jeff wrote: > > For example from my workstation if I search an internal domain we use I > know which internal DNS server it goes to ask the question. That DNS > server in turn may refer to a separate internal DNS server which is > authoritative for the domain or has the record cached. A dig +trace is > useless because the root servers know nothing about the domain. I’ve > found various things that give me parts of the information but wonder if > there isn’t something that would do something like trace so I can see > each DNS server that was referred to in such lookups. You can trace upwards. To find the zone within which a name lives, ask for the SOA. You'll probably bet a NOERROR / NODATA response with the SOA in the authority section, for example, (1) You can then ask for the NS records at that name to find where the name is hosted. (2) You can work up the namespace by trimming off a label and repeating the process. (3) (4) Given the parent name servers you can then check the delegation NS RRset for the child. (5) However, for private zones, it is possible that the NS records do not tell the truth - the hostmaster may be relying on static configuration of all the servers instead. *** (1) ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> soa hermes.cam.ac.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14961 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;hermes.cam.ac.uk. IN SOA ;; AUTHORITY SECTION: cam.ac.uk. 14400 IN SOA authdns0.csx.cam.ac.uk. hostmaster.ucs.cam.ac.uk. 1347969556 14400 3600 604800 14400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 18 16:28:46 2012 ;; MSG SIZE rcvd: 109 *** (2) ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns cam.ac.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28269 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cam.ac.uk. IN NS ;; ANSWER SECTION: cam.ac.uk. 86400 IN NS dns1.cl.cam.ac.uk. cam.ac.uk. 86400 IN NS authdns0.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS ns2.ic.ac.uk. cam.ac.uk. 86400 IN NS bitsy.mit.edu. cam.ac.uk. 86400 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 86400 IN NS dns0.cl.cam.ac.uk. cam.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 18 16:31:41 2012 ;; MSG SIZE rcvd: 200 *** (3) ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> soa ac.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32406 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ac.uk. IN SOA ;; ANSWER SECTION: ac.uk. 86400 IN SOA ns0.ja.net. operations.ja.net. 2012091860 28800 7200 360 14400 ;; Query time: 13 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 18 16:32:00 2012 ;; MSG SIZE rcvd: 91 *** (4) ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns ac.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41140 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ac.uk. IN NS ;; ANSWER SECTION: ac.uk. 7474IN NS ns2.ja.net. ac.uk. 7474IN NS ns4.ja.net. ac.uk. 7474IN NS auth03.ns.uu.net. ac.uk. 7474IN NS ws-fra1.win-ip.dfn.de. ac.uk. 7474IN NS ns3.ja.net. ac.uk. 7474IN NS ns0.ja.net. ac.uk. 7474IN NS ns1.surfnet.nl. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 18 16:32:16 2012 ;; MSG SIZE rcvd: 202 *** (5) ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns cam.ac.uk @ns0.ja.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48627 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cam.ac.uk. IN NS ;; AUTHORITY SECTION: cam.ac.uk. 86400 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. cam.ac.uk. 86400 IN NS ns2.ic.ac.uk. cam.ac.uk.
format error: CNAME response for DNSKEY RR
Why does named complain in this manner? I noticed this when wondering about validating stub resolvers which might query for DNSKEY and DS records without knowing where zone cuts are in order to reduce latency. 03-Oct-2012 17:44:47.571 resolver: notice: DNS format error from 212.72.49.3#53 resolving www.bbc.co.uk/DNSKEY for client 127.0.0.1#48638: CNAME response for DNSKEY RR ; <<>> DiG 9.9.2-vjs197.15rc1 <<>> +dnssec dnskey www.bbc.co.uk. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15670 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN DNSKEY ;; Query time: 21 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 3 17:44:47 2012 ;; MSG SIZE rcvd: 42 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: format error: CNAME response for DNSKEY RR
Mark Andrews wrote: > > Why does named complain in this manner? > > It's fallout from the type code roll from KEY to DNSKEY. KEY can > exist beside CNAME so the CNAME is not followed for KEY, the same > is not supposed to be true for DNSKEY. I'll open a bug ticket for > this. Thanks! Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Responses erroneously marked "invalid response"?
Havard Eidnes wrote: > So I'm sitting here scrathing my head even more confused than > usual. Anyone have any insights? The SOA has the wrong owner name. Bind followed a referral for map.media6degrees.com but the SOA wrongly says the zone apex is media6degrees.com. https://lists.isc.org/pipermail/bind-users/2009-December/078403.html http://fanf.livejournal.com/107721.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: How to Setup DNSSEC
babu dheen wrote: > > All users in our company using internal DNS server for name resolution. > All internal DNS server are pointed to our gateway recursive BIND name > server which is responsible for getting DNS queries from authoritative > internet DNS server. > > Now we would like to configure DNSSEC on my gateway DNS and internal DNS > server. For recursive DNSSEC, I recommend BIND 9.8 or newer, since then you don't have to mess around with getting the root trust anchor. Once you have a recent version of the software, check your network isn't broken using a DNS reply size tester such as https://www.dns-oarc.net/oarc/services/replysizetest/ If large UDP packets and TCP/53 get through OK, then you can go ahead and add the following to the options section of your nameserver configuration: dnssec-validation auto; dnssec-lookaside auto; And that's it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Disable log message
Alan Clegg wrote: > > This message was added by general recognition that being able to rebuild > a "drop-in" binary for BIND when you didn't have access to the build > directory (where the config.log contains the information) was a good > thing. > > I, for one, see no reason to suppress this message (but I do have blind > spots at times). I have a tangentially related patch. I wanted to direct BIND's startup logging to the same file that it is configured to use after initialization - rather than always sending startup messages to syslog. The patch adds a -L command-line option for this purpose. You could use it to suppress the startup logging with -L/dev/null I suppose... http://dotat.at/cgi/git/bind-9.git?a=commitdiff;h=logging-startup Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: limitations of dig +nssearch
M. Meadows wrote: > > Does anyone know why dig brownmackie.com +nssearch only returns 5 auth > nameserver soa records? A check of whois shows they have 7 auth > nameservers. Two of them do not respond to queries for brownmackie.com. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Delegations
Phil Mayers wrote: > > No. Zone cuts can be at any label inside a zone. Provided "inside" does not include the zone apex :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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 and DNSSEC
Feng He wrote: > > Take a look at: > http://www.dnssec.lk/docs/DNSSEC_in_6_minutes.pdf I recommend using "auto-dnssec maintain" so named keeps the zone signed, instead of dnssec-signzone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Strange issue with signed zone
Peter Andreev wrote: > > We signed another zone and met the same problem again. The only > difference is algorithm - now it is RSASHA256. > > > We have ~30 servers running BIND (9.8, 9.7, 9.6). A week ago we > > signed first of our zones with RSA/SHA1 + NSEC3 + OPT-OUT. > > Recently we realised that our servers don't generate NSEC3 for signed zone. > > Problem has gone after we restarted BIND instances. > > We are using views, could it be related? Did you add an NSEC3PARAM record? The signing algorithms that support NSEC3 use NSEC by default unless the zone has an NSEC3PARAM record. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: User wanting to use a .local domain to host DNS
King, Harold Clyde (Hal) wrote: > I'm a bit confused by a user request. I think he is trying to keep some > hosts on the private side of DNS, but he wants to use a DNS name like > host.sub.local. I do not know of the use of the .local TLD except in > bonjure. Can anyone shed some light on the use of the .local TLD? Microsoft have recommended its use for sites that don't have a properly registered domain name. http://support.microsoft.com/kb/296250 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: truncated responses vs. minimal-responses?
Matus UHLAR - fantomas wrote: > > I know. But there are cases you just have much of data in the DNS and what I > am asking is, if BIND really does skip authority section, if it helps to > avoid sending truncated packets. Yes it does. For example, have a look at responses to queries for dotat.at in mx for various buffer sizes and observe that RRsets are dropped but the TC bit is not set. ; <<>> DiG 9.9.2-vjs287.12 <<>> +norec +dnssec +ignore +multiline mx dotat.at @puck.nether.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31890 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dotat.at. IN MX ;; ANSWER SECTION: dotat.at. 3600 IN MX 1 mx.cam.ac.uk. dotat.at. 3600 IN RRSIG MX 5 2 3600 ( 20121217120814 20121117113945 56700 dotat.at. FLOLFiTEbnAsBka05qJK9nbY3sknNIbG2zSewoqIUkI1 fnm8PDzOB42WoAI2N4vNcQQVkd560B8hRB5a0+tLLZOB +lz7EA1uLnqCaINJ46BOA0+hXAcAMZMbzYFfVOTN8T/K 89WkExApwdXxffi2dSGOKXAj4KuM3ryfz1g/n7g= ) ;; AUTHORITY SECTION: dotat.at. 3600 IN NS black.dotat.at. dotat.at. 3600 IN NS ns1.gratisdns.dk. dotat.at. 3600 IN NS ns3.gratisdns.dk. dotat.at. 3600 IN NS puck.nether.net. dotat.at. 3600 IN RRSIG NS 5 2 3600 ( 20121225040504 20121125035952 56700 dotat.at. Hdvs1a2cdGOezLYbNTr1T47g+ZYA9ceBgUQD1tkHvJjL 0+nwREF/0JRs9Neb/Y+jpe0+PeIcDKCEOyD8GTeyc0ve Ez4sKt3OmkVUp1QN4gFmaeH/oPnPmhYzIuSrlgLkDwOl IoiixyHNKdF1Op14uUOS8bG3Qn8/HrHS3VjvogM= ) ;; ADDITIONAL SECTION: puck.nether.net.86400 IN A 204.42.254.5 puck.nether.net.86400 IN 2001:418:3f4::5 black.dotat.at. 3600 IN A 131.111.11.130 black.dotat.at. 3600 IN 2001:630:212:100:646f:7461:742e:6174 black.dotat.at. 3600 IN RRSIG A 5 3 3600 ( 20121217151010 20121117143125 56700 dotat.at. ASD2mv5bJgCvope4pfPMxG9LULCOgnUEgRfpw6BIYaRi 1wGMbezO2L7e9PVPeZ6vN5Cc0T+faN5NpgT0o9aJTdSK vRoFABIyNsPAMS41ekPL6KdAoz5vbHvplDaNBIfIXs+B NMySjVw+K/kDFjdW2ygPaRQb8WzfCQoCUEuUc7Y= ) black.dotat.at. 3600 IN RRSIG 5 3 3600 ( 20121224154647 20121124151930 56700 dotat.at. sb5EcG/+C8PG4E5BFUVag59M9zDDwxZGAFdgnMHSacVX 2kBPoLx+O7IwyO/wanYFpW/sINojumV0NVvE48AI2Ubs 5R/YKIKwHOwgrbwXB2S86x9xGUIGljMJtN07NxbGGpKS CDhlGH7za4Au32srZFVNu3cozq0Q20dsWKHQ3DA= ) ;; Query time: 93 msec ;; SERVER: 2001:418:3f4::5#53(2001:418:3f4::5) ;; WHEN: Wed Nov 28 18:33:16 2012 ;; MSG SIZE rcvd: 922 ; <<>> DiG 9.9.2-vjs287.12 <<>> +norec +dnssec +bufsize=512 +ignore +multiline mx dotat.at @puck.nether.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46694 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dotat.at. IN MX ;; ANSWER SECTION: dotat.at. 3600 IN MX 1 mx.cam.ac.uk. dotat.at. 3600 IN RRSIG MX 5 2 3600 ( 20121217120814 20121117113945 56700 dotat.at. FLOLFiTEbnAsBka05qJK9nbY3sknNIbG2zSewoqIUkI1 fnm8PDzOB42WoAI2N4vNcQQVkd560B8hRB5a0+tLLZOB +lz7EA1uLnqCaINJ46BOA0+hXAcAMZMbzYFfVOTN8T/K 89WkExApwdXxffi2dSGOKXAj4KuM3ryfz1g/n7g= ) ;; Query time: 98 msec ;; SERVER: 2001:418:3f4::5#53(2001:418:3f4::5) ;; WHEN: Wed Nov 28 18:35:32 2012 ;; MSG SIZE rcvd: 233 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: truncated responses vs. minimal-responses?
Matus UHLAR - fantomas wrote: > > Nice to see. I'm seeing recommendations to set minimal-responses to avoid > truncation problem anywhere and I'd like to have documented somewhere that > it just won't help... It will reduce the likelihood of a fragmented response and therefore poor interactions with misconfigured firewalls. But another way to avoid that problem is to reduce the EDNS UDP buffer size. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: truncated responses vs. minimal-responses?
Mark Andrews wrote: > In message <20121205125024.gc11...@fantomas.sk>, Matus UHLAR - fantomas > writes: > > > > I'm curious if there's any case where the AUTHORITY section is needed to > > proper function of DNS. > > Yes. Referrals. And, (to a lesser extent) negative answers, since the negative cache TTL comes from the SOA record in the authoruty section. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
restart named; missing TCP socket
I have had a few instances recently when named has failed to re-open its
TCP listening socket after a restart. This is particularly likely if I
try to bounce it quickly with a command line like
# rndc stop; /etc/rc.d/rc.named start
The servers in question are recursive (apart from a few local zones) with
simple ACLs. (I have had the same problem on servers with less simple
ACLs too.)
listen-on-v6 { ::1; };
listen-on { 127.0.0.1; };
allow-query{ localhost; };
allow-transfer { localhost; };
What do others do to avoid this problem?
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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: restart named; missing TCP socket
Mark Andrews wrote:
>
> You need to wait for named to stop
>
> p=`rndc stop -p | awk '{print $2}'`
> while kill -0 $p
> do
> sleep 1
> done
> /etc/rc.d/rc.named start
Thanks.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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: set directory for "auto" key files
Chris Thompson wrote: > > One slight niggling disadvantage is that you can't tell > named-checkzone / named-compilezone with the -j option where > to find the journal is it isn't in the default location. I submited a patch to add a -J option which addresses this problem. (RT #30958) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Wildcard CNAME record?
Matus UHLAR - fantomas wrote: > On 16.01.13 14:57, Baird, Josh wrote: > > Is it acceptable to have a wildcard CNAME? Example: > > > > * IN CNAMEsomewhere.com. > > > > Or, would it be advised to only use wildcard 'A' records? > > while it is technically valid, I don't think it's acceptable to use solutions > that require wildcards ;-) RFC 4592 is enlightening in a rather unpleasant manner. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)
Brian Kroth wrote: > > > RFC 4035 sec 2.2 says > > > > There MUST be an RRSIG for each RRset using at least one DNSKEY of > > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset > > itself MUST be signed by each algorithm appearing in the DS RRset > > located at the delegating parent (if any). > > > > This says to me that you can have extra DNSKEY records (that don't yet have > > a corresponding DS pair upstream), but not extra DS records (that don't yet > > have a corresponding DNSKEY downstream), since every DS records must have a > > key and sig associated with it. Be careful: this paragraph is about zones that are signed with more than one algorithm. It says that you can't have a DS record for an algorithm that isn't used to sign a zone. It's fine to have DS records without matching DNSKEY records, provided there is another DS with the same algorithm that does have a matching DNSKEY record. > > This says to me that the RFC also acknowledges that things might/will get > > out of sync due to caching in DNS, but doesn't describe to me what resolvers > > do in that context. Do they complain that the DS they happened to choose to > > look for a valid chain of trust didn't work and throw the whole thing out, > > or do they just move along to the next one in the hopes that it might > > succeed? The latter. > Given the latest RFC evidence I posted, I think my summary view is as follows, > please correct me if it seems wrong: > > 1) DS records are just used to validate the chain of trust upstream for DNSKEY > records found downstream, so there MUST exist a DS record for each > DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not > for just standby keys that are listed in DNSKEY records but not signing), but > there need not exist a DNSKEY/RRSIG chain for each DS record (which is what > contradicts 4035 2.2). So, we could prepublish DS records without an issue, > but DNSKEYs that are published must be validated by an existing chain of trust > (DNSKEY/DS pair) before they can be used to validate other RRSIGs. That doesn't sound quite right to me. It's probably easiest to work upwards: Each RRset in a zone must be signed by a private key corresponding to one of the zone's DNSKEY RRs. Different RRsets can be signed by different keys. In particular, it is common for the DNSKEY RRset to be signed by a different key (a key-signing key) from the rest of the zone (which uses a zone-signing key); there may be more differences during a key rollover. The KSKs are special in that they authenticate the zone's keys. For a zone to be secure there must be a DS record in the parent corresponding to a KSK. If a particular DNSKEY is not self-signed then it fails to prove the zone admin has both private and public halves of the key. DS records corresponding to ZSKs are useless. There can be extra DS records and extra DNSKEY records. They are ignored if they aren't usable as part of a validation chain. So the usual chain of authentication is parent RRSIG(DS)child DS-> DNSKEY(ksk) <-> RRSIG(DNSKEY) DNSKEY(ksk) DNSKEY(zsk) -> RRSIG(A,NS,MX etc) A,NS,MX etc If you are signing with multiple algorithms then it must be possible to validate the zone using each algorithm by itself. That is, each algorithm must have a ZSK and a KSK and an RRSIG on every record. The zone is considered bogus if it is bogus according to any of the algorithms. A validator knows whether to expect multiple algorithms for a zone by examining its DS RRset in the parent. So for an algorithm rollover you need to get all the DNSKEYs and RRSIGs for the new algorithm in place before adding it to the DS RRset, and you must remove the old algorithm from the DS RRset before removing its DNSKEYs and RRSIGs. You have much less flexibility than there is for normal key rollovers. Pay attention to the following sentence in RFC 6781 section 4.1.4! Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm. It is also worth looking at http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing You do not need to follow the timing restrictions in RFC 5011 unless you support users that have configured a trust anchor for your zone. If you only support the normal validation chain from the root then RFC 5011 is not relevant. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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/bin
Re: DNSSEC DS vs DNSKEY record publication order question (wrt key algorithm rollover)
Brian Kroth wrote: > > For instance, suppose I did the following: > > - gen new algorithm keys and sign with them > - wait for some period then publish the new DS (old DS remains) > - revoke the old algorithm KSK (leave the ZSK alone), which changes its DS > fingerprint, so publish a new DS It doesn't make sense to have any records that refer to a revoked key, other than its self-signed RRSIG which confirms the revocation. > However, if I'm reading things correctly, then the REVOKE bit really just > governs automatic trust-anchor updates for clients that support that > mechanism, but the key is still usable for validating at the very least > itself, if not also other RRSIGs (eg: for compatibility with clients that > don't understand the REVOKE bit and have another trust anchor to work off > of?). Right. > In looking at an example, dnssec-signzone still signs a DNSKEY record which > includes the old algorithm's ZSK for that zone, so I think there's still a > valid chain of trust, and the same RFC 6781 4.1.4 note applies. You need to be clear about whether there are signatures with both algorithms or not. Because all the DNSKEYs form a single RRset, they will all be signed with all algorithms. It is an error to have a DNSKEY RRset that includes keys with an algorithm that doesn't sign the RRset - the chain of trust does not cross over between algorithms except at DS RRsets. > If this is true, then the only way to actually complete the algorithm rollover > is to just drop the algorithm from the DS records once the new algorithm is in > place, but before actually dropping the RRSIGs and DNSKEY records for that > algorithm, correct? Right. > [1] I guess I should have mentioned that basically I got stuck with a system > with a deficient dnssec implementation on 100+ zones that are generated from a > db via perl, so I was really hoping in the course of fixing it up to to get to > something where I (or the person behind me) could just change $ALG = > 'NEW_VALUE' and have it complete the rest of the steps as necessary, even if > some of them were just "compare expected vs. seen DS and generate an email to > tell people to push things up stream when they need to be updated". Now, it's > looking more and more to me like some of this just isn't possible to automate > well. Best attempt I have seen so far is http://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: What causes 'zone transfer setup failed' ?
Jan-Piet Mens wrote: > > I'm seeing quite a number of messages like > > xfer-out: debug 3: client 192.168.1.2#54688 (example.com): zone > transfer setup failed >From the source it looks like it will always precede this message with another log line stating the reason. There are lots of possibilities... Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: What causes 'zone transfer setup failed' ?
Jan-Piet Mens wrote: > > On Fri Jan 25 2013 at 13:45:58 CET, Ben Croswell wrote: > > A common issue is the secondary not being allowed to query the master for > > the SOA of the zone. Ensure the master has an allow-query that includes the > > secondary. > > The BIND slave can query the PowerDNS master (for the SOA over UDP and > for the AXFR over TCP), and zones are transferred. Note that the log message related to outgoing zone transfers from named, not slaving zones to named. So is named rejecting the requests due to an ACL? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Unexpected wildcard matching
ip admin wrote: > > Any idea why the wildcard matching is affected by the individual > levels/labels of > hello.test.com? See RFC 4592 "The Role of Wildcards in the Domain Name System", section 2.2 "Existence Rules" and especially 2.2.2 "Empty Non-terminals": 2.2. Existence Rules The notion that a domain name 'exists' is mentioned in the definition of wildcards. In section 4.3.3 of RFC 1034: # Wildcard RRs do not apply: # ... # - When the query name or a name between the wildcard domain and # the query name is know[n] to exist. . . . "Existence" is therefore an important concept in the understanding of wildcards. Unfortunately, the definition of what exists, in RFC 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is taken at the definition of existence. 2.2.2. Empty Non-terminals Empty non-terminals [RFC2136, section 7.16] are domain names that own no resource records but have subdomains that do. In section 2.2.1, "_tcp.host1.example." is an example of an empty non-terminal name. Empty non-terminals are introduced by this text in section 3.1 of RFC 1034: # The domain name space is a tree structure. Each node and leaf on # the tree corresponds to a resource set (which may be empty). The # domain system makes no distinctions between the uses of the # interior nodes and leaves, and this memo uses the term "node" to # refer to both. The parenthesized "which may be empty" specifies that empty non- terminals are explicitly recognized and that empty non-terminals "exist". Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: TKEY and zone transfer
Evan Hunt wrote: > > Also, generate a TSIG key to use for the initial TKEY negotiation. I thought the point of TKEY was to upgrade from slow public key authentication to fast secret key authentication, i.e. that you would start off by authenticating the client with SIG(0). Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: reverse resolution failing
Jim Pazarena wrote: > > while it can resolve "webmail.acrodex.com" ( 139.142.184.10 ) > it cannot reverse resolve 139.142.184.10 They are using classless reverse DNS, which is fine except that the nameservers for the target zone are very broken. 10.184.142.139.in-addr.arpa. CNAME 10.0-25.184.142.139.in-addr.arpa. 0-25.184.142.139.in-addr.arpa. NS pluto.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS nova.acrodex.com. 0-25.184.142.139.in-addr.arpa. NS saturn.acrodex.com. Nova does not exist. Pluto refuses most questions for 10.0-25.184.142.139.in-addr.arpa except if you ask for a PTR, in which case it replies with a bogus question section containing 139.0.184.142.in-addr.arpa. Saturn works OK for most questions, and returns a PTR record if you ask for ANY, but if you request a PTR directly it ignores you. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Slaving from DNS masters behind LVS
Nick Urbanik wrote: > > I think that it is not necessarily always true that you should avoid a > load balancer. Every day, our DNS caches are answering about 140,000 > queries per second. I think that it is rather hard to configure > resolvers to query only three machines yet still meet the demand > unless you either use very massive, expensive machines, or use load > balancers. Another option is to use anycast. http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk= Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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 does not answer
Christian Tardif wrote: > > Back to a DNS problem, I came back to this thread. If I do a "dig +norec", I > still don't get the final answer but then, I get a whole bunch of information > (the NS records for the requested zone, and the A records relativey to these > NS records) That means the local name server is giving you a referral: it is telling you where to get the answer from, which isn't the local name server. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Building a fresh named.root
Robert Moskowitz wrote: > On 02/14/2013 09:05 AM, Warren Kumari wrote: > > BIND now comes with a baked in roots file (in the imaginatively named > > lib/dns/rootns.c ) > > Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. > > There is no need for a named.root file, and is just another thing to go > > wrong… > > Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.___ 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: Building a fresh named.root
Robert Moskowitz wrote: > > Which begs the next question I was going to ask. How often should I download > a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Building a fresh named.root
Robert Moskowitz wrote: > > More records 1/3/2013 than in the named.ca stub which IF my version has > it builtin raises the question about keeping current at this time in the > Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: NSEC3/NSEC transition
David Sherman wrote: > > If dynamic signing is used with BIND 9.8, what is the recommended > procedure to switch from NSEC3-signed zone to NSEC-signed without > changing existing DNSKEYs (currently RSA/SHA-512 algorithms are used for > both ZSK and KSK)? Any specific options for dnssec-signzone? Use nsupdate to delete the NSEC3PARAM record - see http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch04.html#id2563909 If you are using dynamic signing then you aren't using dnssec-signzone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: empty-zones not set warning, but have net 192.168.128/24
Robert Moskowitz wrote: > I have been getting this warning, and wonder why? > I have read: https://kb.isc.org/article/AA-00804/0/Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html named logs the message if there are any RFC 1918 zones that ought to be configured but are not. > I have a 128.168.192.in-addr.arpa.zone zone in my internal view. So what > might I be missing? Do I need to create my own delegation tree? Set empty-zones-enable yes; Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Free secondary servers supporting DNSSEC?
Vernon Schryver wrote: > > How does a secondary authoritative DNS server fail to support DNSSEC? A security-aware authoritative server has to support: * EDNS0 and DO * RRSIG records alongside the RRsets they cover in responses * Special logic for DS in parent zones * NSEC or NSEC3 in negative and wildcard responses Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Free secondary servers supporting DNSSEC?
Robert Moskowitz wrote: > > One of my secondaries, though, does not support DNSSEC and it is the one that > gives me a bit of geographical diversity. So I am looking for someplace that > will accept my smallish domains. Have a look at https://web.gratisdns.dk - Danish only, but that's not too much of a problem with automatic translation... Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Registrar that supports self-run domains and provides DNSSEC support
Robert Moskowitz wrote: > > Right now I use Network Solutions as my registrar. Just never changes as they > were the only show in town back then. > > But they don't seem to support DNSSEC protected domains, and even IPv6 glue > records are special requests, it seems. Have a look at http://wiki.gandi.net/en/domains/faq/transfer Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: broken ISP in china
Lyle Giese wrote: > > Recently I moved this domain(lcrcomputer.net) to a registrar that suports > DNSSEC and inserted the DS record for this domain. Was it signed before this point? I am wondering if this is a DNS response size problem - was the cause the addition of the DS record, or the addition of DNSKEY and RRSIG records? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Registrar that supports self-run domains and provides DNSSEC support
On 19 Feb 2013, at 08:06, Doug Barton wrote: > GoDaddy supports everything you're looking for. Though you might prefer to use a less repulsive provider. http://kottke.org/11/12/the-internets-go-daddy-issues Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ 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: Cannot create A record issue
Jsilliman wrote: > The serial number gets updated in the logs, but not when I do a dig. > (21 vs 3-old) Did you dig @localhost or is dig querying some recursive server elsewhere? What does /etc/resolv.conf contain? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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 returns with localdomain.com with out DOT at the end of the domain
Mesut GULNAZ wrote: > when i query bind for www.google.com from a PC from my network > bind response me with www.google.com.localdomain.com > with no result Sounds like you have a wildcard in your local domain and the resolver search path includes your local domain. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Problems with resolving a local tld
Robert Moskowitz wrote: > Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got > insecure response; parent indicates it should be secure I think this suggests that one of the servers for htt doesn't have the signed version. Another reason not to use made-up domain names: CAs are going to stop issuing X.509 certificates for them. (It baffles me why they ever did so.) http://ssl.entrust.net/blog/?p=1831 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: in-addr.arpa insecure?
Robert Moskowitz wrote: > I got tipped off about this from logwatch report. On my public DNS server had > the following: > > Feb 26 04:02:04 onlo named[19336]: validating @0xb2929ee0: in-addr.arpa SOA: > got insecure response; parent indicates it should be secure Looks like something in your setup is dropping RRSIGs, and this is probably responsible for both your private htt. TLD validation problems and these in-addr.arpa validation problems. Do you all your servers have "dnssec-enable yes"? Do you have any non-BIND servers or middleboxes? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Blocking private addresses with a optionq
King, Harold Clyde (Hal) wrote:
> Is there an option for bind like the allow-recursion { }
> For blocking out going records of 10.0.0.0/8 and 192.168.0.0/16 so I could do
> a view like:
I'm not sure what you mean by "blocking out going records" but there are a
couple of options that might do what you want:
There is the "blackhole" acl which makes named ignore all requests and
never send queries to a particular address range.
There is the server ... { bogus yes; }; clause which stops named from
sending queries to a particular address range.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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: Building from source and running in chroot environment
Spumonti Spumonti wrote: > Are there relatively recent instructions on how to build BIND from > source and run it in a chroot environment? It sounds obvious but > everything I've come across assumes BIND is provided by some package > manager or included with the operating system. I'd like to build the > latest version of BIND and run it in a chroot environment. I know you > have to pre-populate the chroot directories but am not entirely clear on > everything that's needed. In the chroot you will need: /dev/random and /dev/urandom A syslog socket (if you are using syslog) and/or somewhere for named's log files Your rndc key Your named.conf and zone files :-) If you have a recent OpenSSL you want to use BIND's configure --without-gost option or copy OpenSSL's "engines" library directory into the chroot. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
RFC 5011 trust anchor rollover status
In response to ICANN's consultation on DNSSEC root key rollovers
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm
I was wondering how to check that a rollover is progressing OK. BIND
doesn't provide much help with this (unless I have missed something) so I
thought it might be useful to write a script to summarize the RFC 5011
managed keys status. Run it with the path to your managed-keys.bind file
as an argument.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
#!/usr/bin/perl
use warnings;
use strict;
use POSIX qw(strftime);
my $now = strftime "%Y%m%d%H%M%S", gmtime;
sub ext8601 ($) {
my $d = shift;
$d =~ s{()(..)(..)(..)(..)(..)}
{$1-$2-$3.$4:$5:$6};
return $d;
}
sub getkey ($$) {
my $h = shift;
my $k = shift;
m{\s+(\d+)\s+(\d+)\s+(\d+)\s+[(]\s*$};
$k->{flags} = $1;
$k->{protocol} = $2;
$k->{algorithm} = $3;
my $data = "(";
while (<$h>) {
s{^\s+}{};
s{\s+$}{};
last if m{^[)]};
$data .= $_;
}
m{ alg = (\S+); key id = (\d+)};
$k->{alg} = $1;
$k->{id} = $2;
$k->{data} = $data;
return $k;
}
sub fmtkey ($) {
my $k = shift;
return sprintf "%16s tag %s", $k->{name}, $k->{id};
}
sub printstatus ($) {
my $a = shift;
if ($a->{removehd} ne "1970010100") {
printf " untrusted and to be removed at %s\n", ext8601
$a->{removehd};
} elsif ($a->{addhd} lt $now) {
printf " trusted\n";
} else {
printf " waiting for %s\n", ext8601 $a->{addhd};
}
}
sub digkeys ($) {
my $name = shift;
my $keys;
open my $d, "-|", qw{dig +multiline DNSKEY}, $name;
while (<$d>) {
next unless m{^([a-z0-9.-]*)\s+\d+\s+IN\s+DNSKEY\s+};
next unless $name eq $1;
push @$keys, getkey $d, { name => $name };
}
return $keys;
}
my $anchor;
while (<>) {
next unless m{^([a-z0-9.-]*)\s+KEYDATA\s+(\d+)\s+(\d+)\s+(\d+)\s+};
my $k = getkey *ARGV, {
name => $1,
refresh => $2,
addhd=> $3,
removehd => $4,
};
$k->{name} =~ s{[.]*$}{.};
push @{$anchor->{$k->{name}}}, $k;
}
for my $name (keys %$anchor) {
my $keys = digkeys $name;
my $anchors = $anchor->{$name};
for my $k (@$keys) {
if ($k->{flags} & 1) {
printf "%s %s KSK", fmtkey $k, $k->{alg};
} else {
# ZSK - skipping
next;
}
if ($k->{flags} & 512) {
print " revoked";
}
my $a;
for my $t (@$anchors) {
if ($t->{data} eq $k->{data} and
$t->{protocol} eq $k->{protocol} and
$t->{algorithm} eq $k->{algorithm}) {
$t->{matched} = 1;
$a = $t;
last;
}
}
if (not defined $a) {
print " - WARNING NO MATCHING TRUST ANCHOR\n";
next;
}
printstatus $a;
}
for my $a (@$anchors) {
next if $a->{matched};
printf "%s %s ???", fmtkey $a, $a->{alg};
printstatus $a;
}
}
___
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: How to optimize dns requests
Abdellatif ... wrote: > > It doesn't seem to use the cache, here is the call of dig mail.com : If you dig it twice do you get a faster response? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: How to optimize dns requests
Matus UHLAR - fantomas wrote: > > this is clearly a cached answer (aa flag is missing). How did you come to > the conclusion that caching does not work? It's probably a cached answer from one of the forwarders. The response time from the server was too long for it to be locally cached. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Precautions for upgrading from 9.7.7 to 9.9.2-P2
Wang, Yu wrote: > > I am in the process of preparing bind upgrade from 9.7.7 to 9.9.2-p2. I > am reading release notes from 9.8.0 up to see if there are new > things/features that might cause issues. I would welcome and appreciate > advice on precautions I should take before, during, and after upgrade. The main thing that you are likely to trip over is the change in the default format of slaved zones, from text to raw. named should move the old files out of the way and retransfer the zones, and complain about it in the log. You probably want to remove the old slave zone files, either before upgrading (to avoid upsetting named) or afterwards (to keep things tidy). Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
