Re: [UNsolved] was: what does dig +trace do?

[Mark Andrews]

In message <4e66b5b5.30...@chrysler.com>, Kevin Darcy writes:
> On 9/1/2011 7:57 PM, Mark Andrews wrote:
> > In message<4e5fb1ab.4040...@data.pl>, Torinthiel writes:
> >> On 09/01/11 17:56, Tom Schmitt wrote:
> >>> =20
> >>> I found the cause of my problem (and a solution):
> >>> =20
> >>> dig +trace actually has another behaviour than doing the trace manually=
> >>   step by step with dig.
> >>> =20
> >>> =20
> >>> For a trace, dig is asking for the NS-records, then for the IP-address =
> >> of the nameserver found and then go on asking this nameserver. Till the d=
> >> estination is reached.
> >>> =20
> >>> In my case, dig is asking for the nameservers of the root-zone and is g=
> >> etting the answer:
> >>> . IN NS root1
> >>> . IN NS root2=20
> >>> etc
> >>> =20
> >>> Next dig is asking for the A-record of root1. And here is the differren=
> >> ce:
> >>> =20
> >>> If I do "dig root1" dig is asking exactly this, it is asking for the A-=
> >> record of root1. And of course I get the correct answer from named.
> >>> =20
> >>> The +trace option does not do this!
> >>> Instead, the +trace-option is using the searchsuffix in the resolv.conf=
> >>   and is asking for root1.my.search.suffix. and NOT for root1.
> >>> This is why the +trace option fails every time.
> >>> =20
> >>> After deleting the searchsuffix in resolv.conf, dig +trace is working f=
> >> ine without any error.
> >>> =20
> >>> In my oppinion it's a bug that dig +trace behave in a differrent way th=
> >> an doing the queries with dig one by one.
> >>
> >> No, IMHO, it's a bug in your root zone.
> >> Names without dot at end are relative. Change your root zone to say
> >> =2E IN NS root1.
> >> =2E IN NS root2.
> >>
> >> (with dots appended) and you should be home.
> > "dig +trace" calls getaddrinfo() and that needs to be able to resolve
> > the hostname (without dots at the end).  getaddrinfo() is called
> > so that we don't have to have a full blown iterative resolver in
> > dig.
> >
> > The Internet moved from being a flat namespace (names without dots)
> > for hostnames to a heirachical namespace (names with *internal*
> > dots) a 1/4 century ago.  http://tools.ietf.org/html/rfc921
> >
> > Hostnames without dots are now local (e.g. localhost) or need to
> > be qualified (resolv.conf: search).
> 
> Actually, RFC 1123 requires a way to suppress domain suffixing, and 
> mentions the "trailing dot" convention:
> 
> 6.1.4.3 Interface Abbreviation Facilities
> 
> User interfaces MAY provide a method for users to enter abbreviations 
> for commonly-used names. Although the definition of such methods is 
> outside of the scope of the DNS specification, certain rules are 
> necessary to insure that these methods allow access to the entire DNS 
> name space and to prevent excessive use of Internet resources. If an 
> abbreviation method is provided, then:
> 
> (a) There MUST be some convention for denoting that a name is already 
> complete, so that the abbreviation method(s) are suppressed. A trailing 
> dot is the usual method.
> 
> But it appears that getaddrinfo() doesn't, apparently (according to a 
> quick wrapper program I tested with) support the "trailing dot" 
> convention for suppressing domain suffixing, or, AFAIK, any other way to 
> suppress domain suffixing, therefore "dig +trace" is stuck either -- as 
> you said -- implementing a full iterative resolver itself, or calling 
> getaddrinfo() and confusing the user with unwanted domain suffixing, in 
> the special case of a delegation to a root name.
> 
> Let's be clear, though: dig +trace *should* be able to deal with a 
> delegation to a root name, as twisted and obscure as that is. It only 
> fails to do so because of some design decisions/tradeoffs made with 
> getaddrinfo() and/or dig itself. Not because the user is doing something 
> "wrong".

