Re: Validating a DNSSEC installation

[Erik Lotspeich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Chris,

Thanks for your response -- that explains it.  I hope that you don't
mind if I continue this discussion with another question.

I changed my configuration to use views to separate my external zone
(for which BIND is authoritative) from internal clients (which should
use BIND as a validating resolver).  I now receive the expected behavior
- -- sort of.

r...@starfish:/home/erik# dig +dnssec +adflag @localhost lotspeich.org

; <<>> DiG 9.6.1 <<>> +dnssec +adflag @localhost lotspeich.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60454
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[snip]

r...@starfish:/home/erik# dig +adflag @localhost lotspeich.org

; <<>> DiG 9.6.1 <<>> +adflag @localhost lotspeich.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3194
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

As you can see, the ad bit is set when +dnssec is used along with
+adflag.  However, I can receive the ad bit without +dnssec when making
other queries:

r...@starfish:/home/erik# dig +adflag isc.org.

; <<>> DiG 9.6.1 <<>> +adflag isc.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6612
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

Is this expected or do I need to fine-tune my configuration further?

Thanks,

Erik.

Chris Buxton wrote:
> On Jun 13, 2009, at 4:59 AM, Erik Lotspeich wrote:
>> Is it normal that a validating resolver can't validate a domain it is
>> authoritative for?
> 
> Absolutely. As Alan Clegg wrote not long ago on this list, this is why a
> DNSSEC validating resolver should not be authoritative for any signed
> zones.
> 
> Chris Buxton
> Professional Services
> Men & Mice
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAko4jHMACgkQY21D/n6bGwcU8QCgvliX8Hbu3A0BvTjbo9LxaS8B
EBkAn0m0N9btGvXrGaiORug3M03RF7Eh
=Fpf5
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Validating a DNSSEC installation

[Chris Buxton]

On Jun 16, 2009, at 4:08 AM, Chris Thompson wrote:

On Jun 15 2009, Chris Buxton wrote:
On Jun 13, 2009, at 4:59 AM, Erik Lotspeich wrote:
Is it normal that a validating resolver can't validate a domain it  
is

authoritative for?


Absolutely. As Alan Clegg wrote not long ago on this list,


You presumably refer to

https://lists.isc.org/pipermail/bind-users/2009-January/074760.html

which I *suppose* counts as "not long ago" ... :-)


That's not long ago to me... it was this year after all. :-)

 this is  
why  a DNSSEC validating resolver should not be authoritative for  
any  signed zones.


This seems too strong to me, There are lots of good reasons why one  
may
want a resolver to stealth slave local (possibly signed) zones, and  
thus
be "authoritative" for them. However, it is certainly the case that  
because
no other validation is performed on these zones, they should be  
fetched
by secure means, e.g. TSIG-signed transfers from trusted master  
servers.


As a purist, I dislike stealth slaves. They're too error-prone. It's  
better to use a stub zone if necessary, in my opinion.


That said, if only DNSSEC-ignorant resolvers (including stub  
resolvers) are querying the server, then yes, there is a valid case to  
be made for a stealth slave. But even then, if the zone has any  
subzones, or might ever be given any subzones, then I believe there  
will be problems unless the resolving stealth slave is also given  
trust anchors for all such subzones. It's better and simpler, then, to  
use a single trust anchor and a stub zone (a resolver hint) for the  
domain apex rather than a slave zone.


Chris Buxton
Professional Services
Men & Mice

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: create journal file: permission denied

[Mark Andrews]

In message , Dan Le
tkeman writes:
> Hello,
> 
> I'm trying to setup ddns and the log file is showing that it cannot
> create the journal file
> 
> 
> 16-Jun-2009 22:03:30.145 update: info: client 172.16.56.111#63970:
> updating zone 'dan.net/IN': error: journal open failed: unexpected
> error
> 16-Jun-2009 22:03:30.211 update: info: client 172.16.56.111#63970:
> updating zone 'dan.net/IN': deleting rrset at 'none.dan.net' A
> 16-Jun-2009 22:03:30.212 update: info: client 172.16.56.111#63970:
> updating zone 'dan.net/IN': adding an RR at 'none.dan.net' A
> 16-Jun-2009 22:03:30.212 general: info: journal file
> /var/named/dan.net/dan.net.hosts.jnl does not exist, creating it
> 16-Jun-2009 22:03:30.218 general: error:
> /var/named/dan.net/dan.net.hosts.jnl: create: permission denied
> 16-Jun-2009 22:03:30.218 update: info: client 172.16.56.111#63970:
> updating zone 'dan.net/IN': error: journal open failed: unexpected
> error
> 
> I have tried moving the zone into it's own directory and giving the
> named user full rights to it but it is still unable to create the
> file.
> 
> Is there anything else I can try?

