Perhaps a real example would help.
Here is an example of a captive portal root domain. Everything goes to .25
. A 141.211.7.25
*. A 141.211.7.25
But I need everything except one host, dns1.itd.umich.edu, so I need
wildcards
Sorry, I hadn’t done a series of webinars before and hadn’t realized the
constant reminders are the default setting. I just turned them off. Thank you
for letting us know these are annoying.
Vicky
> On Feb 11, 2020, at 10:32 AM, Jim Popovitch via bind-users
> wrote:
>
> First, I love it
First, I love it that ISC does these informative sessions.
However, why send out iCal/Calendar instructions AND then send me emails
1 day and 1 hour before each session?
I don't want to cancel my registration, but I do want to cancel the
constant email reminders. Help!
-Jim P.
Oh, that explains it, I didn't know there is such a thing as "empty
domain", thanks!
On 11/02/2020 16:33, Matus UHLAR - fantomas wrote:
On 11.02.20 15:58, Petr Bena wrote:
for example test.prod.app.pcp.cn.prod
step 2) search the available zones - the zone in question here is
pcp.cn.prod
The wildcard doesn’t cover empty non terminals.
The only nonstandard implementation that did this was djbdns and the behavior
was considered to be incompatible with rest of the DNS implementations.
Ondrej
--
Ondřej Surý — ISC
> On 11 Feb 2020, at 15:59, Petr Bena wrote:
>
> Hello,
>
> I
On 11.02.20 15:58, Petr Bena wrote:
for example test.prod.app.pcp.cn.prod
step 2) search the available zones - the zone in question here is
pcp.cn.prod which is found
step 3) no matching name is found but *.prod.app exists inside of
pcp.cn.prod which is returned
However, with
On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer wrote:
>
> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> Warren Kumari wrote
> a message of 70 lines which said:
>
> > Also, can you try:
> > dig +tcp . axfr @192.0.32.132
> > dig +tcp . axfr @192.0.47.132
> > dig +tcp . axfr
Hello,
I fail to see that:
for example test.prod.app.pcp.cn.prod
step 2) search the available zones - the zone in question here is
pcp.cn.prod which is found
step 3) no matching name is found but *.prod.app exists inside of
pcp.cn.prod which is returned
However, with
Yes, this is standard behaviour. It falls out of this section of RFC 1034
which is part of STD 13 (DNS). Work the algorithm by hand with the records
you said existed in the zone.
4.3.2. Algorithm
The actual algorithm used by the name server will depend on the local OS
and data structures used
But, is this behaviour consistent with other DNS software (microsoft DNS
etc.), or is this specific only to BIND9?
Is there any standard / documentation that explain how or why is this
happening? Because it just doesn't make any sense to me.
On 11/02/2020 14:39, Tony Finch wrote:
Petr Bena
Hi,
> So maybe try setting `request-ixfr no;` and see if that improves matters.
Nope, didn't change anything. Also, I was wrong when I stated that dig works,
it does not. It transfers only a part of the zone as well.
However, in the meantime we found, that some component drops packets. I
Petr Bena wrote:
>
> Why is this? Is that normal or a bug?
It's because wildcards in the DNS are crazy and totally abnormal, but
sadly ossified tradition means it cannot be considered a bug. (It's also
intimately tied up with the subtle semantics of NXDOMAIN, and rigidly
enforced by DNSSEC.)
Hello,
I observed very weird behaviour that I can reproduce on both these BIND9
versions:
BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version)
(slave)
BIND 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 (master)
Someone has created a wildcard CNAME:
*.prod.app.pcp.cn.prod. 300
Warren Kumari wrote:
> von Dein, Thomas wrote:
> >
> > Does anyone have an idea, what's wrong here and how I could possibly fix
> > this?
>
> This sounds very much like a path MTU issue -- it starts the transfer,
> gets part of the way and then a big packet doesn't make it through...
I
On Mon, Feb 10, 2020 at 02:32:55PM -0500,
Warren Kumari wrote
a message of 70 lines which said:
> Also, can you try:
> dig +tcp . axfr @192.0.32.132
> dig +tcp . axfr @192.0.47.132
> dig +tcp . axfr @b.root-servers.net
>
> (no, I'm not really sure why trying with the first 2 IPs instead of
>
15 matches
Mail list logo