Well really they are.  Address records on TLD labels will *never*
work reliably unless you can get the world to agree to stop using
search lists.

One could tweak dig to disable searching when resolving these
addresses, as the answers from the dns are absolute, but it is good
practice to never expect them to work in the first place.

"ssh tld" or "mail user@tld" or "browser http://tld/"; will never
work reliably as long as search lists exist.

This is as much about expectation setting as anything else.

Mark

>  - Kevin
> 
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users

Re: [UNsolved] was: what does dig +trace do?

[Kevin Darcy]

On 9/1/2011 7:57 PM, Mark Andrews wrote:

In message<4e5fb1ab.4040...@data.pl>, Torinthiel writes:

On 09/01/11 17:56, Tom Schmitt wrote:

=20
I found the cause of my problem (and a solution):
=20
dig +trace actually has another behaviour than doing the trace manually=

  step by step with dig.

=20
=20
For a trace, dig is asking for the NS-records, then for the IP-address =

of the nameserver found and then go on asking this nameserver. Till the d=
estination is reached.

=20
In my case, dig is asking for the nameservers of the root-zone and is g=

etting the answer:

. IN NS root1
. IN NS root2=20
etc
=20
Next dig is asking for the A-record of root1. And here is the differren=

ce:

=20
If I do "dig root1" dig is asking exactly this, it is asking for the A-=

record of root1. And of course I get the correct answer from named.

=20
The +trace option does not do this!
Instead, the +trace-option is using the searchsuffix in the resolv.conf=

  and is asking for root1.my.search.suffix. and NOT for root1.

This is why the +trace option fails every time.
=20
After deleting the searchsuffix in resolv.conf, dig +trace is working f=

ine without any error.

=20
In my oppinion it's a bug that dig +trace behave in a differrent way th=

an doing the queries with dig one by one.

No, IMHO, it's a bug in your root zone.
Names without dot at end are relative. Change your root zone to say
=2E IN NS root1.
=2E IN NS root2.

(with dots appended) and you should be home.

"dig +trace" calls getaddrinfo() and that needs to be able to resolve
the hostname (without dots at the end).  getaddrinfo() is called
so that we don't have to have a full blown iterative resolver in
dig.

The Internet moved from being a flat namespace (names without dots)
for hostnames to a heirachical namespace (names with *internal*
dots) a 1/4 century ago.  http://tools.ietf.org/html/rfc921

Hostnames without dots are now local (e.g. localhost) or need to
be qualified (resolv.conf: search).


Actually, RFC 1123 requires a way to suppress domain suffixing, and 
mentions the "trailing dot" convention:


6.1.4.3 Interface Abbreviation Facilities

User interfaces MAY provide a method for users to enter abbreviations 
for commonly-used names. Although the definition of such methods is 
outside of the scope of the DNS specification, certain rules are 
necessary to insure that these methods allow access to the entire DNS 
name space and to prevent excessive use of Internet resources. If an 
abbreviation method is provided, then:


(a) There MUST be some convention for denoting that a name is already 
complete, so that the abbreviation method(s) are suppressed. A trailing 
dot is the usual method.


But it appears that getaddrinfo() doesn't, apparently (according to a 
quick wrapper program I tested with) support the "trailing dot" 
convention for suppressing domain suffixing, or, AFAIK, any other way to 
suppress domain suffixing, therefore "dig +trace" is stuck either -- as 
you said -- implementing a full iterative resolver itself, or calling 
getaddrinfo() and confusing the user with unwanted domain suffixing, in 
the special case of a delegation to a root name.


Let's be clear, though: dig +trace *should* be able to deal with a 
delegation to a root name, as twisted and obscure as that is. It only 
fails to do so because of some design decisions/tradeoffs made with 
getaddrinfo() and/or dig itself. Not because the user is doing something 
"wrong".