/var/named/dan.net needs to be writable by named.  If you
are using a Linux box you may also need to ensure that
SELinux is properly configured to allow the write.  See the
FAQ for how to do this.

Mark
 
> Thanks,
> Dan.
> ___
> 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

create journal file: permission denied

[Dan Letkeman]

Hello,

I'm trying to setup ddns and the log file is showing that it cannot
create the journal file


16-Jun-2009 22:03:30.145 update: info: client 172.16.56.111#63970:
updating zone 'dan.net/IN': error: journal open failed: unexpected
error
16-Jun-2009 22:03:30.211 update: info: client 172.16.56.111#63970:
updating zone 'dan.net/IN': deleting rrset at 'none.dan.net' A
16-Jun-2009 22:03:30.212 update: info: client 172.16.56.111#63970:
updating zone 'dan.net/IN': adding an RR at 'none.dan.net' A
16-Jun-2009 22:03:30.212 general: info: journal file
/var/named/dan.net/dan.net.hosts.jnl does not exist, creating it
16-Jun-2009 22:03:30.218 general: error:
/var/named/dan.net/dan.net.hosts.jnl: create: permission denied
16-Jun-2009 22:03:30.218 update: info: client 172.16.56.111#63970:
updating zone 'dan.net/IN': error: journal open failed: unexpected
error

I have tried moving the zone into it's own directory and giving the
named user full rights to it but it is still unable to create the
file.

Is there anything else I can try?

Thanks,
Dan.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSDigger.com - An announcement and request for feature tips.

[Joe Baptista]

On Tue, Jun 16, 2009 at 10:36 PM, Frank Bulk  wrote:

> Sounds interesting.
>
> How is it different than these?:
> http://whois.webhosting.info


That one is a bit wacky.  It tells me the TLD for the Peking University
Domain Name : "xn--1lq90ic7fzpc.xn--fiqs8s" is Invalid!  That's a lie.  300
million people in china can resolve the chinese character domain name for
peking university.  Obviously this beta can't see China either.  Thats
unfortunate.  I like digger better.


> http://www.domaintools.com/reverse-ip/


Can't see China either.  I digger better.

So far when it comes to China - they all have myopic vision - I thing digger
is a winner for information.  I would recommend all these tool be more user
friendly to the Chinese Citizen.  Three hundred million people in china
would appreciate knowing they could find their national university at
digger.

My two two cents ;)
joe baptista



> 
>
> Frank
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jay Ess
> Sent: Tuesday, June 16, 2009 7:19 PM
> To: bind-us...@isc.org
> Subject: DNSDigger.com - An announcement and request for feature tips.
>
> DNSDigger.com - A massive reverse resolver that lets you dig deeper into
> the
> Net.
>
> DNSDigger.com is a service that lets you get more information about an
> domain
> name. It can show you what other domain names is hosted on a server.
> For example can that information be a valuable data for a hosting company
> that
> want to estimate how many customers a competitor has or se what other
> domains is
> hosted on a shared server and estimate the likelihood of that server being
> DDOSed.
>
> I am posting this to the Bind emailing list for two reasons.
> 1. To announce a relevant service (relevant to DNS)
> 2. To ask you for feature requests.
>
> I hope you don't get to pissed off ;)
>
> ___
> 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
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium

The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.

 Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSDigger.com - An announcement and request for feature tips.

[Joe Baptista]

Can DNSdigger see .GOD?  What about .SATAN.

Does DNSdigger see the Peking University on the China National TLD DNS?
What happens if I ask it a question on the domain 北京大学.中国 or the equivalent
ascii IDN of  xn--1lq90ic7fzpc.xn--fiqs8s ?

Well I tried digger.  I know it does not speak Chinese, Peaking University
at 北京大学.中国 does not resolve.  Nor does the ascii xn--1lq90ic7fzpc.xn--fiqs8s
resolve - so we can assume digger can't yet see China.  Thats unfortunate.

Until digger can see China - it sure won't see .GOD and .SATAN.

But that fault aside - I like digger.  I'll use it - so sad it has limited
vision of the name space.  But I'm sure it will improve.

cheers
joe baptista

- thats one recommend bookmark ;)


On Tue, Jun 16, 2009 at 8:19 PM, Jay Ess  wrote:

