Re: Query Refused problem
On Donnerstag 01 Oktober 2009 Mark Andrews wrote: > Specifies which hosts are allowed to get answers > from the cache. If > allow-query-cache is not set then > allow-recursion is used if set, otherwise > allow-query is used if set unless > recursion no; is set in which case > none; is used, otherwise the default > (localnets; localhost;) is > used. Not exactly a good explanation. At least, I've read it twice and still don't exactly know where the "if..else..elseif..." parts connect. Maybe someone could change that to pseudocode with "if" statements, or make it several sentences so it's clear where if..unless..except..otherwise parts start and end. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
stub zone and dnssec processing fails?
Hi,
I've been trying to configure bind to use a stub zone, for which I
have keys configured. When I do this, I see a ServFail, with the
logs pointing to:
01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving
'xelerance.ca/DNSKEY/IN': 193.110.157.135#53
When I disable the trusted-keys {} for this zone, the resolving
works, but then it seems to ignore the stub and go out via the
regular path
Enabling/disabling DLV did not make a difference. The relevant parts of
the named.conf:
options {
dnssec-enable yes;
dnssec-validation yes;
// dnssec-lookaside . trust-anchor dlv.isc.org.;
recursion yes;
};
zone "ca." IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};
trusted-keys {
"ca." 257 3 7 "AwEAAbTcBX0/Z6uh4gUFmPhNMExALpP8eVy+KyHQ3IY8z/XlDoRVoe2Cv0IXBWp
MFme3sQpAEGg9Ps1+lYXpn2zO0BfpcED2nVlZ9KFBwh1MuEHvaAAkYKZtT/aqOIDJftRdmU8ClFZgaeJ
c8Scvf5boGczVvG/ZdbDpHVM73x6a4rQqjTDlgwSaNU+/vimOWii5d4lWBxUDQKsqkQ27UGqyGtYQxNY
giRGx80phZkmhxOnSwfXIG/RJa0Hl6CtlsG3klywJ+7NAZM/n8Y0TQqjOHudC0SedXSCmQ0C/Ds0QX5M
7c/S7alVBYsOdHhJF05MaIA5ij0thAmuvJUW7ofqO5ec=" ; // key id = 46215
};
Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
On 30.09.09 15:59, Sven Eschenberg wrote:
> When I had no allow-query statement at all in my config, everything
> worked find (includign recursion) for all clients, that were in subnets
> directly attached to the server. The external view (authoriative, non
> recursive) did work for every client as supposed to.
> Now a client on a not directly attached subnet, with it's own view,
> could not resolve anything, except local zones on the server. (Though
> recursion was turned on for the view).
> External view's clients could nto recurse, though recursion was turned
> on, obviously to realyl recurse I'd need an allow-query statement.
>
> Adding an allow-query statement to the general config, limitied to the
> campus network made all local views work, but with the result, that no
> client matching the external view could looks up the authoriative zones.
>
> Now, I am wondering if I did set uop everything right afterall, here's
> what I did do:
>
> External view, no recursion, allow-query {any;}
> Not directly attached client with internal view: match on client's ip,
> allow recursion, allow query for the client's ip.
> all other internal views, matched by locally attached netowrks, no
> allow-query statement, allow recursion.
>
> This seems to work.
>
> I am wondering: Would it be harmfull to allow queries by any host
> (globally) as long as external clients (in their view) are not allowed
> any recursion? Would that be more feasible?
allow-query { any; }; is default. Do you have any other allows's ?
the first error message indicated that you didn't allow query-cache or recursion
for some clients. Apparently you cloned a view but forget to allow either
one in the new view...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck & Porky Pig
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: socket is not connected error on bind 9.5.1-P3
On 30.09.09 14:59, Louis Luciano (qipman) wrote: > Does anyone know what might be causing these messages? > > 30-Sep-2009 08:20:56.071 client 10.10.10.10#44554: transfer of > 'domain.com/IN': send: socket is not connected apparently a client that requested transfer but closed connection. Do you have many of them? Do you allow transfers to all clients? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
Inbetween I overhauled the config, setting all the options explicitly
where needed, instead of building on default behavior and everything
works as expected now. Lessen learned: Ignore defaults, always set
things as YOU want them to be :-).
Thanks for your reply though.
Regards
-Sven
Matus UHLAR - fantomas schrieb:
On 30.09.09 15:59, Sven Eschenberg wrote:
When I had no allow-query statement at all in my config, everything
worked find (includign recursion) for all clients, that were in subnets
directly attached to the server. The external view (authoriative, non
recursive) did work for every client as supposed to.
Now a client on a not directly attached subnet, with it's own view,
could not resolve anything, except local zones on the server. (Though
recursion was turned on for the view).
External view's clients could nto recurse, though recursion was turned
on, obviously to realyl recurse I'd need an allow-query statement.
Adding an allow-query statement to the general config, limitied to the
campus network made all local views work, but with the result, that no
client matching the external view could looks up the authoriative zones.
Now, I am wondering if I did set uop everything right afterall, here's
what I did do:
External view, no recursion, allow-query {any;}
Not directly attached client with internal view: match on client's ip,
allow recursion, allow query for the client's ip.
all other internal views, matched by locally attached netowrks, no
allow-query statement, allow recursion.
This seems to work.
I am wondering: Would it be harmfull to allow queries by any host
(globally) as long as external clients (in their view) are not allowed
any recursion? Would that be more feasible?
allow-query { any; }; is default. Do you have any other allows's ?
the first error message indicated that you didn't allow query-cache or recursion
for some clients. Apparently you cloned a view but forget to allow either
one in the new view...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Glue record miunderstanding
Hello, I believe I understand what a glue record is, and why I would need one. I would like some clarification if possible. While I am not the hugest fan of the dns report services, this report was brought to my attention: http://www.intodns.com/hostwizard.com It says I am missing glue for my ns1 at 64.84.37.14 This domain is registered through goDaddy. First Question: What is the procedure for using `dig` to determine that I am in fact missing an A record for my NS at the parent NS? I would like to confirm their message. Second, I logged into the control panel at GoDaddy, (I do not mind switching registrars, though I find it hard to believe they do not supply glue records for NS's), and I see something that looks like a glue record area. http://dl.getdropbox.com/u/340087/Drops/10.01.09/dns-8234d865-130008.png However, I did not add that data, it was already there. It also references IPv6, and any edits or changes to it do not seem to stick. I emailed support at GoDaddy, asking how to add a glue record through their system. I am not sure they understood the issue at hand, but this is what I recieved back: Thank you for contacting Online Support. Unfortunately this is not something you would be able to setup through us. We apologize for any inconvenience. Is it also correct, I only need a NS glue record for the actual NS itself. There does not need to be a glue record for very zone that I am providing DNS for? Thanks for any suggestions. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
On 01.10.09 19:10, Sven Eschenberg wrote:
> Funny enough, I did not have any allow-query at all, but adding
> allow-query {any;} did indeed change the behavior. But allow-query-cache
> obviously defaults to localhost, localnets and was triggering the
> behavior that confused me.
OK, again: did you have any other allows ?
Which means allow-recursion, allow-query-cache
> Inbetween I overhauled the config, setting all the options explicitly
> where needed, instead of building on default behavior and everything
> works as expected now. Lessen learned: Ignore defaults, always set
> things as YOU want them to be :-).
Could you post your config (and optional includes) somewhere?
I still thinkthe real problem lied elsewhere...
> Matus UHLAR - fantomas schrieb:
>> On 30.09.09 15:59, Sven Eschenberg wrote:
>>> When I had no allow-query statement at all in my config, everything
>>> worked find (includign recursion) for all clients, that were in
>>> subnets directly attached to the server. The external view
>>> (authoriative, non recursive) did work for every client as supposed
>>> to.
>>> Now a client on a not directly attached subnet, with it's own view,
>>> could not resolve anything, except local zones on the server. (Though
>>> recursion was turned on for the view).
>>> External view's clients could nto recurse, though recursion was
>>> turned on, obviously to realyl recurse I'd need an allow-query
>>> statement.
>>>
>>> Adding an allow-query statement to the general config, limitied to
>>> the campus network made all local views work, but with the result,
>>> that no client matching the external view could looks up the
>>> authoriative zones.
>>>
>>> Now, I am wondering if I did set uop everything right afterall,
>>> here's what I did do:
>>>
>>> External view, no recursion, allow-query {any;}
>>> Not directly attached client with internal view: match on client's
>>> ip, allow recursion, allow query for the client's ip.
>>> all other internal views, matched by locally attached netowrks, no
>>> allow-query statement, allow recursion.
>>>
>>> This seems to work.
>>>
>>> I am wondering: Would it be harmfull to allow queries by any host
>>> (globally) as long as external clients (in their view) are not
>>> allowed any recursion? Would that be more feasible?
>>
>> allow-query { any; }; is default. Do you have any other allows's ?
>>
>> the first error message indicated that you didn't allow query-cache or
>> recursion
>> for some clients. Apparently you cloned a view but forget to allow either
>> one in the new view...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Glue record miunderstanding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-Oct-2009, at 16:03, Scott Haneda wrote: Is it also correct, I only need a NS glue record for the actual NS itself. There does not need to be a glue record for very zone that I am providing DNS for? The only case where glue *must* be present is when a nameserver name is a subdomain of the zone it's authoritative for. So, if ns1.example.com is one of the nameservers for example.com, then there must be glue in the com zone. In all other cases it is not required. However, some registries may include glue even when its not necessary, since it simplifies the logic of generating their zone. To check if glue is present, ask your parent's nameservers for some record inside your zone. When you get back the delegation response, if glue is present it'll be included in the ADDITIONAL section. Here's a real-world example. In this case, glue is unnecessary in the com zone, but Verisign is including it anyway: 18:24:04 % dig +norec IN A www.example.com @a.gtld-servers.net ; <<>> DiG 9.4.3-P3 <<>> +norec IN A www.example.com @a.gtld-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55065 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.example.com. IN A ;; AUTHORITY SECTION: example.com.172800 IN NS a.iana-servers.net. example.com.172800 IN NS b.iana-servers.net. ;; ADDITIONAL SECTION: a.iana-servers.net. 172800 IN A 192.0.34.43 b.iana-servers.net. 172800 IN A 193.0.0.236 ;; Query time: 65 msec ;; SERVER: ;; WHEN: Thu Oct 1 18:24:13 2009 ;; MSG SIZE rcvd: 113 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkrFLHkACgkQmFeRJ0tjIxF8qwCeILXgTweMvfy5/44oA3PTV//G z5YAoJBBRer7pj1RE9xfUdGG2GugFUfM =crTH -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Glue record miunderstanding
On Oct 1, 2009, at 3:25 PM, Matthew Pounsett wrote: On 01-Oct-2009, at 16:03, Scott Haneda wrote: Is it also correct, I only need a NS glue record for the actual NS itself. There does not need to be a glue record for very zone that I am providing DNS for? The only case where glue *must* be present is when a nameserver name is a subdomain of the zone it's authoritative for. So, if ns1.example.com is one of the nameservers for example.com, then there must be glue in the com zone. In all other cases it is not required. However, some registries may include glue even when its not necessary, since it simplifies the logic of generating their zone. To check if glue is present, ask your parent's nameservers for some record inside your zone. When you get back the delegation response, if glue is present it'll be included in the ADDITIONAL section. Here's a real-world example. In this case, glue is unnecessary in the com zone, but Verisign is including it anyway: 18:24:04 % dig +norec IN A www.example.com @a.gtld-servers.net ; <<>> DiG 9.4.3-P3 <<>> +norec IN A www.example.com @a.gtld- servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55065 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.example.com. IN A ;; AUTHORITY SECTION: example.com.172800 IN NS a.iana-servers.net. example.com.172800 IN NS b.iana-servers.net. ;; ADDITIONAL SECTION: a.iana-servers.net. 172800 IN A 192.0.34.43 b.iana-servers.net. 172800 IN A 193.0.0.236 ;; Query time: 65 msec ;; SERVER: ;; WHEN: Thu Oct 1 18:24:13 2009 ;; MSG SIZE rcvd: 113 Taking your example: $dig +norec IN A ns1.hostwizard.com @a.gtld-servers.net ; <<>> DiG 9.4.3-P3 <<>> +norec IN A ns1.hostwizard.com @a.gtld- servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31543 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;ns1.hostwizard.com.IN A ;; ANSWER SECTION: ns1.hostwizard.com. 172800 IN A 64.84.37.14 ;; AUTHORITY SECTION: hostwizard.com. 172800 IN NS ns1.hostwizard.com. hostwizard.com. 172800 IN NS ns1.nacio.com. ;; ADDITIONAL SECTION: ns1.hostwizard.com. 172800 IN A 64.84.37.14 ns1.nacio.com. 172800 IN A 64.84.0.18 ;; Query time: 252 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Oct 1 16:00:56 2009 ;; MSG SIZE rcvd: 122 So I see my NS is listed in the additional section. This to me tells me there is in fact glue, so I should consider the report at http://intodns.com/hostwizard.com to be inaccurate? -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
In message <200910011237.09...@zmi.at>, Michael Monnerie writes:
> On Donnerstag 01 Oktober 2009 Mark Andrews wrote:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Specifies which hosts are allowed to =
> get answers
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from the cache. =A0If
> > allow-query-cache is not set then
> > allow-recursion is used if set, otherwise
> > allow-query is used if set unless
> > recursion no; is set in which case
> > none; is used, otherwise the default
> > (localnets; localhost;) is
> > used.
>
> Not exactly a good explanation. At least, I've read it twice and still =
>
> don't exactly know where the "if..else..elseif..." parts connect. Maybe =
>
> someone could change that to pseudocode with "if" statements, or make it =
>
> several sentences so it's clear where if..unless..except..otherwise =
>
> parts start and end.
>
> mfg zmi
> -- =
if (set(allow-query-cache))
use allow-query-cache;
else if (set(allow-recursion))
use allow-recursion;
else if (set(allow-query))
use allow-query;
else if (set(recursion no;))
use { none; };
else
use { localnets; localhost; };
> // Michael Monnerie, Ing.BSc- http://it-management.at
> // Tel: 0660 / 415 65 31 .network.your.ideas.
> // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
> // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
> // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
>
> ___
> 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: Glue record miunderstanding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-Oct-2009, at 19:03, Scott Haneda wrote: So I see my NS is listed in the additional section. This to me tells me there is in fact glue, so I should consider the report at http://intodns.com/hostwizard.com to be inaccurate? Yeah, I just ran a few queries and can't figure out what exactly it's complaining about. Matt -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkrFTN4ACgkQmFeRJ0tjIxHkYwCfdIo1dfhDzGov84ouWPviqWrk 5IIAnAy44CUqm7gfX43PQ88KOdUQv47K =XnOk -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: stub zone and dnssec processing fails?
In message , Paul Wou
ters writes:
>
> Hi,
>
> I've been trying to configure bind to use a stub zone, for which I
> have keys configured. When I do this, I see a ServFail, with the
> logs pointing to:
>
> 01-Oct-2009 11:00:03.053 lame-servers: info: not insecure resolving 'xeleranc
> e.ca/DNSKEY/IN': 193.110.157.135#53
>
>
> When I disable the trusted-keys {} for this zone, the resolving
> works, but then it seems to ignore the stub and go out via the
> regular path
>
> Enabling/disabling DLV did not make a difference. The relevant parts of
> the named.conf:
>
> options {
> dnssec-enable yes;
> dnssec-validation yes;
> // dnssec-lookaside . trust-anchor dlv.isc.org.;
> recursion yes;
> };
>
> zone "ca." IN {
> type stub;
> masters { 192.228.22.190; 192.228.22.189; };
> };
>
> trusted-keys {
> "ca." 257 3 7 "AwEAAbTcBX0/Z6uh4gUFmPhNMExALpP8eVy+KyHQ3IY8z/XlDoRVoe2Cv0IX
> BWp
> MFme3sQpAEGg9Ps1+lYXpn2zO0BfpcED2nVlZ9KFBwh1MuEHvaAAkYKZtT/aqOIDJftRdmU8ClFZg
> aeJ
> c8Scvf5boGczVvG/ZdbDpHVM73x6a4rQqjTDlgwSaNU+/vimOWii5d4lWBxUDQKsqkQ27UGqyGtYQ
> xNY
> giRGx80phZkmhxOnSwfXIG/RJa0Hl6CtlsG3klywJ+7NAZM/n8Y0TQqjOHudC0SedXSCmQ0C/Ds0Q
> X5M
> 7c/S7alVBYsOdHhJF05MaIA5ij0thAmuvJUW7ofqO5ec=" ; // key id = 46215
> };
>
> Paul
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with those that server unsigned content
which is correctly rejected. Stubs pre-populate the delegation,
they do not override the delegation.
The alternative is to override the addresses for ?.ca-servers.ca
with those of servers that serve the signed version of ca. You
will also need to ensure that these servers serve the zones that
are othewise delgated to them using these names. You will still get
the odd failure due to talking to ns-ext.isc.org.
You could just override these if you can't get the content of
ca-servers.ca as ca-servers.ca is delegated to [a-f].ca-servers.ca.
You will get more failures however.
ca. 86400 IN NS j.ca-servers.ca.
ca. 86400 IN NS k.ca-servers.ca.
ca. 86400 IN NS l.ca-servers.ca.
ca. 86400 IN NS m.ca-servers.ca.
I use a similar technique to test IPv6 connectivity for the root
servers.
Mark
; <<>> DiG 9.3.6-P1 <<>> ca ns +norec @192.228.22.190
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56860
;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ca.IN NS
;; ANSWER SECTION:
ca. 86400 IN NS e.ca-servers.ca.
ca. 86400 IN NS d.ca-servers.ca.
ca. 86400 IN NS l.ca-servers.ca.
ca. 86400 IN NS c.ca-servers.ca.
ca. 86400 IN NS a.ca-servers.ca.
ca. 86400 IN NS b.ca-servers.ca.
ca. 86400 IN NS k.ca-servers.ca.
ca. 86400 IN NS f.ca-servers.ca.
ca. 86400 IN NS ns-ext.isc.org.
ca. 86400 IN NS m.ca-servers.ca.
ca. 86400 IN NS j.ca-servers.ca.
;; Query time: 251 msec
;; SERVER: 192.228.22.190#53(192.228.22.190)
;; WHEN: Fri Oct 2 10:36:50 2009
;; MSG SIZE rcvd: 219
; <<>> DiG 9.3.6-P1 <<>> +dnssec ca @ns-ext.isc.org.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36584
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ca.IN A
;; AUTHORITY SECTION:
ca. 3600IN SOA jbq01.tor.cira.ca.
admin-dns.cira.ca. 2009100120 1800 900 604800 3600
;; Query time: 168 msec
;; SERVER: 2001:4f8:0:2::13#53(2001:4f8:0:2::13)
;; WHEN: Fri Oct 2 10:43:20 2009
;; MSG SIZE rcvd: 92
--
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
Bind, dnssec, udp fragmentation woes.
Hello all, For the last couple days I've been trying to figure out how to get dnssec implemented within my environment. A simplified description of my network is as follows: cloud -> Nokia IP330(Check Point) -> BigIP F5 -> debian -> named. My problem seems to be that when asking for dnssec-related information over udp, bind generates fragmented UDP packets that are then being blocked somewhere-along-the-way. I am not currently able to determine at what point it's being blocked, however. Here's what I can do: (within named's network): dig @named +dnssec +notcp DNSKEY domain.tld dig @named +dnssec +tcp DNSKEY domain.tld (outside of named's network): dig @named +dnssec +tcp DNSKEY domain.tld dig @named +notcp A domain.tld Here's what I can't do: (outside of named's network): dig @named +notcp +dnssec A domain.tld dig @named +notcp +dnssec DNSKEY domain.tld This is making it so my TLD can't get the DNSKEY via UDP, and therefore fails. I've tried setting various options in bind (edns-udp-size 512;, max-udp-size 512;), to no avail. As far as I can see from tcpdump, bind gets the request, generates some fragmented udp packets, which then enter TheVoid. Does anyone have any experience in getting bind to work with dnssec through potentially faulty firewalls and/or *NOT* fragment the UDP packets? It's possible that the firewall does both: denies fragmented udp packets, and denies udp packets which are not 512 bytes. Any help at all would be greatly appreciatedsuch as category logging statements that might be of relevance, tools to diagnose udp fragmentation problems, documentation of linux kernel parameters that might affect bind's generation of UDP packets (fragmentation?), etc. Thank you very much for your time, -- Nicholas Wheeler Systems Administrator Development Infostructure signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Glue record miunderstanding
In message <73e2882f-00b3-41cb-b46d-351774486...@conundrum.com>, Matthew Pounse
tt writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 01-Oct-2009, at 19:03, Scott Haneda wrote:
>
> > So I see my NS is listed in the additional section. This to me
> > tells me there is in fact glue, so I should consider the report at http://i
> ntodns.com/hostwizard.com
> > to be inaccurate?
>
> Yeah, I just ran a few queries and can't figure out what exactly it's
> complaining about.
>
> Matt
It's making a observation ("i" in a blue circle) that there were
not additional records for ns1.nacio.com being returned by
ns1.hostwizard.com presumable because ns1.hostwizard.com doesn't
serve the zone that contains ns1.nacio.com. There is nothing wrong
with this. These records are NOT GLUE records. Only parent servers
return GLUE records.
That being said there would be a error condition if the address
(A/) record for ns1.hostwizard.com didn't exist except as glue.
The way to check for that is to make a query for ns1.hostwizard.com
and follow all the delegations until you get to the zone that serves
ns1.hostwizard.com.
Modern versions of named attempt to detect glue only delegations
and refuse to load zones that contain have them.
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
Re: stub zone and dnssec processing fails?
On Fri, 2 Oct 2009, Mark Andrews wrote:
zone "ca." IN {
type stub;
masters { 192.228.22.190; 192.228.22.189; };
};
To make the test signed ca work you need to replace the NS RRet
with the names of the nameservers that serve the signed CA zone.
At the moment you end up with those that server unsigned content
which is correctly rejected. Stubs pre-populate the delegation,
they do not override the delegation.
It seems that using a forward type zone does work:
zone "ca." IN {
type forward;
forwarders { 66.241.135.248; 193.110.157.136; };
};
dig +dnssec -t ds xelerance.ca. @localhost
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 12, ADDITIONAL: 1
I had tried it before and it failed. Must have been an operator error.
Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind, dnssec, udp fragmentation woes.
You really want to work out what is being blocked, EDNS?, responses bigger that 512 bytes? DNSSEC? fragmented responses? With a clean path all of these should succeed but only the last one won't have "tc" set. This does a plain DNS query, a EDNS query that limits the response to 512 bytes, a DNSSEC query that limits the response to 512 bytes, a DNSSEC query that limits the response to something that would not normally be fragmented but exceeds 512 bytes, a DNSSEC query that will normally be fragmented. % dig soa se @192.36.133.107 +norec +ignore % dig soa se @192.36.133.107 +norec +ignore +bufsize=512 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=1200 +dnssec % dig dnskey se @192.36.133.107 +norec +ignore +bufsize=4096 +dnssec Named does the following by default. Ensure you have a up to date version of namesd dig dnskey se @192.36.133.107 +norec +ignore +bufsize=4096 +dnssec dig dnskey se @192.36.133.107 +norec +ignore +bufsize=512 +dnssec dig dnskey se @192.36.133.107 +norec +ignore 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
Re: Glue record miunderstanding
Yeah, I just ran a few queries and can't figure out what exactly it's
complaining about.
Matt
It's making a observation ("i" in a blue circle) that there were
not additional records for ns1.nacio.com being returned by
ns1.hostwizard.com presumable because ns1.hostwizard.com doesn't
serve the zone that contains ns1.nacio.com. There is nothing wrong
with this. These records are NOT GLUE records. Only parent servers
return GLUE records.
That being said there would be a error condition if the address
(A/) record for ns1.hostwizard.com didn't exist except as glue.
The way to check for that is to make a query for ns1.hostwizard.com
and follow all the delegations until you get to the zone that serves
ns1.hostwizard.com.
Modern versions of named attempt to detect glue only delegations
and refuse to load zones that contain have them.
Thank you for the explanation Mark. Also I was not aware that newer
versions of named would refuse to load zones that were in error of
glue only. This is good to know. Thank you.
--
Scott * If you contact me off list replace talklists@ with scott@ *
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Glue record miunderstanding
> On 01-Oct-2009, at 16:03, Scott Haneda wrote: >> Is it also correct, I only need a NS glue record for the actual NS >> itself. There does not need to be a glue record for very zone that I >> am providing DNS for? On 01.10.09 18:25, Matthew Pounsett wrote: > The only case where glue *must* be present is when a nameserver name is a > subdomain of the zone it's authoritative for. > > So, if ns1.example.com is one of the nameservers for example.com, then > there must be glue in the com zone. In all other cases it is not > required. However, some registries may include glue even when its not > necessary, since it simplifies the logic of generating their zone. and often breaks when the A record of nameserver changes. > To check if glue is present, ask your parent's nameservers for some > record inside your zone. When you get back the delegation response, if > glue is present it'll be included in the ADDITIONAL section. to check if glue is present in the zone, you usually must see the zone. the exception is when you know that the server doesn't have any other zones loaded where the record could appear. > Here's a real-world example. In this case, glue is unnecessary in the > com zone, but Verisign is including it anyway: > > 18:24:04 % dig +norec IN A www.example.com @a.gtld-servers.net > ;; AUTHORITY SECTION: > example.com. 172800 IN NS a.iana-servers.net. > example.com. 172800 IN NS b.iana-servers.net. > > ;; ADDITIONAL SECTION: > a.iana-servers.net. 172800 IN A 192.0.34.43 > b.iana-servers.net. 172800 IN A 193.0.0.236 the server returns glue records in additional section because it's also authoritative for .net and iana-servers.net has those glue records in .net zone. Therefore server constructed response of all data it has loaded: % dig any iana-servers.net. @a.gtld-servers.net ;; ANSWER SECTION: iana-servers.net. 172800 IN NS a.iana-servers.net. iana-servers.net. 172800 IN NS b.iana-servers.org. iana-servers.net. 172800 IN NS c.iana-servers.net. iana-servers.net. 172800 IN NS d.iana-servers.net. iana-servers.net. 172800 IN NS ns.icann.org. ;; ADDITIONAL SECTION: a.iana-servers.net. 172800 IN A 192.0.34.43 c.iana-servers.net. 172800 IN A 139.91.1.10 d.iana-servers.net. 172800 IN A 208.77.188.44 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