- Kevin


___
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: Bug in Bind 9.8 or am I doing something wrong?

[Mark Andrews]

In message , Tony F
inch writes:
> Jaap Akkerhuis  wrote:
> >
> > Additionally .local is reserved for mDNS ..
> >
> > Can you give some references?
> 
> http://tools.ietf.org/html/draft-chapin-rfc2606bis
 
https://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/

Approved but not yet published as a RFC.

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Lundy, Fastnet: West or southwest, 6 to gale 8, decreasing 5 at times later.
> Rough or very rough. Showers, squally at first. Moderate or good.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Bug in Bind 9.8 or am I doing something wrong?

[SM]

Hi Jaap,
At 15:42 06-09-2011, Jaap Akkerhuis wrote:

Make me wonder who reserved .local and specifically earmaked it to be
used for mDNS. Iana  doesn't seem
to know about this.

Can you give some references?


See draft-cheshire-dnsext-multicastdns-14 which you may have read. 
:-)  There is also a proposal for a "Special-Use Domain Name" 
(draft-cheshire-dnsext-special-names-01).


Regards,
-sm 


___
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: Bug in Bind 9.8 or am I doing something wrong?

[Tony Finch]

Jaap Akkerhuis  wrote:
>
> Additionally .local is reserved for mDNS ..
>
> Can you give some references?

http://tools.ietf.org/html/draft-chapin-rfc2606bis

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet: West or southwest, 6 to gale 8, decreasing 5 at times later.
Rough or very rough. Showers, squally at first. 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: Bug in Bind 9.8 or am I doing something wrong?

[Jaap Akkerhuis]

Mark,

you remark somewhere that:

Additionally .local is reserved for mDNS ..

Make me wonder who reserved .local and specifically earmaked it to be
used for mDNS. Iana  doesn't seem
to know about this.

Can you give some references?

jaap
___
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: Bug in Bind 9.8 or am I doing something wrong?

[Mark Andrews]

In message <4e662676.1070...@lcrcomputer.net>, Lyle Giese writes:
> I was following Mark Andrew's discussion with a user about DNSSEC and 
> played with it here and found an issue.  Not sure if I am doing 
> something wrong or if there is a bug somewhere.
> 
> We have a Windows AD domain and use Bind 9.8 on our Linux servers for 
> most DNS resolution.  In order to politely setup things, I forwarded the 
> queries for AD zones to the Windows server:
> 
> zone "chaseprod.local"{
>   type forward;
>   forwarders {10.0.100.205;};};

Use a namespace delegated to you.  You don't own .local.  Additionally
.local is reserved for mDNS which is a seperate beast to DNS.

Named doesn't yet have the ability to disable DNSSEC validation
for specified namespaces.

Alternatively sign chaseprod.local and distribute trust anchors for
it if you really intend to hijack namespace you don't own.

Mark

