Re: Wildcard oddity
On Mon, Sep 29, 2014 at 08:52:41PM -0700, Ronald F. Guilmette wrote: > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > ; *.purple.colors IN A 127.0.0.4 > === > > Note that that last line is commented out. > > Curiously, when I do this query: > >dig simon.purple.colors.test0.tristatelogic.com > > I get back NXDOMAIN. Why? > > Intutively I would have thought that this query would have been matched > by "*.colors", but the presence of jason seems to be throwing a monkey > wrench into the works for simon! See RFC 1034 section 4.3.3: Wildcard RRs do not apply: - When the query name or a name between the wildcard domain and the query name is know to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X. Also see RFC 4592 section 2.2.2 (empty non-terminals) which would apply above and make purple.colors.test0.tristatelogic.com "exist". Mukund pgpLT8asSUKv0.pgp Description: PGP signature ___ 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: Wildcard oddity
In message <20703.1412049...@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > > My apologies for my earlier, arguably off-topic questions. > > Now I have a real honest-to-goodness BIND question. > > I have the following simple zone file installed as "test0.tristatelogic.com": > > === > $TTL 3600 > @ IN SOA server1.tristatelogic.com. hostmaster.tristatelogic.c > om. ( > 1412047583 10800 3600 604800 3600 ) > IN NS server1.tristatelogic.com. > > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > ; *.purple.colors IN A 127.0.0.4 > === > > Note that that last line is commented out. > > Curiously, when I do this query: > >dig simon.purple.colors.test0.tristatelogic.com > > I get back NXDOMAIN. Why? Because that is how wildcard processing works. Go read RFC 1034, Section 4.3.2. Algorithm. Note the words "label by label". Does the label colors exist? Does the label purple exist? Does the label simon exist? Does the label "*" exist? Mark > Intutively I would have thought that this query would have been matched > by "*.colors", but the presence of jason seems to be throwing a monkey > wrench into the works for simon! > > It is also rather perplexing that when I uncomment that final line, > then things seem to work as expected, i.e. the dig shown above then > matches _that_ record, and I get back 127.0.0.4 (which is indeed > what intutively _should_ happen). > > There must be something quirky about the wildcard matching rules that > I'm not understanding. Why do these two rules cause something (i.e. > anything) within the colors subdomain to *not* resolve? > > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > > ___ > 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
Wildcard oddity
My apologies for my earlier, arguably off-topic questions. Now I have a real honest-to-goodness BIND question. I have the following simple zone file installed as "test0.tristatelogic.com": === $TTL 3600 @ IN SOA server1.tristatelogic.com. hostmaster.tristatelogic.com. ( 1412047583 10800 3600 604800 3600 ) IN NS server1.tristatelogic.com. *.colors IN A 127.0.0.2 *.jason.purple.colors IN A 127.0.0.3 ; *.purple.colors IN A 127.0.0.4 === Note that that last line is commented out. Curiously, when I do this query: dig simon.purple.colors.test0.tristatelogic.com I get back NXDOMAIN. Why? Intutively I would have thought that this query would have been matched by "*.colors", but the presence of jason seems to be throwing a monkey wrench into the works for simon! It is also rather perplexing that when I uncomment that final line, then things seem to work as expected, i.e. the dig shown above then matches _that_ record, and I get back 127.0.0.4 (which is indeed what intutively _should_ happen). There must be something quirky about the wildcard matching rules that I'm not understanding. Why do these two rules cause something (i.e. anything) within the colors subdomain to *not* resolve? *.colors IN A 127.0.0.2 *.jason.purple.colors IN A 127.0.0.3 ___ 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: Diagnostic help
So if my server is authoritative for MyDomain.com, should Joe Sixpak be
able to resolve it via whatever DNS he's using, as mine is currently set up?
Do I need to change it to
|allow-query { any; };|
in order to allow that to happen? Will my restriction on recursion keep
the riffraff to a minimum?
Thanks.
On 9/29/14, 7:58 PM, Ben Croswell wrote:
The default for allow query is local host local nets. Basically the
server itself and directly connected networks
On Sep 29, 2014 8:03 PM, "Bill Christensen"
mailto:billc_li...@greenbuilder.com>>
wrote:
Hi folks,
Something got sideways on one of my DNS servers, and I would
appreciate some help in figuring out what's going on.
I'm running BIND 9.10.1. This server is authoritative master for
a number of domains.
First off, I may have the allow-query set incorrectly. Currently I
have:
acl query-permit {
(range of IP address on the local LAN which are allowed to use
this server as their query server)
};
acl recursive-permit {
(range of IP address on the local LAN which are allowed to use
this server for recursive queries)
};
acl transfer-permit {
(IP addresses of a couple other name servers allowed to do
transfers with this one)
};
and at the beginning of the options section:
allow-recursion { recursive-permit; };
allow-transfer { transfer-permit; };
// allow-query { query-permit; };
Allow-query is commented out, which I assume will allow anyone to
query this server for the domains for which it has master or slave
records, but does not allow the general public to do recursive
queries or queries on domains not hosted here.
Let me know if I've got that right, or how to correct it if I don't.
If this part is correct I'll continue the questioning.
Thanks!
___
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
___
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: Diagnostic help
The default for allow query is local host local nets. Basically the server
itself and directly connected networks
On Sep 29, 2014 8:03 PM, "Bill Christensen"
wrote:
> Hi folks,
>
> Something got sideways on one of my DNS servers, and I would appreciate
> some help in figuring out what's going on.
>
> I'm running BIND 9.10.1. This server is authoritative master for a number
> of domains.
>
> First off, I may have the allow-query set incorrectly. Currently I have:
>
> acl query-permit {
> (range of IP address on the local LAN which are allowed to use this
> server as their query server)
> };
>
> acl recursive-permit {
> (range of IP address on the local LAN which are allowed to use this
> server for recursive queries)
> };
>
> acl transfer-permit {
> (IP addresses of a couple other name servers allowed to do transfers
> with this one)
> };
>
> and at the beginning of the options section:
>
> allow-recursion { recursive-permit; };
> allow-transfer { transfer-permit; };
> // allow-query { query-permit; };
>
> Allow-query is commented out, which I assume will allow anyone to query
> this server for the domains for which it has master or slave records, but
> does not allow the general public to do recursive queries or queries on
> domains not hosted here.
>
> Let me know if I've got that right, or how to correct it if I don't.
>
> If this part is correct I'll continue the questioning.
>
> Thanks!
>
>
>
>
> ___
> 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
>
___
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
Diagnostic help
Hi folks,
Something got sideways on one of my DNS servers, and I would appreciate
some help in figuring out what's going on.
I'm running BIND 9.10.1. This server is authoritative master for a
number of domains.
First off, I may have the allow-query set incorrectly. Currently I have:
acl query-permit {
(range of IP address on the local LAN which are allowed to use this
server as their query server)
};
acl recursive-permit {
(range of IP address on the local LAN which are allowed to use this
server for recursive queries)
};
acl transfer-permit {
(IP addresses of a couple other name servers allowed to do
transfers with this one)
};
and at the beginning of the options section:
allow-recursion { recursive-permit; };
allow-transfer { transfer-permit; };
// allow-query { query-permit; };
Allow-query is commented out, which I assume will allow anyone to query
this server for the domains for which it has master or slave records,
but does not allow the general public to do recursive queries or queries
on domains not hosted here.
Let me know if I've got that right, or how to correct it if I don't.
If this part is correct I'll continue the questioning.
Thanks!
___
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: Maximum DNS packet size?
In message <70279.1412020...@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > My apologies if this question might also be considered a bit > off-topic for this list. > > Is the maximum possible size of a DNS packet (just the payload part... > not including IP and UDP headers) 64k bytes? > > I have some old code which assumes that, perhaps incorrectly. DNS UDP message size can be up to 512 bytes. RFC 103[45] EDNS UDP message size can be up to 65535 bytes less overhead but most implementations advertise a much smaller size (~4K). RFC 6891 TCP message size can be up to 65535 bytes as there is a 2 octet header specifying the size of the TCP DNS message. RFC 103[45] Mark > ___ > 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
Maximum DNS packet size?
My apologies if this question might also be considered a bit off-topic for this list. Is the maximum possible size of a DNS packet (just the payload part... not including IP and UDP headers) 64k bytes? I have some old code which assumes that, perhaps incorrectly. ___ 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: Punycode questions
In message , Tony Finch wrote: >Ronald F. Guilmette wrote: >> To be more specific and concrete about it, here is a small >> example Perl program I wrote: >> >>ftp://ftp.tristatelogic.com/pub/punybug.pl >> >> When *I* run this, it prints out several "Invalid punycode!" >> errors. > >I think that is because the function you are calling is intended for >encoding individual labels, not whole domain names. Quite right sir! Thanks for the tip! Re-reading the man pages just now I see that I was using the incorrect function for the conversion. I was using the Net::IDN::Punycode::encode_punycode but apparently I really should instead be using Net::IDN::Encode::domain_to_ascii which is apparently the thing that should be used for converting complete domain names. (Unfortunately, I've still got problems, even now that I'm using the correct function, but those are probably due to me having failed to upgrade my FreeBSD ports for some time now.) ___ 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: Punycode questions
Ronald F. Guilmette wrote: > > In a nutshell, I'd just like to know whether or not Punycode > encoded strings may ever validly contain either (a) leading > periods or else (b) two consecutive periods. Would any strings > that contain either of those things be considered to be "valid" > Punycode encoded strings? No. For details see RFCs 5891, 5892, and 3492. > To be more specific and concrete about it, here is a small > example Perl program I wrote: > >ftp://ftp.tristatelogic.com/pub/punybug.pl > > When *I* run this, it prints out several "Invalid punycode!" > errors. I think that is because the function you are calling is intended for encoding individual labels, not whole domain names. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. 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