> DNSDigger.com - A massive reverse resolver that lets you dig deeper into
> the Net.
>
> DNSDigger.com is a service that lets you get more information about an
> domain name. It can show you what other domain names is hosted on a server.
> For example can that information be a valuable data for a hosting company
> that want to estimate how many customers a competitor has or se what other
> domains is hosted on a shared server and estimate the likelihood of that
> server being DDOSed.
>
>
> I am posting this to the Bind emailing list for two reasons.
> 1. To announce a relevant service (relevant to DNS)
> 2. To ask you for feature requests.
>
> I hope you don't get to pissed off ;)
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium

The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.

 Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dynamic dns updates from cisco router dhcp

[Dan Letkeman]

Hello,

I have setup dynamic dns updates from a cisco router which is handing
out dhcp addresses.  In the debug's i'm getting messages that say
REFUSED and SERVFAIL when trying to do a dynamic update.

I'm unsure as to where the problem lies, but I think it might have to
do with the security on the BIND server.  I have added the networks to
the zone via the allow-update option.  But whatever I try I still get
the REFUSED error on the router.

Here is my config:

acl ecs {
172.16.56.0/21;
};
acl home {
192.168.75.229;
};
acl slaves {
172.16.200.151;
192.168.75.115;
};

options {
directory "/etc";
pid-file "/var/run/named/named.pid";
forwarders {
142.161.130.155;
142.161.2.155;
};
notify yes;
allow-recursion {
172.16.0.0/16;
192.168.75.0/24;
};
query-source address 172.16.200.150;

sortlist {
   { 192.168.75/24;
 { 172.16.88/21; };
   };
   { 172.16.56/21;
 { 172.16.56/21; };
   };
 };

};

zone "16.172.in-addr.arpa" {
type master;
file "/var/named/172.16.rev";
notify yes;
also-notify {
172.16.200.151;
172.16.56.250;
};
};
zone "tech.net" {
type master;
file "/var/named/tech.net.hosts";
notify yes;
also-notify {
172.16.200.151;
172.16.56.250;
};
};
zone "me.net" {
type master;
file "/var/named/me.net.hosts";
also-notify {
172.16.200.151;
192.168.75.115;
};
notify yes;
};
zone "." {
type hint;
file "/var/named/root.db";
};
zone "168.192.in-addr.arpa" {
type master;
file "/var/named/192.168.rev";
};
zone "ecs.net" {
type master;
file "/var/named/ecs.net.hosts";
};
zone "me.com" {
type master;
file "/var/named/me.com.hosts";
};
zone "dan.net" {
type master;
file "/var/named/dan.net.hosts";
allow-update {
192.168.75.1;
172.16.56.111;
192.168.75.31;
};
};
controls {
};


The zone i'm trying to send dynamic updates to is the last one.

Thanks,
Dan.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: DNSDigger.com - An announcement and request for feature tips.

[Frank Bulk]

Sounds interesting.

How is it different than these?:
http://whois.webhosting.info
http://www.domaintools.com/reverse-ip/

Frank

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jay Ess
Sent: Tuesday, June 16, 2009 7:19 PM
To: bind-us...@isc.org
Subject: DNSDigger.com - An announcement and request for feature tips.

DNSDigger.com - A massive reverse resolver that lets you dig deeper into the
Net.

DNSDigger.com is a service that lets you get more information about an
domain 
name. It can show you what other domain names is hosted on a server.
For example can that information be a valuable data for a hosting company
that 
want to estimate how many customers a competitor has or se what other
domains is 
hosted on a shared server and estimate the likelihood of that server being
DDOSed.

I am posting this to the Bind emailing list for two reasons.
1. To announce a relevant service (relevant to DNS)
2. To ask you for feature requests.

I hope you don't get to pissed off ;)

___
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: queries with no RD bit set are truncating

[Mark Andrews]

In message , Peter
 Andreev writes:
> Kevin, this server is totally non-recursive. Neither recurse option is
> enabled and packet size does not exceed 512 byte. May be it was some
> temporarly bugs due to mysterious causes.

I suspect someone has modified the server to mitigate it
being used in a amplification attack.  By returning TC you
force TCP and all real iterative resolvers should handle
that.  Spoofed sources won't see the reply.

Mark
 
-- 
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

DNSDigger.com - An announcement and request for feature tips.

[Jay Ess]

DNSDigger.com - A massive reverse resolver that lets you dig deeper into the 
Net.

