Apologies for the double post, I was not finished with edits in my
previous post:
> John Levine wrote:
> > >It is true at first glance the regex-esque syntax in our I-D may seem
> > >a bit complex but I don't believe anywhere near the complexity of
> > >NAPTR
> >
> > None of the complexity of NAPT
> John Levine wrote:
> > >It is true at first glance the regex-esque syntax in our I-D may seem
> > >a bit complex but I don't believe anywhere near the complexity of
> > >NAPTR
> >
> > None of the complexity of NAPTR is in the DNS or the DNS servers; it's
> > all in the applications that use NAPTR
John Levine wrote:
> >It is true at first glance the regex-esque syntax in our I-D may seem a
> >bit complex but I don't believe anywhere near the complexity of NAPTR
>
> None of the complexity of NAPTR is in the DNS or the DNS servers; it's
> all in the applications that use NAPTR. For DNS serve
>It is true at first glance the regex-esque syntax in our I-D may seem a
>bit complex but I don't believe anywhere near the complexity of NAPTR
None of the complexity of NAPTR is in the DNS or the DNS servers; it's
all in the applications that use NAPTR. For DNS servers, NAPTR is
just a record it
Woodworth, John R wrote:
> I respectfully disagree. I, although naturally biased, feel
> strongly our I-D is something which should have existed since the
> beginning of DNS. It allows address space to be "tagged" and
> organized in a manner that just makes sense.
>
> Imagine if you will a class
> John R. Levine wrote:
> > > Just curious, is there a fundamental reason you have to oppose this
> > > beyond simply the scale?
> >
> > It's a cargo cult style extension of a not particularly useful IPv4
> > convention to IPv6. A much more useful convention that happens to be
> > easier to implem
PS:
>I understand rwhois exists but it is much more complicated to manage
>than DNS and for the most part is only used at the RIR level for
>reverse IP namespace.
This would probably be a good time to read up on RDAP.
R's,
John
___
Please visit https:/
>beginning of DNS. It allows address space to be "tagged" and
>organized in a manner that just makes sense.
We'll have to agree to violently disagree at this point.
R's,
John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubsc
>Though, if you want to participate in the cargo cult of generic PTRs,
>you don't need the complexity of draft-woodworth-bulk-rr's regex-driven
>templates in your nameserver. Knot DNS's "minimal viable product"
>implementation is ~300 SLOC and uses a hardcoded template.
Having looked at the draft,
> > Just curious, is there a fundamental reason you have to oppose this
> > beyond simply the scale?
>
> It's a cargo cult style extension of a not particularly useful IPv4
> convention to IPv6. A much more useful convention that happens to
> be easier to implement is that hosts with static addres
John R. Levine wrote:
> > Just curious, is there a fundamental reason you have to oppose this
> > beyond simply the scale?
>
> It's a cargo cult style extension of a not particularly useful IPv4
> convention to IPv6. A much more useful convention that happens to be easier
> to implement is that h
Just curious, is there a fundamental reason you have to oppose this
beyond simply the scale?
It's a cargo cult style extension of a not particularly useful IPv4
convention to IPv6. A much more useful convention that happens to be
easier to implement is that hosts with static addresses have rD
> I'll let the market decide. For now, such a requirement isn't even
> a blip on the horizon as far as I can see.
Understood. I guess we all have our own perspective and priorities.
There are, however, several popular commercial DNS vendors I know
first hand which are offering their own propriet
> > We're still in the early phases of IPv6. If sufficient ISPs drop PTR
> > for dynamic IPv6 addresses, email providers and others who base some
> > sort of "reputation" on IPv4 PTRs today will simply have to adapt.
>
>
> Steinar,
>
> I think this is bigger than anti-spam logic. Simply put: Cu
> > Simply pretending a shark doesn't exist offers very little in shark
> > protection. While I understand this school of thought I don't believe
> > it will solve the problem or remove the need.
>
> We're still in the early phases of IPv6. If sufficient ISPs drop PTR
> for dynamic IPv6 addresses,
> > >A very popular option is to only create or delegate IPv6 PTR entries
> > >for hosts with static address assignments, and to return NXDOMAIN for
> > >address space used for dynamic address assignments.
> >
> > I talk to a lot of large providers at M3AAWG and that's the consensus
> > about what
>
> >A very popular option is to only create or delegate IPv6 PTR entries
> >for hosts with static address assignments, and to return NXDOMAIN for
> >address space used for dynamic address assignments.
>
> I talk to a lot of large providers at M3AAWG and that's the consensus
> about what to do. If
>A very popular option is to only create or delegate IPv6 PTR entries for
>hosts with static address assignments, and to return NXDOMAIN for
>address space used for dynamic address assignments.
I talk to a lot of large providers at M3AAWG and that's the consensus
about what to do. If it doesn't h
Tom wrote:
> This is the configuration-option, where I'm searching for. But probably this
> will take some time, until it's accepted, tested, implemented...etc. What do
> you propose in the meantime instead of using wildcards or allow the clients
> to register themselves or making static PTR-entrie
On 26.08.16 07:34, Tom Tom wrote:
I'm searching a way to respond to IPv6-PTR-Queries like the
"$GENERATE"-mechanism for IPv4 has done it.
On 26 August 2016 at 13:45, Matus UHLAR - fantomas
wrote:
why? configuring single IP addresses or taking them from DHCP is easier
than creating new useles
On 26 August 2016 at 15:41, Matus UHLAR - fantomas
wrote:
>
>>> On 26.08.16 14:01, Matthew Pounsett wrote:
>
>> That's not necessarily true for IPv6, where even a modest network could
>> have trillions of addresses that may need PTR records.
>>
>
> that's exactly why using $GENERATE and/or creati
On 26 August 2016 at 13:45, Matus UHLAR - fantomas
wrote:
> On 26.08.16 07:34, Tom Tom wrote:
>
>> I'm searching a way to respond to IPv6-PTR-Queries like the
>> "$GENERATE"-mechanism for IPv4 has done it.
>>
>
> why? configuring single IP addresses or taking them from DHCP is easier
> than
> cre
On 26.08.16 07:34, Tom Tom wrote:
I'm searching a way to respond to IPv6-PTR-Queries like the
"$GENERATE"-mechanism for IPv4 has done it.
why? configuring single IP addresses or taking them from DHCP is easier than
creating new useless mechanism.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ;
Hello Tom
I only know of Knot having a feature available for this use case:
https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records
Daniel
On 26.08.16 11:51, Tom wrote:
> Many thanks for your quick feedback.
>
> This is the configuration-option,
Many thanks for your quick feedback.
This is the configuration-option, where I'm searching for. But probably
this will take some time, until it's accepted, tested,
implemented...etc. What do you propose in the meantime instead of using
wildcards or allow the clients to register themselves or m
> Hi list
>
> I'm searching a way to respond to IPv6-PTR-Queries like the "$GENERATE"
> -mechanism for IPv4 has done it.
>
> I read about Delegation, self-registration with "tcp-self" or using
> Wildcards with the disadvantage, that every query has the same response.
> Is there a (planned) way, to
Hi list
I'm searching a way to respond to IPv6-PTR-Queries like the
"$GENERATE"-mechanism for IPv4 has done it.
I read about Delegation, self-registration with "tcp-self" or using
Wildcards with the disadvantage, that every query has the same
response. Is there a (planned) way, to generate revers
27 matches
Mail list logo