> This seemed to work until I added some stuff for DNSSEC to my named.conf.
> 
> In the global option section, I have:
> 
>   dnssec-enable yes;
>   dnssec-validation auto;
>   dnssec-lookaside auto;
> 
> And as a general option, I added:
> 
> include "/etc/bind.keys";
> 
> Under Bind 9.8.0-P4 and Bind 9.8.1 (compiled from source with no special 
> options under SLES 10), resolution of a valid record in the forwarded 
> zone fails when I added the above dnssec options:
> 
> 
> ; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58140
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;chasew8s1.corp.chaseprod.local.  IN  A
> 
> ;; AUTHORITY SECTION:
> . 10794   IN  SOA a.root-servers.net. nstld.veris
> ign-grs.com. 2011090600 
> 1800 900 604800 86400
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Sep  6 08:43:25 2011
> ;; MSG SIZE  rcvd: 123
> 
> If I comment out dnssec-validation auto and the include for bind.keys, 
> the resolution for the forwarded zone works:
> 
> 
> ; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7529
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 3
> 
> ;; QUESTION SECTION:
> ;chasew8s1.corp.chaseprod.local.  IN  A
> 
> ;; ANSWER SECTION:
> chasew8s1.corp.chaseprod.local.   2599 IN A   10.0.102.10
> chasew8s1.corp.chaseprod.local.   2599 IN A   10.0.100.205
> 
> ;; AUTHORITY SECTION:
> . 517399  IN  NS  l.root-servers.net.
> . 517399  IN  NS  d.root-servers.net.
> . 517399  IN  NS  k.root-servers.net.
> . 517399  IN  NS  i.root-servers.net.
> . 517399  IN  NS  a.root-servers.net.
> . 517399  IN  NS  g.root-servers.net.
> . 517399  IN  NS  m.root-servers.net.
> . 517399  IN  NS  b.root-servers.net.
> . 517399  IN  NS  j.root-servers.net.
> . 517399  IN  NS  f.root-servers.net.
> . 517399  IN  NS  h.root-servers.net.
> . 517399  IN  NS  e.root-servers.net.
> . 517399  IN  NS  c.root-servers.net.
> 
> ;; ADDITIONAL SECTION:
> j.root-servers.net.   604029  IN  2001:503:c27::2:30
> l.root-servers.net.   604031  IN  A   199.7.83.42
> m.root-servers.net.   604061  IN  A   202.12.27.33
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Sep  6 08:42:47 2011
> ;; MSG SIZE  rcvd: 351
> 
> Is this a bug or am I doing something wrong?
> 
> Thanks,
> Lyle Giese
> LCR Computer Services, Inc.
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Bug in Bind 9.8 or am I doing something wrong?

[Spain, Dr. Jeffry A.]

Lyle: If I understand your issue correctly, it is one that I also experienced 
when using a Windows 2008 R2 DNS server to forward to a BIND 9.8.0 recursive 
resolver configured to perform DNSSEC validation. By default Windows 2008 R2 
DNS forwards queries with the CD flag set in the query, and it includes the OPT 
pseudo-resource record with the DO bit set. The meaning of this to the BIND 
resolver is supposed to be "don't bother checking DNSSEC validity" (CD bit set) 
and return DNSSEC information (DO bit set). Unfortunately Windows can't do its 
own DNSSEC validity checking since there is no way to successfully configure 
trust anchors, i.e. Windows DNS isn't really ready for DNSSEC prime time. Thus 
BIND returns answers to Windows even if DNSSEC validation would have failed.

You can alter these unfortunately configured flags in Windows DNS queries using 
the command:
dnscmd /config /EnableEDnsProbes 0

The effect of this is to cause the Windows DNS server to send its queries 
without the OPT pseudo-resource record in the Additional Records section of the 
query. Thus there is no DO bit set, and as a fortunate side effect, the CD flag 
in the standard DNS query flags field is cleared as well.

Under these circumstances, BIND will do DNSSEC validation properly as long as 
you have "dnssec-validation auto;" in the configuration. It will return proper 
SERVFAIL responses to Windows if DNSSEC validation fails.

See "Dnscmd" at http://technet.microsoft.com/en-us/library/cc772069(WS.10).aspx 
for further details.

Hope this is relevant and helpful. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School


