Re: BIND 9.8.0b1 Released Today
At Fri, 21 Jan 2011 14:00:19 -0500 (EST), Paul Wouters wrote: > >* BIND now supports a new zone type, static-stub. This allows the > > administrator of a recursive nameserver to force queries for a > > particular zone to go to IP addresses of the administrator's choosing, > > on a per zone basis, both globally or per view. I.e. if the > > administrator wishes to have their recursive server query 192.0.2.1 and > > 192.0.2.2 for zone example.com rather than the servers listed by the > > .com gTLDs, they would configure example.com as a static-stub zone in > > their recursive server. [RT #21474] > > Does this work with DNSSEC if one loads an explicit trust anchor, even > if in the "world view" the trust anchor is missing? I'm afraid I don't understand the question. Could you be more specific, e.g., by using the above example.com example? --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
Sue Graves writes: New Features 9.8.0 * BIND now supports a new zone type, static-stub. This allows the administrator of a recursive nameserver to force queries for a particular zone to go to IP addresses of the administrator's choosing, on a per zone basis, both globally or per view. I.e. if the administrator wishes to have their recursive server query 192.0.2.1 and 192.0.2.2 for zone example.com rather than the servers listed by the .com gTLDs, they would configure example.com as a static-stub zone in their recursive server. [RT #21474] Thanks that's great meaningful from my point. Once I did need this feature years ago, but bind didnt have at that time. So I wrote a kernel module with linux kernel to intercept the DNS requests and match them with special domains. If matched, the module will return the customized responses directly rather than letting bind to answer them. The module opens two TCP ports on kernel so it even supports administrative commands via socket. tcp0 0 127.0.0.1: 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:4445 0.0.0.0:* LISTEN Now bind provides this capibility I think it's great much for the bind based products so called GSLB(?) so that it can direct clients' traffic to different sites in different situations. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
failed multi-view zone transfer
greetings, i'm in the midst of an odd problem (to me, anyway) and would appreciate any pointers. three servers, all running bind-9.7.2-P3 compiled from source with the same options. one master; two slaves. two views: internal and external. one master and one slave are on the same subnet with just a switch between 'em; the other slave is on a different subnet "out on the internet". i'm wanting to have both views for all zones transferred to both slaves. i've set things up with tsig and per mark andrews' great scheme documented at http://www.mail-archive.com/bind-users@lists.isc.org/msg03593.html transfers from the master to the slave on its same subnet happen as desired; transfers from the master to the slave on the different subnet do not. notify logging shows that the notifies are being properly received by both slaves. my master zone definitions specify also-notify for both slaves. each slave zone definition specifies a masters statement. what i've observed (initially because of a typo and quite by chance) is that the transfer to the slave on the internet does not happen if the host specified in the SOA's MNAME field is also specified in an NS record. but if the host specified in the SOA's MNAME field is not an NS record then the transfer does complete. and therein lies the problem. i've intentionally not posted my config, thinking someone might recognize this off the top of their head. i will certainly post it if necessary. thanks, jeffreyp ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
In message , Barry Mar golin writes: > In article , > Dave Knight wrote: > > > I guess the tool just always assumes that there's probably a www worthy > > asking about > > That's what I assumed at first, too. But the report for his domain also > included NS records for the subdomain test.nsbeta.info. Do you think it > also has test. in its default set of names to look up? It would get the NS records returned in the referral / answer from the test zone and as they are supposed to be the same it doesn't matter from which zone they come from. > -- > Barry Margolin, bar...@alum.mit.edu > Arlington, MA > *** PLEASE don't copy me on replies, I'll read them in the group *** > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
On Fri, 21 Jan 2011, Sue Graves wrote: * BIND now supports a new zone type, static-stub. This allows the administrator of a recursive nameserver to force queries for a particular zone to go to IP addresses of the administrator's choosing, on a per zone basis, both globally or per view. I.e. if the administrator wishes to have their recursive server query 192.0.2.1 and 192.0.2.2 for zone example.com rather than the servers listed by the .com gTLDs, they would configure example.com as a static-stub zone in their recursive server. [RT #21474] Does this work with DNSSEC if one loads an explicit trust anchor, even if in the "world view" the trust anchor is missing? (eg can you use this to more easilly deploy dnssec testbeds similar to how unbound can do this? Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.8.0b1 Released Today
Introduction
BIND 9.8.0b1 is the first beta release of BIND 9.8.
This document summarizes changes from BIND 9.7 to BIND 9.8. Please see
the CHANGES file in the source code release for a complete list of all
changes.
Download
The latest development versions of BIND 9 software can always be found
on our web site at http://www.isc.org/downloads/development. There you
will find additional information about each release, source code, and
some pre-compiled versions for certain operating systems.
Support
Product support information is available on
http://www.isc.org/services/support for paid support options. Free
support is provided by our user community via a mailing list.
Information on all public email lists is available at
https://lists.isc.org/mailman/listinfo.
New Features
9.8.0
* BIND now supports a new zone type, static-stub. This allows the
administrator of a recursive nameserver to force queries for a
particular zone to go to IP addresses of the administrator's choosing,
on a per zone basis, both globally or per view. I.e. if the
administrator wishes to have their recursive server query 192.0.2.1 and
192.0.2.2 for zone example.com rather than the servers listed by the
.com gTLDs, they would configure example.com as a static-stub zone in
their recursive server. [RT #21474]
* BIND now supports Response Policy Zones, a way of expressing
"reputation" in real time via specially constructed DNS zones. See the
draft specification here:
http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt [RT #21726]
* BIND 9.8.0 now has DNS64 support. named synthesizes records
from specified A records if no record exists. IP6.ARPA CNAME
records will be synthesized from corresponding IN-ADDR.ARPA. [RT
#21991/22769]
* Dynamically Loadable Zones (DLZ) now support dynamic updates.
Contributed by Andrew Tridgell of the Samba Project. [RT #22629]
* Added a "dlopen" DLZ driver, allowing the creation of external DLZ
drivers that can be loaded as shared objects at runtime rather than
having to be linked with named at compile time. Currently this is
switched on via a compile-time option, "configure --with-dlz-dlopen".
Note: the syntax for configuring DLZ zones is likely to be refined in
future releases. Contributed by Andrew Tridgell of the Samba Project.
[RT #22629]
* named now retains GSS-TSIG keys across restarts. This is for
compatibility with Microsoft DHCP servers doing dynamic DNS updates for
clients, which don't know to renegotiate the GSS-TSIG session key when
named restarts. [RT #22639]
* There is a new update-policy match type "external". This allows
named to decide whether to allow a dynamic update by checking with an
external daemon. Contributed by Andrew Tridgell of the Samba Project.
[RT #22758]
* There have been a number of bug fixes and ease of use enhancements
for configuring BIND to support GSS-TSIG [RT #22629/22795]. These include:
o Added a "tkey-gssapi-keytab" option. If set, dynamic updates
will be allowed for any key matching a Kerberos principal in the
specified keytab file. "tkey-gssapi-credential" is no longer required
and is expected to be deprecated. Contributed by Andrew Tridgell of the
Samba Project. [RT #22629]
o It is no longer necessary to have a valid /etc/krb5.conf
file. Using the syntax DNS/hostname@REALM in nsupdate is sufficient for
to correctly set the default realm. [RT #22795]
o Documentation updated new gssapi configuration options (new
option tkey-gssapi-keytab and changes in tkey-gssapi-credential and
tkey-domain behavior). [RT 22795]
o DLZ correctly deals with NULL zone in a query. [RT 22795]
o TSIG correctly deals with a NULL tkey->creator. [RT 22795]
Feature Changes
9.8.0
* There is a new option in dig, +onesoa, that allows the final SOA
record in an AXFR response to be suppressed. [RT #20929
* There is additional information displayed in the recursing log
(qtype, qclass, qid and whether we are following the original name). [RT
#22043]
* For Mac OS X, you can now have the test interfaces used during
"make test" stay beyond reboot. See bin/tests/system/README for details.
Security Fixes
9.8.0
None.
Bug Fixes
9.8.0
* BIND now builds with threads disabled in versions of NetBSD
earlier than 5.0 and with pthreads enabled by default in NetBSD versions
5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads
and ptl2. [RT #19203]
* If BIND has openssl compiled in (the default) and has any
permission problems opening the openssl.cnf file, BIND utilities fail.
Currently ISC is including a patch to openssl in
bin/pkcs11/openssl-0.9.8l-patch but ISC is working on a better solution
until openssl fixes this. [RT #20668]
* nsupdate will now preserve the entered case of domain names in
update requests it sends. [RT #20928]
* Added a regression test for fix 2896/RT #21045 ("rndc sign" failed
to properly update the zone when adding a DNSKEY for publication only).
[RT #2
Re: get a domain's dns records
In article , Dave Knight wrote: > I guess the tool just always assumes that there's probably a www worthy > asking about That's what I assumed at first, too. But the report for his domain also included NS records for the subdomain test.nsbeta.info. Do you think it also has test. in its default set of names to look up? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why queries rejected?
It might not be your bug. It might be other sites. As was said, bind can log info that would help explain it. Or if the number is rising continuously, you can capture a bunch of dns queries with tcpdump or a similar program and look over a sample of the rejected queries. On Jan 18, 2011, at 9:03 PM, p...@mail.nsbeta.info wrote: My zone is game.yy.com, and there are so many "auth queries rejected" in named.stats which was generated by "rndc stats". Could you show me some way to debug it? Thanks. [game.yy.com] 671834 auth queries rejected 3003 recursive queries rejected 685192 queries resulted in successful answer 685891 queries resulted in authoritative answer 676 queries resulted in nxrrset 23 queries resulted in NXDOMAIN 4 requested transfers completed 7 updates completed p...@mail.nsbeta.info writes: You haven't provided enough information for us to know. Have you bothered checking logs? Nothing special in logs from what I checked. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
On 21/01/11 14:21, p...@mail.nsbeta.info wrote: Dave Knight writes: I guess the tool just always assumes that there's probably a www worthy asking about But how does the site know I have a sub domain test.nsbeta.info and its name servers? I didn't think that I have got this sub domain be public. It guessed. See my other email. It tries a number of other names too (blog, forum, help, mail) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: get a domain's dns records
It checks for test. - I saw it do that for my zone. For us it isn't a subdomain but simply an A record. Apparently when it found your record it went ahead and did another check for your sub-zone. I'm surprised that it does not check for ftp.. Whenever we're doing acquisitions here that is one of the zones I find at most sites (though often enough it uses the same IP as the www.. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of p...@mail.nsbeta.info Sent: Friday, January 21, 2011 9:21 AM To: Dave Knight Cc: comp-protocols-dns-b...@isc.org; Barry Margolin Subject: Re: get a domain's dns records Dave Knight writes: > > I guess the tool just always assumes that there's probably a www worthy asking about > But how does the site know I have a sub domain test.nsbeta.info and its name servers? I didn't think that I have got this sub domain be public. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: get a domain's dns records
It seems to do a regular lookup, plus maybe an ANY But I've also noticed that it seems to find test.domain.com. I often put a 'test.whatever.com. IN A 127.0.0.1' into zones and a couple I checked it found them, even though it shouldn't have by "normal" means it also found a 'blog' record I had on one of my domains ... so, it must be looking for some specific records in addition to general lookups. t. -Original Message- From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of p...@mail.nsbeta.info Sent: Friday, January 21, 2011 1:20 AM To: bind-users Subject: get a domain's dns records I'm jsut curious, how does "who.is" know the dns records in my domain (nsbeta.info)? The page shows some of my RRs exactly: http://who.is/dns/nsbeta.info/ Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
Dnia 2011-01-21 08:50 Barry Margolin napisał(a): >In article , > Joseph S D Yao wrote: > >> On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: >> > >> > I'm jsut curious, how does "who.is" know the dns records in my domain >> > (nsbeta.info)? >> > >> > The page shows some of my RRs exactly: >> > >> > http://who.is/dns/nsbeta.info/ >> >> >> The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - >> Who.is - Who.is". They probably did just exactly that - DNS lookup. >> Anything in DNS is public information. > >But the nameservers for the domain don't allow public zone transfers. >So if you know the names in the zone you can look them up, but how did >the site list the names in his zone? My guess would be that they don't list the whole zone. Look what's there: nsbeta.info (dig any nsbeta.info) and some quite easy to guess prefixes: mail, test and www. And everything deduced from them, like names test.nsbeta.info and mail.nsbeta.info resolve to. Probably all questions asked with ANY recordtype I've tested on two other domains, and it looks like that - results show that common prefixes also include blog. And they have some filtering of results, as I have a * TXT record which didn't show up as blog entry. Actually dig any on my zone gives even more information - e.g. SPF record , which didn't show up on results. And they don't support third-level domains as well - asking form mail.nsbeta.info returns information about nsbeta.info Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 21/01/11 2:05 PM, "Zbigniew Jasiński" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> W dniu 2011-01-21 11:23, Kalman Feher pisze:
>> The only way I can replicate the behaviour is with dnssec-enable no or with
>> an unsigned version of the zone in another view. Assuming you've not
>> overlapped your views in such a way (it was a very contrived test), I think
>> you'll need to provide a bit more information on your configuration.
>>
>> -options
>> -relevant view statement
>> -The zone statement (from the hashed file if you are using the new dynamic
>> zones feature).
>> -The zone itself
>> -Query logs.
>>
>> Without the full dig output it is hard to see what is actually happening.
>> I'd suggest including that as well.
>>
>> If you dig axfr or dig rrsig are the signatures present?
>>
>
> I've conducted test with 'auto-dnssec allow' and that works without any
> single problem, than I just change this options to 'auto-dnssec
> maintain' and odd things happen.
>
Perhaps we are getting close to the problem then.
Can you show the content of the key files? Specifically the metadata which
the "maintain" option wants.
Since "allow" works I'm assuming that key file permissions (and directory
permissions) are ok, but it couldn't hurt to check them.
> Didn't mentioned before but this named is working with SoftHSM. But like
> I said no problems with 'auto-dnssec allow'.
>
> this is zone conf:
>
> zone "example" {
> type master;
> file "var/zone/example";
> allow-update { loopback; };
> allow-transfer { trusted; loopback; };
> auto-dnssec maintain;
> key-directory "var/keys/example";
> };
>
> named.conf:
>
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
> inet ::1 port 953 allow { ::1; } keys { "rndc-key"; };
> };
>
> acl trusted {
> 127.0.0.1;
> 172.16.7.5;
> };
>
> acl loopback {
> 127.0.0.1;
> };
>
> acl eth0 {
> 172.16.7.5;
> };
>
> options {
> directory "/";
> query-source address 172.16.7.5;
> notify-source 172.16.7.5;
> transfer-source 172.16.7.5;
> port 53;
> pid-file "var/run/named/named.pid";
> session-keyfile "var/run/named/session.key";
> listen-on {
> loopback;
> eth0;
> };
> listen-on-v6 { none; };
> recursion no;
> notify explicit;
> allow-query { trusted; };
>
> dnssec-enable yes;
> dnssec-validation yes;
> max-journal-size 100k;
> random-device "/dev/urandom";
> };
>
> this is zone file:
>
> $TTL3600
> example.SOA ns1.example. bugs.x.w.example. (
> 1292481908
> 7200
> 3600
> 734400
> 600
> )
> TXT "dnssec test"
> NS ns1.example.
> NS ns2.example.
> $ORIGIN example.
> ns1 A 127.0.0.3
> ns2 A 127.0.0.4
>
> a NS ns1.a
> NS ns2.a
> DS 23344 5 1 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56
>
> ns1.a IN A 127.0.0.1
> ns2.a IN A 127.0.0.1
>
> c NS ns1.c
> c NS ns2.c
> ns1.c IN A 127.0.0.5
> ns2.c IN A 127.0.0.6
>
> ai IN A 127.0.0.1
> IN 0:0:0:0:0:0:0:1
> xx IN A 127.0.0.1
> IN 0:0:0:0:0:0:0:1
>
> w IN A 127.0.0.1
> *.w MX 10 ai
> x.w MX 10 xx
> x.y.w MX 10 xx
>
> If I make query for RRSIG records, named is returning proper signatures.
> for example for SOA record:
>
> $ dig @127.0.0.1 example rrsig +short
> SOA 10 1 3600 20110220123506 20110121113506 51587 example.
> cVzWYkeTASPUiHv0DxFXpTsK4G1QkpS3sZ1jXmDCDv+EaYUs2C/kRlD9
>
>
> same with AXFR, and same for zone file.
>
> - --
> regards
>
> zbigniew jasinski
> [SYStem OPerator]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJNOYSaAAoJEH26UYiRhe/gNmcQALSiNOVoKWBpA/GV1WiarmDt
> b+G6NZPBOtXXW4U90XDqL211TUaeXgLfwesRfIERraDxOTtCPjTx9npIoMQMLrWk
> F91slmf8thgLpPzFqwe2FxMoagL/HdQ8fXrzHmdMU5Lsg8gBalJyVKL56Hozlp9R
> n5LZy8+QBSJHuJKXFIZcBPPCdUW8dEJcONve01ik09gHbwcQzCuqwY7S5vYrDW2s
> fZhYQUCvjdBpmf3uKH1yXiqdtUtUerZN3fCB6r4cGIkzYk98iEj5M6fngsBl49vt
> SijzWbQftd0ThSxHPcEiuSom4pAuFlxN1O7Al8laIRwgme5wvtUeN+PA8sxr7FWl
> cnUC///yLnYJNTJBnbIY0wiWsSTU9H4LU42tnesAKJaIBmaOR9w6QgxLs+E+pyKM
> M3pnC//ZqxGirnV9YetV6mqfch23Y08yWcmjTNI8QytEoXPMMaGXyh4IYJFAiMaz
> SxV5B9Be1KP1DxO2wyHwDEwrZzIkS5sl1iiaoyb+G0d9dWjuvlSmkDSZA43nYXGS
> cn91vMLqUHpYCYVIy3p8w62y7+jOPrIM94vsgONjPijqlB0DZY2JsMP4q2StHUui
> cYEqw5N
Re: get a domain's dns records
Dave Knight writes: I guess the tool just always assumes that there's probably a www worthy asking about But how does the site know I have a sub domain test.nsbeta.info and its name servers? I didn't think that I have got this sub domain be public. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
On 21/01/11 14:18, Phil Mayers wrote: On 21/01/11 13:50, Barry Margolin wrote: In article, Joseph S D Yao wrote: On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: I'm jsut curious, how does "who.is" know the dns records in my domain (nsbeta.info)? The page shows some of my RRs exactly: http://who.is/dns/nsbeta.info/ The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - Who.is - Who.is". They probably did just exactly that - DNS lookup. Anything in DNS is public information. But the nameservers for the domain don't allow public zone transfers. So if you know the names in the zone you can look them up, but how did the site list the names in his zone? Most of the records are well-known (i.e. A/MX/NS/SOA on the zone apex, or www.zone.name) or lookups of the RHS of a well-known. The site appears to probe for "test.zone.name". So it didn't "list" the zone. It looked up some well-known names and RRs and got replies. In case anyone is curious, I tried it with our zone and then looked in the query logs; it looks for: 174.36.196.245#54513: view main: query: zone.name IN A + 174.36.196.245#33561: view main: query: zone.name IN MX + 174.36.196.245#34074: view main: query: zone.name IN NS + 174.36.196.245#44305: view main: query: zone.name IN SOA + 174.36.196.245#50109: view main: query: zone.name IN TXT + 174.36.196.245#52299: view main: query: blog.zone.name IN A + 174.36.196.245#59078: view main: query: forum.zone.name IN A + 174.36.196.245#51346: view main: query: help.zone.name IN A + 174.36.196.245#40281: view main: query: mail.zone.name IN A + 174.36.196.245#45344: view main: query: mail.zone.name IN MX + 174.36.196.245#34294: view main: query: test.zone.name IN A + 174.36.196.245#48627: view main: query: www.zone.name IN A + ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
On 21/01/11 13:50, Barry Margolin wrote: In article, Joseph S D Yao wrote: On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: I'm jsut curious, how does "who.is" know the dns records in my domain (nsbeta.info)? The page shows some of my RRs exactly: http://who.is/dns/nsbeta.info/ The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - Who.is - Who.is". They probably did just exactly that - DNS lookup. Anything in DNS is public information. But the nameservers for the domain don't allow public zone transfers. So if you know the names in the zone you can look them up, but how did the site list the names in his zone? Most of the records are well-known (i.e. A/MX/NS/SOA on the zone apex, or www.zone.name) or lookups of the RHS of a well-known. The site appears to probe for "test.zone.name". So it didn't "list" the zone. It looked up some well-known names and RRs and got replies. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
On 2011-01-21, at 8:50 AM, Barry Margolin wrote: > In article , > Joseph S D Yao wrote: > >> On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: >>> >>> I'm jsut curious, how does "who.is" know the dns records in my domain >>> (nsbeta.info)? >>> >>> The page shows some of my RRs exactly: >>> >>> http://who.is/dns/nsbeta.info/ >> >> >> The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - >> Who.is - Who.is". They probably did just exactly that - DNS lookup. >> Anything in DNS is public information. > > But the nameservers for the domain don't allow public zone transfers. > So if you know the names in the zone you can look them up, but how did > the site list the names in his zone? > I just tried this with one of mine "sanxion.org" It returned > sanxion.org MX 5 minutes 100 sb.sanxion.org > sanxion.org NS 5 minutes ns-ext.isc.org > sanxion.org NS 5 minutes borg.c-l-i.net > sanxion.org NS 5 minutes ns.c-l-i.net > sanxion.org SOA 5 minutes borg.c-l-i.net. > dave.sanxion.org. 2011010900 3600 1800 604800 3600 The above might have been gotten either with separate queries for sanxion.org./in/mx sanxion.org./in/ns sanxion.org./in/soa or a single sanxion.org./in/any > sb.sanxion.orgA 5 minutes 216.235.14.46 > (Gatineau, QC, CA) > sb.sanxion.org5 minutes > 2001:4900:1:393:211:d8ff:fe9b:6b7c these are returned in the additional section when doing the mx, or any query above > www.sanxion.org A 5 minutes 85.17.60.159 > (Amsterdam, 07, NL) I guess the tool just always assumes that there's probably a www worthy asking about dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: when one view doesn't have the zone
In article , p...@mail.nsbeta.info wrote: > In fact I want to the clients that match view_b to fall into the default > view, say it's view_c. There is no fall-through in views. The search stops when it finds the first view that matches. Each view is like a totally separate server (which is actually what we did before views were added to BIND). -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
In article , Joseph S D Yao wrote: > On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: > > > > I'm jsut curious, how does "who.is" know the dns records in my domain > > (nsbeta.info)? > > > > The page shows some of my RRs exactly: > > > > http://who.is/dns/nsbeta.info/ > > > The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - > Who.is - Who.is". They probably did just exactly that - DNS lookup. > Anything in DNS is public information. But the nameservers for the domain don't allow public zone transfers. So if you know the names in the zone you can look them up, but how did the site list the names in his zone? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: get a domain's dns records
On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: > > I'm jsut curious, how does "who.is" know the dns records in my domain > (nsbeta.info)? > > The page shows some of my RRs exactly: > > http://who.is/dns/nsbeta.info/ The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - Who.is - Who.is". They probably did just exactly that - DNS lookup. Anything in DNS is public information. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-21 11:23, Kalman Feher pisze:
> The only way I can replicate the behaviour is with dnssec-enable no or with
> an unsigned version of the zone in another view. Assuming you've not
> overlapped your views in such a way (it was a very contrived test), I think
> you'll need to provide a bit more information on your configuration.
>
> -options
> -relevant view statement
> -The zone statement (from the hashed file if you are using the new dynamic
> zones feature).
> -The zone itself
> -Query logs.
>
> Without the full dig output it is hard to see what is actually happening.
> I'd suggest including that as well.
>
> If you dig axfr or dig rrsig are the signatures present?
>
I've conducted test with 'auto-dnssec allow' and that works without any
single problem, than I just change this options to 'auto-dnssec
maintain' and odd things happen.
Didn't mentioned before but this named is working with SoftHSM. But like
I said no problems with 'auto-dnssec allow'.
this is zone conf:
zone "example" {
type master;
file "var/zone/example";
allow-update { loopback; };
allow-transfer { trusted; loopback; };
auto-dnssec maintain;
key-directory "var/keys/example";
};
named.conf:
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
inet ::1 port 953 allow { ::1; } keys { "rndc-key"; };
};
acl trusted {
127.0.0.1;
172.16.7.5;
};
acl loopback {
127.0.0.1;
};
acl eth0 {
172.16.7.5;
};
options {
directory "/";
query-source address 172.16.7.5;
notify-source 172.16.7.5;
transfer-source 172.16.7.5;
port 53;
pid-file "var/run/named/named.pid";
session-keyfile "var/run/named/session.key";
listen-on {
loopback;
eth0;
};
listen-on-v6 { none; };
recursion no;
notify explicit;
allow-query { trusted; };
dnssec-enable yes;
dnssec-validation yes;
max-journal-size 100k;
random-device "/dev/urandom";
};
this is zone file:
$TTL3600
example.SOA ns1.example. bugs.x.w.example. (
1292481908
7200
3600
734400
600
)
TXT "dnssec test"
NS ns1.example.
NS ns2.example.
$ORIGIN example.
ns1 A 127.0.0.3
ns2 A 127.0.0.4
a NS ns1.a
NS ns2.a
DS 23344 5 1 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56
ns1.a IN A 127.0.0.1
ns2.a IN A 127.0.0.1
c NS ns1.c
c NS ns2.c
ns1.c IN A 127.0.0.5
ns2.c IN A 127.0.0.6
ai IN A 127.0.0.1
IN 0:0:0:0:0:0:0:1
xx IN A 127.0.0.1
IN 0:0:0:0:0:0:0:1
w IN A 127.0.0.1
*.w MX 10 ai
x.w MX 10 xx
x.y.w MX 10 xx
If I make query for RRSIG records, named is returning proper signatures.
for example for SOA record:
$ dig @127.0.0.1 example rrsig +short
SOA 10 1 3600 20110220123506 20110121113506 51587 example.
cVzWYkeTASPUiHv0DxFXpTsK4G1QkpS3sZ1jXmDCDv+EaYUs2C/kRlD9
same with AXFR, and same for zone file.
- --
regards
zbigniew jasinski
[SYStem OPerator]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNOYSaAAoJEH26UYiRhe/gNmcQALSiNOVoKWBpA/GV1WiarmDt
b+G6NZPBOtXXW4U90XDqL211TUaeXgLfwesRfIERraDxOTtCPjTx9npIoMQMLrWk
F91slmf8thgLpPzFqwe2FxMoagL/HdQ8fXrzHmdMU5Lsg8gBalJyVKL56Hozlp9R
n5LZy8+QBSJHuJKXFIZcBPPCdUW8dEJcONve01ik09gHbwcQzCuqwY7S5vYrDW2s
fZhYQUCvjdBpmf3uKH1yXiqdtUtUerZN3fCB6r4cGIkzYk98iEj5M6fngsBl49vt
SijzWbQftd0ThSxHPcEiuSom4pAuFlxN1O7Al8laIRwgme5wvtUeN+PA8sxr7FWl
cnUC///yLnYJNTJBnbIY0wiWsSTU9H4LU42tnesAKJaIBmaOR9w6QgxLs+E+pyKM
M3pnC//ZqxGirnV9YetV6mqfch23Y08yWcmjTNI8QytEoXPMMaGXyh4IYJFAiMaz
SxV5B9Be1KP1DxO2wyHwDEwrZzIkS5sl1iiaoyb+G0d9dWjuvlSmkDSZA43nYXGS
cn91vMLqUHpYCYVIy3p8w62y7+jOPrIM94vsgONjPijqlB0DZY2JsMP4q2StHUui
cYEqw5NDoCGpxPbnlMJF8FmFmv9R7r+yTPI/O5oR7I4sbhxti3eP0/oDLTlpZDfx
qF6n+qmGBcLll7mn4pUy
=dt7w
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Telling rndc Which IP Address to Use
On 01/20/2011 09:28 PM, Mark Andrews wrote: Or one can not worry about the IP address being used. The addresses are still there for backwards compatibilty with BIND 8 where only the IP address is used. TSIG is really so much stronger than any IP based authentication. It's like putting a screen door on a bank vault. There are other reasons than authentication to care about IP addresses. For example, complex policy-routed or multihomed environments where different source IPs are routed differently. By which I mean: please don't remove this option ;o) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
The only way I can replicate the behaviour is with dnssec-enable no or with an unsigned version of the zone in another view. Assuming you've not overlapped your views in such a way (it was a very contrived test), I think you'll need to provide a bit more information on your configuration. -options -relevant view statement -The zone statement (from the hashed file if you are using the new dynamic zones feature). -The zone itself -Query logs. Without the full dig output it is hard to see what is actually happening. I'd suggest including that as well. If you dig axfr or dig rrsig are the signatures present? On 21/01/11 9:13 AM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-19 18:38, Hauke Lampe pisze: > >> Another thing you might check: >> >> With "dnssec-enable no;" in named.conf, BIND still does its automatic >> DNSSEC signing but won't add RRSIG to responses. >> >> I ran across such a configuration lately. Your problem sounds similar. >> >> >> Hauke. > > that was first thing which I've checked: > > dnssec-enable yes; > > and it's of course enabled. > > I see in journal file: > > ./sbin/named-journalprint var/zone/example.jnl > > add example. 3600IN RRSIG DNSKEY 10 1 3600 > 20110218225336 20110119215336 57635 example. > Xo9o137Q4BmELA0wumTLujJkHq0b/tDbYvuFCfZDfcbp8cuutDJUxCPy > > add example. 3600IN RRSIG DNSKEY 10 1 3600 > 20110218225336 20110119215336 57636 example. > SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN > > add example. 3600IN RRSIG SOA 10 1 3600 > 20110218225336 20110119215336 57635 example. > wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW > > > also RRSIG for SOA record and for DNSKEY records are present in plain > zone file but still named isn't responding with correct signatures. > > - -- > regards > > zbigniew jasinski > [SYStem OPerator] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNOUAtAAoJEH26UYiRhe/goMcP/i5MLxBFh8+Fl2R2oqIKdRR1 > ntBcfXBK1niJmlDpFzGu97gXNxoofk/bWVEhb+eo/e4+ln8bSuOiKVV5PQJ8zq1t > ke5jCIw7iRdBQgMcZNHQCWcI1lCWnPc0SxcCtw6u2ZItfFxqwANwFJw0oXwX/C8i > iVGflBdSUI9G/MGIaCsiwBdNBZnVhgrVz5F3KHXKC6aH49HI9kieXqz8v9pczcGR > xoy/RRrgObvb8N4jz2GA+fq8thFoKzZkoWLWG/5eE9uYd8oY3wLHIoAt0jBfGXOR > UXrFQ1QDqjUdotb3ovUGH2NH1NpWnITYm9gDWqEo3egaLpQU6itc2z57BNkuIkPS > qn3m2rgnEKy+p6flLYNxwyYnrXWVIpti73r+aPpkWQpWptEBcyCIl2su6yLZPv1y > R7ioFCualJLOWWqio9w5hQeRUvgrF6w7XBc97PMWgwLSrjHF0XADOWn9IqB4/XgA > agPSo7p8D6mmfpnv9c+q1JVIUEhEqihNs5/c1/dhRRn4SRIucvvzuVlXB/gqVQep > i+Ft2Tq3zgepBOxLGtZQ22o7VoBSWj8tHT6qRDG9qChsOXE054eN+r8xNbJ4rRzu > oASw1n11vm0JAqceMeadCc0Zz2y4WbIJO7jEsPTp9KUHPNwbDmNnMH7pWyHvxS4v > oZD7PbxPnyDpwRerG7zh > =Sp+3 > -END PGP SIGNATURE- > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-19 18:38, Hauke Lampe pisze: > Another thing you might check: > > With "dnssec-enable no;" in named.conf, BIND still does its automatic > DNSSEC signing but won't add RRSIG to responses. > > I ran across such a configuration lately. Your problem sounds similar. > > > Hauke. that was first thing which I've checked: dnssec-enable yes; and it's of course enabled. I see in journal file: ./sbin/named-journalprint var/zone/example.jnl add example. 3600IN RRSIG DNSKEY 10 1 3600 20110218225336 20110119215336 57635 example. Xo9o137Q4BmELA0wumTLujJkHq0b/tDbYvuFCfZDfcbp8cuutDJUxCPy add example. 3600IN RRSIG DNSKEY 10 1 3600 20110218225336 20110119215336 57636 example. SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN add example. 3600IN RRSIG SOA 10 1 3600 20110218225336 20110119215336 57635 example. wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW also RRSIG for SOA record and for DNSKEY records are present in plain zone file but still named isn't responding with correct signatures. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOUAtAAoJEH26UYiRhe/goMcP/i5MLxBFh8+Fl2R2oqIKdRR1 ntBcfXBK1niJmlDpFzGu97gXNxoofk/bWVEhb+eo/e4+ln8bSuOiKVV5PQJ8zq1t ke5jCIw7iRdBQgMcZNHQCWcI1lCWnPc0SxcCtw6u2ZItfFxqwANwFJw0oXwX/C8i iVGflBdSUI9G/MGIaCsiwBdNBZnVhgrVz5F3KHXKC6aH49HI9kieXqz8v9pczcGR xoy/RRrgObvb8N4jz2GA+fq8thFoKzZkoWLWG/5eE9uYd8oY3wLHIoAt0jBfGXOR UXrFQ1QDqjUdotb3ovUGH2NH1NpWnITYm9gDWqEo3egaLpQU6itc2z57BNkuIkPS qn3m2rgnEKy+p6flLYNxwyYnrXWVIpti73r+aPpkWQpWptEBcyCIl2su6yLZPv1y R7ioFCualJLOWWqio9w5hQeRUvgrF6w7XBc97PMWgwLSrjHF0XADOWn9IqB4/XgA agPSo7p8D6mmfpnv9c+q1JVIUEhEqihNs5/c1/dhRRn4SRIucvvzuVlXB/gqVQep i+Ft2Tq3zgepBOxLGtZQ22o7VoBSWj8tHT6qRDG9qChsOXE054eN+r8xNbJ4rRzu oASw1n11vm0JAqceMeadCc0Zz2y4WbIJO7jEsPTp9KUHPNwbDmNnMH7pWyHvxS4v oZD7PbxPnyDpwRerG7zh =Sp+3 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