DNSDigger.com is a service that lets you get more information about an domain 
name. It can show you what other domain names is hosted on a server.
For example can that information be a valuable data for a hosting company that 
want to estimate how many customers a competitor has or se what other domains is 
hosted on a shared server and estimate the likelihood of that server being DDOSed.



I am posting this to the Bind emailing list for two reasons.
1. To announce a relevant service (relevant to DNS)
2. To ask you for feature requests.

I hope you don't get to pissed off ;)

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Questions about DNAME records

[Michael Milligan]

Chris Buxton wrote:
> On Jun 15, 2009, at 2:37 AM, Braebaum, Neil wrote:
> Now, ignoring that invalid "www" record, the zone above has an apex
> (example.com itself) and then essentially infinite ghostly children. Any
> valid query that lands in that domain (i.e. the qname ends in
> example.com) but is not for example.com itself will be answered by a
> synthetic CNAME record, like this:
> 
> qname.example.com.CNAMEqname.example2.com.
> 
> If that alias points to a valid name in example2.com, then the query is
> answered positively. If it points to a CNAME record in the example2.com
> domain, then you have a CNAME chain (an alias of an alias of a third,
> referenced name), which then causes resolution to continue with the
> referenced name. (Is this what you meant by "forwarding"?)

Don't forget that the DNAME record is also included in the answer as
well as the synthesized CNAME record(s).  I say records since DNAME
chains are possible here too (though not recommended of course).

Regards,
Mike

-- 
Michael Milligan   -> mi...@acmeps.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Questions about DNAME records

[Chris Buxton]

On Jun 16, 2009, at 1:37 AM, Braebaum, Neil wrote:

What I was getting at - probably worded poorly - was say I wanted to
provide resolution for something like:-

_service._tcp.example.com.

if I'd previously created the DNAME record (example.com.IN
DNAME   example2.com.), would creating a SRV RR record in
example2.com.:-

_service._tcp.example2.com.

work as resolution for it?


Yes. The final and complete answer will be:

_service._tcp.example.com.  IN  CNAME   _service._tcp.example2.com.
_service._tcp.example2.com. IN  SRV ... 4 fields here ...


As to the forwarding thing, what I was thinking of, is that
example2.com. forwards out to internet DNS servers for external
resolution


Unfortunately, that's a nonsensical assertion. A domain does not  
forward. A DNS server forwards.



and it just so happens that example.com. is a namespace we
use externally. So would it work in the scenario I've given, that if I
wanted to provide resolution for _service._tcp.example.com. (if it  
works

with the DNAME scenario I've described above), would other records for
example.com. that aren't catered for in example2.com., be obtained by
merit of example2.com. forwarding? Or would the DNAME configuration  
not

allow it?


A DNAME record precludes child names. That is, you cannot have any  
names of the form "foo.example.com" and also have a DNAME record named  
"example.com".



I guess what I'm wondering is that if example.com. is DNAMEd
to example2.com. and the records aren't in example2.com. does the
enquiry end there, or could / would the question be dealt with by  
merit

of example2.com. forwarding to internet DNS servers?


If you have a DNAME record named example.com, then aside from other  
records named example.com, there cannot be any other records in the  
example.com zone. No subdomains are allowed.


So if example.com is hosted on the outside, and example2.com is  
internal, an internal resolver will see the external DNAME record (and  
related, synthesized CNAME records) and be able to resolve them inside  
example2.com (assuming it can find example2.com).


If there is no external version of example2.com, then you're creating  
problems, because a DNAME record from a public zone to a strictly  
private zone will cause resolution for the public for names in the  
example.com domain (except example.com itself) to fail.


Unfortunately, if this explanation isn't clear, I would need to know  
exactly what you're trying to accomplish, probably including real  
names, in order to help further. My employer offers confidential DNS  
consulting service for a fee, if that would be useful to you.


Chris Buxton
Professional Services
Men & Mice

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Validating a DNSSEC installation

[Chris Thompson]

On Jun 15 2009, Chris Buxton wrote:


On Jun 13, 2009, at 4:59 AM, Erik Lotspeich wrote:

Is it normal that a validating resolver can't validate a domain it is
authoritative for?


Absolutely. As Alan Clegg wrote not long ago on this list,


You presumably refer to

 https://lists.isc.org/pipermail/bind-users/2009-January/074760.html

which I *suppose* counts as "not long ago" ... :-)

  this is why  
a DNSSEC validating resolver should not be authoritative for any  
signed zones.