-Original Message-
From: bind-users-bounces+spainj=countryday@lists.isc.org 
[mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of 
Lyle Giese
Sent: Tuesday, September 06, 2011 9:56 AM
To: bind-us...@isc.org
Subject: Bug in Bind 9.8 or am I doing something wrong?

I was following Mark Andrew's discussion with a user about DNSSEC and 
played with it here and found an issue.  Not sure if I am doing 
something wrong or if there is a bug somewhere.

We have a Windows AD domain and use Bind 9.8 on our Linux servers for 
most DNS resolution.  In order to politely setup things, I forwarded the 
queries for AD zones to the Windows server:

zone "chaseprod.local"{
type forward;
forwarders {10.0.100.205;};};

This seemed to work until I added some stuff for DNSSEC to my named.conf.

In the global option section, I have:

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;

And as a general option, I added:

include "/etc/bind.keys";

Under Bind 9.8.0-P4 and Bind 9.8.1 (compiled from source with no special 
options under SLES 10), resolution of a valid record in the forwarded 
zone fails when I added the above dnssec options:

___
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: Bug in Bind 9.8 or am I doing something wrong?

[Chris Buxton]

On Sep 6, 2011, at 7:32 AM, Lyle Giese wrote:
> On 9/6/2011 9:13 AM, Tony Finch wrote:
>> Lyle Giese  wrote:
>> 
>>> zone "chaseprod.local"{
>>> type forward;
>>> forwarders {10.0.100.205;};};
>>> 
>>> This seemed to work until I added some stuff for DNSSEC to my named.conf.
>> 
>> In order to forward a zone in the presence of DNSSEC validation, the zone
>> has to have a valid delegation in the public DNS. You can't use forwarding
>> to splice some private namespace onto the public DNS.
>> 
>> There is a new "static-stub" zone type which should avoid this problem,
>> though it has a number of other differences from a forwarding
>> configuration.
>> 
>> Tony.
> 
> Changing zone to:
> 
> zone "chaseprod.local"{
>   type static-stub;
>   server-addresses {10.0.100.205;};};
> 
> And adding back in the DNSSEC stuff, it's still broke, but the output from 
> dig changes.
> 
> 
> ; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> 
> Very informative.  But if I disable DNSSEC, resolution using a static-stub 
> zone does work.

If named is logging, is there anything interesting in the log from this test?

A response from ISC would be useful here. It's pretty normal to mix DNSSEC 
validation for public namespace with add-on private namespace. Is it true that 
enterprise networks using BIND 9.8 need to have a two-step resolution process, 
as shown below? When did this start? (I haven't tested because nearly every 
customer already uses this kind of strategy.)

client -> internal resolver -> internal auth (unsigned)
-> forwarders in the DMZ with DNSSEC validation 
enabled

Is the situation different when the resolving/caching/validating name server is 
also authoritative for (some of) the internal namespace?

Regards,
Chris Buxton
BlueCat Networks
___
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: slow non-cached quries

[TMK]

On Sat, Sep 3, 2011 at 2:06 PM, TMK  wrote:
>
>> Message: 1
>> Date: Fri, 2 Sep 2011 10:05:42 +0200
>
>> From: TMK 
>> Subject: Re: Fwd: Re: slow non-cached quries
>> To: bind-users@lists.isc.org
>> Message-ID:
>>
>>  
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Sep 2, 2011 9:48 AM, "TMK"  wrote:
>> >
>> > -- Forwarded message --
>> > From: "Leonard Mills" 
>> > Date: Aug 31, 2011 8:15 PM
>> > Subject: Re: slow non-cached quries
>> > To: "TMK" 
>> >
>> > ;; Received 738 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 3133
>> > ms
>> >
>> > That pretty much is your delay.  Look to your intermediate network
>> segments, especially any smart devices.
>> >
>> >> 
>> >> From: TMK 
>> >> To: Mark Andrews 
>> >> Cc: bind-us...@isc.org
>> >> Sent: Wednesday, August 31, 2011 4:44 AM
>> >> Subject: Re: slow non-cached quries
>> >>
>> >> On Tue, Aug 30, 2011 at 9:26 AM, TMK  wrote:
>> >>
>> >>
> Actually we have around 6 servers. All I need to do is to reduce the
> response time for the uncached responses as much as possible. So will the
> master cache server save maybe 200 sec of the response time which is good
> number is there any other way to force my server to contact gtld servers
> closer to its geoloc in Africa to reduce the round trip times is that
> possible

one of the worst responses time we captured on our network was for
domain : a.root-servers.net (this is represent 5% of our dns traffic).
we got response time up to 30 sec.

I know this queries can be generated by viruses. but I need to know:

why the bind responding so slowly to such domain > 30 sec and if there
is way to reduce such time.(even if it is query from a virus)

Regards,
___
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: Seemingly random ServFail issues on a caching server

[Florian CROUZAT]

Florian CROUZAT wrote on 2011-08-31:

> Lyle Giese wrote on 2011-08-31:
>
>> On 8/31/2011 8:40 AM, Florian CROUZAT wrote:
>>> Florian CROUZAT wrote on 2011-08-25:
>>>
 Hi list,

 On a few domains (we'll consider only one domain for this example) I
 encounter sometimes (seemingly randoms) ServFails while resolving
 domain names. A client (192.168.147.2) asks my caching server
 (192.168.151.100) to resolve a target (www.leclercdrive.fr)

 Here are the relevant logs:

 Aug 24 17:14:19 ns named[24929]: 24-Aug-2011 17:14:19.377 queries:
 info: client 192.168.147.2#34502: view internal: query:
 www.leclercdrive.fr IN A + Aug 24 17:14:19 ns named[24929]:
 24-Aug-2011 17:14:19.380 queries: info: client 192.168.147.2#34502:
 view internal: query: www.leclercdrive.fr IN A + Aug 24 17:14:19 ns
 named[24929]: 24-Aug- 2011 17:14:19.382 queries: info: client
 192.168.147.2#34502: view internal: query: www.leclercdrive.fr IN A +


 A tcpdump on the local side of the NS server shows the A request and
 the instant ServFail. A tcpdump on the external side of the NS server
 shows no traffic at all in this case meaning it fails internally and
 doesn't even try to forward the A request to the Internet.

 17:14:19.377608 IP 192.168.147.2.34502>  192.168.151.100.53: 26340+
 A? www.leclercdrive.fr. (37) 17:14:19.378845 IP 192.168.151.100.53>
 192.168.147.2.34502: 26340 ServFail 0/0/0 (37) 17:14:19.380607 IP
 192.168.147.2.34502>  192.168.151.100.53: 52628+ A?
 www.leclercdrive.fr. (37) 17:14:19.381383 IP 192.168.151.100.53>
 192.168.147.2.34502: 52628 ServFail 0/0/0 (37) 17:14:19.382605 IP
 192.168.147.2.34502> 192.168.151.100.53: 58933+ A?
 www.leclercdrive.fr. (37) 17:14:19.383406 IP 192.168.151.100.53>
 192.168.147.2.34502: 58933 ServFail 0/0/0 (37)

 A few minutes before, or later, it worked just fine, see:

 17:15:58.736177 IP 192.168.147.2.34502>  192.168.151.100.53: 49610+
 A? www.leclercdrive.fr. (37) 17:15:58.784470 IP 192.168.151.100.53>
 192.168.147.2.34502: 49610 3/3/6 CNAME[|domain]

 The TTL of the www.leclercdrive.fr entry is 300 - which seems short
 to me - maybe the ServFail happens when a request is treated at the
 exact time of the TTL reaching zero and the cache entry beeing
 flushed ? I tried flushing the cache using rndc but the first request
 after that worked just fine (of course...)

 Any ideas/hints are welcome.

 The DNS server runs 1:9.5.1.dfsg.P3-1+lenny1
 cat /etc/debian_version =>  5.0.4
 (I have no control on the version of the tools)
>>>
>>>
>>>
>>> I found in my logfiles a few other domains where the ServFails happen,
>>> their respective TTL are all different, from 300 sec to 86400. I still
>>> have no idea at all how to resolve this issue and as far as I
>>> investigated, I haven't been able to identify a pattern in those
>>> ServFails. I'm not even sure the TTL is involved since I saw two
>>> ServFail separated in time by less than the TTL value of the entry...
>>>
>>> Florian
>>>
>>
>> The authorative name servers for leclercdrive.fr are a.dns.gandi.net,
>> b.dns.gandi.net and c.dns.gandi.net.  I don't know how big gandi.net
>> is, but traceroutes to those servers end up going through Level3 in
>> Baltimore, MD from here.  They did have a hurricane go through there
>> and I would not be surprised if traffic levels have been a bit high for
>> the last few days.
>>
>> Lyle
>
> Well, it's a french registrar, my servers are in France and my clients
> are french too so from here the traceroute is pretty neat. Anyway my
> problem isn't (apparently) Gandi related, or even www.leclercdrive.fr
> related since the ServFails happen internally and instantanetly in my
> BIND which doesn't even try to forward the A request.
>
>
> Florian

Apparently -- even if I don't understand why -- the problem seems to be that
the NS ({a,b,c}.dns.gandi.net) of leclercdrive.fr and other domains which
ServFail have  entries and my caching server has IPv6 enabled but my
network doesn't route or handle IPv6.

All I had to do to get rid of those ServFails was to add "-4" in the
starting options of bind (CentOS: /etc/default/bind9, OPTIONS=)

Anyway, I don't really understand whether or not it's a bug in bind that
only happens when your interface has a link-local IPv6 addr, the remote NS
have  entries and your network doesn't handle IPv6.

The solution I applied works, but I'm not satisfied with it.
Any precisions are of course welcome.

Greetings,
Florian





___
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: Bug in Bind 9.8 or am I doing something wrong?

[Lyle Giese]

On 9/6/2011 9:13 AM, Tony Finch wrote:

Lyle Giese  wrote:


zone "chaseprod.local"{
type forward;
forwarders {10.0.100.205;};};

This seemed to work until I added some stuff for DNSSEC to my named.conf.


In order to forward a zone in the presence of DNSSEC validation, the zone
has to have a valid delegation in the public DNS. You can't use forwarding
to splice some private namespace onto the public DNS.

There is a new "static-stub" zone type which should avoid this problem,
though it has a number of other differences from a forwarding
configuration.

Tony.


Changing zone to:

zone "chaseprod.local"{
type static-stub;
server-addresses {10.0.100.205;};};

And adding back in the DNSSEC stuff, it's still broke, but the output 
from dig changes.



; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


Very informative.  But if I disable DNSSEC, resolution using a 
static-stub zone does work.


Lyle Giese
LCR Computer Services, Inc.
___
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: Bug in Bind 9.8 or am I doing something wrong?

[Tony Finch]

Lyle Giese  wrote:

> zone "chaseprod.local"{
>   type forward;
>   forwarders {10.0.100.205;};};
>
> This seemed to work until I added some stuff for DNSSEC to my named.conf.

In order to forward a zone in the presence of DNSSEC validation, the zone
has to have a valid delegation in the public DNS. You can't use forwarding
to splice some private namespace onto the public DNS.

There is a new "static-stub" zone type which should avoid this problem,
though it has a number of other differences from a forwarding
configuration.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty, Forth, Tyne: Southwest veering northwest 5 to 7, increasing
gale 8 for a time. Moderate or rough, occasionally very rough in Forties. Rain
or squally 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

Bug in Bind 9.8 or am I doing something wrong?

[Lyle Giese]

I was following Mark Andrew's discussion with a user about DNSSEC and 
played with it here and found an issue.  Not sure if I am doing 
something wrong or if there is a bug somewhere.


We have a Windows AD domain and use Bind 9.8 on our Linux servers for 
most DNS resolution.  In order to politely setup things, I forwarded the 
queries for AD zones to the Windows server:


zone "chaseprod.local"{
type forward;
forwarders {10.0.100.205;};};

This seemed to work until I added some stuff for DNSSEC to my named.conf.

In the global option section, I have:

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;

And as a general option, I added:

include "/etc/bind.keys";

Under Bind 9.8.0-P4 and Bind 9.8.1 (compiled from source with no special 
options under SLES 10), resolution of a valid record in the forwarded 
zone fails when I added the above dnssec options:



; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58140
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;chasew8s1.corp.chaseprod.local.IN  A

;; AUTHORITY SECTION:
.			10794	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2011090600 
1800 900 604800 86400


;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep  6 08:43:25 2011
;; MSG SIZE  rcvd: 123

If I comment out dnssec-validation auto and the include for bind.keys, 
the resolution for the forwarded zone works:



; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7529
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 3

;; QUESTION SECTION:
;chasew8s1.corp.chaseprod.local.IN  A

;; ANSWER SECTION:
chasew8s1.corp.chaseprod.local. 2599 IN A   10.0.102.10
chasew8s1.corp.chaseprod.local. 2599 IN A   10.0.100.205

;; AUTHORITY SECTION:
.   517399  IN  NS  l.root-servers.net.
.   517399  IN  NS  d.root-servers.net.
.   517399  IN  NS  k.root-servers.net.
.   517399  IN  NS  i.root-servers.net.
.   517399  IN  NS  a.root-servers.net.
.   517399  IN  NS  g.root-servers.net.
.   517399  IN  NS  m.root-servers.net.
.   517399  IN  NS  b.root-servers.net.
.   517399  IN  NS  j.root-servers.net.
.   517399  IN  NS  f.root-servers.net.
.   517399  IN  NS  h.root-servers.net.
.   517399  IN  NS  e.root-servers.net.
.   517399  IN  NS  c.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net. 604029  IN  2001:503:c27::2:30
l.root-servers.net. 604031  IN  A   199.7.83.42
m.root-servers.net. 604061  IN  A   202.12.27.33

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep  6 08:42:47 2011
;; MSG SIZE  rcvd: 351

Is this a bug or am I doing something wrong?

Thanks,
Lyle Giese
LCR Computer Services, Inc.
___
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 9.7.4 on centos6

[Adam Tkac]

On 09/06/2011 01:54 AM, Mark Andrews wrote:
> In message <1315237316.31288.2.ca...@ns.five-ten-sg.com>, Carl Byington 
> writes:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>> "dnssec-lookaside auto;" only pulls the "dlv.isc.org" key out of
>>> that file.  The root's key is just for reference in BIND 9.7.x.  If
>>> you just include that file into named.conf it will load the root's
>>> key and org's answers will validate.
>>> e.g.
>>> include "/etc/named.iscdlv.key";
>>> BIND 9.8 has "dnssec-validate auto;" which pulls the root's key out
>>> of that file.
>> Thanks! That works.
> Good.
>
> ISC ships the file as "/etc/bind.keys" with the following comments
> per version.  The comments are there to prevent issues such as this.
> Please report the lack of appropriate comments to the RPM maintainer.
Hello,

on RHEL6 the /etc/named.iscdlv.key file is simple copy of the ISC's
bind.keys with all comments:

[root@rhel6 ~]# rpm -q bind
bind-9.7.3-2.el6_1.P3.2.x86_64
[root@rhel6 ~]# cat /etc/named.iscdlv.key |head -5
/* $Id: bind.keys,v 1.5.42.2 2011-01-04 19:14:48 each Exp $ */
# The bind.keys file is used to override built-in DNSSEC trust anchors
# which are included as part of BIND 9.  As of the current release (BIND
# 9.7), the only trust anchor it sets is the one for the ISC DNSSEC
# Lookaside Validation zone ("dlv.isc.org").  Trust anchors for any other


Just for information, I renamed the bind.keys to named.iscdlv.key
because we shipped ISC DLV key in named.iscdlv.key file before ISC
started to ship bind.keys. It made sense not to break existing
configurations which had named.iscdlv.key included in the named.conf.

We are also shipping the root key in the /etc/named.root.key so you can
simply put

include "/etc/named.root.key";

into your named.conf and root zone should be validated correctly.

Regards, Adam
___
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