Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV
On Tue, 2009-05-05 at 13:45 -0500, Jeremy C. Reed wrote: > On Tue, 5 May 2009, Stephane Bortzmeyer wrote: > > > This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's > > DLV: > > https://www.isc.org/node/437 Question on using "trusted-keys": There are two public sources of "trusted-keys" - ISC's DLV via http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf and Iana's ITAR via https://itar.iana.org/anchors/anchors.xml (though this needs to be 'expanded'). One might also have one's own personal list for local use? Some sections in "named.conf" should logically only be there once (eg, options and logging), some should be there multiple times (zone definitions). Can "trusted-keys" be defined multiple times? - or should there only be one trusted-keys section? I know multiple keys in one trusted-keys section works just fine - which might imply one can only have one trusted-key definition? A 'man named.conf' is not immediately obvious about this. -- . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV
In message <1241593258.1629.60.ca...@ilinux>, Mark Elkins writes: > On Tue, 2009-05-05 at 13:45 -0500, Jeremy C. Reed wrote: > > On Tue, 5 May 2009, Stephane Bortzmeyer wrote: > > > > > This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's > > > DLV: > > > > https://www.isc.org/node/437 > > Question on using "trusted-keys": > > There are two public sources of "trusted-keys" - ISC's DLV via > http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf and Iana's ITAR via > https://itar.iana.org/anchors/anchors.xml (though this needs to be > 'expanded'). > One might also have one's own personal list for local use? > > > Some sections in "named.conf" should logically only be there once (eg, > options and logging), some should be there multiple times (zone > definitions). > > Can "trusted-keys" be defined multiple times? Yes. > - or should there only be > one trusted-keys section? I know multiple keys in one trusted-keys > section works just fine - which might imply one can only have one > trusted-key definition? > > A 'man named.conf' is not immediately obvious about this. > > -- > . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready > /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE > / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 > > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tcp versus udp
In article , Danny Mayer wrote: > Peter Dambier wrote: > > Hello Martin, > > > > since a major outage at my provider, dtag.de or Deutsche Telecom AG, I have > > trouble > > with f.root-servers.net. Sometimes "dig ... +vc" does help me to see > > f.root-servers.net. > > > > The real problem is anycast. With udp it behaves different than with tcp. > > That's nonsense. anycast is invisible to this. anycast doesn't care if > it's udp or tcp, it only deals with the routing tables to determine > where to send the request packet. It's not quite nonsense, only very nearly. One can imagine a corner case where a router has equal cost paths to more than one anycast instance and that same router is set up to do per-packet load balancing, then it might not be possible to set up a TCP connection to that anycast address through that router. This is likely to be a rare occurrence. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tcp versus udp
In article , Mark Elkins wrote: > One place that TCP may make sense - if you are involved in a registry > system and the process involves actually checking the information that > you are given, including nameservers (do they exist, do they serve that > zone - correctly?) - it may make a lot of sense to do TCP Digs for the > information (though that should probably be after a failed UDP dig - as > a number of people do insist on disallowing Port 53 TCP). If the registry is testing for compliant servers then a failed TCP query should flag the server as non-working, as would a failed UDP query. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind Statistics questions
Hi, Comments inline. Thanks in any advance. Best Regards, NR 2009/5/5 JINMEI Tatuya / 神明達哉 > At Tue, 5 May 2009 11:11:13 +0100, > Nuno Ribeiro wrote: > > > I have some doubts and I would like clarify them: > > - Bind ( version 9.5) provides lots of statistics information and > provides > > two interfaces for users to get access to it (file dump and HTTP access). > > For what I see and read the counters are cumulative during the time the > > service is running. My question is if it possible to reset the counter > > statistics in real time in order to have statistic details in a time > > interval? > > It's currently not possible. We've actually discussed before, so you > might want to search the mail archive. It would not be difficult to > implement it, but I've personally not yet seen a strong argument for > it. Most if not all of the things that the reset feature could > provide can be achieved by post-processing cumulative data, so, for > now I'd rather keep the server side simple. > > > Other question is if there is any statistic detail provide us information > > such this "average time answering to queries of type A" > > The answer would be no anyway, but I'm afraid the question is also not > very clear. Can you define "average time answering to queries of type > A" more precisely? (e.g. it's not even clear about an authoritative > server or a recursive server) [NR] I didn't saw yet any option (logging or statistics) that allows an administrator to know which time Bind is taking to process a query (by type of query) and answer to it . This could be saved as general indicators associated to the number of incoming queries (divided by type of query). If this is not possible yet, is there any log that can be activated that allows me to know the time that Bind is is taking to process a query in order to build some post-processing logic that could give me these indicators. Note: I'm considering questions to an authoritative server > > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > -- Nuno Ribeiro ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
child zone not forwarded
Hi,
I have a authorative zone xxx.com and its child as a FORWARD zone to a local
dns...But child is not working, seems like the requests are not forwarded at
all and locally ansvered...Why?
thank you
zone "child.xxx.com" {
type forward;
forward only;
forwarders { 10.129.3.34;};
};
zone "xxx.com" {
type master;
file "dmz.dom";
allow-update { none; };
allow-query { localhost;
can_query; }
};
This message and attachments are confidential and intended solely for the
individual(s) stated in this message. If you received this message although you
are not the addressee, you are responsible to keep the message confidential.
The sender has no responsibility for the accuracy or correctness of the
information in the message and its attachments. Our company shall have no
liability for any changes or late receiving, loss of integrity and
confidentiality, viruses and any damages caused in anyway to your computer
system.
Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve
gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi
halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi
zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan
bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin
herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin
size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin
korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi
herhangi bir zarardan sorumlu tutulamaz. ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: child zone not forwarded
You have to make sure that you actually have NS delegations in xxx.com for
child.xxx.com. That has bitten me on occasion.
If you load the parent and the parent has no NS delegation for a child, it
assumes the child doesn't really exist and ignores the zone forward.
--
-Ben Croswell
2009/5/6 Cihan Subasi (Garanti Teknoloji)
> Hi,
>
> I have a authorative zone xxx.com and its child as a FORWARD zone to a
> local dns...But child is not working, seems like the requests are not
> forwarded at all and locally ansvered...Why?
>
> thank you
>
> zone "child.xxx.com" {
> type forward;
> forward only;
> forwarders { 10.129.3.34;};
> };
> zone "xxx.com" {
> type master;
> file "dmz.dom";
> allow-update { none; };
> allow-query { localhost;
> can_query; }
> };
>
> This message and attachments are confidential and intended solely for the
> individual(s) stated in this
> message. If you received this message although you are not the addressee,
> you are responsible to keep the
> message confidential. The sender has no responsibility for the accuracy or
> correctness of the
> information in the message and its attachments. Our company shall have no
> liability for any changes
> or late receiving, loss of integrity and confidentiality, viruses and any
> damages caused in
> anyway to your computer system.
>
> Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir
> ve gizlidir. Bu mesajin muhatabi
> olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin
> gizliligi ve bu gizlilik yukumlulugune
> uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde
> yer alan bilgilerin dogrulugu ve
> guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu
> bulunmamaktadir. Sirketimiz
> mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan,
> butunlugunun ve gizliliginin
> korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi
> herhangi bir zarardan
> sorumlu tutulamaz.
>
> ___
> 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
NXRRSET
Hello, I am running BIND version 9.2.3 on a Solaris 9 box. Every now and then I will see the following in my DNS cache: domain.com. 458 \- ;-$NXRRSET If I force a MX record lookup it does get the correct MX records for " domain.com". The explanation I have for "NXRRSET" is "Its the number od queries the name server handled that resulted in responses saying that the type of record the querier requested didn't exist for the domain name it specified". If do a MX record look for "domain.com" it does get the correct entries and caches it for the specified TTL. My question is how do I go about identifying what's causing my BIND server to cache a query with the flag "NXRRSET" ? Thank you in advance ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NXRRSET
On May 6, 2009, at 7:49 AM, Thilanka Samarasekera wrote: Hello, I am running BIND version 9.2.3 on a Solaris 9 box. Every now and then I will see the following in my DNS cache: domain.com. 458 \- ;-$NXRRSET If I force a MX record lookup it does get the correct MX records for "domain.com". The explanation I have for "NXRRSET" is "Its the number od queries the name server handled that resulted in responses saying that the type of record the querier requested didn't exist for the domain name it specified". If do a MX record look for "domain.com" it does get the correct entries and caches it for the specified TTL. My question is how do I go about identifying what's causing my BIND server to cache a query with the flag "NXRRSET" ? The query getting the negative response here is for an record named domain.com. For example, there might be: example.com. MX 10 mx.example.com. mx.example.com. A 192.0.2.1 Your cache might then end up with an NXRRSET (no such resource record set) for mx.example.com/IN/, because the mail server is looking for IPv6 addresses for the mail server. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tcp versus udp
In article , Sam Wilson wrote: > In article , Mark Elkins > wrote: > > > One place that TCP may make sense - if you are involved in a registry > > system and the process involves actually checking the information that > > you are given, including nameservers (do they exist, do they serve that > > zone - correctly?) - it may make a lot of sense to do TCP Digs for the > > information (though that should probably be after a failed UDP dig - as > > a number of people do insist on disallowing Port 53 TCP). > > If the registry is testing for compliant servers then a failed TCP query > should flag the server as non-working, as would a failed UDP query. DNS servers MUST support UDP, and only SHOULD support TCP. So a failed TCP query should not flag the server as non-working. -- 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: tcp versus udp
In message , Barry Margolin writes: > In article , > Sam Wilson wrote: > > > In article , Mark Elkins > > wrote: > > > > > One place that TCP may make sense - if you are involved in a registry > > > system and the process involves actually checking the information that > > > you are given, including nameservers (do they exist, do they serve that > > > zone - correctly?) - it may make a lot of sense to do TCP Digs for the > > > information (though that should probably be after a failed UDP dig - as > > > a number of people do insist on disallowing Port 53 TCP). > > > > If the registry is testing for compliant servers then a failed TCP query > > should flag the server as non-working, as would a failed UDP query. > > DNS servers MUST support UDP, and only SHOULD support TCP. So a failed > TCP query should not flag the server as non-working. I would expect TLD's to not accept DNSSEC material without a working TCP/DNS service. There are too many cases where resolvers are forced back to TCP with DNSSEC to allow it to happen. I also suspect that 99.9% of people that block DNS/TCP do so without the necessary considerations required to override the SHOULD of RFC 1123, Section 6.1.5. Anyone that thinks TCP is only used for AXFR and can therefore be blocked clearly has not done the relevent study. Mark RFC 1123. *"SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