This seems too strong to me, There are lots of good reasons why one may
want a resolver to stealth slave local (possibly signed) zones, and thus
be "authoritative" for them. However, it is certainly the case that because
no other validation is performed on these zones, they should be fetched
by secure means, e.g. TSIG-signed transfers from trusted master servers.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: queries with no RD bit set are truncating

[Peter Andreev]

Kevin, this server is totally non-recursive. Neither recurse option is
enabled and packet size does not exceed 512 byte. May be it was some
temporarly bugs due to mysterious causes.

Below I post full sniffer's output for both queries:

No. TimeSourceDestination   Protocol
Info
  1 0.00193.110.129.66194.85.61.20  DNS
Standard query MX lbr.ru

Frame 1 (66 bytes on wire, 66 bytes captured)
Arrival Time: Jun  9, 2009 10:21:34.40548
[Time delta from previous captured frame: 0.0 seconds]
[Time delta from previous displayed frame: 0.0 seconds]
[Time since reference or first frame: 0.0 seconds]
Frame Number: 1
Frame Length: 66 bytes
Capture Length: 66 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:dns]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Intel_db:50:96 (00:0e:0c:db:50:96), Dst:
All-HSRP-routers_c7 (00:00:0c:07:ac:c7)
Destination: All-HSRP-routers_c7 (00:00:0c:07:ac:c7)
Address: All-HSRP-routers_c7 (00:00:0c:07:ac:c7)
 ...0     = IG bit: Individual address (unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Source: Intel_db:50:96 (00:0e:0c:db:50:96)
Address: Intel_db:50:96 (00:0e:0c:db:50:96)
 ...0     = IG bit: Individual address (unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: 193.110.129.66 (193.110.129.66), Dst: 194.85.61.20
(194.85.61.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..0. = ECN-Capable Transport (ECT): 0
 ...0 = ECN-CE: 0
Total Length: 52
Identification: 0x7b9b (31643)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 126
Protocol: UDP (0x11)
Header checksum: 0x7f03 [correct]
[Good: True]
[Bad : False]
Source: 193.110.129.66 (193.110.129.66)
Destination: 194.85.61.20 (194.85.61.20)
User Datagram Protocol, Src Port: 11173 (11173), Dst Port: domain (53)
Source port: 11173 (11173)
Destination port: domain (53)
Length: 32
Checksum: 0xec71 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Domain Name System (query)
[Response In: 2]
Transaction ID: 0xc7e5
Flags: 0x (Standard query)
0...    = Response: Message is a query
.000 0...   = Opcode: Standard query (0)
 ..0.   = Truncated: Message is not truncated
 ...0   = Recursion desired: Don't do query recursively
  .0..  = Z: reserved (0)
  ...0  = Non-authenticated data OK: Non-authenticated
data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
lbr.ru: type MX, class IN
Name: lbr.ru
Type: MX (Mail exchange)
Class: IN (0x0001)

No. TimeSourceDestination   Protocol
Info
  2 0.034553194.85.61.20  193.110.129.66DNS
Standard query response

Frame 2 (66 bytes on wire, 66 bytes captured)
Arrival Time: Jun  9, 2009 10:21:34.440033000
[Time delta from previous captured frame: 0.034553000 seconds]
[Time delta from previous displayed frame: 0.034553000 seconds]
[Time since reference or first frame: 0.034553000 seconds]
Frame Number: 2
Frame Length: 66 bytes
Capture Length: 66 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:dns]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Cisco_ff:e0:1b (00:0b:bf:ff:e0:1b), Dst: Intel_db:50:96
(00:0e:0c:db:50:96)
Destination: Intel_db:50:96 (00:0e:0c:db:50:96)
Address: Intel_db:50:96 (00:0e:0c:db:50:96)
 ...0     = IG bit: Individual address (unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Source: Cisco_ff:e0:1b (00:0b:bf:ff:e0:1b)
Address: Cisco_ff:e0:1b (00:0b:bf:ff:e0:1b)
 ...0     = IG bit: Individual address (unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol, Src: 194.85.61.20 (194.85.61.20), Dst: 193.110.129.66
(193.110.129.66)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..0. = ECN-Capable Transport (ECT): 0
 ..

about server failure cache

[liuqiang]

hi,
   A recursive name  server A  receives a recursive query from a client,but the 
authoritative name server B for the query zone is dead. So name server A return 
a server failure answer to the client.
   I want to konw if name  server A send a query to name server B when another 
client ask the same domain of the zone.
   In other words my question is if the name server cache  server failure 
infomation.
 
Best Regards,
 liuqiang___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users